Ahmed Abdeljaoued

Big Data Essentials – Intro

/0 Comments/in , , , , , , , , , , , /by

1. Big Data Definition

Data umfasst Nummern, Text, Bilder, Audio, Video und jede Art von Informationen die in Ihrem Computer gespeichert werden können. Big Data umfasst Datenmengen, die eine oder mehrere der folgenden Eigenschaften aufweisen: Hohes Volumen (High Volume), hohe Vielfalt (High Variety) und / oder eine notwendige hohe Geschwindigkeit (High Velocity) zur Auswertung. Diese drei Eigenschaften werden oft auch als die 3V’s von Big Data bezeichnet.

1.1. Volumen: Menge der erzeugten Daten

Volumen bezieht sich auf die Menge der generierten Daten. Traditionelle Datenanalysemodelle erfordern typischerweise Server mit großen Speicherkapazitäten, bei massiver Rechenleistung sind diese Modelle nicht gut skalierbar. Um die Rechenleistung zu erhöhen, müssen Sie weiter investieren, möglicherweise auch in teurere proprietäre Hardware. Die NASA ist eines von vielen Unternehmen, die enorme Mengen an Daten sammeln. Ende 2014 sammelte die NASA alle paar Sekunden etwa 1,73 GB an Daten. Und auch dieser Betrag der Datenansammlung steigt an, so dass die Datenerfassung entsprechend exponentiell mitwachsen muss. Es resultieren sehr hohe Datenvolumen und es kann schwierig sein, diese zu speichern.

1.2. Vielfalt: Unterschiedliche Arten von Daten

Das  traditionelle  Datenmodell (ERM)  erfordert  die  Entwicklung  eines  Schemas,  das  die  Daten in ein Korsett zwingt. Um das Schema zu erstellen, muss man das Format der Daten kennen, die gesammelt werden. Daten  können  wie  XML-Dateien  strukturiert  sein,  halb  strukturiert  wie  E-Mails oder unstrukturiert wie Videodateien.

Wikipedia – als Beispiel – enthält mehr als nur Textdaten, es enthält Hyperlinks, Bilder, Sound-Dateien und viele andere Datentypen mit mehreren verschiedenen Arten von Daten. Insbesondere unstrukturierte   Daten haben   eine   große   Vielfalt.  Es   kann   sehr   schwierig   sein, diese Vielfalt in einem Datenmodell zu beschreiben.

1.3. Geschwindigkeit: Geschwindigkeit, mit der Daten genutzt werden

Traditionelle Datenanalysemodelle wurden für die Stapelverarbeitung (batch processing) entwickelt. Sie sammeln die gesamte Datenmenge und verarbeiten sie, um sie in die Datenbank zu speichern. Erst mit einer Echtzeitanalyse der Daten kann schnell auf Informationen reagiert werden. Beispielsweise können Netzwerksensoren, die mit dem Internet der Dinge (IoT) verbunden sind, tausende von Datenpunkten pro Sekunde erzeugen. Im Gegensatz zu Wikipedia, deren Daten später verarbeitet werden können, müssen Daten von Smartphones und anderen Netzwerkteilnehmern mit entsprechender Sensorik in  Echtzeit  verarbeitet  werden.

2. Geschichte von Big Data

2.1. Google Solution

  • Google File System speichert die Daten, Bigtable organisiert die Daten und MapReduce verarbeitet es.
  • Diese Komponenten arbeiten zusammen auf einer Sammlung von Computern, die als Cluster bezeichnet werden.
  • Jeder einzelne Computer in einem Cluster wird als Knoten bezeichnet.

2.2 Google File System

Das Google File System (GFS) teilt Daten in Stücke ‚Chunks’ auf. Diese ‚Chunks’ werden verteilt und auf verschiedene Knoten in einem Cluster nachgebildet. Der Vorteil ist nicht nur die mögliche parallele Verarbeitung bei der späteren Analysen, sondern auch die Datensicherheit. Denn die Verteilung und die Nachbildung schützen vor Datenverlust.

2.3. Bigtable

Bigtable ist ein Datenbanksystem, das GFS zum Speichern und Abrufen von Daten verwendet. Trotz seines Namens ist Bigtable nicht nur eine sehr große Tabelle. Bigtable ordnet die Datenspeicher mit einem Zeilenschlüssel, einem Spaltenschlüssel und einem Zeitstempel zu. Auf diese Weise können dieselben Informationen über einen längeren Zeitraum hinweg erfasst werden, ohne dass bereits vorhandene Einträge überschrieben werden. Die Zeilen sind dann in den Untertabellen partitioniert, die über einem Cluster verteilt sind. Bigtable wurde entwickelt, um riesige Datenmengen zu bewältigen, mit der Möglichkeit, neue Einträge zum Cluster hinzuzufügen, ohne dass eine der vorhandenen Dateien neu konfiguriert werden muss.

2.4. MapReduce

Als dritter Teil des Puzzles wurde ein Parallelverarbeitungsparadigma namens MapReduce genutzt, um die bei GFS gespeicherten Daten zu verarbeiten. Der Name MapReduce wird aus den Namen von zwei Schritten im Prozess übernommen. Obwohl der Mapreduce-Prozess durch Apache Hadoop berühmt geworden ist, ist das kaum eine neue Idee. In der Tat können viele gängige Aufgaben wie Sortieren und Falten von Wäsche als Beispiele für den MapReduce- Prozess betrachtet werden.

