R Data Frames meistern mit dplyr – Teil 2

Dieser Artikel ist Teil 2 von 2 aus der Artikelserie R Data Frames meistern mit dplyr.

Noch mehr Datenbank-Features

Im ersten Teil dieser Artikel-Serie habe ich die Parallelen zwischen Data Frames in R und Relationen in SQL herausgearbeitet und gezeigt, wie das Paket dplyr eine Reihe von SQL-analogen Operationen auf Data Frames standardisiert und optimiert. In diesem Teil möchte ich nun drei weitere Analogien aufzeigen. Es handelt sich um die

  • Window Functions in dplyr als Entsprechung zu analytischen Funktionen in SQL,
  • Joins zwischen Data Frames als Pendant zu Tabellen-Joins
  • Delegation von Data Frame-Operationen zu einer bestehenden SQL-Datenbank

Window Functions

Im letzten Teil habe ich gezeigt, wie durch die Kombination von group_by() und summarise() im Handumdrehen Aggregate entstehen. Das Verb group_by() schafft dabei, wie der Name schon sagt, eine Gruppierung der Zeilen des Data Frame anhand benannter Schlüssel, die oft ordinaler oder kategorialer Natur sind (z.B. Datum, Produkt oder Mitarbeiter).

Ersetzt man die Aggregation mit summarise() durch die Funktion mutate(), um neue Spalten zu bilden, so ist der Effekt des group_by() weiterhin nutzbar, erzeugt aber „Windows“, also Gruppen von Datensätzen des Data Frames mit gleichen Werten der Gruppierungskriterien. Auf diesen Gruppen können nun mittels mutate() beliebige R-Funktionen angewendet werden. Das Ergebnis ist im Gegensatz zu summarise() keine Verdichtung auf einen Datensatz pro Gruppe, sondern eine Erweiterung jeder einzelnen Zeile um neue Werte. Das soll folgendes Beispiel verdeutlichen:

Das group_by() unterteilt den Data Frame nach den 4 gleichen Werten von a. Innerhalb dieser Gruppen berechnen die beispielsweise eingesetzten Funktionen

  • row_number(): Die laufende Nummer in dieser Gruppe
  • n(): Die Gesamtgröße dieser Gruppe
  • n_distinct(b): Die Anzahl verschiedener Werte von b innerhalb der Gruppe
  • rank(desc(b)): Den Rang innerhalb der selben Gruppe, absteigend nach b geordnet
  • lag(b): Den Wert von b der vorherigen Zeile innerhalb derselben Gruppe
  • lead(b): Analog den Wert von b der folgenden Zeile innerhalb derselben Gruppe
  • mean(b): Den Mittelwert von b innerhalb der Gruppe
  • cumsum(b): Die kumulierte Summe der b-Werte innerhalb der Gruppe.

Wichtig ist hierbei, dass die Anwendung dieser Funktionen nicht dazu führt, dass die ursprüngliche Reihenfolge der Datensätze im Data Frame geändert wird. Hier erweist sich ein wesentlicher Unterschied zwischen Data Frames und Datenbank-Relationen von Vorteil: Die Reihenfolge von Datensätzen in Data Frames ist stabil und definiert. Sie resultiert aus der Abfolge der Elemente auf den Vektoren, die die Data Frames bilden. Im Gegensatz dazu haben Tabellen und Views keine Reihenfolge, auf die man sich beim SELECT verlassen kann. Nur mit der ORDER BY-Klausel über eindeutige Schlüsselwerte erreicht man eine definierte, stabile Reihenfolge der resultierenden Datensätze.

Die Wirkungsweise von Window Functions wird noch besser verständlich, wenn in obiger Abfrage das group_by(a) entfernt wird. Dann wirken alle genannten Funktionen auf der einzigen Gruppe, die existiert, nämlich dem gesamten Data Frame:

Anwendbar sind hierbei sämtliche Funktionen, die auf Vektoren wirken. Diese müssen also wie in unserem Beispiel nicht unbedingt aus dplyr stammen. Allerdings komplettiert das Package die Menge der sinnvoll anwendbaren Funktionen um einige wichtige Elemente wie cumany() oder n_distinct().

Data Frames Hand in Hand…

In relationalen Datenbanken wird häufig angestrebt, das Datenmodell zu normalisieren. Dadurch bekommt man die negativen Folgen von Datenredundanz, wie Inkonsistenzen bei Datenmanipulationen und unnötig große Datenvolumina, in den Griff. Dies geschieht unter anderem dadurch, dass tabellarische Datenbestände aufgetrennt werden Stammdaten- und Faktentabellen. Letztere beziehen sich über Fremdschlüsselspalten auf die Primärschlüssel der Stammdatentabellen. Durch Joins, also Abfragen über mehrere Tabellen und Ausnutzen der Fremdschlüsselbeziehungen, werden die normalisierten Tabellen wieder zu einem fachlich kompletten Resultat denormalisiert.

In den Data Frames von R trifft man dieses Modellierungsmuster aus verschiedenen Gründen weit seltener an als in RDBMS. Dennoch gibt es neben der Normalisierung/Denormalisierung andere Fragestellungen, die sich gut durch Joins beantworten lassen. Neben der Zusammenführung von Beobachtungen unterschiedlicher Quellen anhand charakteristischer Schlüssel sind dies bestimmte Mengenoperationen wie Schnitt- und Differenzmengenbildung.

Die traditionelle R-Funktion für den Join zweier Data Frames lautet merge(). dplyr erweitert den Funktionsumfang dieser Funktion und sorgt für sprechendere Funktionsnamen und Konsistenz mit den anderen Operationen.

Hier ein synthetisches Beispiel:

Nun gilt es, die Verkäufe aus dem Data Frame sales mit den Produkten in products zusammenzuführen und auf Basis von Produkten Bilanzen zu erstellen. Diese Denormalisierung geschieht durch das Verb inner_join() auf zweierlei Art und Weise:

Die Ergebnisse sind bis auf die Reihenfolge der Spalten und der Zeilen identisch. Außerdem ist im einen Fall der gemeinsame Schlüssel der Produkt-Id als prod_id, im anderen Fall als id enthalten. dplyr entfernt also die Spalten-Duplikate der Join-Bedingungen. Letzere wird bei Bedarf im by-Argument der Join-Funktion angegeben. R-Experten erkennen hier einen „Named Vector“, also einen Vektor, bei dem jedes Element einen Namen hat. Diese Syntax verwendet dplyr, um elegant die äquivalenten Spalten zu kennzeichnen. Wird das Argument by weggelassen, so verwendet dplyr im Sinne eines „Natural Join“ automatisch alle Spalten, deren Namen in beiden Data Frames vorkommen.

