Zeit im Big Data Stream Processing

Event-Time, Ingestion-Time, Processing-Time? Und was bedeutet da Real-Time? Der Artikel beleuchtet spezielle Herausforderungen der Echtzeitanalyse großer Datenströme besonders im Hinblick auf den Faktor Zeit.

Streams sind überall:

• Logdaten zur Überwachung von Servern
• Sensordaten aus Endgeräten, wie Smartphones (IoT)
• Sensordaten aus Fahrzeugen und Geräten (IoT, Predictive Maintenance)
• Überwachungsdaten- z.B. Webcams
• Social Media Daten
• Echtzeitanalysen in Data Warehouses, resp. Data Lakes
• und viele andere mehr

Statt von ‘Records’ ist die Rede von ‘Events’ oder auch von ‘Messages’ oder ‘Nachrichten’. Die Events werden ununterbrochen generiert und gelangen in einem fortwährenden Strom in die Analytics-Pipeline.

Unaufhörlich treffen neue Events ein. Stream Processing verarbeitet und analysiert ‘unbeschränkten’ Datasets (engl. unbounded Datasets). Eigentlich sind es Warteschlangen (Queues) und die Events.

Zeitkritische Verarbeitung von Data Streams

Sollen beispielsweise Herzpatienten von Ferne überwacht werden, dann ist eine sehr zeitnahe Verarbeitung und Analyse gefordert.

Verläßt der Puls eine gewisse Toleranzschwelle, dann wird ein Alarm ausgelöst. Diagramme werden zusätzlich erstellt und ermöglichen die Diagnose und Überwachung.

Das Szenario ist stark vereinfacht:

Ein kleines Gerät erhebt den Puls bei einem Herzpatienten. Für jeden Herzschlag schickt es ein Event via Internet zu einer Real-Time-Pipeline.

Nicht jedes Event nimmt denselben Weg durchs Internet – und so treffen die Events in nahezu beliebiger Reihenfolge in der Analytics Pipeline ein.

Wird jetzt der Puls unseres fiktiven Patienten ausgewertet, dann dürfen keine Events verloren gehen und es dürfen keine Events mehrfach verarbeitet werden.

Dies zu garantieren, ist in Big Data Systemen eine besonders komplexe Aufgabe. Immerhin sollen diese Systeme ja horizontal skalieren.

Vorkehrungen bei der Konfiguration des Gesamtsystems und bei der Programmierung Analyse sind notwendig, um die geforderte Exactly-Once Verarbeitung zu erreichen.

Zeitfenster (Windows) in der Data Stream Processing

Für eine Echzteit-Analyse werden die laufend eintreffenden Events typischerweise nach Zeitintervallen zusammengefasst (aggregiert) und das Ergebnis wurd als Zeitreihe dargestellt.

Dazu teilt die verwendete Stream Analytics Engine  die Events in Zeitfenster (engl. Windows) ein.

Man unterscheidet die folgenden Window-Typen:

Fixed Windows (heißen auch hopping Windows) unterteilen die Zeit in gleichmäßige Intervalle. Die klassische Batch-Verarbeitung mit den typischen nächtlichen Verarbeitungen, macht eigentlich genau das gleiche. In der real-time Verarbeitung sind die Intervalle jedoch sehr viel kleiner und die Analyse erfolgt sehr zeitnah zum Eintreffen der Daten.

Sliding Windows haben Überlappungen. Dies erlaubt es, einen Einblick in die eintreffenden Daten zu erhalten noch bevor die Verarbeitung eines Window fertig abgeschlossen ist.

Sessions sind auch Zeitfenster. Diese haben jedoch unterschiedliche Länge und überlappen. Selbst die Aktionen in einer Web-Session oder in einer Datenbank-Session bilden einen Event-Stream.

Die Herzschläge unseres fiktiven Patienten analysieren wir mit Fixed Windows – der Puls eines Patienten wird ja pro Minute erhoben.

Typen des Data Stream Processing

Immer häufiger werden klassische ETL-Prozesse durch Data Stream Processing abgelöst. Hier kommt elementweise Verarbeitung zum Zuge, beispielsweise, um Daten zu bereinigen (Datumstransformation und ähnliches).

Gerade für Analysen sind Aggregationen interessant. In SQL entsprechen diese einem Group By.

Oft werden auch Daten aus verschiedenen Quellen zu einem Stream vereint – in SQL entspricht dies einem Join.

Machine Learning auf Streams wird immer beliebter. Anwendungsfälle sind Predictive Maintenance oder Fraud Detection.

Im Beispiel unseres fiktiven Herzpatienten aggregieren wir die Events und zählen sie pro Minute.

Zeitversatz (Time Skew)

