Geradegerückt – 10 Big-Data-Mythen|Analyse der Woche

Gerade im sehr gehypten Bereich „Big Data“ halten sich viele Thesen und Meinungen, die – wenn man den Hype einmal wegrechnet – erstaunlich profan daherkommen. Wir betrachten im Folgenden zehn „Mythen“, die uns während unserer Arbeit immer wieder begegnet sind, kommentieren sie, korrigieren sie, wenn nötig und ordnen sie für ein besseres gemeinsames Verständnis systematisch ein.

1. Für Big Data brauchen man einen Data Scientist

Mit Beginn des Big-Data-Hypes tauchten plötzlich überall Stellenbeschreibungen für Data Scientists auf – erst bei den großen Internetfirmen, später auch bei anderen datengetriebenen Unternehmen. Legt man diese Stellenbeschreibungen nebeneinander, ergibt sich ein sehr weitläufiges Bild zur Charakterisierung dieser Rolle und ihrer Fähigkeiten. Demnach soll ein Data Scientist

• zunächst einmal ein Statistiker sein, sich dementsprechend auch mit Werkzeugen für
  • statistische Auswertungen,
  • Machine Learning
  • und Prediction auskennen,
• mit den verschiedenen Werkzeugen des Big-Data-Ökosystems vertraut sein, insbesondere mit Hadoop,
• aber natürlich auch auf relationalen Datenbanken arbeiten,
• unstrukturierte und textuelle Daten auswerten können
• und natürlich in der Lage sein, Daten in anschaulicher Art und Weise zu visualisieren.

Kennen sie jemanden, der dieses Skill-Portfolio abdeckt? Nein? Wir auch nicht.

Selbst BI- und DWH-Abteilungen sind meist nicht in der Lage, dieses Anforderungsprofil komplett auszufüllen; zu vielfältig und unterschiedlich sind die Technologien, Vorgehensmodelle und Methoden, die mit Big Data und Datenanalyse verknüpft sind. Dennoch erweitern viele bereits vorhandene Rollen ihr Technologie- und Methodik-Portfolio.

Daher erscheint es uns realistischer, die Aufgaben entlang ihrer Wertschöpfung zu untergliedern und den naheliegenden Rollen zuzuweisen. Der Data Scientist wäre dann nur noch für sein eigentliches Kerngebiet zuständig, die Dateninterpretation. Weitere Tätigkeiten könnten dann beispielsweise so aufgeteilt werden:

• Datenakquisition: Enterprise Architekt, ETL-Entwickler
• Datenmodellierung: DB-Administrator, Data Engineer, Data Architect
• Reporting: BI-Entwickler, Dashboard-Entwickler, Data Steward
• Interpretation: Domain Experte, Data Scientist
• Exploration: Business Analyst, Data Analyst
• Preskription: Statistiker, Software-Entwickler

Diese unterschiedlichen Rollen aus IT, Fachbereichen und Betrieb bilden im optimalen Fall ein umfassendes Competence Center, das die unterschiedlichen Anforderungen und Sichtweisen auf Big Data widerspiegelt und das auch die Anforderungen an das „magische Einhorn“ namens „Data Scientist“ mit aufnimmt.

2. Hadoop ist eine NoSQL-Datenbank

Oft hört man Dinge wie: „Polystrukturierte Daten lassen sich am besten in Hadoop oder anderen NoSQL-Datenbanken speichern“. Oder man sieht Architekturen, in denen das Hadoop Filesystem und darauf aufsetzende Komponenten wie Hive direkt dem Endkonsumenten für Ad-hoc-Abfragen zur Verfügung gestellt werden. In letztem Fall ist die Verwunderung groß, wenn die Performance deutlich hinter den Erwartungen zurückbleibt.