Natürlich können wir dieses Beispiel mit den anderen Verben erweitern, um z.B. eine Umsatzbilanz pro Produkt zu erreichen:

dplyr bringt insgesamt 6 verschiedene Join-Funktionen mit: Neben dem bereits verwendeten Inner Join gibt es die linksseitigen und rechtsseitigen Outer Joins und den Full Join. Diese entsprechen genau der Funktionalität von SQL-Datenbanken. Daneben gibt es die Funktion semi_join(), die in SQL etwa folgendermaßen ausgedrückt würde:

Das Gegenteil, also ein NOT EXISTS, realisiert die sechste Join-Funktion: anti_join(). Im folgenden Beispiel sollen alle Produkte ausgegeben werden, die noch nie verkauft wurden:

… und in der Datenbank

Wir schon mehrfach betont, hat dplyr eine Reihe von Analogien zu SQL-Operationen auf relationalen Datenbanken. R Data Frames entsprechen Tabellen und Views und die dplyr-Operationen den Bausteinen von SELECT-Statements. Daraus ergibt sich die Möglichkeit, dplyr-Funktionen ohne viel Zutun auf eine bestehende Datenbank und deren Relationen zu deligieren.

Mir fallen folgende Szenarien ein, wo dies sinnvoll erscheint:

  • Die zu verarbeitende Datenmenge ist zu groß für das Memory des Rechners, auf dem R läuft.
  • Die interessierenden Daten liegen bereits als Tabellen und Views auf einer Datenbank vor.
  • Die Datenbank hat Features, wie z.B. Parallelverarbeitung oder Bitmap Indexe, die R nicht hat.

In der aktuellen Version 0.5.0 kann dplyr nativ vier Datenbank-Backends ansprechen: SQLite, MySQL, PostgreSQL und Google BigQuery. Ich vermute, unter der Leserschaft des Data Science Blogs dürfte MySQL (oder der Fork MariaDB) die weiteste Verbreitung haben, weshalb ich die folgenden Beispiele darauf zeige. Allerdings muss man beachten, dass MySQL keine Window Funktionen kennt, was sich 1:1 auf die Funktionalität von dplyr auswirkt.

Im folgenden möchte ich zeigen, wie dplyr sich gegen eine bestehende MySQL-Datenbank verbindet und danach einen bestehenden R Data Frame in eine neue Datenbanktabelle wegspeichert:

Die erste Anweisung verbindet R mit einer bestehenden MySQL-Datenbank. Danach lade ich den Data Frame diamonds aus dem Paket ggplot2. Mit str() wird deutlich, dass drei darin enthaltene Variablen vom Typ Factor sind. Damit dplyr damit arbeiten kann, werden sie mit mutate() in Character-Vektoren gewandelt. Dann erzeugt die Funktion copy_to() auf der MySQL-Datenbank eine leere Tabelle namens diamonds, in die die Datensätze kopiert werden. Danach erhält die Tabelle noch drei Indexe (von dem der erste aus drei Segmenten besteht), und zum Schluß führt dplyr noch ein ANALYSE der Tabelle durch, um die Werteverteilungen auf den Spalten für kostenbasierte Optimierung zu bestimmen.

Meistens aber wird bereits eine bestehende Datenbanktabelle die interessierenden Daten enthalten. In diesem Fall lautet die Funktion zum Erstellen des Delegats tbl():

Die Rückgabewerte von copy_to() und von tbl() sind natürlich keine reinrassigen Data Frames, sondern Objekte, auf die die Operationen von dplyr wirken können, indem sie auf die Datenbank deligiert werden. Im folgenden Beispiel sollen alle Diamanten, die ein Gewicht von mindestens 1 Karat haben, pro Cut, Color und Clarity nach Anzahl und mittlerem Preis bilanziert werden:

Die Definition der Variablen bilanz geschieht dabei komplett ohne Interaktion mit der Datenbank. Erst beim Anzeigen von Daten wird das notwendige SQL ermittelt und auf der DB ausgeführt. Die ersten 10 resultierenden Datensätze werden angezeigt. Mittels der mächtigen Funktion explain() erhalten wir das erzeugte SQL-Kommando und sogar den Ausführungsplan auf der Datenbank. SQL-Kundige werden erkennen, dass die verketteten dplyr-Operationen in verschachtelte SELECT-Statements umgesetzt werden.

Zu guter Letzt sollen aber meistens die Ergebnisse der dplyr-Operationen irgendwie gesichert werden. Hier hat der Benutzer die Wahl, ob die Daten auf der Datenbank in einer neuen Tabelle gespeichert werden sollen oder ob sie komplett nach R transferiert werden sollen. Dies erfolgt mit den Funktionen compute() bzw. collect():

Durch diese beiden Operationen wurde eine neue Datenbanktabelle „t_bilanz“ erzeugt und danach der Inhalt der Bilanz als Data Frame zurück in den R-Interpreter geholt. Damit schließt sich der Kreis.

Fazit

Mit dem Paket dplyr von Hadley Wickham wird die Arbeit mit R Data Frames auf eine neue Ebene gehoben. Die Operationen sind konsistent, vollständig und performant. Durch den Verkettungs-Operator %>% erhalten sie auch bei hoher Komplexität eine intuitive Syntax. Viele Aspekte der Funktionalität lehnen sich an Relationale Datenbanken an, sodass Analysten mit SQL-Kenntnissen rasch viele Operationen auf R Data Frames übertragen können.

Zurück zu R Data Frames meistern mit dplyr – Teil 1.

 

Was ist eigentlich Apache Spark?

Viele Technologieanbieter versprechen schlüsselfertige Lösungen für Big Data Analytics, dabei kann keine proprietäre Software-Lösung an den Umfang und die Mächtigkeit einiger Open Source Projekten heranreichen.

Seit etwa 2010 steht das Open Source Projekt Hadoop, ein Top-Level-Produkt der Apache Foundation, als einzige durch Hardware skalierbare Lösung zur Analyse von strukturierten und auch unstrukturierten Daten. Traditionell im Geschäftsbereich eingesetzte Datenbanken speichern Daten in einem festen Schema ab, das bereits vor dem Laden der Daten definiert sein muss. Dieses Schema-on-Write-Prinzip stellt zwar sicher, dass Datenformate bekannt und –konflikte vermieden werden. Es bedeutet jedoch auch, dass bereits vor dem Abspeichern bekannt sein muss, um welche Daten es sich handelt und ob diese relevant sind. Im Hadoop File System (HDFS) wird ein Schema für erst bei lesenden Zugriff erstellt.