Konzentrieren wir uns auf die Zeit. Der Zeitpunkt eines einzelnen Herzschlags des Patienten ist die Event-Time. Trifft das Event bei der Pipeline ein, dann spricht man von Ingestion-Time.

Präziserweise würden wir von Timestamp statt von Time sprechen.

Zwischen diesen beiden Zeitpunkten kann theoretisch beliebig viel Zeit verstreichen. Und möglicherweise befindet sich der Patient gerade in einer anderen Zeitzone als die Streaming Pipeline.

Auch innerhalb der Pipeline wird es eine gewisse Zeit dauern, bis das Event verarbeitet wird. Der Zeitpunkt wird Processing Time genannt.

Die Abweichung zwischen der Processing Time und der Event Time bezeichnen wir als Zeitversatz (engl. Time Skew).

Der Begriff “Real-Time” suggeriert, dass der Zeitversatz gleich Null ist. Doch das ist unrealistisch. Eigentlich sollte von “Near-Real-Time” gesprochen werden.

Das hervorgehobene Event wurde um 12:00:xx generiert und wird ist erst um 12:05:yy von der Pipeline verarbeitet.

Soll nach Processing-Time analysiert werden, dann fällt das Event ins Zeitintervall der Minute 12:05 -12:06.

Soll hingegen nach Event-Time analysiert werden, dann gehört das Event ins Zeitintervall zwischen 12:00 und 12:01.

Die Diagonale  zeigt den nie eintreffenden Idealfall: die Verarbeitungszeit ist gleich der Event-Zeit – das wäre Echtzeit im wörtlichen Sinn. Der zeitliche Versatz von der Ideallinie ist sowohl in der x-Achse als auch in der y-Achse sichtbar.

Dieser zeitliche Versatz nicht konstant sondern hängt von vielen technischen Faktoren ab:

• Vom Zustand der Systeme außerhalb der Stream-Analytics-Pipeline, beispielsweise von der Übertragungsgeschwindigkeit im Internet.
• Vom Zustand der Stream-Analytics-Pipeline.

Auswirkungen des zeitlichen Versatzes

Bedeutet “Real-Time” jetzt Verarbeitungszeit – dann verarbeitet die Analytics Engines die Events in der Reihenfolge ihres Eintreffens. Ganz unabhängig davon, wie lange die Events unterwegs und welchen Weg sie durchs Internet eingeschlagen haben.

Das Histogramm zeigt die Anzahl der Events pro Minute. Window-Länge ist also eine Minute. Wir betrachten die Achse “Processing Time” und zählen pro Minute die jeweils Events. Das Ergebnis zeichnen wir im Histogramm auf.

Anders sieht es aus, wenn mit “Real-Time” an die Event-Zeit gemeint ist, wie bei unserem Herzpatienten.

Rechnen wir das Ergebnis der Event-Time Analyse in unserem Beispiel aus:  Diesmal zählen wir die Events pro Minute auf der Achse Event-Time. Dabei entsteht das folgende Histogramm:

Legen wir beide Histogramme übereinander, dann sehen wir große Abweichungen zwischen den beiden Analysen. Je nach Anwendungsfall sind solche Abweichungen nicht tragbar.

Bei unserem Beispiel: die beiden Analysen des Pulses unseres fiktiven Patienten weichen sehr stark voneinander ab.

Analysen nach Event-Zeit

Untersuchen wir das Phänomen genauer.

Zur Verdeutlichung färben wir die Events, die in derselben Minute anfielen (Event-Zeit) mit je einer Farbe.

Daraus leiten wir den Event-Stream ab in der Reihenfolge der Processing-Time. In der Reihenfolge verarbeitet die Analytics Engine die Events ja in jedem Fall.

Die Analyse nach Minute ist für die Überwachung unseres Herzpatienten unbrauchbar.

Die Analytics Engine stellt jetzt die Reihenfolge wieder her, in der die Events ursprünglich angefallen ist.

Wir ergänzen das Diagramm durch den Event-Stream nach Event-Time. Die Pfeile zeigen, wie die Stream Analytics Engine die laufend verarbeiteten Events intern in die Zeitfenster der Event-Zeit zuordnet und so die urspüngliche Reihenfolge wieder herstellt.

Dabei reicht die Zuordnung zum Zeitfenster aus – immerhin werden die Daten anschließend pro Zeitfenster ausgewertet. Pro Zeitfenster verwaltet die Analytics Engine also einen internen Puffer.

Man beachte, dass es sich bei einem Stream nicht um ein abgeschlossenes Dataset handelt, das einfach umsortiert werden kann. Bei dem unbounded Dataset des Streams treffen laufend neue Events ein.

