LakeDB-Konzept – die nächste Evolution der Lakehouse-Architektur

• Der Bereich Datenmanagement verändert sich rasant, und durch Cloud-Storage sowie die steigende Nachfrage nach Echtzeit-Analysen gewinnt das Konzept des Data Lakehouse an Bedeutung
• Projekte wie Apache Iceberg, Apache Hudi und Delta Lake haben der Lakehouse-Architektur zentrale Funktionen wie Schema-Evolution, ACID-Transaktionen und effiziente Updates bereitgestellt
• Googles internes System Napa zeigt einen Ansatz, der über aktuelle Lakehouse-Lösungen hinausgeht
• Darüber hinaus wird unter Einbeziehung von Ideen aus anderen Systemen wie Apache Pinot LakeDB als nächste Form des Lakehouse vorgeschlagen

Die aktuelle Lakehouse-Landschaft: Iceberg, Hudi, Delta Lake

• Apache Iceberg
  • Unterstützt durch ausgefeiltes Metadatenmanagement Schema-Evolution, Time Travel und effiziente Query-Planung
  • Bietet Konsistenzgarantien für große analytische Datensätze
• Apache Hudi
  • Verarbeitet mit log-strukturierter Speicherung und Indexierung Upserts, Deletes und CDC (Change Data Capture) effizient
  • Legt den Schwerpunkt auf Datenmutationen und inkrementelle Verarbeitung
• Delta Lake
  • Bietet ACID-Transaktionen für Spark und Big-Data-Workloads
  • Unterstützt Schema-Validierung, Time Travel sowie integrierte Batch- und Streaming-Verarbeitung
  • Stellt über Delta Live Tables teilweise deklarative Pipelines und materialisierte Sichten bereit

Googles Napa: ein makroskopischer Ansatz

• Ein vollständiges analytisches Datenmanagementsystem, das Low-Latency-Abfragen und kontinuierliche Datenaufnahme für große Datenmengen unterstützt
• LSM(Log-Structured Merge)-Tree-basierte Aufnahme
  • Nutzt für hohen Schreibdurchsatz einen LSM-Tree-Ansatz und führt Daten per Compaction mit bestehenden Daten zusammen
• Einsatz materialisierter Sichten
  • Hält und aktualisiert materialisierte Sichten automatisch zur Beschleunigung von Abfragen
• Queryable Timestamp (QT)
  • Stellt systemweit konsistentes Zeitstandsmanagement bereit
  • Erlaubt eine feine Abstimmung des Gleichgewichts zwischen Datenaktualität und Query-Performance
• F1 Query-Integration
  • Nutzt Googles F1-Query-Engine, um komplexe analytische Abfragen effizient zu verarbeiten
• Hohe Konfigurierbarkeit
  • Datenaktualität, Performance und Kosten lassen sich an Anforderungen der Nutzer anpassen

Vergleich von Napa, Iceberg, Hudi und Delta Lake

• Napa ist ein umfassendes analytisches Datenmanagementsystem, das mit LSM-basierten materialisierten Sichten schnelle Abfragen unterstützt und mit der Technik Queryable Timestamp (QT) die Datenaktualität fein steuert. Es ist nützlich in Szenarien, in denen große Datenmengen schnell analysiert und berichtet werden sollen, und ermöglicht mit hoher Konfigurationsflexibilität ein ausgewogenes Verhältnis von Kosten, Performance und Aktualität.
• Iceberg ist ein Projekt mit Fokus auf das Tabellenformat, das über Metadaten große Datendateien verwaltet und Funktionen wie atomare Updates bereitstellt. Es wird vor allem in Data-Lake-Umgebungen eingesetzt, die Funktionen wie Data Warehousing, Schema-Evolution oder Time Travel benötigen; die Konfigurationsoptionen konzentrieren sich dabei hauptsächlich auf Tabellenlayout und Metadaten.
• Hudi ist eine Plattform, die Data Lakes um datenbankähnliche Funktionen erweitert, und verarbeitet durch log-strukturierte Speicherung und Indexierung Datenmutationen wie Upserts oder Deletes effizient. Sie ist für Echtzeit-Ingestion, Change Data Capture (CDC) und Compliance-Anforderungen wie GDPR gut geeignet, bietet materialisierte Sichten jedoch nicht standardmäßig an.
• Delta Lake ist eine Storage-Schicht mit Unterstützung für ACID-Transaktionen, die Batch- und Streaming-Aufgaben integriert verarbeitet und außerdem Schema-Enforcement sowie Time Travel bietet. Zur Verbesserung der Query-Performance nutzt es zusammen mit Spark Data Skipping und Caching; über separate Delta Live Tables werden auch Konzepte ähnlich materialisierten Sichten unterstützt. Es wird oft eingesetzt, wenn in unterschiedlichen Data-Lake-Umgebungen Zuverlässigkeit und Transaktionsfunktionen ergänzt werden sollen.