Apache Spark ist, ähnlich wie Hadoop, dank Parallelisierung sehr leistungsfähig und umfangreich mit Bibliotheken (z. B. für Machine Learning) und Schnittstellen (z. B. HDFS) ausgestattet. Allerdings ist Apache Spark nicht für jede Big Data Analytics Aufgabe die beste Lösung, Als Einstiegslektüre empfiehlt sich das kostenlose Ebook Getting Started with Spark: From Inception to Production. Wer jedoch erstmal wissen möchte, erfährt nachfolgend die wichtigsten Infos, die es über Apache Spark zu wissen gilt.

Was ist Apache Spark?

Apache Spark ist eine Allzweck-Tool zur Datenverarbeitung, eine sogenannte Data Processing Engine. Data Engineers und Data Scientists setzen Spark ein, um äußerst schnelle Datenabfragen (Queries) auf große Datenmengen im Terabyte-Bereich ausführen zu können.

Spark wurde 2013 zum Incubator-Projekt der Apache Software Foundation, eine der weltweit wichtigsten Organisationen für Open Source. Bereits 2014 es wie Hadoop zum Top-Level-Produkt. Aktuell ist Spark eines der bedeutensten Produkte der Apache Software Foundation mit viel Unterstützung von Unternehmen wie etwa Databricks, IBM und Huawei.

Was ist das Besondere an Spark?

Mit Spark können Daten transformiert, zu fusioniert und auch sehr mathematische Analysen unterzogen werden.
Typische Anwendungsszenarien sind interactive Datenabfragen aus verteilten Datenbeständen und Verarbeitung von fließenden Daten (Streaming) von Sensoren oder aus dem Finanzbereich. Die besondere Stärke von Spark ist jedoch das maschinelle Lernen (Machine Learning) mit den Zusätzen MLib (Machine Learning Bibliothek) oder SparkR (R-Bibliotheken direkt unter Spark verwenden), denn im Gegensatz zum MapReduce-Algorithmus von Hadoop, der einen Batch-Prozess darstellt, kann Spark sehr gut iterative Schleifen verarbeiten, die für Machine Learning Algorithmen, z. B. der K-Nearest Neighbor Algorithmus, so wichtig sind.spark-stack

Spark war von Beginn an darauf ausgelegt, Daten dynamisch im RAM (Arbeitsspeicher) des Server-Clusters zu halten und dort zu verarbeiten. Diese sogenannte In-Memory-Technologie ermöglicht die besonders schnelle Auswertung von Daten. Auch andere Datenbanken, beispielsweise SAP Hana, arbeiten In-Memory, doch Apache Spark kombiniert diese Technik sehr gut mit der Parallelisierung von Arbeitsschritten über ein Cluster und setzt sich somit deutlich von anderen Datenbanken ab. Hadoop ermöglicht über MapReduce zwar ebenfalls eine Prallelisierung, allerdings werden bei jedem Arbeitsschrit Daten von einer Festplatte zu einer anderen Festplatte geschrieben. Im Big Data Umfeld kommen aus Kostengründen überwiegend noch mechanisch arbeitende Magnet-Festplatten zum Einsatz, aber selbst mit zunehmender Verbreitung von sehr viel schnelleren SSD-Festplatten, ist der Arbeitsspeicher hinsichtlich der Zeiten für Zugriff auf und Schreiben von Daten unschlagbar. So berichten Unternehmen, die Spark bereits intensiv einsetzen, von einem 100fachen Geschwindigkeitsvorteil gegenüber Hadoop MapReduce.

Spark kann nicht nur Daten im Terabyte, sondern auch im Petabyte-Bereich analysieren, ein entsprechend großes Cluster, bestehend aus tausenden physikalischer oder virtueller Server, vorausgesetzt. Ähnlich wie auch bei Hadoop, skaliert ein Spark-Cluster mit seiner Größe linear in seiner Leistungsfähigkeit. Spark ist neben Hadoop ein echtes Big Data Framework.
Spark bringt sehr viele Bibliotheken und APIs mit, ist ferner über die Programmiersprachen Java, Python, R und Scala ansprechbar – das sind ohne Zweifel die im Data Science verbreitetsten Sprachen. Diese Flexibilität und geringe Rüstzeit rechtfertigt den Einsatz von Spark in vielen Projekten. Es kann sehr herausfordernd sein, ein Data Science Team mit den gleichen Programmiersprachen-Skills aufzubauen. In Spark kann mit mehreren Programmiersprachen gearbeitet werden, so dass dieses Problem teilweise umgangen werden kann.spark-runs-everywhere

In der Szene wird Spark oftmals als Erweiterung für Apache Hadoop betrachtet, denn es greift nahtlos an HDFS an, das Hadoop Distributed File System. Dank der APIs von Spark, können jedoch auch Daten anderer Systeme abgegriffen werden, z. B. von HBase, Cassandra oder MongoDB.

Was sind gängige Anwendungsbeispiele für Spark?

  • ETL / Datenintegration: Spark und Hadoop eignen sich sehr gut, um Daten aus unterschiedlichen Systemen zu filtern, zu bereinigen und zusammenzuführen.
  • Interaktive Analyse: Spark eignet sich mit seinen Abfragesystemen fantastisch zur interaktiven Analyse von großen Datenmengen. Typische Fragestellungen kommen aus dem Business Analytics und lauten beispielsweise, welche Quartalszahlen für bestimmte Vertriebsregionen vorliegen, wie hoch die Produktionskapazitäten sind oder welche Lagerreichweite vorhanden ist. Hier muss der Data Scientist nur die richtigen Fragen stellen und Spark liefert die passenden Antworten.
  • Echtzeit-Analyse von Datenströmen: Anfangs vor allem zur Analyse von Server-Logs eingesetzt, werden mit Spark heute auch Massen von Maschinen- und Finanzdaten im Sekundentakt ausgewertet. Während Data Stream Processing für Hadoop noch kaum möglich war, ist dies für Spark ein gängiges Einsatzgebiet. Daten, die simultan von mehreren Systemen generiert werden, können mit Spark problemlos in hoher Geschwindigkeit zusammengeführt und analysiert werden.
    In der Finanzwelt setzen beispielsweise Kreditkarten-Unternehmen Spark ein, um Finanztransaktionen in (nahezu) Echtzeit zu analysieren und als potenziellen Kreditkartenmissbrauch zu erkennen.
  • Maschinelles Lernen: Maschinelles Lernen (ML – Machine Learning) funktioniert desto besser, je mehr Daten in die ML-Algorithmen einbezogen werden. ML-Algorithmen haben in der Regel jedoch eine intensive, vom Data Scientist betreute, Trainingsphase, die dem Cluster viele Iterationen an Arbeitsschritten auf die großen Datenmengen abverlangen. Die Fähigkeit, Iterationen auf Daten im Arbeitsspeicher, parallelisiert in einem Cluster, durchführen zu können, macht Spark zurzeit zu dem wichtigsten Machine Learning Framework überhaupt.
    Konkret laufen die meisten Empfehlungssysteme (beispielsweise von Amazon) auf Apache Spark.

 

