Evaluation: Ab wann lohnt sich Big Data?
Die Antwort auf die Frage muss differenziert erfolgen. Dieser Artikel erläutert die wichtigsten Eigenschaften von “Big Data” und zeigt wichtige Kriterien, um zu entscheiden, ob eine Big-Data-Evaluation sinnvoll ist. Eine Liste minimaler Skills, um Big Data zielgerichtet evaluieren zu können, rundet den Katalog ab.
Eines sei vorweggenommen: Big-Data Technologien funktionieren bestens auch für überschaubare Datenbestände.
Inhalt
1 Begriffserklärung: Was ist Big Data überhaupt?
2 Was ist ein verteiltes, horizontal skalierbares System?
3 Evaluationskriterium: Größe der Datasets
3.1 Big Data OLTP-Systeme
3.2 Big Data OLAP-Systeme
4 Evaluationskriterium: Kosten-Nutzen
4.1 Evaluationskriterium: Art der Lizenz
4.2 Evaluationskriterium: Personalkosten
4.3 Evaluationskriterium: Art der Infrastruktur
4.3.1 On Premises
4.3.2 RZ-Dienstleister
4.3.3 Cloud-Lösung
4.3.4 Zusätzliche Kriterien zur Evaluation der Cloud-Infrastruktur
5 Evaluationskriterium: Komplexität der Daten
5.1 Verfeinerte Fragestellung: Benötigen wir Data Science?
6 Minimale Skills um Big Data Tools zu evaluieren
1 Begriffsklärung: Was ist Big Data überhaupt?
Seit Jahren dominiert die folgende Definition:
Eigentlich ist das keine Definition sondern ein Vergleich: Datensätze, die größer und komplexer sind und vor allem aus neuen Datenquellen stammen.
Natürlich drängen sich jetzt die folgenden Fragen auf:
- Wie groß muss ein Datensatz sein, damit ich mich mit Big Data befassen muss?
- Wie komplex muss ein Datensatz sein, um auf Big Data zu setzen?
- Und was sind schon ‘neue Datenquellen’?
Diese Definition stammt aus einem Blog-Post bei Gartner aus dem Jahr 2002 und seither ist die Definition: ‘Big Data – das sind die 3V’ überall anzutreffen. Doch sie definiert nicht, sie verwirrt.
Als die Definition entstand, standen die damit gemeinten ‘neuen Datenquellen’ und ‘innovativen Technologien’ noch ganz am Anfang.
Jetzt, nach 20 Jahren, wissen wir mehr: Ich definiere den Begriff Big-Data neu:
Der Begriff ‘Big Data’ bezeichnet Methoden zur Speicherung, Abfrage, Verarbeitung und Analyse von Daten mit Hilfe von verteilten und horizontal skalierbaren Systemen.
2 Was ist ein verteiltes, horizontal skalierbares System?
Wikipedia bringt es auf den Punkt:
Horizontale Skalierung bedeutet die Steigerung der Leistung eines Systems durch das Hinzufügen zusätzlicher Rechner/Knoten. Die Effizienz dieser Art der Skalierung ist jedoch stark von der Implementierung der Software abhängig, da nicht jede Software gleich gut parallelisierbar ist.
Wir brauchen also speziell geschriebene, parallelisierbare Software, um überhaupt horizontal skalieren zu können. Big Data Tools weisen genau diese Eigenschaft auf. Reicht der Festplattenplatz nicht mehr, dann erweitern wir das Cluster um weitere Rechner.
Die eingangs gestellten Fragen formulieren wir um:
- Wie groß muss ein Datensatz sein, damit sich ein horizontal skalierendes System zu dessen Analyse lohnt?
- Wie komplex muss ein Datensatz dazu sein?
Ausgehend von einem einzelnen System (links) werden weitere Systeme hinzugefügt, so dass ein Cluster von drei (Mitte) resp. sechs (rechts) Rechnern entsteht. Jeder der Rechner besteht aus CPU, RAM, Festplatte etc. Das Cluster als Gesamtsystem verhält sich dem Anwender gegenüber nicht anders, als das Ausgangssystem links. So wird Daten- und Rechenlast auf mehrere Rechner verteilt.
3 Evaluationskriterium: Größe der Datasets
Die erste Frage ist einfach zu beantworten:
Es gibt keine Grenze nach unten und es gibt keine Grenze nach oben:
Horizontal skalierbare Analytics-Systeme funktionieren auf einem Cluster aus Raspberry Pi genauso wie auf einem Cluster, der ein ganzes RZ füllt.
Um die Frage der Größe der Datasets zu beantworten, müssen wir zwischen OLAP-Systemen und OLTP-Systemen, also zwischen Online Analytical Processing und Online Transaction Processing.
3.1 Big Data OLTP-Systeme
OLTP-Systeme sind Datenbank-Systeme, und übernehmen dabei sowohl die Organisation der Datenhaltung als auch die Organisation des schnellen Schreibens und Lesens. Die Antwortzeiten liegen im ms-Bereich.
NoSQL-Datenbanken werden gerne eingesetzt und viele sind in der Lage, in Bezug auf die Datenhaltung auf mehrere Nodes zu skalieren.
Bei OLTP-Systemen stellt sich zusätzlich die Frage nach der Art der Transaktionen. Skaliert das System horizontal, dann verändert sich das Transaktionsverhalten.
Besonders heikel ist dabei oft der Trade-Off zwischen Hochverfügbarkeit, Konsistenz und Fehlertoleranz des Systems.
Wer relationale Datenbanken gewohnt ist, und in einem horizontal skalierbaren System nach den ACID-Transaktionseigenschaften sucht, muss eine bittere Pille schlucken: diese Systeme sind nicht gefeit vor einem Teilausfall. Fällt also ein einzelner Node im Cluster aus, dann wird unter Umständen das Gesamtsystem blockiert.
Für die horizontale Skalierbarkeit müssen die Transaktionseigenschaften gelockert werden. Moderne horizontal skalierbare Datenbanken erlauben oft die Wahl der Art der Transktionseigenschaften für einzelne Transaktionen. Sicher ein Evaluationskriterium, wenn es um Big-Data-OLTP-Systeme geht.
Wann lohnt es sich überhaupt ein OLTP-Big Data weiter zu evaluieren?
Da gibt es sicher eine Schmerzgrenze: nämlich da, wo das bisher eingesetzte System wegen zu großer Datenlast seinen Dienst versagt.
Die Datenlast kann daraus resultieren, dass das Volumen der Daten das eingesetzte System überfordert oder aber auch daran, dass das eingesetzte System für die Struktur der Daten nicht geeignet ist. Beispielsweise eignen sich relationale Datenbanken nicht für effizientes Handhaben von Graph-Daten. Dazu wird man spezielle Graph-Datenbanken evaluieren.
Die Menge der Daten ist von der Struktur der Daten unabhängig zu evaluieren. Liegen die Daten in unserem Beispiel nicht nur in Form von Graphen vor sondern zusätzlich auch in sehr großen Mengen, dann evaluieren wir horizontal skalierbare Graph-Datenbanken.
3.2 Big Data OLAP-Systeme
Wichtig ist: Big-Data-Technologien eignen sich nicht, für die Verwaltung vieler kleiner Files. Beispielsweise für viele Word-Dokumente. Sie wurden gebaut, um sehr große Files zu speichern und zu analysieren.
Nur zu Ausbildungs- und Testzwecken ist die Analyse kleiner Files sinnvoll. In der Produktion aber nicht. Hintergrund: Ein verteiltes Filesystem, wie das Hadoop Distributed Filesystem (HDFS), unterteilt einzelne Files in Blöcke von 128MB (der Wert wird konfiguriert und soll hier zur Illustration dienen). Ein Big-Data-File sollte also viele solcher Blöcke umfassen. Man beachte, dass durchaus auch Blockgrößen von 256MB oder gar 512MB konfiguriert werden, oder auch 64MB.
Das Evaluationskriterium umformuliert:
OLAP Big-Data-Technologien sind geeignet für Files, die in viele Blöcke von 128MB aufgeteilt werden.
Beispiele für solche Files:
- Suchmaschinenindexe (der Ursprung der Big-Data-Technologien bei Google)
- Die Menge aller Messungen in einer IoT-Anwendung
- Log-Files einer Serverfarm
- Daten eines Data Warehouses
Wann lohnt es sich überhaupt ein OLAP-Big Data weiter zu evaluieren?
Da gibt es sicher eine Schmerzgrenze: nämlich da, wo das Data Warehouse zu langsam wird. Oder die bisherige Datenanalyse einfach zu lange läuft.
In einem neuen Projekt würde ich abwägen, ob eine derartige Datenmenge erwartet wird. Falls ja, dann würde ich Big-Data-Tools evaluieren.
4 Evaluationskriterium: Kosten-Nutzen
Die Frage nach der Größe der Datensätze wird jetzt also umgemünzt in die Frage nach dem Einsatz der Tools und der Art der Infrastruktur.
- Wann lohnen sich Big-Data-Tools?
- Wann lohnt sich Big-Data-Infrastruktur?
Die Kosten-Nutzen Analyse möchte ich nicht beantworten, sondern einen Katalog an typischen Kostenfaktoren zusammenstellen, die beim Bau und Betrieb eines Big-Data-Systems besonders relevant sind:
Liste typischer Kostenfaktoren:
4.1 Evaluationskriterium: Art der Lizenz
Keine Lizenzkosten zahlen ist natürlich verlockend. Wer A sagt muss auch B sagen: Sich 100% auf Open Source zu verlassen, bedeutet die Software 100% selbst in Betrieb zu nehmen und zu warten.
Hinter vielen Open-Source Tools steht eine Community von Software-Engineers, die diese Projekte weiterentwickeln. Gerade bei der ASF (Apache Software Foundation) wird großer Wert darauf gelegt, dass die Projekte von einer aktiven Community betreut werden.
Doch wie werden diese Software-Engineers bezahlt? Die Frage stellt sich, gerade weil sie das Ergebnis ihrer Arbeit kostenlos zur Verfügung stellen. Wir beobachten verschiedene Muster:
- Bezahlter Day-Job bei einem Unternehmen und Entwicklung am Open Source Projekt in der Freizeit. Das ist wahre Leidenschaft.
- Bezahlter Day-Job bei einem Unternehmen, das den Entwicklern die Möglichkeit bietet, zu einem Open Source Projekt beizutragen, ohne dass dem Unternehmen ein Nutzen entsteht. Förderung der Mitarbeiterzufriedenheit.
- Das Big-Data-Tool wird von einem Unternehmen für eigene Zwecke entwickelt und eingesetzt. Später spendet das Unternehmen die Software der Open-Source Community gespendet. Das Unternehmen selbst entwickelt das Tool mit eigenen Leuten weiter und begrüßt auch externe Entwickler in der Community. Damit fließt weiteres Know-How ein.
- Gerade beim vorherigen Muster ist zu beobachten, dass sich eine Gruppe der Entwickler im bestem Einvernehmen mit dem ursprünglichen Unternehmen als eine Art Spin-Off selbständig macht und das Projekt mit der neuen eigenen Firma und der erweiterten Community weiterentwickelt. Zusätzlich entstehen dann kommerzielle Ergänzungen zum Open Source Tool und eine rege Beratertätigkeit. Das trifft beispielsweise zu auf Apache Kafka (heute Confluent – ursprünglich LinkedIn), Apache Spark (heute Databricks, ein Spin-Off der University of California at Berkeley).
Gerade bei diesem letzten Modell sehen wir, dass die Frage ‘Open Source vs kommerzielle Software’ nicht einfach mit ja oder nein zu beantworten ist. Die Ergänzungen zum Open Source Tool könnten ja durchaus ihren Wert für unser Projekt haben. Meistens handelt es sich um zusätzliche Features, die das Leben erleichtern.
4.2 Evaluationskriterium: Personalkosten
Letztendlich ist das eine strategische Frage:
- Eigenes Personal muss rekrutiert oder ausgebildet werden (siehe Skill-Liste).
- Die Neueingestellten müssen erst gefunden und dann eingearbeitet werden – ein Kostenfaktor.
- Das bestehende Personal muss erst ausgebildet werden – ebenfalls ein Kostenfaktor.
- Auch der Dienstleister muss sich zuerst mit dem Projekt vertraut machen – ebenfalls ein Overhead.
- Der Dienstleister kann auch als Berater und Trainer für das eigene Personal hinzugezogen werden. Möglicherweise eine lohnenswerte Option.
4.3 Evaluationskriterium: Art der Infrastruktur
Der zweite Aspekt der Kosten-Nutzen-Frage bezieht sich auf den Ort der Infrastruktur. Mittlerweile haben wir die Wahl: On-Premises bedeutet, wir bauen die Infrastruktur in den eigenen Räumen auf, oder wir schließen einen Vertrag mit einem RZ-Dienstleister ab, oder wir profitieren von einem Cloud-Angebot. Im folgenden werden die drei Möglichkeiten näher vorgestellt.
4.3.1 On Premises
Entscheiden wir uns für On-Prem, dann bauen wir ein eigenes RZ auf. Vielleicht sind die Daten derart sensibel, dass kein Weg daran vorbei führt. Dabei kaufen wir nicht nur die Rechner selbst ein, installieren und unterhalten diese, sondern wir sorgen auch für die passenden Räumlichkeiten. Diese können wir auch bei einem RZ-Dienstleister beziehen.
4.3.2 RZ-Dienstleister
Statt ein eigenes RZ aufzubauen, kann ja ein Anbieter für RZ-Dienstleistungen Hilfe erbringen. Diese übernehmen den Aufbau des RZ selbst. Beispiele aus dem Dienstleistungskatalog
- Gebäude,
- Sicherheit des Gebäudes,
- Brandschutz,
- Zugangskontrolle,
- unterbruchsfreie Stromversorgung,
- Kühlung,
- performante Internetanbindung, Sicherheit dieser Anbindung,
Bei einigen Anbietern kann man die Server selbst beschaffen und der Anbieter baut sie in seinem RZ ein. Oder er vermietet seine eigenen Server. Mittlerweile gibt es eine Vielzahl von Geschäftsmodellen.
4.3.3 Cloud-Lösung
Oder aber wir ziehen einen Cloud-Anbieter vor, der auch die Software selbst auf seinen eigenen Rechnern installiert, überwacht und upgradet. Dort mieten wir Rechenzeit und Speicherkapazität. Wir können uns auf das Kerngeschäft konzentrieren. Das tönt verlockend.
Wer die Angebote im Hinblick auf die zu erwartenden Kosten vergleichen möchte, ist konfrontiert mit fehlenden Standards. Jeder Cloud-Anbieter schnürt eigene Pakete und verwendet ein eigenes Wording. Man wird nicht umhin kommen, Accounts bei den jeweiligen Anbietern zu erstellen und die Angebote besser kennen zu lernen, insbesondere auch, um das Wording zu verstehen.
Solche Einsteiger-Accounts sind in der Regel kostenlos – die Hürden werden niedrig gehalten. Gleichzeitig erhält man einen Eindruck von der Usability und über die Dokumentation. Selbstverständlich bieten die Cloud-Anbieter auch Schulungsprogramme an, bis hin zur jeweiligen Zertifizierung.
4.3.4 Zusätzliche Kriterien zur Evaluation der Cloud-Infrastruktur
Ein wichtiges Kriterium darf bei der Evaluation der Infrastruktur dabei nicht fehlen:
Welches Wachstum der Datenmenge sehen wir voraus?
Die Einstiegshürden werden sehr tief gehalten, doch mit welchen Kosten ist in Zukunft zu rechnen?
Auch eine zweite Frage gehört unbedingt in den Evaluationskatalog: Wie einfach ist es, die erwartete große Datenmenge zu einem anderen Cloud-Anbieter zu transferieren?
Es könnte ein böses Erwachen folgen – die Wahl ist mit offenen Augen zu treffen.
5 Evaluationskriterium: Komplexität der Daten
Wir erinnern uns: In der Definition ‘Big Data = 3V’ steht eines der V für Variety, also komplexität der Daten.
Manchmal ist auch die Rede von ‘unstrukturierten’ Daten. Je unstrukturierter, desto komplexer, könnte man meinen.
Ist denn die Struktur in relationalen Datenbanken komplex? Viele werden die Frage bejahen und dann relationale Datenbanken doch nicht in die Big-Data-Welt verorten wollen.
Sind denn Dokumente, die Texte in natürlicher Sprache enthalten, unstrukturiert? Viele werden auch diese Frage bejahen und doch können gerade Suchmaschinen wie Google sehr viel Struktur in solchen Dokumenten erkennen.
Ich würde die Komplexität der Datenstrukturen nicht als primär identifizierendes Merkmal für den Einsatz von Big-Data-Technologien sehen. Die Landschaft der horizontal skalierenden Tools ist sehr vielfältig. Für die Handhabung vieler Datenstrukturen gibt es viele Tools:
Beispiel Apache Spark: Dieses ist sehr vielseitig und bietet APIs für die folgenden Anwendungsfälle:
- Tabellenartige Daten, wie CSV (Spark SQL, Spark Dataframes/Datasets, Parquet, ORC, AVRO)
- Beliebig strukturierte Daten wie Text, Bilder etc (Spark MLib)
- Netzwerkartige Daten (Spark GraphX)
- Real-Time Analysen
Als die Definition ‘Big Data = 3V’ entstand, sah man, dass Google mit riesigen Mengen von scheinbar unstrukturierten Texten gut zurecht kam. Zudem kamen immer mehr NoSQL-Datenbanken auf, die spezialisiert waren, auf unterschiedliche Strukturen von Daten. Die künstliche Intelligenz schlummerte gerade wieder in einem Winterschlaf und begann sich angesichts dieser Entwicklungen zu regen. All diese Aspekte flossen ein in die 3V, die damals innovativ waren. Das ist überholt, auch im Hinblick auf die verarbeitbare Komplexität der Daten.
In den zwanzig Jahren seit der Definition Big-Data = 3V entstand das Fachgebiet der Data Science.
5.1 Verfeinerte Fragestellung: Benötigen wir Data Science?
Und man sollte sich bei der Evaluation die Frage stellen, ob für die Analyse der Daten Künstliche Intelligenz (KI), Machine Learning also die Methoden der Data Science notwendig sind? Falls die Frage bejaht wird, dann gehört dieser Aspekt mit in den Evaluationskatalog der einzusetzenden Big Data Tools.
So wie in den vergangenen zehn Jahren der Begriff ‘Data Science’ an Form gewann, so schärft sich in der aktuellen Debatte der Begriff ‘Data Engineering’.
Ich sehe Big Data als eine Facette des Data Engineerings. Data Scientisten bedienen sich gerne großer Datenmengen und benötigen Data-Engineering Skills.
Ein Data Engineer wird ein fertiges KI-Modell in Betrieb nehmen.
Die Tabelle grenzt ab zwischen den Tätigkeitsfeldern des (Big-)-Data-Engineers und des Data Scientisten. Die Evaluation der Big-Data-Tools gehört also ins Tätigkeitsfelds des (Big-)Data-Engineers.
Das folgende Kapitel zeigt eine Übersicht über die Skills und Kenntnisse die Data-Engineers benötigt, um Big-Data-Tools zu evaluieren.
6 Minimale Skills um Big Data Tools zu evaluieren
Um die Tools bei deren heutigem Reifegrad erfolgreich einzusetzen, ist eine gute, fundierte Grundausbildung als Informatiker wichtig. Folgende Aspekte gehören unbedingt dazu:
- Kenntnisse in Python, insbesondere Funktionale Programmierung. Java oder Scala Grundkenntnisse.
- Gute SQL-Kenntnisse – diese Sprache wird in vielen Tools eingesetzt. Und damit einhergehend Kenntnisse des relationalen Datendesigns. Big-Data-Tools sind nicht relational, doch sind Kenntnisse der Denkweise und des Wording aus der relationalen Welt sehr hilfreich.
- Netzwerk Grundkenntnisse: Die Rechner werden zu einem Cluster vernetzt und so sind Grundkenntnisse aus dem Netzwerkbereich ein Muss.
- Linux Grundkenntnisse: Linux ist das Server-Betriebssystem der Big-Data Welt.
- Kenntnisse gängiger Architekturen, und zwar
- Architekturen verteilter Systeme,
- Architekturen von Big-Data-Pipelines, und Data Lakes.
- Kenntnisse der Trade-Offs verteilter Systeme und damit einhergehend, Kenntnisse über die Organisation verteilter Transaktionen.
- Kenntnisse gängiger Maßnahmen bei der Optimierung von Datenabfragen in Datenbanken und Big-Data-OLAP Systemen.
- Kenntnisse gängiger Muster von NoSQL-Datenbanken.
- Von enormem Vorteil ist es, wenn man vor der Evaluation das eine oder andere System Hands-On kennengelernt hat. Das ermöglicht es, das evaluierte Tool einzuordnen. Dazu eignen sich Open Source Tools bestens.
- Grundkenntnisse der Data Science, also des Machine Learnings. Es gilt zu evaluieren, ob gewisse Fragestellungen mit KI lösbar sein könnten.
- Kenntnisse gängiger Maßnahmen bei der Optimierung von Datenzugriffen.
Dieser Katalog stellt auch das minimale Skill-Set eines Data Engineers dar.