Hadoop ist in erster Linie eine Plattform bzw. ein Clusterbetriebssystem. Aufgrund seiner generischen Schnittstellen seit Version 2.0 gibt es bereits eine Vielzahl an Software-Produkten, die auf der Hadoop Plattform laufen. Die wohl wichtigste Komponente von Hadoop ist das Hadoop Distributed Filesystem (HDFS). Hierbei handelt es sich um nichts weiter als ein verteiltes Dateisystem zur Ablage von bevorzugt sehr großen Dateien. Eine weitere wichtige Komponente ist YARN, der Ressourcen-Manager des Clusters, auf dem verteilte, auf maximalen Datendurchsatz ausgelegte Jobs, ausgeführt werden. SQL-ähnliche Abfragewerkzeuge wie Hive nutzen HDFS und YARN zur Abbildung ihrer Tabellen und zur Ausführung von Suchen. Da Hadoop aber keine echte Datenbank ist, gibt es für die Daten zum Beispiel auch keine Indizierung. Bei einer Suchanfrage wird jeder Datensatz angefasst. Deshalb ist der Einsatz von HDFS über Hive als Ad-hoc-Suchsystem für den Endnutzer auch eher suboptimal: Mit jeder Abfrage wird der ganze Cluster für das Verarbeiten der Daten mobilisiert und der gesamte Bestand betroffener Tabellen angefasst, quasi wie bei einer Datenbank, die jedes Mal einen Full Table Scan macht.

NoSQL-Datenbanken hingegen sind eine Gruppe „echter“ Datenbanken, die sich in die Unterkategorien Key Value Stores, Column Familiy Stores, Dokumentendatenbanken und Graphendatenbanken unterteilen lassen. Diese Datenbanken sind auf die interaktive Arbeit mit Endnutzerkomponenten ausgelegt und lassen sich im Gegensatz zu relationalen Datenbanken über mehrere Netzwerkpartitionen skalieren. Dabei verzichten sie zugunsten besserer Skalierbarkeit, Schemalosigkeit und Performance auf ACID-Konformität.

Hadoop Distributionen wie HortonWorks, MapR, InfoSphere BigInsights, Pivotal HD oder Cloudera bringen die NoSQL-Datenbank HBase mit, die bereits in Hadoop integriert ist und sich auch mit der Abfragetechnologie Hive verknüpfen lässt. Wenn von Hadoop als NoSQL-Abfragesystem gesprochen wird, ist also normalerweise von der NoSQL-Datenbank HBase in einer der Hadoop Distributionen die Rede und nicht vom Hadoop Filesystem.

3. Data Lake wird das Data Warehouse ersetzen

Die Schaffung eines zentralen, Hadoop basierten, Data Lakes soll zahlreiche Vorteile mit sich bringen und eine große Bandbreite an neuen Analyse- und Geschäftsmodellen ermöglichen. Der Gedanke dabei ist, alle Daten in Rohform für unbestimmt lange Zeit auf der verhältnismäßig günstigen Hadoop Infrastruktur vorzuhalten. Durch die skalierbare Rechenleistung sollen außerdem Ad-hoc-Reports erzeugt werden – mit der Möglichkeit, bis auf die Einzeldatensatzebene herunterzugehen. Somit wären Cubes, Views, Standardreports etc., die in den letzten Jahren in den Data Warehouses vieler Unternehmen geschaffen wurden, von nun an überflüssig, richtig?

Nicht so ganz: Dass Hadoop sich als Plattform zur Schaffung eines Data Lakes, also eines Sammelbeckens für Daten, auf Grund seines Preises und seiner Skalierbarkeit anbietet, ist sicherlich korrekt. Die Werkzeugbandbreite für Hadoop ist ebenfalls bereits erstaunlich umfangreich und weitet sich auch im Bereich des Ad-hoc-Reportings immer weiter aus. Dennoch besitzen die Werkzeuge nach wie vor nicht den Funktionsumfang und die Reife von etablierten relationalen Datenbanken oder von Business-Intelligence-Programmen, die diese Datenbanken nutzen. Denn nur weil es mit der Skalierbarkeit von Hadoop technisch möglich ist, Berichte bis auf den einzelnen Datensatz herunterzubrechen, bedeutet das noch nicht, dass dies auch aus rein fachlicher Sicht genauso einfach möglich wäre.