Quadratische Funktion:

  • wendet die gleiche Logik auf jeden Wert an, jeweils einen Wert
  • gibt das Ergebnis für jeden Wert aus
    (map square'(1 2 3 4)) = (1 4 9 16)

Additionsfunktion

  • wendet die gleiche Logik auf alle Werte an, die zusammen genommen werden.
    (reduce + ‘(1 4 9 16)) = 30

Die Namen Map und Reduce können bei der Programmierung mindestens bis in die 70er-Jahre zurückverfolgt werden. In diesem Beispiel sieht man, wie die Liste das MapReduce-Modell verwendet. Zuerst benutzt man Map der Quadratfunktion auf einer Eingangsliste für die Quadratfunktion, da sie abgebildet ist, alle angelegten Eingaben und erzeugt eine einzige Ausgabe pro Eingabe, in diesem Fall (1, 4, 9 und 16). Additionsfunktion reduziert die Liste und erzeugt eine einzelne Ausgabe von 30, der die Summe aller Eingänge ist.

Google nutzte die Leistung von MapReduce, um einen Suchmaschinen-Markt zu dominieren. Das Paradigma kam in der 19. Websearch-Engine zum Einsatz und etablierte sich innerhalb weniger Jahre und ist bis heute noch relevant. Google verwendete MapReduce auf verschiedene Weise, um die Websuche zu verbessern. Es wurde verwendet, um den Seiteninhalt zu indexieren und ein Ranking über die Relevant einer Webseite zu berechnen.

Dieses  Beispiel  zeigt  uns  den MapReduce-Algorithmus, mit dem Google Wordcount auf Webseiten ausführte. Die Map-Methode verwendet als Eingabe einen Schlüssel (key) und einen Wert, wobei der Schlüssel den Namen des Dokuments darstellt  und  der  Wert  der  Kontext  dieses Dokuments ist. Die Map-Methode durchläuft jedes Wort im Dokument und gibt es als Tuple zurück, die aus dem Wort und dem Zähler 1 besteht.

Die   Reduce-Methode   nimmt   als   Eingabe auch  einen  Schlüssel  und  eine  Liste  von  Werten an, in der der Schlüssel ein Wort darstellt. Die  Liste  von  Werten  ist  die  Liste  von  Zählungen dieses Worts. In diesem Beispiel ist der Wert 1. Die Methode “Reduce” durchläuft alle Zählungen. Wenn die Schleife beendet ist, um die Methode zu reduzieren, wird sie als Tuple zurückgegeben, die aus dem Wort und seiner Gesamtanzahl besteht.

 

Georgios Gkekas

Eine Hadoop Architektur mit Enterprise Sicherheitsniveau

/5 Comments/in , , , , , , , , , , , , , , , /by

Dies ist Teil 2 von 3 der Artikelserie zum Thema Eine Hadoop-Architektur mit Enterprise Sicherheitsniveau.

Der aktuelle Stand der Technologie

Zum Glück ist Hadoop heutzutage ein bisschen reifer, als es noch vor zehn Jahren war. Es gibt viele Tools, einige davon OpenSource und einige lizenziert, die den Sicherheitsmangel im Hadoop zu lösen versuchen. Die Tabelle unten zeigt eine Auswahl der am meisten genutzten Sicherheitstools. Da jedes Tool von einer anderen Hadoop Distribution bevorzugt wird, habe ich diese Parameter mit berücksichtigt.

Es ist zu beachten, dass die zwei populärsten Hadoop Distributions (Hortonworks und Cloudera) kaum Unterschiede aufweisen, wenn man sie auf funktionaler Ebene vergleicht. Der größte Unterschied  besteht darin, dass Hortonworks ein Open Source und Cloudera ein kommerzielles Produkt ist. Abgesehen davon hat jeder Vendor den einen oder anderen Vorteil, ein ausführlicher Vergleich würde jedoch den Rahmen dieses Artikels sprengen.

sicherheitsmerkmale-hadoop-hortenworks-cloudera-other

Hadoop kommt von der Stange ohne aktivierte Authentisierung. Die Hadoop Dienste vertrauen jedem User, egal als was er oder sie sich ausgibt. Das sieht  folgendermaßen aus:

Angenommen Mike arbeitet an einer Maschine, die ihm Zugriff auf den Hadoop Cluster erlaubt und Sudo-Rechte gibt. Aber Mike hat das Passwort für den hdfs Superuser nicht. Er kann sich jetzt einfach als der hdfs User ausgeben, indem er die folgenden Kommandos ausführt. Dabei bekommt er fatalerweise alle Rechten des hdfs Superusers und ist in der Lage das gesamte HDFS Filesystem zu löschen. Es würde sogar bereits der Environment variabel USER ausreichen, um einen anderen User umzuwandeln.

hadoop-linux-useradd-hdfs

Kerberos ist im Moment der einzige Weg um Authentisierung im Hadoop zu gewährleisten. Kein Weg führt daran vorbei, es sei denn, man ist verrückt genug, um ein hochkompliziertes System auf Linux basierter ACLs auf jeder Maschine zu installieren und zu verwalten, um User daran zu hindern sich falsch zu authentifizieren. Es ist zudem wichtig zu beachten, dass Kerberos als einziges Sicherheitsmerkmal zur Authentifizierung dient, aber ohne richtige Authentisierung gibt es auch keine richtige Autorisierung. Wenn User jetzt selbst in der Lage sind, sich beliebig als jemand anderes auszugeben, können sie so selbst zu den sensibelsten Daten unbefugten Zugriff erlangen.

Apache Ranger oder Sentry erlauben die Definition und Verwaltung von Access Control Lists (ACLs). Diese Listen legen fest, welche User Zugriff auf welchen Bereich des HDFS Filesystems haben Der gleiche Effekt kann auch ohne diese Tools, durch einfache  Hadoop ACLs erreicht werden, die den normalen Linux ACLs ähneln. Es empfiehlt sich jedoch die neuesten Tools zu benutzen, wegen a) ihrer Benutzerfreundlichkeit, b) ihrer ausgearbeiteten APIs, die einem Administrator erlauben die Listen ohne GUI zu verwalten und beim Programmieren sogar zu automatisieren, und c) wegen ihrer Auditingfähigkeiten, die das Nachverfolgen von Zugriffen und Aktionen ermöglichen.

Anbei ist das Bild einer Ranger Policy, die der Gruppe der User rekursiv Lese- und Ausführungsrechte auf das Verzeichnis /projects/autonomous_driving gibt.

Alle einzelne Stücke des Puzzles kommen zusammen

Nachdem wir ermittelt haben, welche Technologien es gibt, die uns zu einem sicheren Cluster verhelfen, müssen diese im nächsten Schritt zusammengesetzt werden. Zum Glück hat jeder Vendor seine eigene Technologie, um Tools aus dem  Hadoop Ecosystem zu integrieren und zu verwalten. Cloudera beispielsweise bietet den sehr wirksamen Cloudera Manager und Hortonworks das Apache Ambari an. Die beiden Tools kümmern sich um das Anlegung der technischen Hadoop User (hdfs, hadoop, hive, ranger, e.t.c.) und der entsprechenden Kerberos Keytabs, die den technischen Usern erlauben, sich gegenüber Hadoop zu authentisieren. Am Ende der Installation hat man sämtliche Konfigurationen zentral platziert und kann neue personalisierte Accounts anlegen. Man kann sich dann im Ranger oder Sentry Web UI anmelden und ACLs für die User und Gruppen definieren.

