Posts

Data Science Knowledge Stack – Was ein Data Scientist können muss

September 11, 2017/7 Comments/in Data Mining, Data Science, Data Science Hack, Data Science News, Education / Certification, Gerneral, Insights, Main Category /by Benjamin Aunkofer

Was muss ein Data Scientist können? Diese Frage wurde bereits häufig gestellt und auch häufig beantwortet. In der Tat ist man sich mittlerweile recht einig darüber, welche Aufgaben ein Data Scientist für Aufgaben übernehmen kann und welche Fähigkeiten dafür notwendig sind. Ich möchte versuchen, diesen Konsens in eine Grafik zu bringen: Ein Schichten-Modell, ähnlich des OSI-Layer-Modells (welches übrigens auch jeder Data Scientist kennen sollte).
Ich gebe Einführungs-Seminare in Data Science für Kaufleute und Ingenieure und bei der Erläuterung, was wir in den Seminaren gemeinsam theoretisch und mit praxisnahen Übungen erarbeiten müssen, bin ich auf die Idee für dieses Schichten-Modell gekommen. Denn bei meinen Seminaren fängt es mit der Problemstellung bereits an, ich gebe nämlich Seminare für Data Science für Business Analytics mit Python. Also nicht beispielsweise für medizinische Analysen und auch nicht mit R oder Julia. Ich vermittle also nicht irgendein Data Science, sondern eine ganz bestimmte Richtung.

Ein Data Scientist muss bei jedem Data Science Vorhaben Probleme auf unterschiedlichsten Ebenen bewältigen, beispielsweise klappt der Datenzugriff nicht wie geplant oder die Daten haben eine andere Struktur als erwartet. Ein Data Scientist kann Stunden damit verbringen, seinen eigenen Quellcode zu debuggen oder sich in neue Data Science Pakete für seine ausgewählte Programmiersprache einzuarbeiten. Auch müssen die richtigen Algorithmen zur Datenauswertung ausgewählt, richtig parametrisiert und getestet werden, manchmal stellt sich dabei heraus, dass die ausgewählten Methoden nicht die optimalen waren. Letztendlich soll ein Mehrwert für den Fachbereich generiert werden und auch auf dieser Ebene wird ein Data Scientist vor besondere Herausforderungen gestellt.

Read this article in English:
“Data Science Knowledge Stack – Abstraction of the Data Scientist Skillset”

Data Science Knowledge Stack

Mit dem Data Science Knowledge Stack möchte ich einen strukturierten Einblick in die Aufgaben und Herausforderungen eines Data Scientists geben. Die Schichten des Stapels stellen zudem einen bidirektionalen Fluss dar, der von oben nach unten und von unten nach oben verläuft, denn Data Science als Disziplin ist ebenfalls bidirektional: Wir versuchen gestellte Fragen mit Daten zu beantworten oder wir schauen, welche Potenziale in den Daten liegen, um bisher nicht gestellte Fragen zu beantworten.

Der Data Science Knowledge Stack besteht aus sechs Schichten:

Database Technology Knowledge

Ein Data Scientist arbeitet im Schwerpunkt mit Daten und die liegen selten direkt in einer CSV-Datei strukturiert vor, sondern in der Regel in einer oder in mehreren Datenbanken, die ihren eigenen Regeln unterliegen. Insbesondere Geschäftsdaten, beispielsweise aus dem ERP- oder CRM-System, liegen in relationalen Datenbanken vor, oftmals von Microsoft, Oracle, SAP oder eine Open-Source-Alternative. Ein guter Data Scientist beherrscht nicht nur die Structured Query Language (SQL), sondern ist sich auch der Bedeutung relationaler Beziehungen bewusst, kennt also auch das Prinzip der Normalisierung.

Andere Arten von Datenbanken, sogenannte NoSQL-Datenbanken (Not only SQL) beruhen auf Dateiformaten, einer Spalten- oder einer Graphenorientiertheit, wie beispielsweise MongoDB, Cassandra oder GraphDB. Einige dieser Datenbanken verwenden zum Datenzugriff eigene Programmiersprachen (z. B. JavaScript bei MongoDB oder die graphenorientierte Datenbank Neo4J hat eine eigene Sprache namens Cypher). Manche dieser Datenbanken bieten einen alternativen Zugriff über SQL (z. B. Hive für Hadoop).

Ein Data Scientist muss mit unterschiedlichen Datenbanksystemen zurechtkommen und mindestens SQL – den Quasi-Standard für Datenverarbeitung – sehr gut beherrschen.

Data Access & Transformation Knowledge