Für relationale Systeme hat sich OLAP zur bevorzugten Methode zur analytischen Informationsgewinnung entwickelt. Nicht etwa, weil es neue technische Möglichkeiten bietet, sondern weil es Methoden zur Auswertung der Daten mit überschaubarem Entwicklungsaufwand zulässt. Aufgrund ihrer jahrzehntelangen Nutzungserfahrung ist die Auswertungsmethodik klassischer Data Warehouses der Methodik von Big-Data-Systemen noch Jahre voraus.

Big-Data-Referenzarchitekturen sehen daher Hadoop, genauso wie Streamingsysteme, Analytics-Labs und Sandboxes, meist nur als Zusatz zur bestehenden Data-Warehouse-Architektur. Dabei lösen skalierbare Systeme als zentrale Komponenten oft die dezentralen Staging-Umgebungen ab, auf denen die Daten für das Core Warehouse aufbereitet werden.

4. Durch Big Data lösen sich alle Probleme mit der Datenintegration von selbst

Immer, wenn einer Technologie zugeschrieben wird, die Lösung aller bisherigen Probleme zu sein, ist Skepsis angesagt. Vorsicht ist also geboten, wenn Hersteller mit „Big Data“ die Lösung aller Probleme bei der Datenintegration versprechen. Dieses Versprechen führt vor allem aus zwei Gründen in die Irre:

1. Der grobe Workflow bleibt der gleiche, nur die Techniken ändern sich. Während ETL-Strecken oder SQL-Transformationen im herkömmlichen Sinne dafür sorgen, dass die Daten aus den Quellsystemen extrahiert und so aufbereitet werden, dass sie in einer Struktur vorliegen, in der man sie einfach und effektiv abfragen kann, so wird in einer Big-Data-Architektur gleiches nur durch andere Werkzeuge getan. Hier sind Technologien wie Hive, Pig, oder Spark die bekannten Kandidaten.
    
2. Etablierte Werkzeuge zur Datenintegration werden fit gemacht, um auch in Big-Data-Technologien Verwendung zu finden. Beispiele sind SQL on Hadoop oder ETL als verteilte Jobs in Spark, die zum Beispiel von Oracle Data Integrator, Informatica ETL, Datameer Platform oder Machine-Learning-Plattformen wie RapidMiner genutzt werden.

Die Probleme bei der Datenintegration sind vielfältig und nicht immer werden diese automatisch durch Big-Data-Technologien gelöst. Einige Herausforderungen bleiben, auch wenn das ETL jetzt auf dem Cluster läuft und theoretisch vielfältigere und mehr Daten in kürzerer Zeit verarbeitet werden können. Das grundlegende Problem bei den neuen Technologien besteht weiterhin darin, dass man sich Gedanken machen muss, wie man die Daten aus den Quellsystemen in Relation setzt, welche Fragen man beantworten und welche Attribute man dazu kombinieren muss.

Vielleicht wird es ja tatsächlich irgendwann eine Big-Data-Technologie geben, die all dies überflüssig macht; der man also nur alle Daten der Quellsysteme zur Verfügung stellen und dann die Abfragen schicken muss: Quasi ein echtes Cognitive Computing System. Vielleicht wird dies irgendwann möglich sein. Die Technologien, die derzeit unter „Big Data“ gehandelt werden, sind davon jedoch noch weit entfernt!

5. Logfiles, Social Media Content und Sensordaten sind unstrukturierte Daten

Problematisch an dieser Aussage ist die Verwendung des Begriffs „unstrukturiert“. Unstrukturierte Daten per se gibt es eigentlich nicht. Struktur ist in jeder sinnvoll interpretierbaren Menge von Zahlen und Buchstaben inhärent vorhanden. Entscheidend ist die Art und Weise der Strukturierung und inwiefern diese dazu geeignet ist, die Daten maschinell sinnvoll weiterzuverarbeiten.