Das ist allerdings nicht der Idealzustand. Jedes Unternehmen verwaltet ihre User bereits in bestimmten Verwaltungssystemen, die sich innerhalb der IT Infrastruktur befinden. Diese Systeme (oder auch Identity Management Systems) sind ein wichtiges vertikales, abteilungsübergreifendes Element der unternehmerischen IT Architektur. Jedes EDS Tool im Unternehmen ist an ein Identity Management System, wie Active Directory oder LDAP, gekoppelt und muss damit die User nicht selbst verwalten.

Der Stellenwert solcher Tools wird sofort erkennbar, wenn man die strengen Sicherheitsregeln eines modernen Unternehmens betrachtet: Passwörter müssen bestimmte Kriterien erfüllen und alle 30 Tagen gewechselt werden. Außerdem darf niemand eins seiner letzten zehn Passwörter benutzen.

Eine IT Architektur, die die Implementierung solcher unternehmensbreiten  Anforderungen in jeder einzelne Applikation fördert ist der Alptraum jedes Applikationsentwicklers und zeigt das Versagen des IT-Architekten.

Aber lassen Sie uns zurück zu unserem Hauptthema kommen. Wie können wir ein System wie Active Directory oder LDAP in Hadoop integrieren?  Der nächste Abschnitt gibt die Antwort auf diese Frage.

Weiter zu  Teil 3 von 3 – Eine Einterprise Hadoop Architektur für beste Sicherheit

Zurück zu Teil 1 von 3 – Motivation und Anforderungen einer Data Science Plattform

Georgios Gkekas

Eine Hadoop Architektur mit Enterprise Sicherheitsniveau

/2 Comments/in , , , , , , , , /by

Die Motivation für eine unternehmenskonforme Sicherheitsarchitektur für Hadoop

Hadoop und die damit einhergehenden Technologien und Applikationen (Hadoop Ecosystem) stellen keine neue Idee mehr dar. Zugegebenermaßen hat man jedoch das Gefühl, dass Hadoop noch lange nicht reif genug für dessen Integration an die IT Infrastruktur und an die Prozesse eines Unternehmens ist. Bei fast jeder Hadoop Distribution mangelt es an bestimmten nicht-funktionalen Aspekten. Die Hadoop Community hat sich sehr lange um die Erfüllung der funktionalen Anforderungen gekümmert und dabei Aspekte wie Sicherheit, Monitoring, Data Governance und Auditing vernachlässigt.

Eine berechtigte Frage wäre nun: Warum ist das so?

Zum besseren Verständnis der Leser werde ich zunächst auf diese Frage und die Geschichte von Hadoop eingehen, bevor ich mich mit dem Aufbau einer sicheren Hadoop Infrastruktur beschäftige.
Hadoop hat eine, für IT Verhältnisse, relativ lange Geschichte hinter sich. Das erste Release fand im Februar 2006 statt, wobei Yahoo bereits von Beginn an Interesse an der Mitwirkung und Benutzung bekundete. Am Anfang waren alle Applikationen, die für Hadoop geschrieben wurden, Backend Data-Crunching Jobs. Diese führten eine Art von Datenanalyse, basierend auf großen Datenmengen,  durch, die sonst, ohne die Verwendung der von Hadoops verteilter Architektur und Prozessframework, viel länger gedauert hätte. Dabei haben die Entwickler mithilfe der MapReduce Ausführungsengine Aggregierungen und  anderen SQL-ähnliche Abfragen von Datenbeständen geschrieben. Sämtliche Applikationen waren von ihrer Natur her Batchjobs, die regelmäßig auf dem Cluster angestoßen wurden, um Resultate zu berechnen und diese weiter an standardisierte Visualisierungstools zu leiten. Normale User brauchten daher keinen direkten Zugriff auf den Cluster selbst, sondern nur auf die Tools, die die Resultate der Hadoop Jobs sammelten. Das hat die Arbeit der ITler stark vereinfacht, da sie  den Hadoop Cluster, der viele sensible Daten über ihr Unternehmen beherbergt , komplett von der restlichen IT Infrastruktur abtrennen und durch Firewalls sichern konnten. Die Kommunikationskanäle zwischen Hadoop und anderen Tools waren dabei auf das absolut Notwendigste –   sprich Daten rein, Resultate raus –  begrenzt. Durch diese Limitierung fiel das zeitaufwendige Installieren und Verwalten von Usern und das Schreiben von Autorisierungspolicies weg.
Mit dem Zuwachs der Datenmenge in modernen Unternehmen und der wachsenden Popularität des Hadoop Ecosystems kamen weitere Use Cases und mehrere Tools hinzu. Hadoop2 hat in diesem Zuge eine komplett neue Architektur veröffentlicht, in der man nicht mehr vom MapReduce abhängig ist. Andere Ausführungsengines sind aufgetaucht, die auf bestimmte Use Cases abzielen und sich in diesen Fällen durch bessere Leistung als das MapReduce Framework auszeichnen. Mehr und mehr Business- und Daten-Analysten wurden daraufhin auf Hadoop aufmerksam und wollten die Technik für sich nutzen.. Insbesondere Banken und Finanzdienstleister erkannten das gewaltige Potenzial dieser Technologie und wollten sie nutzen, um ihre Kunden besser zu verstehen.
Das war der Moment, in dem Unternehmen weltweit den Druck empfanden, eine ernste Sicherheitsarchitektur für Hadoop zu entwickeln. Dabei stießen ihre Ingenieure jedoch auf erste Probleme:
Wie gewährleistet man nutzerbasierten Zugriff auf Tools, die sich normalerweise innerhalb eines Hadoop Clusters befinden? Und noch wichtiger: Wie beschützt man sensible Daten vor unbefugtem Zugriff? Welcher Nutzer darf auf welche Daten zugreifen?
All diese Fragen, die sich mit dem Thema „Personalisierter Zugriff“  befassten, brauchten umgehend eine Antwort.

Die Sicherheitsanforderungen einer Data Science Plattform

Den Bedarf an höheren Sicherheitsvorkehrungen haben insbesondere die Hadoop Plattformen, die ihren Usern interaktive und adhoc Jobs/Abfragen ermöglichen möchten. Solche Plattformen sind in der BigData Welt als interaktive oder explorative (abgeleitet vom englischen Wort Exploration) Umgebungen bekannt. Ihr Hauptziel ist es, eine BigData Umgebung anzubieten, die den Usern erlaubt, neue Techniken und maschinelles Lernen auf Datensätze anzuwenden, um versteckte Muster zu erkennen.