Liegen Daten in einer Datenbank vor, können Data Scientists einfache (und auch nicht so einfache) Analysen bereits direkt auf der Datenbank ausführen. Doch wie bekommen wir die Daten in unsere speziellen Analyse-Tools? Hierfür muss ein Data Scientist wissen, wie Daten aus der Datenbank exportiert werden können. Für einmalige Aktionen kann ein Export als CSV-Datei reichen, doch welche Trennzeichen und Textqualifier können verwendet werden? Eventuell ist der Export zu groß, so dass die Datei gesplittet werden muss.
Soll eine direkte und synchrone Datenanbindung zwischen dem Analyse-Tool und der Datenbank bestehen, kommen Schnittstellen wie REST, ODBC oder JDBC ins Spiel. Manchmal muss auch eine Socket-Verbindung hergestellt werden und das Prinzip einer Client-Server-Architektur sollte bekannt sein. Auch mit synchronen und asynchronen Verschlüsselungsverfahren sollte ein Data Scientist vertraut sein, denn nicht selten wird mit vertraulichen Daten gearbeitet und ein Mindeststandard an Sicherheit ist zumindest bei geschäftlichen Anwendungen stets einzuhalten.

Viele Daten liegen nicht strukturiert in einer Datenbank vor, sondern sind sogenannte unstrukturierte oder semi-strukturierte Daten aus Dokumenten oder aus Internetquellen. Auch hier haben wir es mit Schnittstellen zutun, ein häufiger Einstieg für Data Scientists stellt beispielsweise die Twitter-API dar. Manchmal wollen wir Daten in nahezu Echtzeit streamen, beispielsweise Maschinendaten. Dies kann recht anspruchsvoll sein, so das Data Streaming beinahe eine eigene Disziplin darstellt, mit der ein Data Scientist schnell in Berührung kommen kann.

Programming Language Knowledge

Programmiersprachen sind für Data Scientists Werkzeuge, um Daten zu verarbeiten und die Verarbeitung zu automatisieren. Data Scientists sind in der Regel keine richtigen Software-Entwickler, sie müssen sich nicht um Software-Sicherheit oder -Ergonomie kümmern. Ein gewisses Basiswissen über Software-Architekturen hilft jedoch oftmals, denn immerhin sollen manche Data Science Programme in eine IT-Landschaft integriert werden. Unverzichtbar ist hingegen das Verständnis für objektorientierte Programmierung und die gute Kenntnis der Syntax der ausgewählten Programmiersprachen, zumal nicht jede Programmiersprache für alle Vorhaben die sinnvollste ist.

Auf dem Level der Programmiersprache gibt es beim Arbeitsalltag eines Data Scientists bereits viele Fallstricke, die in der Programmiersprache selbst begründet sind, denn jede hat ihre eigenen Tücken und Details entscheiden darüber, ob eine Analyse richtig oder falsch abläuft: Beispielsweise ob Datenobjekte als Kopie oder als Referenz übergeben oder wie NULL-Werte behandelt werden.

Data Science Tool & Library Knowledge

Hat ein Data Scientist seine Daten erstmal in sein favorisiertes Tool geladen, beispielsweise in eines von IBM, SAS oder in eine Open-Source-Alternative wie Octave, fängt seine Kernarbeit gerade erst an. Diese Tools sind allerdings eher nicht selbsterklärend und auch deshalb gibt es ein vielfältiges Zertifizierungsangebot für diverse Data Science Tools. Viele (wenn nicht die meisten) Data Scientists arbeiten überwiegend direkt mit einer Programmiersprache, doch reicht diese alleine nicht aus, um effektiv statistische Datenanalysen oder Machine Learning zu betreiben: Wir verwenden Data Science Bibliotheken, also Pakete (Packages), die uns Datenstrukturen und Methoden als Vorgabe bereitstellen und die Programmiersprache somit erweitern, damit allerdings oftmals auch neue Tücken erzeugen. Eine solche Bibliothek, beispielsweise Scikit-Learn für Python, ist eine in der Programmiersprache umgesetzte Methodensammlung und somit ein Data Science Tool. Die Verwendung derartiger Bibliotheken will jedoch gelernt sein und erfordert für die zuverlässige Anwendung daher Einarbeitung und Praxiserfahrung.

Geht es um Big Data Analytics, also die Analyse von besonders großen Daten, betreten wir das Feld von Distributed Computing (Verteiltes Rechnen). Tools (bzw. Frameworks) wie Apache Hadoop, Apache Spark oder Apache Flink ermöglichen es, Daten zeitlich parallel auf mehren Servern zu verarbeiten und auszuwerten. Auch stellen diese Tools wiederum eigene Bibliotheken bereit, für Machine Learning z. B. Mahout, MLlib und FlinkML.