Einführung in WEKA

Waikato Environment for Knowledge Analysis, kurz WEKA, ist ein quelloffenes, umfangreiches, plattformunabhängiges Data Mining Softwarepaket. WEKA ist in Java geschrieben und wurde an der WAIKATO Iniversität entwickelt. In WEKA sind viele wichtige Data Mining/Machine Learning Algorithmen implementiert und es gibt extra Pakete, wie z. B. LibSVM für Support Vector Machines, welches nicht in WEKA direkt implementiert wurde. Alle Einzelheiten zum Installieren und entsprechende Download-Links findet man unter auf der Webseite der Waikato Universität. Zusammen mit der Software wird ein Manual und ein Ordner mit Beispiel-Datensätzen ausgeliefert. WEKA arbeitet mit Datensätzen im sogenannten attribute-relation file format, abgekürzt arff. Das CSV-Format wird aber ebenfalls unterstützt. Eine Datei im arff-Format ist eine ASCI-Textdatei, welche aus einem Header- und einem Datateil besteht. Im Header muss der Name der Relation und der Attribute zusammen mit dem Typ stehen, der Datenteil beginnt mit einem @data-Schlüsselwort. Als Beispiel sei hier ein Datensatz mit zwei Attributen und nur zwei Instanzen gegeben.

WEKA unterstützt auch direktes Einlesen von Daten aus einer Datenbank (mit JDBC) oder URL. Sobald das Tool installiert und gestartet ist, landet man im Hauptmenü von WEKA – WEKA GUI Chooser 1.

Abbildung 1: WEKA GUI Chooser

Abbildung 1: WEKA GUI Chooser

Der GUI Chooser bietet den Einstieg in WEKA Interfaces Explorer, Experimenter, KnowledgeFlow und simple CLI an. Der Explorer ist ein graphisches Interface zum Bearbeiten von Datensätzen, Ausführen von Algorithmen und Visualisieren von den Resultaten. Es ist ratsam, dieses Interface als Erstes zu betrachten, wenn man in WEKA einsteigen möchte. Beispielhaft führen wir jetzt ein paar Algorithmen im Explorer durch.

Der Explorer bietet mehrere Tabs an: Preprocess, Classify, Cluster, Associate, Select attributes und Visualize. Im Preprocess Tab hat man die Möglichkeit Datensätze vorzubereiten. Hier sind zahlreiche Filter zum Präprozessieren von Datensätzen enthalten. Alle Filter sind in supervised und unsupervised unterteilt, je nachdem, ob das Klassenattribut mitbetrachtet werden soll oder nicht. Außerdem kann man entweder Attribute oder Instanzen betrachten, mit Attributen lässt man Filter spaltenweise arbeiten und bei Instanzen reihenweise. Die Auswahl der Filter ist groß, man kann den ausgewählten Datensatz diskretisieren, normalisieren, Rauschen hinzufügen etc. Unter Visualize können z. B. die geladenen Datensätze visualisert werden. Mit Select attributes kann man mithilfe von Attribut Evaluator und Search Method ein genaueres Ergebnis erzielen. Wenn man im Preprocess den Datensatz lädt, erhält man einen Überblick über den Datensatz und dessen Visualisierung. Als Beispiel wird hier der Datensatz diabetes.arff genommen, welcher mit WEKA zusammen ausgeliefert wird. Dieser Datensatz enthält 768 Instanzen mit je 9 Attributen, wobei ein Attribut das Klassenattribut ist. Die Attribute enthalten z. B. Informationen über die Anzahl der Schwangerschaften, diastolischer Blutdruck, BMI usw. Alle Attribute, außer dem Klassenattribut, sind numerisch. Es gibt zwei Klassen tested negativ und tested positiv, welche das Resultat des Testens auf diabetes mellitus darstellen. über Preprocess -> Open File lädt man den Datensatz in WEKA und sieht alle relevanten Informationen wie z. B. Anzahl und Name der Attribute. Nach dem Laden kann der Datensatz klassifiziert werden.

Abbildung 2: Diabetes.arff Datensatz geladen in WEKA

Abbildung 2: Diabetes.arff Datensatz geladen in WEKA

Hierzu einfach auf Classify klicken und unter Choose den gewünschten Algorithmus auswählen. Für diesen Datensatz wählen wir jetzt den Algorithmus kNN (k-Nearest Neighbour). Der Algorithmus klassifiziert das Testobjekt anhand der Klassenzugehörigkeit von den k Nachbarobjekten, die am nähsten zu dem Testobjekt liegen. Die Distanz zwischen den Objekten und dem Testobjekt wird mit einer Ähnlichkeitsmetrik bestimmt, meistens als euklidische oder Manhattan-Distanz. In WEKA ist der Algorithmus unter lazy iBk zu finden. Wenn man auf das Feld neben dem Algorithmusnamen in WEKA mit rechter Maustaste klickt, kann man unter show properties die Werte für den ausgewählten Algorithmus ändern, bei iBk kann man u.A. den Wert für k ändern. Für den ausgewählten Datensatz diabetes.arff stellen wir beispielsweise k = 3 ein und führen die 10-fache Kreuzvalidierung durch, indem wir unter Test Options die Cross Validation auswählen. Nach der Klassifikation werden die Ergebnisse in einer Warhheitsmatrix präsentiert. In unserem Fall sieht diese wie folgt aus:

Die Anzahl der richtig klassifizierten Instanzen beträgt 72.6563 %. Wenn man in der Result list auf den entsprechenden Algorithmus einen Rechtsklick macht, kann man z. B. noch den Fehler der Klassifizierung visualisieren. Entsprechend lassen sich im Explorer unter Cluster Clustering-Algorithmen und unter Associate Assoziationsalgorithmen auf einen ausgewählten Datensatz anwenden. Die restlichen Interfaces von WEKA bieten z. T. die gleiche Funktionalität oder erweitern die Möglichkeiten des Experimentierens, fordern aber mehr Erfahrung und Wissen von dem User. Das Experimenter Interface dient dazu, mehrere Datensätze mit mehreren Algorithmen zu analysieren. Mit diesem Interface kann man groß-skalierte Experimente durchführen. Simple CLI bietet dem User eine Kommandozeile, statt einem graphischen Interface, an.