Jeder wird uns zustimmen, dass das Paradebeispiel unstrukturierter Daten, der Freitext deutscher Sprache, selbstverständlich eine Struktur hat: Es gibt Sätze, es gibt Verben, Substantive, die sich aufeinander beziehen. Jeder Satz ist allerdings unterschiedlich strukturiert und die Struktur muss mittels Satzanalyse mühsam herausgearbeitet werden. Auch Logfiles, Social Media Content und Sensordaten werden oft fälschlicherweise als unstrukturiert dargestellt. Im Gegensatz zu Freitext, der sich je nach Ansichtsweise ja durchaus noch als unstrukturiert klassifizieren lässt, verfügen Logfiles, Social-Media-Metadaten, Sensordaten sowie andere XML- oder JSON-organisierte Daten über eine viel eindeutigere Struktur.

Im Gegensatz zu traditionellen relationalen Datenbanken, deren Daten es immer ein festes Schema aufweisen, ist dies bei den semistrukturierten Daten aus Logs, Social Media und Sensoren nicht der Fall. Ein fixes Schema liegt hier nicht vor, das heißt, unterschiedlich strukturierte Schemata und nicht tabellarische Schemata müssen im System kombiniert werden.

6. Datenstrukturen in NoSQL-Datenbanken und Hadoop sind flexibler als in relationalen Datenbanken

Nicht die Datenstrukturen an sich sind flexibler, sondern ihre Speicherung. Manche NoSQL-Datenbanken verzichten auf ein festes Schema und speichern die Daten so ab, wie sie eingefügt werden. Das spart zu Beginn die Mühe, sich Gedanken über die Datenstruktur und eine relationale Tabellenstruktur zu machen. Außerdem hat dies den Vorteil, dass man sich nicht um die Struktur kümmern muss, wenn sich das Schema einmal ändert. Relationale Datenbankstrukturen müssten in dem Fall noch einmal angepasst werden, NoSQL-Datenbanken speichern einfach das neue Format.

Das Problem der Struktur verlagert sich damit allerdings nur an eine andere Stelle. Möchte man die Datenstrukturen abfragen, muss man sich zur Abfragezeit überlegen, in welcher Form man die Daten bekommen möchte, und man wird gegebenenfalls mit nicht vorhandenen Attributen zu deren Filterung zu kämpfen haben.

Flexible Datenstrukturen sind allerdings auch in der relationalen Welt abbildbar. Datenmodellierungstechniken wie Data Vault und Achor Modeling helfen, eine Flexibilisierung zu erreichen.

7. Map Reduce ist das Big-Data-Programm zur verteilten Durchführung von Berechnungen

Map Reduce ist der Begriff, der am häufigsten im Zusammenhang mit der verteilten Ausführung von Programmlogik fällt. Hier zeigt sich schon der erste Irrtum: Map Reduce ist kein Programm, das ausgeführt wird, sondern lediglich eine Herangehensweise für das Schreiben eines Programms. Das Programm löst daraufhin ein Problem, das wiederum verteilt gelöst werden kann. Map Reduce ist der erste Vertreter einer ganzen Reihe von Verteilungsframeworks, also einer Art und Weise, wie Algorithmen verteilt werden können, und es ist in diesem Bereich derzeit am präsentesten. Alternativen sind unter anderem Spark, Flink, Slider und Tez, die anders funktionieren, aber auch die verteilte Ausführung von Programmen ermöglichen. Sie unterscheiden sich in ihren Eigenschaften, Verteilungsalgorithmen, In-Memory-Nutzung und Latenzzeiten.

Solche Frameworks regeln die Art und Weise der Verteilung, der verteilten Rechnung. Die konkrete Verteilung übernimmt dann ein Ressourcen-Manager wie YARN, der die von Map Reduce erzeugten Code-Teile auf die verschiedenen Knoten des Clusters verteilt. Map Reduce funktioniert dabei weitestgehend unabhängig von der Programmiersprache, weil es nur die Art und Weise beschreibt, wie Dinge verteilt gerechnet werden können, aber nicht die Programmiersprache bestimmt, in der die Berechnung implementiert werden muss.