Data Science Method Knowledge

Ein Data Scientist ist nicht einfach nur ein Bediener von Tools, sondern er nutzt die Tools, um seine Analyse-Methoden auf Daten anzuwenden, die er für die festgelegten Ziele ausgewählt hat. Diese Analyse-Methoden sind beispielweise Auswertungen der beschreibenden Statistik, Schätzverfahren oder Hypothesen-Tests. Etwas mathematischer sind Verfahren des maschinellen Lernens zum Data Mining, beispielsweise Clusterung oder Dimensionsreduktion oder mehr in Richtung automatisierter Entscheidungsfindung durch Klassifikation oder Regression.

Maschinelle Lernverfahren funktionieren in der Regel nicht auf Anhieb, sie müssen unter Einsatz von Optimierungsverfahren, wie der Gradientenmethode, verbessert werden. Ein Data Scientist muss Unter- und Überanpassung erkennen können und er muss beweisen, dass die Vorhersageergebnisse für den geplanten Einsatz akkurat genug sind.

Spezielle Anwendungen bedingen spezielles Wissen, was beispielsweise für die Themengebiete der Bilderkennung (Visual Computing) oder der Verarbeitung von menschlicher Sprache (Natural Language Processiong) zutrifft. Spätestens an dieser Stelle öffnen wir die Tür zum Deep Learning.

Fachexpertise

Data Science ist kein Selbstzweck, sondern eine Disziplin, die Fragen aus anderen Fachgebieten mit Daten beantworten möchte. Aus diesem Grund ist Data Science so vielfältig. Betriebswirtschaftler brauchen Data Scientists, um Finanztransaktionen zu analysieren, beispielsweise um Betrugsszenarien zu erkennen oder um die Kundenbedürfnisse besser zu verstehen oder aber, um Lieferketten zu optimieren. Naturwissenschaftler wie Geologen, Biologen oder Experimental-Physiker nutzen ebenfalls Data Science, um ihre Beobachtungen mit dem Ziel der Erkenntnisgewinnung zu machen. Ingenieure möchten die Situation und Zusammenhänge von Maschinenanlagen oder Fahrzeugen besser verstehen und Mediziner interessieren sich für die bessere Diagnostik und Medikation bei ihren Patienten.

Damit ein Data Scientist einen bestimmten Fachbereich mit seinem Wissen über Daten, Tools und Analyse-Methoden ergebnisorientiert unterstützen kann, benötigt er selbst ein Mindestmaß an der entsprechenden Fachexpertise. Wer Analysen für Kaufleute, Ingenieure, Naturwissenschaftler, Mediziner, Juristen oder andere Interessenten machen möchte, muss eben jene Leute auch fachlich verstehen können.

Engere Data Science Definition

Während die Data Science Pioniere längst hochgradig spezialisierte Teams aufgebaut haben, suchen beispielsweise kleinere Unternehmen eher den Data Science Allrounder, der vom Zugriff auf die Datenbank bis hin zur Implementierung der analytischen Anwendung das volle Aufgabenspektrum unter Abstrichen beim Spezialwissen übernehmen kann. Unternehmen mit spezialisierten Daten-Experten unterscheiden jedoch längst in Data Scientists, Data Engineers und Business Analysts. Die Definition für Data Science und die Abgrenzung der Fähigkeiten, die ein Data Scientist haben sollte, schwankt daher zwischen der breiteren und einer engeren Abgrenzung.

Die engere Betrachtung sieht vor, dass ein Data Engineer die Datenbereitstellung übernimmt, der Data Scientist diese in seine Tools lädt und gemeinsam mit den Kollegen aus dem Fachbereich die Datenanalyse betreibt. Demnach bräuchte ein Data Scientist kein Wissen über Datenbanken oder APIs und auch die Fachexpertise wäre nicht notwendig…

In der beruflichen Praxis sieht Data Science meiner Erfahrung nach so nicht aus, das Aufgabenspektrum umfasst mehr als nur den Kernbereich. Dieser Irrtum entsteht in Data Science Kursen und auch in Seminaren – würde ich nicht oft genug auf das Gesamtbild hinweisen. In Kursen und Seminaren, die Data Science als Disziplin vermitteln wollen, wird sich selbstverständlich auf den Kernbereich fokussiert: Programmierung, Tools und Methoden aus der Mathematik & Statistik.

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

March 2, 2016/1 Comment/in Big Data, Business Intelligence, Data Science News, InMemory, NoSQL, Tools /by Mathias Golombek

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?

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 scientists, 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.

Data Science mit Neo4j und R