Erfolgskriterien für Process Mining

Process Mining ist viel mehr als die automatische Erstellung von Prozessmodellen

Process Mining ist auf dem Vormarsch. Durch Process Mining können Unternehmen erkennen, wie ihre Prozesse in Wirklichkeit ablaufen [1]. Die Ergebnisse liefern erstaunliche Einblicke in die Prozessabläufe, die Sie anderweitig nicht bekommen können. Jedoch gibt es auch einige Dinge, die schiefgehen können. In diesem Artikel geben Ihnen Frank van Geffen und Anne Rozinat Tipps, Ratschläge und Hinweise auf typische Fallstricke, damit Ihr erstes Process-Mining-Projekt so erfolgreich wie möglich wird. Read more

Mobilgeräte-Sicherheit

Safety first! Testen Sie Ihr Wissen rund um Mobile Device Management!

Mobile Device Management (MDM) unterstützt nicht nur der Verwaltung von mobilen Endgeräten und die Software- und Datenverteilung. Es ermöglicht vor allem, die nötige Sicherheit, Transparenz und Kontrolle beim Einsatz von Smartphones und Tablets zu schaffen.

Sicherheit ist das A und O bei der unternehmensinternen Nutzung von Mobilgeräten. Neben der klassischen Geräteverwaltung bilden deshalb Security-Funktionen wie Datenverschlüsselung, Remote-Recovery, App Blacklists und ein Malware-Schutz die Hauptpfeiler von MDM-Lösungen.

Zuverlässige Schutzfunktionen sollen vor allem verhindern, dass interne Daten unkontrolliert das Unternehmen verlassen. Zu diesem Zweck sorgt ein MDM-Client auf dem mobilen Device für die Einhaltung der Corporate-Regeln. Solche Regeln könnten beispielsweise die Nutzung von Kamera oder Bluetooth verbieten oder die Installation bestimmter Apps und Browser. Auch Jailbreak und Rooten stehen oft auf der Verbotsliste.

Neben Unterlassungen lassen sich auch Gebote vorschreiben, etwa, dass die Geräte beim Einschalten durch eine PIN-Eingabe entsperrt werden müssen, dass Daten auf den Devices per Backup vor Verlusten geschützt und gestohlene oder verlorene Geräte bereinigt werden müssen.

Solche Policy-Vorgaben werden per Echtzeitüberwachung kontrolliert – gerade beim Arbeiten mit kritischen Datensätzen wie personenbezogenen Daten, Kontodaten und anderen vertraulichen Informationen eine absolute Notwendigkeit. Verstößt ein Nutzer gegen eine oder mehrere dieser Regeln wird der Zugriff auf die geschäftskritischen Ressourcen blockiert. Als letzte Konsequenz und bei Verlust oder Diebstahl kann das Smartphone oder Tablet auch gesperrt oder dessen Inhalte kontrolliert gelöscht werden. Die Lokalisierung, das Sperren und Löschen der mobilen Devices sollte deshalb auch über die Luftschnittstelle möglich sein.

Herausforderung BYOD

Eine weitere Sicherheitshürde ist zu bewältigen, wenn das Unternehmen seinen Mitarbeitern die berufliche Nutzung ihrer privaten Geräte erlaubt: In solchen BYOD-Szenarien (BYOD = Bring Your Own Device) ist die strikte Trennung privater und geschäftlicher Daten ein Muss. Während Unternehmen stets im Auge behalten müssen, welche geschäftskritischen Daten ihre Mitarbeiter erheben, verarbeiten und nutzen, müssen deren private Daten privat bleiben. Hier haben sich Container-Lösungen etabliert. Diese stellen sicher, dass die Anwendungen und ihre Daten in einem abgeschotteten Umfeld (Container) – sauber getrennt voneinander – laufen.

Mit einer Container-Lösung lässt sich beispielsweise verhindern, dass Firmeninformationen per Copy & Paste auf Facebook oder Twitter landen. Ein Zugriff aus dem Firmenkontext auf die private Facebook- oder Twitter-App wäre damit schlichtweg nicht möglich. Durch Container lassen sich somit viele Schwachstellen eliminieren.

Für einen absolut sicheren, rollenbasierten Datenaustausch hochsensibler Dokumente empfiehlt sich die Einrichtung eines Secure Data Rooms. Dieser ist vollständig isoliert und durch multiple Sicherheitsstandards vor unbefugten Zugriffen gesichert. Dem Secure Data Room sind Rollenrechte hinterlegt, so dass nur bestimmte, authentifizierte Nutzergruppen auf diesen Raum zugreifen können. So lässt sich zum Beispiel für die Vorstandsebene ein Secure Data Room anlegen, in dem Geschäftsberichte und Verträge abgelegt und – je nach erlaubten Bearbeitungsstufen – eingesehen oder auch bearbeitet werden können.

In Zusammenarbeit mit IBM

 

Mobilgeräte-Administration – Testen Sie Ihr Wissen zum Mobile Device Management!

Ordnung im Chaos

Der Wildwuchs an Mobilgeräten und Betriebssystemen erschwert in vielen Unternehmen deren Administration – und die Integration in die bestehende IT-Landschaft. Doch wie lässt sich Ordnung ins Chaos bringen?

Smartphones, Tablets, Notebooks, dazu IOS, Android, Blackberry und Windows – angesichts der Vielfalt an Geräten und Betriebssystemen wird deren Administration und Sicherheit für die IT zunehmend zum Problem. Kaum ein Unternehmen kommt daher heute um das Thema “Mobile Device Management” (MDM) herum, denn all diese Mobilgeräte mit ihren diversen Betriebssystemen “von Hand” zu administrieren und auf demselben Sicherheitsniveau zu halten ist so gut wie unmöglich.

Moderne MDM-Lösungen helfen, die heterogene Geräteflotte in den Griff zu bekommen und sie wie die klassischen stationären IT-Geräte zentral zu konfigurieren und zu verwalten. Sie bieten Unterstützung auf drei Ebenen: Auf der untersten Ebene geht es um die reine Verwaltung der Devices, darüber folgt das Management der Daten und oben ist die Überwachung und Sicherheit der Gerätenutzung angesiedelt.