Hier sind einige der wichtigsten Ziele, die ein sicheres Hadoop Umfeld erfüllen muss:

  1. Jeder User muss in der Lage sein, selber Abfragen oder Machine Learning Algorithmen auf große Datenmengen anzustoßen.
  2. User müssen sogar in der Lage sein, selber Daten einzufügen und zwar in einer kontrollierten Art und Weise.
  3. Resultate müssen direkt auf dem Cluster abrufbar sein, damit die neuesten BigData Visualisierungstechnologien genutzt werden können
  4. Unbefugter Zugriff auf Datensätze einer dritten Abteilung durcheinzelne Personen oder Gruppen muss verhindert werden.
  5. Jeder Datenzugriff muss kontrolliert und auditiert werden können.

Dieser Artikel ist der Start der drei-teiligen Serie zum Thema Sicherheit auf Enterprise-Niveau für Hadoop. 

Weiter zu Teil 2 von 3 – Sicherheitstechnologie in Hadoop

Mathias Golombek

Data Science on a large scale – can it be done?

/1 Comment/in , , , , , /by

Analytics drives business

In today’s digital world, data has become the crucial success factor for businesses as they seek to maintain a competitive advantage, and there are numerous examples of how companies have found smart ways of monetizing data and deriving value accordingly.

On the one hand, many companies use data analytics to streamline production lines, optimize marketing channels, minimize logistics costs and improve customer retention rates.  These use cases are often described under the umbrella term of operational BI, where decisions are based on data to improve a company’s internal operations, whether that be a company in the manufacturing industry or an e-commerce platform.

On the other hand, over the last few years, a whole range of new service-oriented companies have popped up whose revenue models wholly depend on data analytics.  These Data-Driven Businesses have contributed largely to the ongoing development of new technologies that make it possible to process and analyze large amounts of data to find the right insights.  The better these technologies are leveraged, the better their value-add and the better for their business success.  Indeed, without data and data analytics, they don’t have a business.

Data Science – hype or has it always been around?Druck

In my opinion, there is too much buzz around the new era of data scientists.  Ten years ago, people simply called it data mining, describing similar skills and methods.  What has actually changed is the fact that businesses are now confronted with new types of data sources such as mobile devices and data-driven applications rather than statistical methodologies.  I described that idea in detail in my recent post Let’s replace the Vs of Big Data with a single D.

But, of course, you cannot deny that the importance of these data crunchers has increased significantly. The art of mining data mountains (or perhaps I should say “diving through data lakes”) to find appropriate insights and models and then find the right answers to urgent, business-critical questions has become very popular these days.

The challenge: Data Science with large volumes?

Michael Stonebraker, winner of the Turing Award 2014, has been quoted as saying: “The change will come when business analysts who work with SQL on large amounts of data give way to data EXASOL Pipelinescientists, which will involve more sophisticated analysis, predictive modeling, regressions and Bayesian classification. That stuff at scale doesn’t work well on anyone’s engine right now. If you want to do complex analytics on big data, you have a big problem right now.”

And if you look at the limitations of existing statistical environments out there using R, Python, Java, Julia and other languages, I think he is absolutely right.  Once the data scientists have to handle larger volumes, the tools are just not powerful and scalable enough.  This results in data sampling or aggregation to make statistical algorithms applicable at all.

A new architecture for “Big Data Science”

We at EXASOL have worked hard to develop a smart solution to respond to this challenge.  Imagine that it is possible to use raw data and intelligent statistical models on very large data sets, directly at the place where the data is stored.  Where the data is processed in-memory to achieve optimal performance, all distributed across a powerful MPP cluster of servers, in an environment where you can now “install” the programming language of your choice.

Sounds far-fetched?  If you are not convinced, then I highly recommend you have a look at our brand-new in-database analytic programming platform, which is deeply integrated in our parallel in-memory engine and extensible through using nearly any programming language and statistical library.

For further information on our approach to big data science, go ahead and download a copy of our technical whitepaper:  Big Data Science – The future of analytics.

Miachael Hunger

Data Science mit Neo4j und R

/0 Comments/in , , , , , , , , , /by

Traurig, aber wahr: Data Scientists verbringen 50-80% ihrer Zeit damit, Daten zu bereinigen, zu ordnen und zu bearbeiten. So bleibt nur noch wenig Zeit, um tatsächlich vorausschauende Vorhersagemodelle zu entwickeln. Vor allem bei klassischen Stacks, besteht die Datenanalyse zum Großteil darin, Zeile für Zeile in SQL zu überführen. Zeit zum Schreiben von Modell-Codes in einer statistischen Sprache wie R bleibt da kaum noch. Die langen, kryptischen SQL-Abfragen verlangsamen aber nicht nur die Entwicklungszeit. Sie stehen auch einer sinnvollen Zusammenarbeit bei Analyse-Projekten im Weg, da alle Beteiligten zunächst damit beschäftigt sind, die SQL-Abfragen der jeweils anderen zu verstehen.

Komplexität der Daten steigt

Der Grund für diese Schwierigkeiten: Die Datenstrukturen werden immer komplexer, die Vernetzung der Daten untereinander nimmt immer stärker zu. Zwängt man diese hochgradig verbundenen Datensätze in eine SQL-Datenbank, in der Beziehungen naturgemäß abstrakt über Fremdschlüssel dargestellt werden, erhält man als Ergebnis übermäßig komplizierte Schematas und Abfragen. Als Alternative gibt es jedoch einige NoSQL-Lösungen – allen voran Graphdatenbanken – die solche hochkomplexen und heterogenen Daten ohne Informationsverlust speichern können – und zwar nicht nur die Entitäten an sich, sondern auch besonders die Beziehungen der Daten untereinander.

Datenanalysen zielen immer stärker darauf ab, das Verhalten und die Wünsche von Kunden besser verstehen zu können. Die Fragen lauten z. B.:

  • Wie hoch ist die Wahrscheinlichkeit, dass ein Besucher auf eine bestimmte Anzeige klickt?
  • Welcher Kunde sollte in welchem Kontext welche Produktempfehlungen erhalten?
  • Wie kann man aus der bisherigen Interaktionshistorie des Kunden sein Ziel vorhersagen, bevor er selbst dort ankommt?
  • In welchen Beziehungen steht Nutzer A zu Nutzer B?

Menschen sind bekanntermaßen von Natur aus sozial. Einige dieser Fragen lassen sich daher beantworten, wenn man weiß, wie Personen miteinander in Verbindung stehen: Unsere Zielperson, Nutzer A ähnelt in seinem Kontext und Verhalten Benutzer B. Und da Benutzer B ein bestimmtes Produkt (z. B. ein Spielfilm) gefällt, empfehlen wir diesen Film auch Nutzer A. In diese Auswertung fließen natürlich auch noch weitere Faktoren mit ein, z. B. die Demographie und der soziale Status des Nutzers, seine Zuordnung zu Peer Groups, vorher gesehene Promotions oder seine bisherigen Interaktionen.