Moderne Real-Time Analytics Systeme sind in der Lage, diese Zuordnung vorzunehmen.

Watermark

Bleibt die Frage, wie lange diese internen Puffer bestehen bleiben. Immerhin läuft die Pipeline ununterbrochen und potenziell unendlich lange. Diese Puffer verbrauchen Platz im Memory, der Platz ist endlich und muss frei gegeben werden.

Der zeitliche Versatz liegt in der Natur der Pipeline. Die Abweichung zwischen Event-Time und Processing-Time sollte für die meisten Events vergleichbar sein. Es wird immer Ausreisser geben, die mit erheblicher Verspätung eintreffen.

Als Watermark bezeichnet man die Toleranzgrenze für verspätetes Eintreffen. Setzen wir in unserem Beispiel die Watermark auf zwei Minuten, dann wird der Pupper für das erste Intervall, das ja um 12:01 endet, um 12:03 abgeschlossen, also zwei Minuten nach Ende des Zeitfensters.

Später eintreffende Events werden für die Analyse nicht mehr berücksichtigt.

Trigger

Wir sprechen von Echtzeit und wollen sofort Ergebnisse sehen und nicht warten, bis das Zeitfester plus die Wassermarke verstrichen sind. In unserem Beispiel mit einem Zeitfenster von einer Minute un der Watermark von zwei Minuten, würde das ja bedeuten, dass wir drei Minuten warten müssen, um Ergebnisse zu sehen.

Nach drei Minuten werden wird das Endergebnis sehen. In einer gut funktionierenden Pipeline, sollten in den meisten Fällen ja relativ wenig verspätete Events eintreffen, so dass meistens die Auswertung für ein Zeitfenster unmittelbar aktuell ist.

Doch gerade bei längeren Zeitfenstern wäre es interessant, auch schon vorher einen Einblick zu erhalten und ein vorläufiges Ergebnis zu sehen.

Triggers dienen genau dazu.

Early Trigger bestimmen den Zeitpunkt, du dem ein Einblick in die Entwicklung der Analyse bei einem offenen Zeitfenster erlaubt. Der Zeitpunkt wird relativ zum Beginn des Zeitfensters bestimmt.

Ontime Trigger bestimmen den Einblick in die Analyse nach Abschluss des Zeitfensters.

Late Trigger bestimmen die Watermark, also die Zeitspanne, die nach dem Ontime Trigger noch durchlaufen wird, bevor die Ergebnisse der Auswertung für das betroffene Zeitfenster abschließend vorliegen und der betreffende Puffer im Memory frei gegeben wird.

In der Animation wurden die folgenden Werte angenommen:

• Ontime Trigger = Dauer eines Zeitfensters = 1 Minute
• Early Trigger nach 20 Sekunden (diese Wahl passt zum Beispiel und ist nicht praktischer Natur)
• Late Trigger = Watermark = 2 Minuten

Als Anwender der Data Stream Processing Engine

Auf der Reise von der Quelle bis zur Verarbeitung durchläuft ein Event viele Stationen. Jede kann theoretisch einen Zeitstempel auf das Event schreiben und nach jedem dieser Zeitstempel könnte eine Auswertung erfolgen. Die Aussage des Ergebnisses wäre jedes Mal eine andere.

Als Anwender eines Real-Time Systems sorgen wir dafür, dass wir die Events nach dem richtigen Zeitstempel auswerten. Je nach Anwendungsfall berücksichtigen wir auch unterschiedliche Zeitzonen.

Jedes Real-Time Analytics System löst die in diesem Artikel ganannten Herausforderungen. Jedes System hat ein eigenes API und ein eigenes Wording. So wird beispielsweise der Trigger nicht in jedem System so benannt.

Die Darstellung in diesem Artikel beziehen sich auf  das allgemeine Data Flow Model. Und mit Apache Beam ist auch eine Art Standard in Arbeit, um dem Endanwender die Einarbeitung zu erleichtern.

In den meisten Anwendungsfällen wird eine Auswertung nach Event-Time notwendig sein. Wir müssen also dafür sorgen, dass der Event-Timestamp auf den Events vorhanden ist.

Das unterliegende System kann dem Anwender die komplexe Handhabung der Zuordnung der Events zu den passenden Windows ab.

Moderne Big Data Stream Analytics Systeme ermöglichen dies für Datenströme, die so groß sind, dass sie auf einem verteilten System analysiert werden müssen. Und so werden auch die Data-Buffers die für diese Zuordnung notwendig sind, auf mehrere Systeme verteilt.

Weiterführende Quelle:

Akidau et. al: The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale Unbounded, Out-of-Order Data Processing, 2015, Proceedings of the VLDB Endowment

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.

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:

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?

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

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