8. In-Memory Computing bändigt die wachsende Datenflut

In-Memory Computing – und stellvertretend dafür SAP HANA als DIE In-Memory-Plattform auf dem Markt – wird meist im gleichem Atemzug wie Big Data genannt. In-Memory-Systeme sollen die Rechenprozesse für Reporting und analytische Abfragen auf den immer weiter wachsenden Datenbeständen drastisch verkürzen.

Schaut man sich jedoch die erhältlichen Plattformen an, beginnen diese im Enterprise-Sektor meist mit wenigen hundert Gigabyte und enden bei zwei Terabyte Hauptspeicher. Gerade die High-end-Systeme in diesem Bereich sind fast immer mit exorbitanten Kosten verbunden. Die Speichergrößen reichen aber bei weitem nicht aus für das verwaltbare Datenvolumen im Big-Data-Bereich. Schließlich werden Big-Data-Projekte selten unter einem Gesamtdatenvolumen von 50 TB begonnen.

Hier könnte man entgegnen, dass Daten und Voraggregation ja komprimiert werden können. Aber das sollen Big-Data-Systeme ja eigentlich vermeiden. Stattdessen sollen sie die Möglichkeit bieten, von der Gesamtauswertung bis auf den unveränderten Einzeldatensatz hinunterzugehen.

Dennoch haben In-Memory Systeme auch in Big-Data-Architekturen ihre Daseinsberechtigung: In Streaming-Prozessen, bei denen Mitarbeiter eingehende Daten Datensatz für Datensatz bearbeiten, um direkt auf diese reagieren zu können (z. B. bei der Auswertung von Sensordaten, Click-Streams zur Adserver-Steuerung etc.), erweisen sich In-Memory-Systeme als äußerst nützlich. Ihre Kapazität muss hier lediglich dem Gesamtvolumen der Daten über die Durchlaufzeit des Prozesses bzw. über die Vorhaltezeit der Streaming-Windows entsprechen. Solche Streaming-Systeme werden meist mit Batch-orientierten Systemen und NoSQL-Datenbanken für die Ergebnisablage und Abfrage mit typischen Pattern wie der Lambda- oder Kappa-Architektur verknüpft.

9. Realtime Processing und Stream Processing sind das gleiche

Hier sehen wir weitere Termini, die selbst in vielen Fachartikeln rund um Big Data nicht trennscharf behandelt werden. Realtime wird an der Latenzzeit zwischen Datenaufkommen bzw. Abfragestart und Lieferung der Informationen bemessen. Streaming hingegen bedeutet im Gegensatz zu Batch das Verarbeiten von Daten als Einzeldatensätze ab dem Moment ihrer Entstehung.

Von Echtzeit reden wir beispielsweise, wenn wir uns Charts ansehen, die sich in Echtzeit basierend auf dem derzeitigen Datenstand aktualisieren. Im Hintergrund befindet sich unter Umständen nur eine gewöhnliche relationale Datenbank, an die lediglich in schneller Frequenz Abfragen zur Aktualisierung gesandt werden. Streaming hingegen nutzt Streaming-Plattformen wie Apache Storm, Spark Streaming, Oracle Event Processing oder IBM InfoSphere Streams. Der Hauptunterschied dieser Systeme zu Batch-orientierten (DB-)Systemen besteht darin, dass hier mit „Data in Motion“ anstelle von „Data at Rest“ gearbeitet wird. Die Daten bleiben also nicht bestehen, sondern werden die ganze Zeit „in-memory“ gehalten. Dabei werden die Datensätze einzeln verarbeitet und nur solange behalten, wie die Verarbeitung des einzelnen Datensatzes andauert, um diesen danach direkt über das Netzwerk an den nächsten Verarbeitungsknoten weiterzugeben.