Visualisierung eines Graphen mit RNeo4j

Mit R und Neo4j lassen sich Graphen und Teilgraphen ganz einfach mit RNeo4j, igraph und visNetwork libraries visualisieren.

 

Das folgende Beispiel zeigt wie in einem Graphen Schauspieler und Filme sowie ihre Beziehungen zueinander anschaulich dargestellt werden können, z. B. um Empfehlungen innerhalb eines Filmportals zu generieren. Dabei sind zwei Schauspieler über eine Kante miteinander verbunden, wenn sie beide im gleichen Film mitspielen.

Im ersten Schritt werden dazu in Neo4j die Film-Datensätze importiert (Achtung: Dieser Vorgang löscht die aktuelle Datenbank).

Als nächstes wird mit Cypher eine entsprechende Liste von Beziehungen aus Neo4j gezogen. Wie man sehen kann, ist die Darstellung des gewünschten Graph-Musters innerhalb der Abfrage sehr anschaulich.

Die visNetwork Funktion erwartet sowohl Kanten-Dataframes als auch Knoten-Dataframes. Ein Knoten-Dataframe lässt sich daher über die eindeutigen Werte des Kanten-Dataframes generieren.

Im Anschluss können die Knoten- und Kanten-Dataframes in das visNetwork übertragen werden.
visNetwork(nodes, edges)

Nun kommt igraph mit ins Spiel, eine Bibliothek von Graph-Algorithmen. Durch Einbindung der Kantenliste lässt sich einfach ein igraph Graph-Objekt erstellen, das den Teilgraphen miteinschließt.

Die Größe der Knoten kann als Funktion der Edge-Betweeness-Centrality definiert werden. In visNetwork entspricht dabei jede “value”-Spalte im Knoten-Dataframe der Größe des Knoten.
nodes$value = betweenness(ig)

Mit Einführung der “Value”-Spalte werden die Knoten nun alle unterschiedlich groß dargestellt.
visNetwork(nodes, edges)

Mit Hilfe eines Community-Detection-Algorithmus lassen sich im Graphen nun Cluster finden. In diesem Beispiel wird der „Girvan-Newman”-Algorithmus verwendet, der in igraph als cluster_edge_betweenness bezeichnet wird.

In der Liste oben sind alle Schauspieler der ersten zwei Cluster zu sehen. Insgesamt konnten sechs Cluster identifiziert werden.

Durch Hinzufügen einer “Group”-Spalte im Knoten-Dataframe, werden alle Knoten in visNetwork entsprechend ihrer Gruppenzugehörigkeit farblich markiert. Diese Cluster-Zuordnung erfolgt über clusters$membership. Durch Entfernen der “Value”-Spalte lassen sich die Knoten wieder auf eine einheitliche Größe bringen.

Werden die Knoten- und Kanten-Datenframes erneut in visNetwork übertragen, sind nun alle Knoten eines Clusters in derselben Farbe dargestellt.
visNetwork(nodes, edges)

Mit diesem Workflow lassen sich Teilgraphen in Neo4j einfach abfragen und Cluster-Algorithmen einfach darstellen.

Generell eignen sich Graphdatenbanken wie Neo4j besonders gut, um stark vernetzte und beliebig strukturierte Informationen zu handhaben – egal ob es sich um Schauspieler, Filme, Kunden, Produkte, Kreditkarten oder Bankkonten handelt. Zudem können sowohl den Knoten als auch den Kanten beliebige qualitative und quantitative Eigenschaften zugeordnet werden. Beziehungen zwischen Daten sind also nicht mehr bloße Strukturinformationen, sondern stehen vielmehr im Zentrum des Modells.

Cypher: intuitiv nutzbare Programmiersprache

Die Zeiten, in denen Data Science zum Großteil aus Datenbereinigung und -mapping besteht, sind damit vorbei. Mit dem entsprechenden Ansatz laufen Entwicklungsprozesse deutlich schneller und einfacher ab. Data Scientists kommen mit weniger Code schneller ans Ziel und können mehr Zeit in das tatsächliche Entwickeln von relevanten Modellen investieren. Dabei nutzen sie die Flexibilität einer quelloffenen NoSQL-Graphdatenbank wie Neo4j kombiniert mit der Reife und weiten Verbreitung der Statistiksprache R für statistisches Rechnen und Visualisierung. Programmierer müssen nicht mehr stundenlang komplexe SQL-Anweisungen schreiben oder den ganzen Tag damit verbringen, eine Baumstruktur in SQL zu überführen. Sie benutzen einfach Cypher, eine musterbasierte, für Datenbeziehungen und Lesbarkeit optimierte Abfragesprache und legen los.

Benjamin Aunkofer

3D-Visualisierung von Graphen

/2 Comments/in , , , /by

Die Graphentheorie ist ein wichtiger Teil vieler Methoden und Anwendungsgebiete für Big Data Analytics. Graphen sind mathematisch beschreibbare Strukturen, ohne die im Ingenieurwesen nichts funktionieren würde. Ein Graph besteht aus zwei Knoten (Ecken, engl. Vertex), die über eine Kante (engl. Edge) verbunden sind.

Auf Graphen stoßen Data Scientists beispielsweise bei der Social Media Analyse, beim Aufbau von Empfehlungssystemen (das Amazon-Prinzip) oder auch bei Prozessanalysen (Process Mining). Aber auch einige Big Data Technologien setzen ganz grundlegend auf Graphen, beispielsweise einige NoSQL-Datenbanken wie die Graphendatenbank Neo4j und andere.

Graphen können nicht nur einfache Verkettungen, sondern komplexe Netzwerke abbilden. Das Schöne daran ist, dass Graphen nicht ganz so abstrakt sind, wie viele andere Bereiche der Mathematik, sondern sich wunderbar visualisieren lassen und wir auch in unserem Vorstellungsvermögen recht gut mit ihnen “arbeiten” können.

ubigraph-node-visualization2

Mit der Visualisierung von Graphen, können wir uns Muster vor Augen führen und ein visuelles Data Mining betreiben. Iterative und auch rekursive Vorgänge sowie Abhängigkeiten zwischen einzelnen Objekten/Zuständen können visuell einfach besser verstanden werden. Bei besonders umfangreichen und zugleich vielfältigen Graphen ist eine Visualisierung in drei bzw. vier Dimensionen (x-, y-, z-Dimensionen + Zeit t) nicht nur schöner anzusehen, sondern kann auch sehr dabei helfen, ein Verständnis (z. B. über Graphen-Cluster) zu erhalten. Read more

