Überblick
Im Eröffnungskapitel wird klar dargelegt, warum wir ein Produkt wie Delta Lake entwickeln möchten. Databricks hat versucht, das Data Warehouse direkt auf dem Cloud-Objektspeicher aufzubauen. Bei diesem Versuch sind wir auf einige Probleme mit dem Objektspeicher gestoßen. Um diese Probleme zu lösen, haben wir vorgeschlagen Die technische Lösung von Delta Lake wurde übernommen.
Vorteile der Objektspeicherung
- Kostengünstig, Pay-as-you-go, Pay-as-you-go
- Kann sich schnell ausdehnen und zusammenziehen
- Durch die Trennung von Speicher und Rechenleistung können Benutzer Speicher- oder Rechenressourcen unabhängig voneinander anpassen
Probleme mit der Objektspeicherung
- Der Objektspeicher bietet nur eine kv-ähnliche API, und jeder Pfad ist ein Schlüssel. Es ist schwierig, Transaktionen zwischen schlüsselübergreifenden Objekten zu garantieren. Beim Aktualisieren einer bestimmten Tabelle lesen andere Clients möglicherweise Zwischendaten. Sogar ein unerwarteter Exit während des Aktualisierungsprozesses kann zu beschädigten Daten führen
- Besonders schlecht ist die Leistung von Metadatenoperationen, insbesondere von Listenoperationen. Beispielsweise kann S3 jedes Mal nur 1.000 Objekte zurückgeben, und jede Ausführung dauert Hunderte von ms.
- Da es beim Lesen von Daten in der Cloud zu einer anfänglichen Latenz (langsamer Start) kommt, müssen Sie die Fußzeile jeder auszuführenden Datei häufig lesen, wenn Sie die in der Fußzeile der Parkettdatei gespeicherten Min/Max-Statistikinformationen verwenden möchten Prädikate Beim Herunterschieben kann dieser Prozess aufgrund des Problems des „langsamen Starts“ dazu führen, dass diese „Überspringprüfung“ langsamer ist als die ursprüngliche Abfrage.
Designideen für Delta Lake
Um diese Objektspeicherprobleme zu lösen, wurde daher das Architekturdesign von Delta Lake vorgeschlagen, einer ACID-Tabellenspeicherschicht über Cloud-Objektspeichern. Er
verglich hier auch mehrere andere Lösungsideen
, beispielsweise durch Datenpartitionierung oder durch eine Zentralisierung System wie Schneeflocke. Der Nachteil dieser Art von Metadatendiensten besteht darin, dass ein separater Metadatendienst verwaltet werden muss, und dieser Dienst kann leicht zu einem Engpass werden, da alle Vorgänge über diesen Dienst erfolgen müssen. Die Idee von Delta Lake dient dazu, Metadaten direkt im Objektspeicher zu speichern
und eine Transaktionsgarantie über das WAL-Protokoll zu erreichen.
Sie können sehen, dass sich im Partitionsverzeichnis Datendateien befinden und das Transaktionsprotokoll im Verzeichnis _dalta_log aufgezeichnet wird.
Diese Protokolle zeichnen auf, welche Dateien hinzugefügt wurden, welche Dateien gelöscht wurden, Metadatenvorgänge, Schemaänderungen und Statistikinformationen.
Wenn Sie auf diese Weise lesen, müssen Sie das Delta-Protokoll durchlaufen, um die Liste der Dateien zu ermitteln, die gelesen werden müssen. Um zu vermeiden, dass bei jedem Lesen alle JSON-Dateien überprüft werden müssen, führen wir regelmäßig einen Checkpoint durch und führen mehrere JSON-Dateien zusammen in eine .parquet-Datei. Und notieren Sie die neueste Checkpoint-ID in _last_checkpoint.
Der Prozess des Lesens von Daten auf diese Weise besteht darin, die Checkpoint-Datei abzufragen, um die Liste dieser Dateien zu finden, und dann irrelevante Dateien basierend auf den Statistiken in den Metadaten herauszufiltern , und dann diese Datendateien direkt lesen. Dies ist viel schneller als die ursprüngliche Operationsliste + das Lesen der Fußzeile der Datei.
Protokoll lesen
- Last_Checkpoint-ID lesen
- Verwenden Sie die Listenoperation, um den Prüfpunkt und die JSON-Liste danach zu finden. Auf diese Weise können Sie eine Ansicht der Tabelle zu einem bestimmten Zeitpunkt erstellen. Hier ist zu beachten, dass das Design auch mit dem Eventual kompatibel ist Konsistenz des Cloud-Speichers.
- Lesen Sie Daten basierend auf der Dateiliste dieser Metadaten
Protokoll schreiben
- Nach dem Schreiben eines Datenobjekts müssen die Metadaten im Verzeichnis delta_log aktualisiert werden.
- Suchen Sie die Dateisequenz-ID r, die neu geschrieben werden soll, und schreiben Sie den neuen Datensatz
r + 1.json
(Würde das nicht bedeuten, dass jede JSON-Datei nur eine Datei aufzeichnet?) Gemäß der Beschreibung im Papier sollte eine Protokolldatei mehrere Vorgänge enthalten. Es ist möglich, dass es sich bei Spark um einen Mikro-Batch-Schreibvorgang handelt und jeder Schreibvorgang mehrere Vorgänge umfassen kann Operationen. Änderungen an Datendateien
- Der Schreibvorgang
r+1.jsonmuss atomar sein. Dies hängt von den atomaren APIs ab, die von verschiedenen Cloud-Anbietern bereitgestellt werden.- Beispielsweise verfügt Google Cloud Storage über eine atomare Put-If-Absent-Schnittstelle
- HDFS verwendet die atomare Umbenennungs-API
- S3 verfügt nicht über diese Möglichkeit und stellt daher einen zusätzlichen Koordinationsdienst zur Verfügung, um dies zu erreichen.
- Wenn der Schreibvorgang fehlschlägt, wird der vorherige Schritt erneut ausgeführt und der Commit erneut ausgeführt.
Transaktionsschutz
ACID entspricht jeweils Atomizität (entweder Erfolg oder Misserfolg), Konsistenz (Daten erfüllen immer Integritätsbeschränkungen und Änderungen an den Daten sind für Benutzer sofort sichtbar, nachdem die Transaktion abgeschlossen ist), Isolation (gleichzeitige Vorgänge beeinflussen sich nicht gegenseitig) und Haltbarkeit (Daten sind nicht flüchtig).
Atomizität : Der Vorgang in der Protokolldatei ist atomar. Die Änderung dieser Datei ist eigentlich der Prozess der Transaktionsübermittlung, ob erfolgreich oder fehlgeschlagen, um Atomizität und Konsistenz sicherzustellen: Konsistenz bedeutet, dass eine Transaktion die Datenbank
von
einem Punkt an konsistent machen muss. Ändern Sie den Konsistenzstatus in einen anderen Konsistenzzustand (Ausführungserfolg) oder auf den ursprünglichen Konsistenzzustand zurücksetzen (Ausführungsfehler). Dies bedeutet, dass Integritätsbeschränkungen eingehalten werden müssen, damit die Datenbank vor und nach Transaktionen konsistent und korrekt bleibt. In diesem Sinne garantiert Delta Lake derzeit Transaktionsfähigkeiten auf einer einzelnen Tabelle, sodass auch die Konsistenz gewährleistet werden kann. Wenn die Atomizität erfüllt ist, kann die Konsistenz erfüllt werden. Isolation: Isolation bezieht sich auf die gleichzeitige Ausführung. Die verschiedenen Transaktionen können sich nicht gegenseitig stören Das heißt, die innerhalb einer Transaktion verwendeten Vorgänge und Daten sind von anderen gleichzeitigen Transaktionen isoliert. Diese Eigenschaft stellt sicher, dass der Effekt der gleichzeitigen Ausführung einer Reihe von Transaktionen gleichbedeutend mit der seriellen Ausführung in einer bestimmten Reihenfolge ist , dh um einen solchen Effekt zu erzielen: für zwei beliebige gleichzeitige Transaktionen T1 und T2 aus Sicht der Transaktionen T1, T2 oder Es endet, bevor T1 beginnt, oder beginnt, nachdem T1 endet, sodass jede Transaktion nicht den Eindruck hat, dass andere Transaktionen gleichzeitig ausgeführt werden. Dies erfordert zwei Dinge:
- Während der Ausführung einer Transaktion sollte der Zwischenzustand (möglicherweise inkonsistent) der Daten nicht für alle anderen Transaktionen offengelegt werden.
- Zwei gleichzeitige Transaktionen sollten nicht in der Lage sein, mit denselben Daten zu arbeiten. Datenbankverwaltungssysteme verwenden normalerweise Sperren, um diese Funktion zu implementieren.
Nehmen Sie als Beispiel Überweisungen: Während des gesamten Prozesses der Geldüberweisung von A an B ändert sich bei der Abfrage von A-Konto und B-Konto der Geldbetrag auf den beiden Konten nicht, solange die Transaktion noch nicht festgeschrieben wurde. Wenn A gleichzeitig Geld an B überweist, gibt es eine andere Transaktion, die den Übertragungsvorgang von C nach B ausführt. Wenn beide Transaktionen enden, muss das Geld auf dem Konto von B das von A nach B überwiesene Geld plus die Überweisung von C sein . Bs Geld plus sein eigenes ursprüngliches Geld.
Auf diese Weise verhindert die Isolierung Dateninkonsistenzen aufgrund einer kreuzweisen Ausführung, wenn mehrere Transaktionen gleichzeitig ausgeführt werden. Die Transaktionsisolation ist in verschiedene Ebenen unterteilt, darunter nicht festgeschriebenes Lesen (nicht festgeschriebenes Lesen), festgeschriebenes Lesen (festgeschriebenes Lesen), wiederholbares Lesen (wiederholbares Lesen) und serialisierbares Lesen (serialisierbar). Die Isolierung der oben genannten vier Ebenen wird nacheinander verbessert, um jeweils unterschiedliche Probleme zu lösen. Je höher die Transaktionsisolationsstufe, desto besser kann sie die Datenintegrität und -konsistenz gewährleisten, aber gleichzeitig sind auch die Auswirkungen auf die Parallelitätsleistung umso größer.
**Persistenz: **Daten werden in den persistenten Speicher geschrieben. Fehler, die während der Commit-Phase auftreten, werden neu geschrieben, um die Haltbarkeit sicherzustellen.
Häufige Probleme in der Isolation sind
- Dirty Read: Dirty Read bezieht sich auf das Lesen nicht festgeschriebener Daten aus anderen Transaktionen. Nicht festgeschrieben bedeutet, dass die Daten möglicherweise zurückgesetzt werden, was bedeutet, dass sie am Ende möglicherweise nicht in der Datenbank gespeichert werden, dh nicht vorhanden sind. Daten, die gelesen werden und irgendwann existieren müssen, werden Dirty Reading genannt.
- Nicht wiederholbares Lesen: Nicht wiederholbares Lesen bedeutet, dass innerhalb derselben Transaktion derselbe Datenstapel, der zu unterschiedlichen Zeiten gelesen wird, unterschiedlich sein und von anderen Transaktionen beeinflusst werden kann. Beispielsweise haben andere Transaktionen diesen Datenstapel geändert und übermittelt .
- Phantomlesung: Phantomlesung dient zum Einfügen von Daten (INSERT). Angenommen, Transaktion A hat den Inhalt einiger Zeilen geändert, ihn jedoch noch nicht übermittelt. Zu diesem Zeitpunkt hat Transaktion B dieselbe Datensatzzeile wie der Datensatz eingefügt, bevor Transaktion A sich geändert hat, und sie übermittelt, bevor Transaktion A übermittelt wurde. Zu diesem Zeitpunkt Bei der Abfrage in Transaktion A werden Sie feststellen, dass es den Anschein hat, dass die Änderungen gerade keine Auswirkungen auf einige Daten haben. Tatsächlich wurden sie jedoch nur von Transaktion B eingefügt, was beim Benutzer ein magisches und halluzinierendes Gefühl hervorruft. Dies wird als Phantomlesen bezeichnet .
In Delta Lake kann der Festschreibungsprozess von mehreren Clients parallel ausgeführt werden, aber nur ein Client wird gleichzeitig erfolgreich festgeschrieben. Der fehlgeschlagene Client versucht erneut, in die nächste Datei zu schreiben. Zu diesem Zeitpunkt sollte eine Logik zur Konflikterkennung vorhanden sein . Dies ist ein optimistischer Parallelitätskontrollmechanismus
Und indem die Liste der jedes Mal übermittelten Versionsdateien über das Delta-Protokoll verwaltet wird, kann eine MVCC-Semantik erreicht werden. Beim Lesen wird nur eine erfolgreich übermittelte Version gelesen. Daher erreicht Delta Lake die obige Isolation durch optimistische Parallelitätskontrolle + MVCC. Mehrere Probleme wird nicht existieren. Es hat die Serialisierbare Isolationsstufe erreicht,
sodass man sagen kann, dass die ACID-Semantik garantiert ist.
Funktionen auf höherer Ebene
Zeitreisen und Rollbacks
Die Snapshots in jeder Version werden am Prüfpunkt aufgezeichnet, sodass Zeitreisen sehr einfach sind. Spark SQL unterstützt das Lesen von Daten einer bestimmten Version über AS OF timestampund VERSION AS OF commit_id. Um die Daten historischer Versionen zu lesen, müssen Sie natürlich die Dauer festlegen Datenspeicherung. Dadurch wird verhindert, dass die Daten beim Lesen physisch gelöscht werden.
Gleichzeitig können die Daten auch über die MERGE INTO-Syntax zurückgesetzt/repariert werden.
Effizientes UPSERT, DELETE und MERGE
Da Transaktionen unterstützt werden, können Daten sicher aktualisiert werden, ohne den aktuellen Reader zu beeinträchtigen. Er erwähnte nicht, wie das Update implementiert wird, aber es fühlt sich an, als ob es ähnlich wie bei Hudi sein sollte, wo die Datei zuerst lokalisiert und dann neu geladen wird. Schreiben Sie diesen Teil des Dokuments.
Streaming-Aufnahme und -Konsum
Es kann einen Teil der Funktionen der Nachrichtenwarteschlange übernehmen. Die delta_log-Daten können zum Lesen der Datenänderungen nach einem bestimmten CP-Punkt verwendet werden. Die Komprimierungsaufgabe kann im Hintergrund ausgeführt werden, um kleine Dateien zu großen Dateien zusammenzuführen und so die Leseleistung zu optimieren.
Optimierung des Datenlayouts
Aufgrund der Unterstützung von Transaktionen kann auch eine gewisse Hintergrundlayoutoptimierung zur Optimierung des Lesens verwendet werden. Gängige Optimierungsmethoden: Kompakt, Aktualisierungsstatistik, Index, Z-Reihenfolge. Z-Reihenfolge kann den Vergleich von Tabellen in mehrdimensionalen Szenarien ermöglichen. Gute
Daten Skipping-Effekt. Der Leistungstest zeigt auch die Auswirkung von Zorder auf die Datenfilterung in mehrdimensionalen Szenarien.
Caching
Dies bedeutet, dass entfernte Daten auf der Computerseite auf der lokalen Festplatte zwischengespeichert werden können. Da sich eine Datendatei nach dem Schreiben nicht mehr ändert, ist das Caching relativ sicher und kann Abfragen sehr stark beschleunigen.
Audit-Protokollierung
Durch die Metadatenverwaltung können Datenoperationsprotokolle in Metadaten aufgezeichnet und historische Dateiänderungen tabellarisch dargestellt werden. Paimon verfügt auch über eine ähnliche Prüfprotokolltabelle.
Schema-Evolution
Durch die Metadatenverwaltung verfügen Tabellen tatsächlich über Multiversionsfähigkeiten, und die zugrunde liegenden Daten können über verschiedene Versionen von Schemata gelesen werden. Dies ist natürlich auch möglich.
Konnektoren zu Abfrage- und ETL-Engines
Das ist ziemlich interessant. Das bedeutet, dass es einen Konnektor bietet, der sich mit anderen Systemen integrieren lässt, aber einen Mechanismus verwendet.
Durch die Bereitstellung der _symlink_format_manifest-Datei kann ein Snapshot des aktuellen Systems für Stapelverarbeitungs- und Olap-Systeme verfügbar gemacht werden, und diese Systeme müssen nur in der Lage sein, Parquet-Dateien zu lesen. Benutzer müssen lediglich eine SQL ausführen, um eine solche Manifestdatei zu
generieren kann als Erscheinungsbild von Presto, Arthena, RedShift und SnowFlake verwendet werden. Es ist kein zusätzlicher Plug-in-Entwicklungsaufwand erforderlich.
Häufige Nutzungsszenarien
-
Traditionelles ETL basiert auf Cloud-Speicher und nutzt die Vorteile des Cloud-Objektspeichers
-
BI-Analyse. Direkt basierend auf der Olap-Abfrage des Objektspeichers. Um diese Art der Abfrage zu beschleunigen, wurde eine speziell entwickelte Photon-Laufzeitumgebung entwickelt, die die Fähigkeit zur Ad-hoc-Abfrage erheblich verbessert. Der Vorteil besteht darin, dass keine Daten in ein importiert werden müssen Sondersystem separat.
Schließlich sollte Lakehouse der Hauptgeschäftsführer von Delta Lake sein, und Databricks hätte später ein entsprechendes Papier veröffentlichen sollen. Lakehouse implementiert Batch-ETL, Streaming-Computing, Olap-Analyse und maschinelles Lernen direkt auf der Grundlage der einheitlichen Speicherung von Objektspeichern.
Leistung
Schließlich gibt es mehrere wesentliche Leistungsverbesserungen:
- Metadaten werden über Protokolldateien verwaltet, wodurch Metadatenvorgänge wie Listen in herkömmlichen Architekturen reduziert werden.
- Der Effekt der Layoutoptimierung wie Z-Reihenfolge
- Die Schreibleistung bleibt ähnlich wie zuvor
Verwandte Arbeit
Hudi/Iceberg: Sehr ähnlich, das Speicherformat und das Protokoll werden auch in Bezug auf die Speicherung definiert. Die Funktionen sind tatsächlich ähnlich.
Hive: Derzeit verfügt Hive mithilfe von Metastore auch über ACID-Funktionen. Es fehlen jedoch möglicherweise einige Zeitreisefunktionen und Aktualität der Daten. Nicht ausreichend. Wenn die Partitionsdaten groß sind, stellen Metadatenvorgänge immer noch den Engpass dar.
HBase/kudu: Diese Systeme können zusätzlich zu HDFS auch Schreib- und Lesefunktionen mit geringerer Latenz bereitstellen. Kleine Schreibvorgänge können zusammengeführt und geschrieben werden. Sie müssen jedoch ausgeführt werden. Die Kosten für ein separates verteiltes System sind völlig unterschiedlich.
Cstore: Das letzte ist Cstore. Auf lange Sicht versuchen diese Systeme, leistungsstarke Transaktionsfunktionen und Analysefunktionen bereitzustellen. Und Cstore ist ein System das versucht, HTAP auf diese Weise zu integrieren. Diese Systeme bieten residente Dienste zur Optimierung von OLTP oder Analyse.
Delta Lake hingegen läuft direkt auf dem Objektspeicher und bietet eine relativ ausreichende Transaktionsschicht. Dadurch entfällt der Overhead unabhängiger Speicherdienste.
Zusammenfassen
Delta Lake kapselt eine Schicht von Schreib- und Leseprotokollen basierend auf optimistischer Parallelitätskontrolle + MVCC auf der Cloud-Objektspeicherung und bietet ACID-Semantik. Auf dieser Basis implementiert es Funktionen wie Zeitreise, Aktualisieren/Löschen, Datenlayout und Schemaentwicklung . , Streaming Read und eine Reihe von High-Level-Funktionen.
Obwohl es drei Hauptdaten-Lake-Produkte auf dem Markt gibt: Delta Lake, Hudi und Iceberg. Die ursprüngliche Absicht bei der Schaffung dieser drei hat jedoch immer noch ihren eigenen Schwerpunkt. In diesem Artikel wird hauptsächlich Delta Lake vorgestellt, das hauptsächlich Folgendes tun möchte Es nutzt die günstigen und nutzungsabhängigen Eigenschaften des Cloud-Objektspeichers, muss jedoch eine Reihe von Objektspeicherproblemen lösen. Hudi wurde ursprünglich von Uber eingeführt, um die inkrementelle Aktualisierung seines internen Offline-Speichers zu
lösen Data Warehouse. Problem. Mit der Politur der Open-Source-Community und des Open-Source-Marktes haben sich die Funktionen dieser Produkte jedoch allmählich angenähert, und alle verfügen im Wesentlichen über Aktualisierung/Löschen, ACID, Zeitreise, Datenlayoutoptimierung, Streaming-Lesen und andere Funktionen .
Darüber hinaus auch Technologietrends, die sich sehen lassen
- Trennung von Speicherung und Berechnung
- Lakehouse-Architektur basierend auf demselben Speicher
Referenz
Einführung und Vergleich von ACID für Cloud Data Warehouse- und Data Lake-Metadaten - Alibaba Cloud Developer Community Einführung und Vergleich von ACID für Cloud Data Warehouse- und Data Lake-Metadaten
https://www.cnblogs.com/cciejh/p/acid.html In- Tiefes Verständnis von Big Data. Datenarchitektur – Transaktionen und ihre ACID-Eigenschaften.
Isolationsstufen und Implementierungsprinzipien von MySQL-Transaktionen (lesen Sie einfach diesen Artikel!) – Zhihu. Isolationsstufen und Implementierungsprinzipien von MySQL-Transaktionen
sprechen kurz über Datenbank-Parallelitätskontrolle – Sperren und MVCC – Vertrauen orientierte Programmierung
Parallelitätskontrolle – Delta Lake-Dokumentation