de.wedoany.com-Bericht: Databricks gibt die Einführung einer Technologie namens LTAP (Lake Transactional/Analytical Processing) bekannt, deren Marketing-Slogan „Ein Datensatz, null Kompromisse, null Kopien“ lautet. Ziel ist es, das Problem zu lösen, dass OLTP und OLAP nur schwer im selben System koexistieren können. Die Technologie basiert auf der Open-Source-Engine Apache Spark und stützt sich auf zwei neue Produkte: Reyden (eine neue Rechen-Engine) und Lakebase (ein serverloses PostgreSQL auf Basis offener Objektspeicher). Databricks versucht, Transaktionen, Analysen, Streams und operative Daten auf einer einzigen Speicherkopie im Data Lakehouse (einer Kombination aus Data Lake und Data Warehouse) zu vereinen, um die grundlegende Herausforderung zu bewältigen, dass OLTP kleine zeilenorientierte Lesevorgänge und häufige Schreibvorgänge ausführt, während OLAP große spaltenorientierte Lesevorgänge und Batch-Schreibvorgänge durchführt. Dieses Problem wird besonders dringlich, da der Datenbankmarkt die Arbeitslasten verfolgt, die durch den Einsatz von KI-Agenten entstehen.
Allerdings gibt es Kontroversen um die Behauptung der „Null-Kopien“. Datenentwickler weisen darauf hin, dass die aktuellen PostgreSQL-Daten in LTAP zunächst im Pageserver-Format als lokaler Speicher vorliegen und dann zur langfristigen Persistenz als Parquet-Dateien in den Objektspeicher übertragen werden. PostgreSQL/Lakebase kann Daten aus dem Objektspeicher abrufen und die Parquet-Daten zurück in den Pageserver konvertieren. Ein Kommentator von einem Konkurrenten von Databricks merkt an, dass dies tatsächlich „zwei Datensätze, nicht einer“ sei. Auf einer PostgreSQL-Konferenz im Mai dieses Jahres bestätigten auch Folien der Databricks-Ingenieure Hristo Stoyanov und Jonathan Katz dies, die zeigten, dass der Pageserver Speicher bereitstellt, während die Spark-Analyse-Executoren Schichtdateien mit vollständigen Seitenbildern aus der Spiegelungsschicht im Objektspeicher abrufen. In einer privaten Nachrichtengruppe, die The Register einsehen konnte, antwortete ein Databricks-Ingenieur, dass es technisch gesehen zwei Kopien seien, da der Pageserver in der Neon-Architektur als Cache oder Materialisierungsschicht fungiere. Lakebase basiert auf der Technologie von Neon, das Databricks im letzten Jahr übernommen hat, und bietet Copy-on-Write-Verzweigungen sowie automatisch skalierendes serverloses Computing.
Die Vereinheitlichung von OLTP und OLAP ist nicht neu bei Databricks. Bereits 2014 begann SingleStore mit der Arbeit an In-Memory-Zeilenspeicher und Festplatten-Spaltenspeicher und setzte eine mehrschichtige Speichertechnologie ein, die Analysen und Transaktionsverarbeitung auf einem einzigen System ermöglicht. Ein Cloud-Datenbankdienst, den das Unternehmen 2020 einführte, verwaltet angeblich automatisch Daten über eine dreischichtige Architektur aus Arbeitsspeicher, lokalem Cache und Objektspeicher. Auf die Behauptung von Databricks, dass Hybrid Transactional/Analytical Processing (HTAP) gescheitert sei, antwortete Nadeem Asghar, CTO von SingleStore, dass die Vereinheitlichung von OLTP und OLAP genau das Ziel von HTAP sei: „Es in LTAP umzubenennen, ändert nur das Marketing. Es ändert nicht die physikalische Realität.“ Er wies darauf hin, dass auf dem System von Databricks drei Engines laufen, jede mit eigenem Cache und eigener Einschätzung der Datenfrische, und dass die physikalische Form der „zwei Datensätze“ einen Mechanismus zur Synchronisation erfordere. Darüber hinaus bietet MongoDB Spaltenindexe, Oracle HeatWave for MySQL ermöglicht Analysen auf Transaktionsanwendungen, und SAP treibt seit 2011 Echtzeitanalysen auf Basis der In-Memory-Datenbank HANA voran.
Databricks besteht darauf, dass die Behauptung der „Null-Kopien“ wahr sei, da zwei autoritative Datenkopien vermieden werden, die synchronisiert werden müssten. In einer Erklärung gegenüber The Register sagte ein Databricks-Sprecher, dass Benutzer in LTAP mit einer einzigen autoritativen Kopie der Daten arbeiten, die eine einzige Quelle der Wahrheit in Iceberg habe, während andere interne Zwischenkopien zur „Datenbank-Speicherhierarchie“ gehörten. Auf einer kürzlichen Konferenz schränkte Databricks dies dahingehend ein, dass es nur eine „autoritative“ Kopie der Daten oder nur eine Kopie „im Speicher“ gebe, ähnlich der Beschreibung von SingleStore, dass seine Speicherschicht „für den Benutzer transparent“ sei.
Andy Pavlo, außerordentlicher Professor für Datenbanken an der Carnegie Mellon University, weist darauf hin, dass Databricks unabhängig von den Marketing-Debatten beeindruckende Ingenieursarbeit geleistet habe, um die neue Engine Reyden in die Lage zu versetzen, PostgreSQL-Seiten zu lesen. Er sagt, dass es keine einfache Aufgabe sei, dass die Reyden-Engine den Inhalt von PostgreSQL-Seiten interpretieren könne, da die Seiten nicht vollständig in sich geschlossen seien und Metadaten aus dem Katalog von Neon/PostgreSQL abgerufen werden müssten. Die Technologie ermögliche zeitnähere Analysen, und zwar auf transaktionssichere Weise, ohne darauf warten zu müssen, dass Daten nach S3 gepusht werden. Gleichzeitig sei Reyden zustandslos und könne durch Hinzufügen von Rechenressourcen horizontal skaliert werden. Pavlo räumt jedoch ein: „Letztendlich kopieren sie die Daten trotzdem.“