Thomas Kalippke

Finance Controlling und NoSQL Data Science – zwei Welten treffen aufeinander

/0 Comments/in , , , , , /by

Wenn ein konservativer, geschäftskritischer Fachbereich auf neue Technologien mit anderen, kreativen Möglichkeiten trifft, führt das zu Reibungen, aber auch zu Ergebnissen, die andere Personen auf neue Ideen bringen können. Bei dem hier geschilderten Anwendungsfall geht es um die Ermittlung einer kurzfristigen Erfolgrechnung (KER) unter Nutzung von NoSQL-Technologien. Einer Aufgabenstellung, die für beide Seiten sehr lehrreich war.

1-opener-image

Erinnern Sie sich noch an die Werbespots von Apple mit Justin Long und John Hodgman als menschlicher Apple und Personal Computer? Ähnlich wie in den Werbespots sind die beiden Bereiche Finance Controlling und Data Science zu betrachten. Der eine eher konservativ, geschäftskritisch, mit etablierten Methoden und Verfahren; der andere mit einem Zoo voller verschiedener Werkzeuge für den kreativen Umgang mit Daten. Insbesondere wenn dann auch noch NoSQL ins Spiel kommt, mag man glauben, dass keinerlei Berührungspunkte existieren. Dennoch eignen sich neue Technologien auch für etablierte Bereiche und können diese bereichern und auf neue Ideen bringen.

Bei einer kurzfristigen Erfolgsrechnung (sog. KER) handelt es sich um die Aufstellung kaufmännischer Kennzahlen und den Vergleich über Zeiträume. Unter anderem wird hierbei auch häufig von Deckungsbeitragsrechnung oder Betriebsergebnisrechnung gesprochen. Eine KER wird vom Controlling daher aus der kaufmännischen Software generiert (z.B. SAP FiCo) und zumeist nur als Datei oder tatsächlich noch auf Papier an Bereichsleiter oder die Geschäftsführung übergeben.

Ergänzend zu der standardisierten Aufstellung sollte es in dem hier geschilderten Fall möglich sein, dass die Berechnung der KER unter Berücksichtigung von Filtermöglichkeiten ad hoc durch einen Endanwender möglich sein soll. Das bedeutet, dass nicht mehr nur ausschließlich das Controlling die Erfolgsrechnung generieren kann, sondern auch jeder Fachbereich selbständig für sich. Dementsprechend müssen die Werkzeuge aus dem Data Science einmal konfiguriert und benutzerfreundlich bereitgestellt werden.

Die Generierung einer Erfolgrechnung mag auf den ersten Blick nicht direkt als Aufgabe für einen Data Scientist wirken, schließlich sind die Daten und deren Aufbau bekannt, genauso wie die Form des Endergebnisses. Dennoch stellen sich der Vielzahl bekannter Variablen, genauso viele unbekannte gegenüber. Denn wenn ein relationales Modell einfach in eine neue Technologie (NoSQL) überführt wird, hat man nichts dabei gewonnen. Erst der kreative Einsatz neuer Methoden und der etwas andere Umgang mit bekannten Daten führt zu einer Verbesserung und neuen Idee.

Daten

Bei den zu verarbeitenden Daten handelt es sich um Buchungsdaten (SAP Export), Plandaten (csv-Export aus einem Planungssystem) und um manuelle Informationen aus Excel (als csv-Dateien). Insgesamt sind es mindestens neun Datenquellen unterschiedlicher Qualität. Insbesondere bei den manuell erstellten Excel-Daten muss mehrfach geprüft werden, ob die Dateien in dem vereinbarten Format vorliegen. (Gerade bei manuell gepflegten Daten greift Murphys Law – immer!)

Die Inhalte der Excel-Daten reichern die anderen beiden Quelldaten durch weitere Informationen an. Hierbei handelt es sich u.a. um Mappinginformationen zur Ergänzung kurzer Schreibweisen oder maskierter Inhalte, damit diese durch Endanwender gelesen werden können. Beispielsweise sind Kostenstellen in Unternehmensbereiche, Abteilungen und Produktgruppen zu entschlüsseln.

Bei den Buchungsdaten aus dem SAP-System handelt es sich um die monatlichen Saldenwerte eines Kontos, die granular auf Kostenstelle, Marke, Periode und weitere Merkmale heruntergebrochen wurden. Damit wird also nicht pro Monat ein Kontensaldo übergeben, sondern eine Vielzahl von Salden je Konto, je nachdem, wie viele Merkmale geliefert werden.

Beispiel für eine Zeile aus dem SAP-Export:

Je Periode (im Regelfall: Monate) wird eine Datei geliefert; dabei ist aus dem Dateinamen die Betriebszugehörigkeit und die Periode abzulesen. Es gilt zudem, dass ein Unternehmen in mehr als 12 Perioden pro Jahr Buchungen durchführen kann (in diesem Fall bis zu 16).

Die Buchungsinformationen und alle weiteren Dateien werden mit einer Java-Anwendung in die NoSQL-Datenbank importiert. Hierbei wird auf eine multi-model Datenbank zurückgegriffen, um im späteren Verlauf verschiedene NoSQL-Technologien nutzen zu können (z.B. documentstore, graphdb, multi-value und bi-temporal).2-KER-Modell

Modellierung

Für jede Datenquelle wird eine Datensatzart genutzt. Relational gesprochen bedeutet das eine Tabelle je Quelle oder für Benutzer von document stores: eine “collection” für gleichartige Dokumente.

Bei der gewählten Datenbank wird allerdings nicht zwischen verschiedenen “collections” unterschieden. Nur durch ein Feld je Datensatz wird der Typ des Datensatzes festgelegt. In der Anwendung wird dieses Feld interpretiert und der Datensatz entsprechend angezeigt (anhand von Templates für die JSON-Ausgabe). Da – wie bei document stores üblich – die Dokumente ein dynamisches Schema aufweisen, können sich alle Datensätze in ihrer Art und Ausprägung (Key/Values) unterscheiden.

Als Ergänzung zu den bisherigen Quelldaten werden innerhalb der Datenbank weitere Datensätze für das Layout der KER-Ausgabe angelegt. Diese beschreiben im Prinzip nur die Reihenfolge und den Inhalt der späteren Ausgabe (dazu später mehr).

