Im vorherigen Artikel, Infrastruktur, Monitoring und Softwareverteilung, haben wir eine erste Übersicht über den Aufbau des Analytics Clusters erhalten, ohne im Detail auf Inhalte des Clusters einzugehen. Das möchte ich mit diesem Artikel mit dem Schwerpunkt Daten ergänzen.
Das Besondere an der Datenanalyse über Big Data Infrastrukturen ist die Berücksichtigung der (wenigstens) drei essentiellen Kriterien:
Nun könnten Sie argumentieren, dass wir uns über Daten und Datenmodelle keine Gedanken machen müssen, da die Technologien eben unter Berücksichtigung dieser Kriterien entwickelt wurden. Und an sich ist der Gedanke korrekt.
Nutzen wir die Technologien ohne Überlegungen, welche Daten uns wie vorliegen und was wir mit diesen Daten erreichen möchten, so vergeuden wir ggf. wichtiges Potential der Umgebung. Oder anders ausgedrückt: Wird unsere Verarbeitung zu langsam oder ab einer gewissen Datenmenge nicht mehr möglich, so können wir durch das Hinzufügen weiterer Ressourcen (=Cluster Member) voraussichtlich sehr gut und auch schneller weiterarbeiten, da die meisten Technologien horizontal skalieren. Das ist zwar effektiv, aber nicht effizient.
Aber wie können wir Daten effizient verarbeiten?
Betrachten wir zu Beginn eine klassische relationale Datenbank. Die meisten Systeme verarbeiten ihre Daten in der Granularität einer Seite (Page) mit einer Größe zwischen 4 KB und 64 KB. Je nach Größe der Felder einer Tabelle passen dann mehr oder weniger Daten in eine Seite, so dass immer dann, wenn ich beispielsweise einen Datensatz (nehmen wir 5 Felder mit ganzzahligen Werten: id, feld1, feld2, feld3. feld4) auslesen möchte, 4 KB bis 64 KB Daten ausgelesen werden müssen.
Das SQL Statement könnte dann ungefähr so aussehen:
select feld1, feld2 from tabelleA where id = 100;
Auch wenn die Rückgabewerte nun ganzzahlige Werte sind, wurden in der Datenbank 4 KB bis 64 KB verarbeitet. Für einen Datensatz von wenigen Bytes.
Das geschieht in der Annahme, dass umliegende Datensätze ggf. im Nachhinein auch verwendet werden und mit dem Wissen, dass das sogenannte Row Level Locking, also die Verwaltung der Daten pro Zeile und nicht pro Seite, für die Datenbank recht aufwendig ist.
Bei dieser Technologie ist es nicht vorgesehen, dass nur einzelne Felder wie feld1 und feld2 ausgelesen werden.
Um das zu erreichen, wurden vor einigen Jahren (ca. Anfang/Mitte der 1990er Jahre) Spalten orientierte Datenbanken entwickelt, die, vereinfacht ausgedrückt, eine Zeile zu einer Spalte machen und somit, unter anderem, die gezielte Selektion einzelner Werte ermöglichen. Diese Technologien haben allerdings den Nachteil, dass diese eben keine Zeile betrachten, was beispielsweise die Verarbeitung von Transaktionen auf Zeilenebene - teilweise drastisch - erschwert.
Die Basistechnologien eines Big Data Analytics Clusters, wie beispielsweise das verteilte Dateisystem HDFS aus dem Hadoop Umfeld, interessieren sich in der Regel nicht Formate, sondern speichern Ihre Daten so ab, wie sie diese erhalten.
Analysetools, wie Apache Drill oder Presto (oder Andere), lesen diese Daten vorzugsweise verteilt und massiv parallel, ein und geben Ihnen, je nach Anfrage, Ihr gewünschtes Ergebnis zurück. Nur können diese Tools auch keine Wunder bewirken. Aber wie wir diese Tools unterstützen können, sehen wir nun in Bereich Daten(formate).
Schauen wir uns zu Beginn die unterschiedlichen Formate an, die sehr häufig in diesem Umgebungen verwendet werden: TXT- oder CSV-, JSON- oder XML-, Parquet- oder ORC-Dateien.
Erst genannte Gruppe (nachfolgend nur noch CSV genannt) repräsentiert einen Datensatz über eine Zeile und jedes Attribut wird als Zeichenkette dargestellt. Einzelne Attribute werden über ein Trennzeichen (einen Komma oder Semikolon) voneinander getrennt. Attributbezeichnungen werden häufig über eine Headerzeile festgelegt. Datentypen sind hierbei nicht direkt erkennbar, reine Zeichenketten können durch Anführungszeichen gekennzeichnet werden. Bei diesem Format ist es nicht möglich Spalten mit einem Index zu versehen, so dass beim Auslesen der Daten immer die gesamte Datei eingelesen und von dem Analysetool ausgewertet werden muss.
Die zweite Gruppe, JSON- und XML-Dateien (JSON), verhalten sich auf der einen Seite anders, auf der anderen Seite sehr ähnlich. Anders zu CSV-Dateien ist, dass die Werte nicht zeilenweise und mit ein Trennzeichen versehen abgebildet sind, sondern über eine Attribut- bzw. Elementkennzeichnung pro Attribut und ggf. nicht identisch pro Datensatz. Dieses bietet die Möglichkeit, dass nicht jeder Datensatz dieselbe Struktur haben muss. Zusätzlich können, in unterschiedlicher Detaillierung, Datentypen definiert werden. Was jedoch auch dieses Format mit der CSV-Datei gleich hat, ist die Notwendigkeit bei der Analyse der Daten die gesamte Datei auslesen zu müssen.
Die letzte Gruppe (Parquet), die wir uns anschauen wollen, sind Datei-Formate, die zur Speicherung von Daten eher einer Datenbank gleichen, somit eine Art Tabellenstruktur (oder besser: ein Metadatenmodell) mit Aufbau und Formaten mitbringen. Dieses erlaubt es uns Daten nicht (nur) zeilenweise, sondern (auch) spaltenweise auslesen zu können. Zusätzlich werden beispielsweise bei Parquet-Dateien Metadaten pro Spalte gespeichert, um beim Auslesen der Daten nicht anhand der Daten, sondern anhand der Metadaten entscheiden zu können, ob relevante Informationen zur Analyse in der Datei zu finden sind.
Leider kann man nicht pauschal sagen, welches Format ideal für Ihren Anwendungszweck ist. Aber es gibt sicherlich Szenarien, wo sich die Formate unterschiedlich empfehlen. CSV-Formate sind super einfach zu erzeugen, beispielsweise über Exporte aus Datenbanken oder Excel-Dateien. Und vor allem, solange diese nicht extrem groß sind, lassen sich diese auch sehr einfach über einen Editor anzuschauen. JSON-Dateien lassen sich auch gut exportieren, aber eben nicht so ganz einfach. Und die Betrachtung mit einem Texteditor liegt nicht so sehr auf der Hand. Des Weiteren nimmt eine JSON-Datei aufgrund der Elementbeschreibungen pro Datensatz sehr viel Platz pro Datensatz ein. Sie haben aber den Vorteil, dass sie sich einfach in alternativen Technologien, wie NoSQL-Datenbank importieren und wiederverwenden lassen. Parquet-Dateien haben im Besonderen bei großen Datenmengen (und darüber reden wir hier ja, oder?) den Vorteil der sehr effizienten Nutzung. Bei kleinen Datensätzen ist der Overhead jedoch nicht unerheblich. Zusätzlich bieten sie den Vorteil einer Komprimierung mit dem Nachteil, dass die Erzeugung und das Auslesen einer Parquet-Datei ein gesondertes Programm benötigt. Mal eben kurz mit einem Texteditor die Datei anschauen oder zwei Dateien in einer zusammenführen: das geht nicht.
Eine weitere Gruppe von Daten schauen wir uns später noch an und zwar die, die von den Datenbanken im Hadoop-Cluster gespeichert werden.
Aber zuvor sollten wir das Thema Datenmodellierung angehen.
Viele Jahre haben wir uns um Datenmodelle auf verschiedenen Ebenen und mit unterschiedlicher Notation gekümmert: Konzeptionelle Modelle, logische und physische Modelle, Krähenfuß-Notationen und weitere und weiterhin spannende Besonderheiten. Die Modellierung hat teilweise größere Teams und Enterprise Data Architekten beschäftigt und hatte den Vorteil, dass man eher häufiger als seltener genau wusste, welche Daten in welche Ausprägung wo zu finden sind. Und diese Modell waren (und sind) die Basis zur Abbildung in relationalen Datenbanken. Hier sprechen wir von Schema on Write.
Diesen Artikel hatten wir mit den drei großen Vs der Big Data-Technologien begonnen:
Im Besonderen die Datenvielfalt (Variety) und Geschwindigkeit (Velocity) machen allerdings die Verwendung von Datenmodellen schwierig und manches Mal auch wenig sinnvoll. Wenn viele Daten sehr unstrukturiert oder selten einheitlich oder vollständig geliefert werden (Datenvielfalt) ist ein Modell wenig aussagekräftig. Ist ein festes Schema in einer Datenbank vorgeschrieben, dann muss dieses natürlich auch eingehalten werden. Werden die Daten allerdings in einer sehr hohen Geschwindigkeit geliefert und muss jeder Datensatz auf seine Struktur hin überprüft werden, so ist das sehr aufwendig.
Um diesen Einschränkungen entgegen zu wirken, wurde das klassische Schema on Write der relationalen Datenbanken in den neuen Technologien um ein Schema on Read, also dem Auslesen des Schemas erst dann, wenn man es benutzt, ergänzt.
Was bedeutet das für Auswertungen in unserem Cluster? Zum Einen bedeutet es, dass der Datenanalyst (m, w, d) mit Veränderungen an den Daten umgehen muss, da das Analysetool diese einfach an die Analyse zurück liefert. Zum Anderen bedeutet es, dass wir zur Beschreibung unserer Daten etwas Drittes benötigen. Vielleicht so etwas wie ein Modell? Wohl eher so etwas wie einen Datenkatalog. Dieses Thema greife ich in einem späteren Blog-Post nochmals auf.
Als Datenbank bezeichnet man sowohl eine Datei mit Daten, wie auch Systeme, die Daten speichern, verwalten und bereitstellen. Letzteres wird auch häufig Datenbank-Management-System (DBMS) genannt und soll hier berücksichtigt werden.
In unserem Kontext (Big Data) unterscheiden wir drei Arten von Datenbanken und zwar jene, die auf HDFS aufsetzen, und jene, die die gesamte Umsetzung eigenständig abbilden.
Starten wir mit Datenbanken, die auf HDFS aufsetzen. Sie stellen sich sicherlich die Frage, warum man das tun sollte? Hat doch HDFS den Nachteil, dass es Daten in einer bestimmten (und recht großen) Blockgröße speichert und eigentlich das Ändern von Daten nicht ermöglichst, sondern nur das Überschreiben. Dieser genannten Probleme haben sich Systeme, wie beispielsweise Apache HBase (nachfolgend: HBase) und Apache Phoenix angenommen und sogar teilweise eliminiert. Diese können dann zusätzlich von den Vorteilen des HDFS und zwar der Verteilung und damit der sehr hohen Datenverfügbarkeit und Parallelität bei der Verarbeitung profitieren. Konkret erreicht HBase dies durch die Ergänzung oder sogar der teilweisen Umgehung der Speicherkomponenten (HDFS Datanode) und durch die Bereitstellung eines sogenannten Write Ahead Logs (WAL), der die Daten zur Speicherung und Verwendung (zusätzlich) (im HDFS und in Memory) zwischenspeichert, um einen möglichst hohen Datendurchsatz zu erreichen.
Eine sehr populäre Technologie zur Speicherung sehr großer Datenmengen ohne HDFS ist Apache Cassandra. Sie bietet, ähnlich wie HBase, die Möglichkeit, spaltenbasierend Daten zu speichern und zu analysieren. Und nutzt hierzu intern das Parquet-Format. Da Cassandra nicht auf HDFS aufbaut, muss es seine Verteilung (Cluster) und die verteilte Speicherung (Replikation) eigenständig umsetzen, was allerdings auch den Freiheitsgrad gegenüber HBase erhöht. So ist Cassandra beispielsweise masterless, also ohne einen dedizierten Hauptknoten definiert, was einen Single of Failure vermeidet.
Wie schon zuvor, bei den Datenformaten, ist es nicht sinnvoll für alle Aufgaben die eine Technologie als die Beste hervorzuheben. Apache HBase hat den Vorteil, dass es auf ein ggf. bestehendes HDFS aufsetzt und sich somit sehr leicht in eine bestehende Infrastruktur integriert. Cassandra hat den Vorteil, dass es das eben nicht zwingend benötigt und somit für eine dedizierte Aufgabe (Best of Breed-Ansatz) eingesetzt werden kann.
Und ich sollte die zig anderen Datenbanken nicht unterschlagen, wie ArangoDB oder CosmosDB (aus Microsoft Azure) oder auch passive Technologien wie Microsoft ADLS2 (Azur Data Lake Storage V2) oder Amazon AWS S3, die ebenso viele Möglichkeiten zur Speicherung anbieten wie die zuvor genannte. Nun eben anders.
Leider gilt auch hier: es kommt eben darauf an.