In der Regel ist die Durchsetzung der unternehmens- und branchenspezifischen Sicherheitsrichtlinien für sämtliche mobilen Endgeräte, die im und für das Unternehmen im Einsatz sind, das wichtigste Motiv für die Anschaffung einer MDM-Lösung. Aber nicht für jedes Unternehmen sind alle Ebenen wichtig. So spielt bei manchen beispielsweise das Thema Sicherheit nur eine untergeordnete Rolle – etwa, weil keinerlei Anschluss an die Infrastruktur zugelassen wird und die Geräte einfach nur verwaltet werden sollen. Doch auch für diesen Fall hat eine MDM-Lösung einen erheblichen Nutzwert.

Einfach und sicher verwalten

Auf Administrationsebene geht es bei MDM darum, bekannte Funktionen aus dem stationären Umfeld auch für mobile Devices anzubieten. Die Mobilgeräteflotte sollte sich ebenso einfach und sicher verwalten lassen wie die klassische IT. Zu diesen Grundfunktionen gehören das Erfassen und Anlegen eines neuen Mobilgeräts, die automatische Verteilung von Software und die Umsetzung von Unternehmensrichtlinien. Idealerweise lässt sich ein MDM-System mit bestehenden Verzeichnissen wie dem Active Directory und anderen Unternehmensressourcen verbinden, was Vieles vereinfacht.

Verschiedene Nutzerrollen, zum Beispiel für Geschäftsführung, Marketing und Vertrieb, Controlling oder IT, können angelegt und die entsprechenden Zugriffsrechte individuell angepasst werden. Auch sollte ein MDM-System mit Personalzugängen wie -abgängen umgehen und das erforderliche Aufspielen beziehungsweise Löschen von Unternehmensdaten und -software auf den Geräten automatisch ausführen können.

Das alles erfolgt idealerweise über eine zentrale Konsole. Über diese wird das Device auch mit den definierten Richtlinien (Policies) verknüpft und im Anschluss mit der darauf basierenden Grundkonfiguration, Zertifikaten und Ähnlichem beschickt. Im laufenden Betrieb sorgt dann ein MDM-Client auf dem Device für Sicherheit und die Einhaltung der Regeln.

In Zusammenarbeit mit IBM.

Toolkits & Services für Semantische Textanalysen

Named Entity Recognition ist ein Teilgebiet von Information Extraction. Ziel von Information Extraction ist die Gewinnung semantischer Informationen aus Texten (im Gegensatz zum verwandten Gebiet des Information Retrieval, bei dem es um das möglichst intelligente Finden von Informationen, die u.U. vorab mit Information Extraction gewonnen wurden, geht). Named Entity Recognition (kurz NER) bezeichnet die Erkennung von Entitäten wie z.B. Personen, Organisationen oder Orten in Texten.

[box]Beispiel:
Albert Einstein war ein theoretischer Physiker, der am 14. März 1879 in Ulm geboren wurde. Er erhielt 1921 den Nobelpreis für Physik. Isaac Newton, Einstein und Stephen Hawking werden oft als die größten Physiker seit der Antike bezeichnet.”[/box]

Die Disambiguierung von Entitäten ist ein weiterer wichtiger Schritt auf dem Weg zu einem semantischen Verständnis von Texten. Wenn man so in obigem Text erkennen kann, dass “Albert Einstein“, “Er” und “Einstein” die gleiche Person bezeichnen, so kann ein Analyseverfahren z.B. daraus schließen, dass in diesem Text Einstein eine wichtigere Rolle spielt, als Newton, der nur einmal erwähnt wurde. Die Hyperlinks hinter den jeweiligen Entitäten zeigen eine Möglichkeit der semantischen Anreicherung von Texten an – in diesem Fall wurden die Entitäten mit entsprechenden Einträgen bei DBpedia automatisch verlinkt.

Named Entity Recognition dient vorrangig zwei Zwecken:

  • Anreicherung von Texten mit Metadaten
  • Abstraktion von Texten zur besseren Erkennung von Mustern

Punkt 1 dient direkt dem Information Retrieval. Anwender können so z.B. gezielt nach bestimmten Personen suchen, ohne alle möglichen Schreibweisen oder Berufsbezeichnungen auflisten zu müssen.

Punkt 2 dient der Vorverarbeitung von Texten als Input für Machine Learning Verfahren. So ist es (je nach Anwendung!) oft nicht von Bedeutung, welche Person, welcher Ort oder auch welche Uhrzeit in einem Text steht sondern nur die Tatsache, dass Personen, Orte oder Zeiten erwähnt wurden.

Sirrus Shakeri veranschaulicht die zentrale Bedeutung semantischer Analyse in seinem Beitrag From Big Data to Intelligent Applications:

intelligent-applications-cirrus-shakeri

Abbildung 1: Von Big Data zu Intelligent Applications von Cirrus Shakeri

Sein “Semantic Graph” setzt voraus, dass Entitäten mittels “Natural Language Processing” erkannt und zueinander in Beziehung gesetzt wurden.

Es ist interessant zu vermerken, dass Natural Language Processing und Data Mining / Machine Learning über viele Jahre als Alternativen zueinander und nicht als Ergänzungen voneinander gesehen wurden. In der Tat springen die meisten Vorgehensmodelle heutzutage von “Data Preparation” zu “Machine Reasoning”. Wir argumentieren, dass sich in vielen Anwendungen, die auf unstrukturierten Daten basieren, signifikante Qualitätsverbesserungen erzielen lassen, wenn man zumindest NER (inklusive Disambiguierung) in die Pipeline mit einbezieht.

Toolkits und Services für NER

Es existiert eine Vielzahl von Toolkits für Natural Language Processing, die Sie mehr oder weniger direkt in Ihre Programme einbinden können. Exemplarisch seien drei Toolkits für Java, Python und R erwähnt:

Diese Toolkits enthalten Modelle, die auf Korpora für die jeweils unterstützten Sprachen trainiert wurden. Sie haben den Vorteil, dass sie auch vollkommen neue Entitäten erkennen können (wie z.B. neue Politiker oder Fernsehstars, die zur Trainingszeit noch unbekannt waren). Je nach Einstellung haben diese Systeme aber auch eine relativ hohe Falsch-Positiv-Rate.

Wer NER nur ausprobieren möchte oder lediglich gelegentlich kleinere Texte zu annotieren hat, sei auf die folgenden Web Services verwiesen, die auch jeweils eine REST-Schnittstelle anbieten.

DBpedia