Das Plädoyer für LakeDB: von Napa inspiriert, anderswo dazugelernt

• Durch die Kombination innovativer Ideen aus Napa und Apache Pinot wird das Konzept eines stärker integrierten und flexiblen LakeDB vorgeschlagen
• LakeDB zielt auf eine Datenmanagementlösung ab, bei der Nutzer ihre Anforderungen deklarativ ausdrücken (Aktualität, Kosten, Konsistenz, Indexnutzung usw.) und das System die Optimierung selbst übernimmt

1. Integration von Storage, Ingestion, Metadaten und Query-Verarbeitung

• Storage, Ingestion, Metadaten und Query-Verarbeitung sind in einem einzigen System enthalten
• Nutzer geben nur Datenaktualität und Konsistenz vor, die nötigen Aufgaben werden automatisch abgestimmt
• Bei Iceberg, Hudi und Delta Lake ist dafür die Anbindung separater Tools nötig, was die Komplexität erhöht

2. Intelligente Optimierung materialisierter Sichten und Datenlayouts

• Zwischen CoW(Copy-on-Write)- und MoR(Merge-on-Read)-Verfahren wird je nach Workload automatisch umgeschaltet
• Snapshots und materialisierte Sichten werden entsprechend benutzerdefinierter Anforderungen an Performance und Kosten passend erstellt und verwaltet
• Bei Hudi, Delta Lake und Iceberg muss dieser Prozess größtenteils manuell konfiguriert werden

3. Fein granular steuerbare Datenaktualität

• Wie bei Napas QT kann der Nutzer das gewünschte Aktualitätsniveau angeben, woraufhin das System den Kompromiss zwischen Performance und Kosten bestimmt
• In bestehenden Systemen war es schwierig, Echtzeitfähigkeit sicherzustellen, da man auf periodische Snapshots und Monitoring angewiesen war

4. Fortgeschrittene Indexierung und Partitionierung, inspiriert von Apache Pinot

• Unterstützt fortgeschrittene Indexverfahren wie Star-Tree, sodass auch Analysen mit hoher Kardinalität verarbeitet werden können
• Zielt auf Performanceverbesserungen, die über einfache Partitionierung und Data Skipping in Iceberg und Delta Lake hinausgehen

5. Flexible Konfiguration

• Dieselbe Tabelle kann von mehreren Konsumenten mit unterschiedlichen Anforderungen an Performance, Kosten und Aktualität konfiguriert werden
• Bestehende Systeme bieten nur begrenzte Konfigurationsspielräume, sodass für vielfältige Workloads viel manuelles Tuning nötig ist

6. Unterstützung für ACID und Schema-Evolution

• Übernimmt und erweitert die Grundlagen von ACID und Schema-Evolution aus Iceberg und Delta Lake
• Soll gleichzeitige Schemaänderungen und die Gewährleistung von Datenkonsistenz in verteilten Umgebungen automatisieren

7. Offenheit und Erweiterbarkeit

• Unterstützt Open Standards und die Anbindung verschiedener Query-Engines und lässt sich bei Bedarf erweitern
• Vermeidet die Bindung an bestimmte Vendoren oder Plattformen und ermöglicht eine flexible Anwendung der Funktionen entsprechend den Nutzeranforderungen

Warum LakeDB die nächste Evolution ist

• Performance: Durch fortgeschrittene Indizes, materialisierte Sichten und dynamische Optimierung des Datenlayouts nähert es sich OLAP-Niveau bei der Geschwindigkeit an
• Einfachheit: Managementfunktionen werden in einem System bereitgestellt; Nutzer definieren nur Anforderungen wie Aktualität oder Performance, der Rest wird automatisch angepasst
• Effizienz: Reduziert Ressourceneinsatz und Betriebsaufwand, was auch Kostenvorteile erwarten lässt
• Flexibilität: Ermöglicht durch fein steuerbare Datenaktualität und umfangreiche Konfigurationsoptionen die Unterstützung unterschiedlichster Workloads
• Echtzeit-Analysen: Übernimmt Indextechniken von Apache Pinot und strebt sowohl geringe Latenz als auch hohen Durchsatz an

Fazit

• Apache Iceberg, Apache Hudi und Delta Lake haben eine große Rolle bei der Weiterentwicklung des Lakehouse-Konzepts gespielt
• Durch die Kombination des Napa-Ansatzes von Google mit Ideen aus Apache Pinot und anderen Systemen lässt sich eine stärker integrierte und leistungsfähige Vision von LakeDB entwerfen
• LakeDB hat als ausgereiftes integriertes System, das Storage, Ingestion, Metadaten und Query-Verarbeitung umfasst, großes Potenzial, eine Datenmanagementarchitektur der nächsten Generation zu werden