February 18, 2016/0 Comments/in Data Mining, Data Science, Data Science Hack, Database, Graph Database, Neo4J, NoSQL, R Statistics, Tools, Tutorial /by Miachael Hunger

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.

library(igraph)

library(visNetwork)

library(RNeo4j)

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).

graph = startGraph("http://localhost:7474/db/data/")

importSample(graph, "movies", input=F)

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.

query = "

MATCH (p1:Person)-[:ACTED_IN]->(:Movie)<-[:ACTED_IN]-(p2:Person)

WHERE p1.name < p2.name

RETURN p1.name AS from, p2.name AS to, COUNT(*) AS weight

edges = cypher(graph, query)

head(edges)

## from to weight

## 1 Brooke Langton Keanu Reeves 1

## 2 Jack Nicholson Kevin Bacon 1

## 3 Jerry O'Connell Kiefer Sutherland 1

## 4 Oliver Platt Sam Rockwell 1

## 5 John Goodman Susan Sarandon 1

## 6 Gary Sinise Kevin Bacon 1

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.

nodes = data.frame(id=unique(c(edges$from, edges$to)))

nodes$label = nodes$id

head(nodes)

## id label

## 1 Brooke Langton Brooke Langton

## 2 Jack Nicholson Jack Nicholson

## 3 Jerry O'Connell Jerry O'Connell

## 4 Oliver Platt Oliver Platt

## 5 John Goodman John Goodman

## 6 Gary Sinise Gary Sinise

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.

ig = graph_from_data_frame(edges, directed=F)

## IGRAPH UNW- 102 362 --

## + attr: name (v/c), weight (e/n)

## + edges (vertex names):

## [1] Brooke Langton --Keanu Reeves

## [2] Jack Nicholson --Kevin Bacon

## [3] Jerry O'Connell --Kiefer Sutherland

## [4] Oliver Platt --Sam Rockwell

## [5] John Goodman --Susan Sarandon

## [6] Gary Sinise --Kevin Bacon

## [7] J.T. Walsh --Noah Wyle

## [8] Jim Broadbent --Tom Hanks

## + ... omitted several edges

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)

head(nodes)

## id label value

## 1 Brooke Langton Brooke Langton 0.000000

## 2 Jack Nicholson Jack Nicholson 511.443714

## 3 Jerry O'Connell Jerry O'Connell 154.815234

## 4 Oliver Platt Oliver Platt 20.643840

## 5 John Goodman John Goodman 1.659259

## 6 Gary Sinise Gary Sinise 33.723499

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.

clusters = cluster_edge_betweenness(ig)

clusters[1:2]

## $`1`

## [1] "Brooke Langton" "Liv Tyler" "Charlize Theron"

## [4] "Emil Eifrem" "Dina Meyer" "Diane Keaton"

## [7] "Keanu Reeves" "Gene Hackman" "Ice-T"

## [10] "Al Pacino" "Carrie-Anne Moss" "Clint Eastwood"

## [13] "Orlando Jones" "Takeshi Kitano" "Laurence Fishburne"

## [16] "Richard Harris"

## $`2`

## [1] "Jack Nicholson" "Jerry O'Connell" "J.T. Walsh"

## [4] "Renee Zellweger" "Kiefer Sutherland" "Cuba Gooding Jr."

## [7] "Marshall Bell" "Aaron Sorkin" "Kevin Bacon"

## [10] "Kevin Pollak" "Christopher Guest" "Demi Moore"

## [13] "Regina King" "Kelly Preston" "John Cusack"

## [16] "Danny DeVito" "Bonnie Hunt" "Corey Feldman"

## [19] "Jay Mohr" "James Marshall" "Jonathan Lipnicki"

## [22] "River Phoenix" "Tom Cruise" "Noah Wyle"

## [25] "Wil Wheaton" "John C. Reilly"

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

1 2	length(clusters) ## [1] 6

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.

nodes$group = clusters$membership

nodes$value = NULL

head(nodes)

## id label group

## 1 Brooke Langton Brooke Langton 1

## 2 Jack Nicholson Jack Nicholson 2

## 3 Jerry O'Connell Jerry O'Connell 2

## 4 Oliver Platt Oliver Platt 3

## 5 John Goodman John Goodman 4

## 6 Gary Sinise Gary Sinise 3

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.

Finance Controlling und NoSQL Data Science – zwei Welten treffen aufeinander

July 10, 2015/0 Comments/in Business Analytics, Data Migration, Data Warehousing, Experience, NoSQL, Use Case /by Thomas Kalippke

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.

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:

1	168120;168120000001869;;1869;;;;;342.925,57;0,00;342.925,57;;;;;;;;;0065;;

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).

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 zurü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.

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.

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.

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.