Das DBpedia Projekt nutzt die strukturierten Informationen der verschieden-sprachigen Wikipedia Sites für den Spotlight Service. Im Unterschied zu den reinen Toolkits nutzen die nun genannten Werkzeuge zusätzlich zu den trainierten Modellen eine Wissensbasis zur Verringerung der Falsch-Positiv-Rate. Die mehrsprachige Version unter http://dbpedia-spotlight.github.io/demo zeigt die Möglichkeiten des Systems auf. Wählen Sie unter “Language” “German“) und dann über “SELECT TYPES…” die zu annotierenden Entitätstypen. Ein Beispieltext wird automatisch eingefügt. Sie können ihn natürlich durch beliebige andere Texte ersetzen. Im folgenden Beispiel wurden “Organisation”, “Person”, und “Place“ ausgewählt:

DBprediaSpotlight

Abbildung 2: DBpedia Demo (de.dbpedia.org)

Die erkannten Entitäten werden direkt mit ihren DBpedia Datenbankeinträgen verlinkt. Im Beispiel wurden die Orte Berlin, Brandenburg und Preußen sowie die Organisationen Deutsches Reich, Deutsche Demokratische Republik, Deutscher Bundestag und Bundesrat erkannt. Personen wurden in dem Beispieltext nicht erkannt. Die Frage, ob man “Sitz des Bundespräsidenten” als Ort (Sitz), Organisation (das Amt des Bundespräsidenten) und / oder Person (der Bundespräsident) bezeichnen sollte, hängt durchaus vom Anwendungsszenario ab.

OpeNER

Das OpeNER Projekt ist das Ergebnis eines europäischen Forschungsprojekts und erweitert die Funktionalität von DBpedia Spotlight mit weiteren semantischen Analysen. Die Demo unter http://demo2-opener.rhcloud.com/welcome.action (Tab “Live Analysis Demo“, “Named Entity Recognition and Classification” und “Named Entity Linking” auswählen und “Analyse” drücken, dann auf der rechten Seite das Tab “NERC” anwählen) ergibt für den gleichen Beispieltext:

opeNER-projekt

Abbildung 3: OpeNER Projekt (opener-project.eu)

Organisationen sind blau hinterlegt, während Orte orange markiert werden. Auch hier werden erkannte Entitäten mit ihren DBpedia Datenbankeinträgen verknüpft. Die Bedeutung dieser Verknüpfung erkennt man wenn man auf das Tab “Map” wechselt. Berlin wurde als Ort erkannt und über die Geo-Koordinaten (geo:long = 13.4083, geo.lat = 52.5186) im DBpedia Eintrag von Berlin konnte das Wort “Berlin” aus obigem Text automatisch auf der Weltkarte referenziert werden.

Es gibt eine Vielzahl weiterer Services für NLP wie z.B. OpenCalais. Einige dieser Services bieten bestimmte Funktionalitäten (wie z.B. Sentiment Analysis) oder andere Sprachen neben Englisch nur gegen eine Gebühr an.

Listen Tagger

Der Vollständigkeit halber sei noch erwähnt, dass in den meisten Anwendungsszenarien die oben genannten Werkzeuge durch sogenannte Listen-Tagger (englisch Dictionary Tagger) ergänzt werden. Diese Tagger verwenden Listen von Personen, Organisationen oder auch Marken, Bauteilen, Produktbezeichnern oder beliebigen anderen Gruppen von Entitäten. Listen-Tagger arbeiten entweder unabhängig von den oben genannten statistischen Taggern (wie z.B. dem Standford Tagger) oder nachgeschaltet. Im ersten Fall markieren diese Tagger alle Vorkommen bestimmter Worte im Text (z.B. „Zalando“ kann so direkt als Modemarke erkannt werden). Im zweiten Fall werden die Listen genutzt, um die statistisch erkannten Entitäten zu verifizieren. So könnte z.B. der Vorschlag des statistischen Taggers automatisch akzeptiert werden wenn die vorgeschlagene Person auch in der Liste gefunden wird. Ist die Person jedoch noch nicht in der Liste enthalten, dann könnte ein Mitarbeiter gebeten werden, diesen Vorschlag zu bestätigen oder zu verwerfen. Im Falle einer Bestätigung wird die neu erkannte Person dann in die Personenliste aufgenommen während sie im Falle einer Ablehnung in eine Negativliste übernommen werden könnte damit dieser Vorschlag in Zukunft automatisch unterdrückt wird.

Regular Expression Tagger

Manche Entitätstypen folgen klaren Mustern und können mit hoher Zuverlässigkeit durch reguläre Ausdrücke erkannt werden. Hierzu zählen z.B. Kreditkarten- oder Telefon- oder Versicherungsnummern aber auch in vielen Fällen Bauteilbezeichner oder andere firmeninterne Identifikatoren.

Fazit

Natural Language Processing und insbesondere Named Entity Recognition und Disambiguierung sollte Teil der Werkzeugkiste eines jeden Anwenders bei der Analyse von unstrukturierten Daten sein. Es existieren mehrere mächtige Toolkits und Services, die allerdings je nach Anwendungsgebiet kombiniert und verfeinert werden müssen. So erkennt DBpedia Spotlight nur Entitäten, die auch einen Wikipedia Eintrag haben, kann für diese aber reichhaltige Metadaten liefern. Der Stanford Tagger hingegen kann auch vollkommen unbekannte Personennamen aus dem textuellen Kontext erkennen, hat aber bei manchen Texten eine relativ hohe Falsch-Positiv-Rate. Eine Kombination der beiden Technologien und anwendungsspezifischen Listen von Entitäten kann daher zu qualitativ sehr hochwertigen Ergebnissen führen.

Man redet gerne über Daten, genutzt werden sie nicht

Der Big Data Hype ist vorbei und auf dem Anstieg zum „ Plateau of Productivity“. Doch bereits in dieser Phase klafft die Einschätzung von Analysten mit der Verbreitung von Big Data Predictive Analytics/Data Mining noch weit von der Realität in Deutschland auseinander. Dies belegt u.a. eine Studie der T-Systems Multimedia Solutions, zu welcher in der FAZ* der Artikel Man redet gerne über Daten, genutzt werden sie nicht, erschienen ist. Mich überrascht diese Studie nicht,  sondern bestätigt meine langjährige Markterfahrung.

Die Gründe sind vielfältig: keine Zeit, keine Priorität, keine Kompetenz, kein Data Scientist, keine Zuständigkeit, Software zu komplex – Daten und Use-Cases sind aber vorhanden.