Nach dem Import der Datensätze werden innerhalb der Datenbank zwischen den Datensätzen Verlinkungen (Graphen) etabliert. So zeigen beispielsweise alle Buchungen auf das jeweils betroffene Konto oder eine KER-Ergebniszeile auf eine Kontengruppe. Aus der Skizze zum Datenmodell können die relevanten Verlinkungen abgelesen werden.

Anzumerken ist hier, dass ein Konto in mehreren Kontengruppen auftreten kann. Eine einzelne n:m-Verlinkung wird daher in diesem Fall über separate Datensätze abgehandelt und nicht in einem Datensatz mit einer Unterstruktur. Das wäre zwar auch möglich, erschwert und verlangsamt allerdings etwaige Aktualisierungen, da die csv-Quelle nur eine Zeile je Zuweisung liefert.

Für die Speicherung der Buchungsinformationen wird auf die Funktionalität der bi-temporalen Datenhaltung 3-bitemporalzurückgegriffen. Hierbei erhält jeder Feldinhalt in einem Datensatz (optional) den Vermerk des Gültigkeitszeitpunktes. Neben dem Transaktionszeitpunkt (wann wurden die Daten gespeichert) ist also auch erkennbar ab (oder auch bis) wann ein Inhalt gültig ist. Dabei ist zu beachten, dass “nicht-gültig” etwas anderes ist, als “falsch”. In dieser Art der Verwendung steht “nicht-gültig” für “nicht mehr aktuell” oder auch “noch nicht aktuell”.

Durch diese Art der Datensatzspeicherung reduziert sich die Anzahl der Buchungsdatensätze auf einen Bruchteil des ursprünglichen Datenbestandes. Beispiel: Es werden jeden Monat 10.000 Buchungen geliefert. Für 16 Monate ergeben sich somit 160.000 Datensätze. Da diese bi-temporal gespeichert werden, bleibt es bei 10.000 Datensätzen in der Datenbank mit je max. 16 Gültigkeitswerten je Feld (für jede Periode).

Hier sei noch angemerkt, dass ein Wert so lange gültig ist, bis ein anderer Wert diesen ergänzt. Wird also für Januar ein bestimmter Wert geliefert und im Laufe des Jahres nicht geändert, bleibt dieser bestehen und wird nicht nochmal gespeichert. Statt 16 Einträgen, bleibt es also bei einem.

Ergänzend dazu stellt sich die Frage zum Umgang mit den Perioden 13 bis 16. Da ein Jahr nur 12 Monate besitzt, können diese nicht einfach mit einem falschen Datum gespeichert werden. Hier greift allerdings der Umstand, dass speziell in diesem Anwendungsfall erst am Ende eines Monats durch den Monatsabschluss alle Buchungen korrekt sind. Innerhalb eines Monats ist das nicht der Fall. Es gibt also genau einen (und nur einen) korrekten Zeitpunkt, an dem die Werte korrekt und gültig sind. Die Werte einer Buchung zu diesem Zeitpunkt werden also nur zu einem Tag in dem Datensatz gespeichert.

Schaut man sich nun den Screenshot des Datensatzes mit den Monatswerten an, fällt auf, dass die Salden-Werte (im Feld “SAP-Werte”) jeweils zum Zweiten eines Monats gespeichert wurden. Da es nur einen gültigen Wert je Monat gibt, ist das Datum irrelevant (es hätte auch der Dritte oder Vierte des Monats sein können). Für jede Periode größer 12 wurde einfach vorgesehen, dass diese ab dem 13.12. eines Jahres hinterlegt werden (d.h. für Periode 14 der 14.12.; Periode 15 der 15.12. usw.). Und da zum Anfang eines Jahres alle Buchungen zu bestimmten Konten auf Null gesetzt werden müssen (also zum 01.01.) bietet sich der Zweite eines Monats an.

Nach dem Einlesen aller gelieferten csv-Dateien, erfolgt die Erzeugung von weiteren Datensätzen für das Layout der Ergebnisrechnung. Diese werden einmalig angelegt und können über eine Benutzeroberfläche vom Anwender angepasst werden.

Wie in der Skizze zum Datenmodell zu erkennen, besteht das Layout der KER aus zwei Datensatztypen. Einmal aus der Layout-Definition (nur ein Datensatz) und zum Zweiten aus mehreren Ergebniszeilen, die jeweils über einen Datensatz beschrieben werden.

4-KER-Layout 5-KER-ErgZeile

 

 

 

 

 

 

 

Beide Datensatztypen bestehen dabei fast ausschließlich aus Linkfeldern (Graphen). Das KER-Layout verweist damit auf die beteiligten Zeilen in der Reihenfolge, wie sie später angezeigt werden; ein Datensatz für eine KER-Zeile verweist auf die jeweiligen Kontengruppen.

In einem zusätzlichen Textfeld einer KER-Zeile wird zudem die Formel eingetragen, über die bei der späteren Anzeige ad hoc das Ergebnis der jeweiligen Zeile berechnet wird (in dem abgebildeten, einfachen Fall nur die Summe zweier Kontengruppen). Dazu steht serverseitig die Bibliothek der Google V8 Javascript-Engine zur Verfügung.

Der Screenshot der Ergebniszeile zeigt zudem die Verwendung von “multi-values” in einem Datensatz. Hierbei können verschiedene Inhalte in einem Feld abgelegt und auch mit anderen Feldern kombiniert werden. In diesem Fall gehören jeweils eine Kontengruppe und der prozentuale Bezug zueinander. Andere Anwendungsfälle sind bspw. die Bankverbindungen oder Kontaktdaten einer Person, da diese auch aus mehreren, zusammengehörenden Feldern bestehen und jede Person mehrere besitzen kann.

Bis hierher wurden die Daten importiert, das Datenmodell aufgebaut und die Datensätze miteinander verlinkt. Aus der NoSQL-Trickkiste nutzen wir die bitemporale Datenhaltung, Graphen, multi-values und document stores. Dadurch wird die Anzahl der Datensätze reduziert und das Datenmodell vereinfacht. Im nächsten Schritt geht es darum, die KER-Ausgabe aufzubereiten und die Ergebnisse – unter Berücksichtigung von Filtermöglichkeiten – mit Hilfe von serverseitigem JavaScript zu berechnen.

Anwendung

Der Anwendungsfall KER-Liste ist im Rahmen eines Gesamtprojektes ein Teilaspekt. Daher wurde auf vorhandene Werkzeuge zurückgegriffen, um mit den gegebenen Mitteln den maximalen Nutzen zu erreichen.

