Die Technik eines Data Lake

Generell würde ich die Optionen zur Datenspeicherung in drei Kategorien einteilen. Files: Die Daten werden als einfache Files abgelegt und wie Tabellen verwendet.

Diese Files müssten Informationen über die Struktur haben und sollten auch in sich indiziert sein. Das Parquet-File-Format ist ein Vertreter dieser Kategorie.

Datenbankprozess: Statt direkt mit den Files zu arbeiten, liegt ein aktiver Service darüber und der fühlt sich wie eine Datenbank an. Er kümmert sich um Caching von oft benutzten Daten, kann per ODBC/JDBC abgefragt werden. Ein typischer Vertreter dieser Gattung in der Big-Data-Welt ist Apache Hive.

In-memory: Für höchste Performance legt man alle Daten ins Memory, indiziert sie und baut damit etwas Hana-Ähnliches. Exasol und SAP Vora arbeiten nach diesem Prinzip.

Die Big-Data-Welt lebt einzig und allein davon, dass viele kleine (und damit preiswerte) Server ein Gesamtsystem bilden. Damit kann man unendlich skalieren, die Hardwarekosten steigen nur linear.

Aber je mehr Knoten das Gesamtsystem formen, umso teurer wird deren Synchronisierung. Eine Verknüpfung („Join“) von drei oder sogar noch mehr Tabellen kann bedeuten, dass jeder Knoten sich die passenden Zwischen­ergebnisse vom vorhergehenden Join holen muss und die Abfrage Stunden läuft.

Dieses Problem nennt sich „Reshuffle“. Dass die Daten in-memory liegen, hilft bei der Neuverteilung der Zwischenergebnisse über das Netzwerk natürlich auch nicht.

Hana wiederum ist eine echte Datenbank. Sie ist rasend schnell bei der Suche. Die Join-Performance ist großartig, man hat volle Transaktionskonsistenz beim Lesen und Schreiben. All das erfordert einiges an Synchronisierung.

Dafür skaliert so eine Datenbank nicht unendlich. Viele Projekte lösen sich aus dem Dilemma des „Reshuffle“, indem die Daten optimiert für gewisse Abfragen abgelegt werden. Das reduziert wiederum die Flexibilität und erhöht die Kosten, also genau die Punkte, die man als Vorteil eines Data Lake eigentlich haben wollte.

Der Synchronisierungsaufwand von Transaktionskonsistenz ist ein logisches Problem. Es kann nicht gelöst werden, ohne weichere Anforderungen zu stellen, etwa „Eventual Consistency“.

Dieses Problem wird als CAP-Theorem bezeichnet. Von den drei Anforderungen Consistency-Availability-Partitioning können, speziell im Fehlerfall, niemals alle der Punkte erreicht werden.

Ein hochverfügbares und verteiltes System muss Abstriche bei der Datenkonsistenz, ein transaktionales Datenbanksystem Abstriche bei der Verfügbarkeit oder Skalierbarkeit machen.

Die in Big Data vorliegenden Daten sind Rohdaten, die durch Nicht-SQL-Transformationen zu Informationen werden – so macht ein Big-Data-basiertes Data Warehouse mit SQL-Abfragen keinen Sinn.

Das Data Lake ist der Spielplatz für den Data Scientist. Diese Person hat darüber einfachen Zugriff auf Daten, die vorher gelöscht wurden oder an die man nur umständlich herankam.

Der Data Scientist kann mit allen Problemen, die sich aus der Big-Data-Technik ergeben, umgehen: Semantik der Daten; langsame Performance; und, welche Daten es gibt. Mischen von Big-Data- und Business-Daten? Für ihn kein Problem.

Hana mit Vora zu koppeln macht aus dieser Argumentation heraus wenig Sinn. Beide speichern die Daten in-memory und erlauben schnelle Suchen – bei entsprechenden Kosten. Beide haben einen Warm Storage auf Disk (Sybase-Datenbank), beide fokussieren sich auf SQL-Abfragen. Vora ist auch nicht mehr als eigenständiges Produkt auf der Preisliste von SAP.

Parquet Files und eine Datenbank ergänzen sich hingegen perfekt. Die Parquet Files in einem Data Lake kosten in der Speicherung praktisch nichts, in der Datenbank ist Speicherplatz teuer.

Eine Datenbank wie Hana ist exzellent für Joins und für komplizierte SQL-Abfragen geeignet, für einen Compute-Cluster sind genau diese Operationen das Aufwändigste.

Die Kombination von beidem ergibt somit schnelle Business-Intelligence-Abfragen und komfortablen Zugriff auf alle Rohdaten. Beide bringen ihre Stärken ein.