Im folgenden Artikel wird die Datenanalyse- und Data-Mining Software der Synop Systems vorgestellt, welche „out-of-the-box“ alle Funktionen bereitstellt, um Daten zu verknüpfen, zu strukturieren, zu verstehen, Zusammenhänge zu entdecken, Muster in Daten zu lernen und Prognose-Modelle zu entwickeln.

Anforderung an „Advanced-Data-Analytics“-Software

Um Advanced-Data-Analytics-Software zu einer hohen Verbreitung zu bringen, sind folgende Aspekte zu beachten:

  1. Einfachheit in der Nutzung der Software
  2. Schnelligkeit in der Bearbeitung von Daten
  3. Analyse von großen Datenmengen
  4. Große Auswahl an vorgefertigten Analyse-Methoden für unterschiedliche Fragestellungen
  5. Nutzung (fast) ohne IT-Projekt
  6. Offene Architektur für Data-Automation und Integration in operative Prozesse

Synop Analyzer – Pionier der In-Memory Analyse

Um diese Anforderungen zu erfüllen, entstand der Synop Analyzer, welcher seit 2013 von der Synop Systems in den Markt eingeführt wird. Im Einsatz ist die Software bei einem DAX-Konzern bereits seit 2010 und zählt somit zum Pionier einer In-Memory-basierenden Data-Mining Software in Deutschland. Synop Analyzer hat besondere Funktionen für technische Daten. Anwender der Software sind aber in vielen Branchen zu finden: Automotive, Elektronik, Maschinenbau, Payment Service Provider, Handel, Versandhandel, Marktforschung.

Die wesentlichen Kernfunktionen des  Synop Analyzer sind:

a. Eigene In-Memory-Datenhaltung:

Optimiert für große Datenmengen und analytische Fragestellungen. Ablauffähig auf jedem Standard-Rechner können Dank der spaltenbasierenden Datenhaltung und der Komprimierung große Datenmengen sehr schnell analysiert werden. Das Einlesen der Daten erfolgt direkt aus Datenbanktabellen der Quellsysteme oder per Excel, CSV, Json oder XML. Unterschiedliche Daten können verknüpf und synchronisiert werden. Hohe Investitionen für Big-Data-Datenbanken entfallen somit. Eine Suche von Mustern von diagnostic error codes (dtc), welche mind. 300 Mal (Muster) innerhalb 100 Mio. Datenzeilen vorkommen, dauert auf einem I5-Proz. ca. 1200 Sek., inkl. Ausgabe der Liste der Muster. Ein Prognosemodel mittels Naive-Bayes für das Produkt „Kreditkarte“ auf 800 Tsd. Datensätzen wird in ca. 3 Sek. berechnet.

b. Vielzahl an Analyse-Methoden

Um eine hohe Anzahl an Fragestellungen zu beantworten, hat der Synop Analyzer eine Vielzahl an vorkonfigurierten Analyse- und Data-Mining-Verfahren (siehe Grafik) implementiert. Daten zu verstehen wird durch Datenvisualisierung stark vereinfacht. Die multivariate Analyse ist quasi interaktives Data-Mining, welches auch von Fachanwendern schnell genutzt wird. Ad hoc Fragen werden unmittelbar beantwortet – es entstehen aber auch neue Fragen dank der interaktiven Visualisierungen. Data-Mining-Modelle errechnen und deren Modellgüte durch eine Testgruppe zu validieren ist in wenigen Minuten möglich. Dank der Performance der In-Memory-Analyse können lange Zeitreihen und alle sinnvollen Datenmerkmale in die Berechnungen einfließen. Dadurch werden mehr Einflussgrößen erkannt und bessere Modelle errechnet. Mustererkennung ist kein Hokuspokus, sondern Dank der exzellenten Trennschärfe werden nachvollziehbare, signifikante Muster gefunden. Dateninkonsistenzen werden quasi per Knopfdruck identifiziert.

synop-systems-module

c. Interaktives User Interface

Sämtliche Analyse-Module sind interaktiv und ohne Programmierung zu nutzen. Direkt nach dem Einlesen werden Grafiken automatisiert, ohne Datenmodellierung, erstellt.  Schulung ist kaum oder minimal notwendig und Anwender können erstmals fundierte statistische Analysen und Data-Mining in wenigen Schritten umsetzen. Data-Miner und Data Scientisten ersparen sich viel Zeit und können sich mehr auf die Interpretation und Ableitung von Handlungsmaßnahmen fokussieren.

d. Einfacher Einstieg – modular und mitwachsend

Der Synop Analyzer ist in unterschiedlichen Versionen verfügbar:

– Desktop-Version: in dieser Version sind alle Kernfunktionen in einer Installation kombiniert. In wenigen Minuten mit den Standard-Betriebssystemen MS-Windows, Apple Mac, Linux installiert. Außer Java-Runtime ist keine weitere Software notwendig. Somit fast, je nach Rechte am PC, ohne IT-Abt. installierbar. Ideal zum Einstieg und Testen, für Data Labs, Abteilungen und für kleine Unternehmen.

– Client/Server-Version: In dieser Version befinden die Analyse-Engines und die Datenhaltung auf dem Server. Das User-Interface ist auf dem Rechner des Anwenders installiert. Eine Cloud-Version ist demnächst verfügbar. Für größere Teams von Analysten mit definierten Zielen.

– Sandbox-Version: entspricht der C/S-Server Version, doch das User-Interface wird spezifisch auf einen Anwenderkreis oder einen Anwendungsfall bereitgestellt. Ein typischer Anwendungsfall ist, dass gewisse Fachbereiche oder Data Science-Teams eine Daten-Sandbox erhalten. In dieser Sandbox werden frei von klassischen BI-Systemen, Ad-hoc Fragen beantwortet und proaktive Analysen erstellt. Die Daten werden per In-Memory-Instanzen bereitgestellt.

Fazit:  Mit dem Synop Analyzer erhalten Unternehmen die Möglichkeit Daten sofort zu analysieren. Aus vorhandenen Daten wird neues Wissen mit bestehenden Ressourcen gewonnen! Der Aufwand für die Einführung ist minimal. Der Preis für die Software liegt ja nach Ausstattung zw. 2.500 Euro und 9.500 Euro. Welche Ausrede soll es jetzt noch geben?

Nur wer früh beginnt, lernt die Hürden und den Nutzen von Datenanalyse und Data-Mining kennen. Zu Beginn wird der Reifegrad klein sein: Datenqualität ist mäßig, Datenzugriffe sind schwierig. Wie in anderen Disziplinen gilt auch hier: Übung macht den Meister und ein Meister ist noch nie von Himmel gefallen.