Als System steht eine multi-model NoSQL-Platform zur Verfügung, die mehrere Bereiche der NoSQL-Welt abdeckt und nicht nur eine Datenbank beinhaltet, sondern gleich ein ganzes Arsenal an Werkzeugen, um Lösungen zu erschaffen. Dazu gehört unter anderem auch eine standardisierte Webanwendung, in der durch einfache Konfigurationen Anwendungen definiert werden und die es ermöglicht, die serverseitige Bibliothek der Google V8 Javascript-Engine zu nutzen. Dadurch wird ein Großteil des Anwendungsfalles aus der Softwareentwicklung herausgelöst und an den Fachbereich übertragen.

Hierbei ist zu beachten, dass der Data Scientist sich nicht von dem Fachthema vollständig lösen kann. Ein Grundverständnis ist notwendig, um zu verstehen, wie die Problemlage ist und was das Endergebnis sein soll. Genauso muss der Fachbereich Grundlagen des Datenhandlings und des Systems verstehen. Nur beide zusammen können in einer transparenten Kommunikationsstruktur Lösungen erarbeiten.

Nach der Konfiguration des Datenmodells und dem Import der Daten wurde alles Weitere in der Standardanwendung der NoSQL-Plattform umgesetzt. Dieses beinhaltet unter anderem die Konfiguration der Erfolgsrechnung, wie auch den JavaScript-Teil zur Ermittlung der Ergebnisse und später auch die grafische Ausgabe in Form eines Dashboards mit den gleichen Filter-Möglichkeiten der KER-Ausgabe.

Um innerhalb der Anwendung die kurzfristige Erfolgsrechnung zu erzeugen, wird auf die Funktion von Listen zurückgegriffen. Diese können, ausgehend von einem Datensatz, die Graph-Strukturen auflösen und so hierarchische Ausgaben erzeugen. Als Ergänzung dazu ist eine Integration von Javascript innerhalb der Listen möglich, so dass Berechnungen serverseitig durchgeführt und Ergebnisse zur Anzeige gebracht werden können. Darüber hinaus ist die Nutzung über eine HTTP API möglich, um die Anwendung ggf. später durch weitere Funktionen zu erweitern.6-KER-Modell-Hierarchisch

Ausgehend von dem definierten Datensatz für das KER-Layout ermöglicht die Listenfunktionalität die Konfiguration von sog. Sublisten (also Listen in Listen in Listen in …). Hierbei verfolgt die Liste die Graphenstruktur und bringt die jeweiligen Datensätze zur Anzeige. Durch das genutzte Modell ist der Startpunkt somit ein einzelner Datensatz, zu dem dann hierarchisch alle weiteren Datensätze dazu geladen werden.

Die entstehende Baumstrukur ist im ersten Schritt leer und muss im Anschluss durch JavaScript gefüllt werden. Dazu wird einerseits auf die Inhalte aus der untersten Ebene zurückgegriffen, um die Saldenwerte zu lesen; andererseits auch auf die hinterlegten Formeln jeder Ergebniszeile, um mit den Summen der Kontengruppen die Ergebnisse zu ermitteln.

Das Zauberwort bei der Nutzung von Javascript heißt hier “eval”. Durch diese Funktion werden Strings als Script evaluiert. Im Detail werden durch reguläre Ausdrücke die Begriffe in den Formeln (Namen der Kontengruppen) durch die Summenwerte der jeweiligen Kontengruppe ersetzt und danach mit Hilfe von “eval” ausgeführt. Das Ergebnis wird dann an die entsprechende Position in der Liste geschrieben.

Im Weiteren erhalten bestimmte Werte noch unterschiedliche Formate, um den kosmetischen Aspekt zu erfüllen. Am Ende erhält der Anwender eine KER-Liste.

7-ker-Beispiel

Filter

Die Generierung einer vollständigen KER dauert bis zu fünf Sekunden. Dabei liegen bis zu 40.000 Buchungsdatensätze zu Grunde. Durch einen interaktiven Filter kann der Anwender den Umfang der Liste und die Berechnung entsprechend einschränken. Folgende Felder aus den Buchungsdatensätzen stehen dabei für Filterkombinationen zur Verfügung:

  • Buchungskreise (Filialen): 14
  • Geschäftsbereich (Abteilung): 32
  • Kostenstelle: 56
  • Marke: 9
  • Absatzkanal: 12

Hierbei kann der Anwender jede beliebige Kombination in jeder erdenklichen Reihenfolge zur Filterung nutzen. Die Liste wird entsprechend neu berechnet und in unter fünf Sekunden zur Anzeige gebracht (wegen der reduzierten Datenmenge häufig in unter einer Sekunde).

Als Ergänzung zu den Filtermöglichkeiten kann auch der zeitliche Aspekt berücksichtigt werden. Da die Buchungsinformationen bitemporal gespeichert wurden, besteht in der Liste die Möglichkeit, ein beliebiges Datum zu wählen und sich die Werte dazu anzeigen zu lassen.

Gesamtfunktion und Ausblick

Durch den generalistischen Ansatz des Datenmodells und der gewählten Datenbank konnte nicht nur die kurzfristige Erfolgsrechnung in der üblichen, tabellarischen Form ausgegeben werden. Ferner wurde eine grafische Ausgabe mit der Bibliothek d3.js realisiert, so dass jede Führungskraft in der Lage ist, eine ad hoc Analyse durchzuführen. (Ich spreche hier gerne von KRV-tauglich. “Kinder, Rentner, Vorstände”).

Derzeitig wird JavaScript innerhalb von Listen genutzt, um bei Bedarf Werte zu errechnen. Als Ausblick steht hier in Kürze die Möglichkeit zur Verfügung, dass Scripte auch innerhalb von Datensätze abgelegt und autonom von der Datenbank selber ausgeführt werden. Das hat zur Folge, dass Objekte (Datensätze) Algorithmen beinhalten und selbständig Informationen suchen und generieren.

Verwendete NoSQL-Methoden

  • document store
  • GraphDB
  • multi-Value
  • Bitemporal

Erwähnte Technologien, Produkte und Marken in diesem Artikel

Der hier beschriebene Anwendungsfall soll zeigen, dass Data Science nicht nur Endergebnisse liefert, die quasi durch eine “black box” entstanden, dessen Vorgehensweise nur eingeweihte Personen beherrschen und beurteilen können. Es ist vielmehr so, dass die “Wissenschaft” das Wissen dafür schafft, damit ein “normaler” Anwender mit den Daten umgehen kann und einen Mehrwert daraus erhält.