Die Begriffsverwirrung ist sicherlich entstanden, weil Streaming-Technologie häufig verwendet wird, um Realtime-Systeme zu implementieren. Der offensichtliche Vorteil der Streaming-Technologie für Realtime ist zum einen, dass sie die Systemlast reduziert, indem sie auf Einzeldatensatzbasis im Push-Verfahren Informationen aktualisiert, statt von jedem Client in hoher Frequenz Pull-Anfragen zu schicken. Zum anderen lassen sich mit ihrer Hilfe gerade komplexere Realtime-Prozeduren mit Verkettungen und Abhängigkeiten untereinander sehr viel strukturierter abbilden.

10. Durch Machine Learning kann die Befangenheit menschlicher Analysten überwunden werden

Es ist ein Kreuz mit der menschlichen Wahrnehmung und Intuition: Hat man es eilig, sind alle Ampeln rot. Bekommt man ein Kind, sieht man überall Kinderwagen. Der Mensch tut sich schwer mit der Erfassung und Einordnung seltener Ereignisse und Wahrscheinlichkeiten. Die Entscheidungsfindung ist bei mangelhafter Information noch schwieriger. Auch große Datenmengen und das Finden von Zusammenhängen sind für uns Menschen schwierig. Ist die Häufung von roten Ampeln nun statistisch relevant, oder ist sie nur auf unsere Eile zurückzuführen?

Machine-Learning-Algorithmen können hier tatsächlich beim Umgang mit großen Datenmengen, kleinen Wahrscheinlichkeiten und der korrekten Einordnung helfen. Was man aber nicht vergessen darf, ist, dass solche Algorithmen immer nur Korrelationen finden, aber nicht notwendigerweise auch Kausalitäten. Sie decken etwas auf, erklären es aber nicht. Die Vorhersage der Grippewellen durch Google wird in dem Zusammenhang gerne zitiert: Anhand des Auftretens von gripperelevanten Suchworten sagte man die Ausbreitung der Grippe vorher. In Untersuchungen kam später heraus, dass sich Daten von Ärzten und anderen offiziellen Quellen in dem Fall wesentlich besser zur Vorhersage eignen. So suchten aufgrund der umfangreichen Berichterstattung über das Thema Grippe mehr Leute nach „Grippe“, aber nicht weil sie selbst die Grippe hatten, sondern weil sie einfach mehr darüber wissen wollten. Grippewellen außerhalb der Saison wurden teilweise gar nicht erkannt, weil auf die falschen Suchwörter geachtet wurde.

Beim Umgang mit den Ergebnissen von Machine-Learning-Algorithmen ist also immer ein gesundes Maß an Skepsis angeraten, weil eben nur eine Korrelation gemessen wird und nicht notwendigerweise eine Kausalität.

Fazit

Die vielen verschiedenen Techniken und Technologien, die üblicherweise unter dem Begriff „Big Data“ zusammengefasst werden, haben sicherlich alle ihre Berechtigung und auch sinnvolle Verwendungsmöglichkeiten. Aufgrund des noch herrschenden Hypes sind aber auch viele Vorurteile und falsche Einordnungen im Umlauf. Um einen sinnvollen Einsatz der Technologien zu gewährleisten, sollte man diese kennen und sie richtig einordnen.

In diesem Artikel haben wir versucht, einige dieser falschen Einschätzungen aufschreiben und geradezurücken, beziehungsweise genauer zu erklären. Es würde uns freuen, wenn wir damit einen kleinen Beitrag für ein besseres gemeinsames Verständnis im Big-Data-Umfeld leisten könnten!

Christopher Thomsen leitet bei der OPITZ CONSULTING Deutschland GmbH das Competence Center Big Data. Sein besonderes Interesse liegt in der Verknüpfung von Technologien aus IT-Trendthemen wie Big Data, Cloud Computing und Mobile Applications.
 

Dr. Jens Bleiholder ist bei der OPITZ CONSULTING Deutschland GmbH als Project Manager tätig und beschäftigt sich seit über 10 Jahren mit verschiedenen Themen in den Bereichen Informationsintegration und Datenqualität und Agiler Business Intelligence.
 

www.opitz-consulting.com