Anmerkung
Der Zugriff auf diese Seite erfordert eine Genehmigung. Du kannst versuchen, dich anzumelden oder die Verzeichnisse zu wechseln.
Der Zugriff auf diese Seite erfordert eine Genehmigung. Du kannst versuchen , die Verzeichnisse zu wechseln.
Dieser Artikel enthält eine Übersicht über Delta Lake-Protokolle, Tabellenfeatures und Kompatibilität mit Delta Lake-Clients für Lese- und Schreibvorgänge.
Das Transaktionsprotokoll für eine Delta-Tabelle enthält Protokollversionsinformationen. Weitere Informationen finden Sie unter Überprüfen der Details der Delta Lake-Tabelle mit Beschreibungsdetails.
Wie gibt das Tabellenprotokoll Lese- und Schreibkompatibilität an?
Jede Delta-Tabelle weist eine Protokollspezifikation auf, die den Satz der Funktionen angibt, die zum Lesen und Schreiben in die Tabelle erforderlich sind. Die Protokollspezifikation wird von Anwendungen verwendet, die aus der Tabelle lesen oder in die Tabelle schreiben, um festzustellen, ob sie alle features verarbeiten können, die die Tabelle unterstützt. Wenn eine Anwendung nicht weiß, wie sie ein Feature behandeln soll, das im Protokoll einer Tabelle als unterstützt aufgeführt ist, dann kann diese Anwendung diese Tabelle nicht lesen oder schreiben.
Die meisten neuen Fähigkeiten und Funktionen, die mit Delta Lake eingeführt werden, erfordern ein Upgrade des Tabellenprotokolls.
In der folgenden Tabelle finden Sie eine Übersicht über die wichtigsten Begriffe, die zum Beschreiben von Delta Lake-Protokollen verwendet werden:
| Begriff | BESCHREIBUNG |
|---|---|
| Delta Lake-Client | Jedes System, das eine Delta-Tabelle liest oder schreibt. |
| Leseprotokoll | Gibt die Unterstützung an, die für einen Delta Lake-Client zum Lesen einer Tabelle erforderlich ist. |
| Protokoll schreiben | Gibt die Unterstützung an, die für einen Delta Lake-Client erforderlich ist, um in eine Tabelle zu schreiben. |
minReaderVersion |
Komponente des Leseprotokolls. Gültige Werte sind 1, 2oder 3. |
minWriterVersion |
Komponente des Writer-Protokolls. Gültige Werte sind ganze Zahlen von 2 bis 7. |
| Tabellenfunktion | Eine Alternative zu Protokollversionen, die differenzierter ist. Tabellenfeatures entsprechen optional aktivierten Delta Lake-Features. |
| Writer-Funktion | Ein Tabellenfeature, das an ein Schreibprotokoll gebunden ist. |
| Leserfunktion | Ein Tabellenfeature, das an ein Leseprotokoll gebunden ist. |
Schreibprotokolle und Writer-Features wirken sich nur auf die Kompatibilität mit Writer-Clients aus, was bedeutet, dass der schreibgeschützte Zugriff auf die Tabelle von älteren Workloads weiterhin unterstützt wird. Leseprotokolle und Lesefeatures wirken sich sowohl auf lese- als auch schreibkompatibilität aus.
Nicht alle Delta Lake-Features sind miteinander kompatibel.
Einige Tabellenfeatures können nicht gelöscht werden, nachdem sie aktiviert wurden. Weitere Informationen finden Sie unter Löschen eines Delta Lake-Tabellenfeatures und Herabstufen des Tabellenprotokolls.
Tabellenfeatures zur Protokollkompatibilität
In Databricks Runtime 12.2 LTS und höher verwendet Databricks Tabellenfeatures , um Unterstützung für Features und Kompatibilität mit Lesern und Autoren anzugeben. Tabellenfeatures verwenden granulare Flags, um anzugeben, welche Features von einer bestimmten Tabelle unterstützt werden. Tabellenfeatures ersetzen das ältere Protokollversionierungsschema durch die Einführung von neuen Funktionen im Delta Lake-Protokoll.
Merkmale des Tabellenschreibers geben an, wie sich die Art des Schreibens von Daten auswirkt. Tabellenschreiber-Funktionen benötigen minWriterVersion == 7. Features, die als Writer-Features implementiert wurden, blockieren keine Leseclients.
Tabellenleserfunktionen kennzeichnen Funktionen, die beeinflussen, wie Daten gelesen werden. Alle Tabellenleserfunktionen sind auch Tabellenschreiberfunktionen. Tabellenlesefunktionen erfordern minReaderVersion == 3 und minWriterVersion == 7. Ein Client kann nicht in eine Tabelle schreiben, die nicht gelesen werden kann.
Wenn Tabellenfeatures aktiviert sind, werden alle vom Protokoll für die Tabelle unterstützten Features in den jeweiligen Listen als readerFeatures oder writerFeatures. Beim Entfernen von Funktionen aus einer Tabelle kann die Tabelle möglicherweise dieses Verhalten ändern, um auf das kleinstmögliche Protokoll umzuschalten. Siehe niedrigstes mögliches Protokoll.
Ganzzahlbasierte Protokollversionen und Legacykompatibilität
Alle Tabellen enthalten eine ganzzahlbasierte Protokollversion, die durch minReaderVersion und minWriterVersion repräsentiert wird. Funktionalität, die mithilfe von Tabellenfeatures implementiert wird, baut auf diesen Protokollversionen auf, aber viele Ältere Reader- und Writer-Clients verwenden weiterhin Protokollversionen zur Verwaltung der Kompatibilität. Delta Lake versucht, das Tabellenprotokoll auf die niedrigste mögliche Version aufzulösen, um die maximale Kompatibilität mit modernen und älteren Delta-Clients aufrechtzuerhalten. Siehe niedrigstes mögliches Protokoll.
Im ganzzahligen Protokollversionsverwaltungsschema bündelt jede Versionsnummer mehrere Features, und Features über Versionsnummern hinweg sind kumulativ. Dies bedeutet, dass Clients, um mit dem Delta-Protokoll kompatibel zu sein, Unterstützung für alle Leser- oder Writer-Features implementieren müssen, die in einer bestimmten Version vorhanden sind, einschließlich aller zuvor veröffentlichten Features.
Hinweis
Databricks bietet unterbrechungsfreie, teilweise Unterstützung für Tabellen-Features in allen unterstützten Databricks-Runtime-Versionen. OSS Delta-Clients wählen aus, wie die Unterstützung für bestimmte Features implementiert werden soll.
Wann ändert sich das Tabellenprotokoll?
Das Protokoll für eine Tabelle ändert sich unter den folgenden Bedingungen:
- Wenn ein neues Feature aktiviert ist, wird das Protokoll aktualisiert.
- Wenn ein Tabellenfeature gelöscht wird, wird das Protokoll herabgestuft.
Das Deaktivieren eines Tabellenfeatures führt nicht zum Protokolldowngrade. Sie müssen das Feature ablegen, um es vollständig aus dem Tabellenprotokoll zu entfernen. Nicht alle Tabellenfeatures können gelöscht werden. Weitere Informationen finden Sie unter Löschen eines Delta Lake-Tabellenfeatures und Herabstufen des Tabellenprotokolls.
Alle Protokolländerungsvorgänge verursachen einen Konflikt mit allen gleichzeitigen Schreibvorgängen.
Streaming-Lesevorgänge schlagen fehl, wenn ein Commit auftritt, der Tabellenmetadaten ändert. Wenn der Stream fortgesetzt werden soll, müssen Sie ihn neu starten. Empfohlene Methoden finden Sie unter Produktionsüberlegungen für strukturiertes Streaming.
Warnung
Die meisten Protokollversionsupgrades können nicht rückgängig gemacht werden, und das Upgraden der Protokollversion könnte die vorhandenen Reader und/oder Writer für die Delta Lake-Tabelle unterbrechen. Databricks empfiehlt, dass Sie für bestimmte Tabellen nur bei Bedarf ein Upgrade durchführen, z. B. um neue Features in Delta Lake zu abonnieren. Sie sollten auch überprüfen, ob alle Ihre aktuellen und zukünftigen Produktionstools Delta Lake-Tabellen mit der neuen Protokollversion unterstützen.
Protokollherabstufungen sind für einige Features verfügbar. Weitere Informationen finden Sie unter Löschen eines Delta Lake-Tabellenfeatures und Herabstufen des Tabellenprotokolls.
Wann wird das Tabellenprotokoll aktualisiert?
Wenn Sie ein Feature in einer Tabelle aktivieren, wird das Tabellenprotokoll automatisch aktualisiert. Einige Features werden automatisch basierend auf der in CREATE oder ALTER Tabellenanweisungen verwendeten Syntax aktiviert, während andere Features explizit aktiviert werden müssen, indem Tabelleneigenschaften festgelegt werden. Manchmal müssen Sie mehrere Tabellenfeatures explizit aktivieren, um die gewünschte Funktionalität zu unterstützen. In anderen Fällen kann die Aktivierung von Funktionen automatisch andere Tabellenfeatures aktivieren. Schauen Sie in der Azure-Databricks-Dokumentation nach den Funktionen und der Syntax, die Sie verwenden, um zu bestimmen, welche Tabellenfunktionen erforderlich sind.
Lesefunktionen erfordern ein Upgrade sowohl des Leseprotokolls als auch des Schreibprotokolls. Writer-Features erfordern nur ein Upgrade des Schreibprotokolls.
Beispielsweise ist die Unterstützung für CHECK Einschränkungen ein Writer-Feature: Nur Schreibanwendungen müssen über CHECK Einschränkungen Bescheid wissen und sie durchsetzen.
Im Gegensatz dazu erfordert die Spaltenzuordnung das Upgraden sowohl der Lese- als auch der Schreibprotokolle. Da die Daten in der Tabelle unterschiedlich gespeichert werden, müssen Reader-Anwendungen die Spaltenzuordnung verstehen, damit sie die Daten korrekt lesen können.
Hinweis
Databricks empfiehlt, die Tabelleneigenschaften minReaderVersion und minWriterVersion nicht zu ändern. Das Ändern dieser Tabelleneigenschaften verhindert keine Protokollupgrades. Wenn Sie diese Werte auf einen niedrigeren Wert festlegen, wird die Tabelle nicht herabgestuft. Weitere Informationen finden Sie unter Löschen eines Delta Lake-Tabellenfeatures und Herabstufen des Tabellenprotokolls.
Geringstmögliches Protokoll
Standardmäßig versucht Delta Lake, das niedrigste Protokoll zu verwenden, das möglich ist, um alle Features darzustellen, die von der Tabelle unterstützt werden.
Dieses Verhalten kann nur dazu führen, das Tabellenprotokoll zu senken, was bedeutet, dass sich minReaderVersion oder minWriterVersion möglicherweise in niedrigere Werte für eine Tabelle ändern können.
Sie müssen den DROP FEATURE Befehl ausführen, um ein Tabellenfeature aus der Liste der unterstützten Features im Tabellenprotokoll zu entfernen. Tabellenfeatures werden nie automatisch gelöscht.
Wenn alle in einer Tabelle vorhandenen Delta Lake-Features in einer niedrigeren Protokollversion vollständig unterstützt werden, wird die Tabelle möglicherweise auf eine Protokollversion zurückgesetzt, die keine Tabellenfeatures verwendet, um die Lese- und Schreibzugriffskompatibilität anzugeben. Wenn dieses Protokolldowngrade eintritt, kann die Tabelle entweder das readerFeatures oder sowohl readerFeatures als auch writerFeatures aus dem Tabellenprotokoll entfernen. Dies führt nicht dazu, dass Delta Lake-Features deaktiviert werden und nur auftreten, wenn Tabellenfeatures nicht im Tabellenprotokoll erforderlich sind.
Alle Änderungen, die das Tabellenprotokoll senken, erhöhen die Kompatibilität mit Reader- und Writer-Clients. Dies liegt daran, dass Lese- und Schreibclients niedrigere Protokollversionen berücksichtigen müssen, auch wenn sie höhere Protokollversionen unterstützen.
Ändern Tabellenfeatures, wie Delta Lake-Features aktiviert werden?
Wenn Sie mit Delta-Tabellen nur über Azure Databricks interagieren, können Sie weiterhin die Unterstützung für Delta Lake-Features mithilfe von Mindestanforderungen für Databricks Runtime nachverfolgen. Azure Databricks unterstützt das Lesen von Delta-Tabellen, für die in allen Databricks Runtime LTS-Releases ein Upgrade auf Tabellenfeatures durchgeführt wurde, solange alle von der Tabelle verwendeten Features von diesem Release unterstützt werden.
Wenn Sie mittels anderen Systemen aus Delta-Tabellen lesen und schreiben, müssen Sie möglicherweise überlegen, wie sich Tabellenfeatures auf die Kompatibilität auswirken, da ein Risiko besteht, dass das System die aktualisierten Protokollversionen nicht verstehen konnte.
Wichtig
Tabellenfeatures werden im Delta Lake-Format für die Writer-Version 7 und die Reader-Version 3 eingeführt. Azure Databricks hat Code in alle unterstützten Databricks Runtime LTS-Versionen zurückportiert, um Unterstützung für Tabellenfeatures hinzuzufügen, aber nur für diejenigen Features, die in dieser Databricks Runtime bereits unterstützt werden. Dies bedeutet, dass Sie zwar die Verwendung von Tabellenfeatures abonnieren können, um generierte Spalten zu aktivieren und weiterhin mit diesen Tabellen in Databricks Runtime 9.1 LTS zu arbeiten, aber Tabellen mit aktivierten Identitätsspalten (die Databricks Runtime 10.4 LTS erfordern) werden in dieser Databricks Runtime immer noch nicht unterstützt.
Wie verwaltet Azure Databricks die Delta Lake-Featurekompatibilität?
Databricks führt Unterstützung für neue Delta Lake-Features und Optimierungen ein, die auf Delta Lake in Databricks Runtime-Releases aufbauen. Azure Databricks-Optimierungen, die Delta Lake-Features nutzen, berücksichtigen die in OSS-Delta Lake verwendeten Protokolle zur Kompatibilität. Viele Azure Databricks-Optimierungen erfordern die Aktivierung von Delta Lake-Features auf einer Tabelle, und einige Azure Databricks-Produkte wie Lakeflow Spark Declarative Pipelines sind von vielen Tabellenfeatures abhängig.
- Alle Tabellen, die von niedrigeren Databricks-Runtime-Versionen geschrieben wurden, verfügen über vollständige Lese- und Schreibunterstützung in höheren Databricks-Runtime-Versionen.
- Tabellen, die von höheren Databricks-Runtime-Versionen geschrieben wurden, können Tabellenfeatures verwenden, die in niedrigeren Databricks-Runtime-Versionen nicht unterstützt werden.
- Einige Features ermöglichen möglicherweise Schreibvorgänge aus niedrigeren Databricks-Runtime-Versionen, ohne alle Optimierungen im Zusammenhang mit den aktivierten Tabellenfeatures vollständig anzuwenden.
Beim Arbeiten mit Tabellenfeatures, die rückportierte Unterstützung für niedrigere Databricks-Runtime-Versionen haben, werden einige Vorgänge, die auf einer bestimmten Databricks-Runtime-Version ausgeführt werden, möglicherweise nicht auf der entsprechenden OSS Delta-Version ausgeführt. Wenn Ihr Entwicklungszyklus oder ihre Datenarchitektur OSS Delta Lake enthält, sollten Sie die Kompatibilität immer in OSS Delta-Clients testen, bevor Sie Tabellenfeatures für Produktionstabellen aktivieren.
Delta Lake-Features und erforderliche Databricks-Runtime-Versionen
Features werden auf Tabellenbasis aktiviert. Die folgende Tabelle enthält die niedrigste Databricks-Runtime-Version mit vollständiger Unterstützung für das angegebene Feature. Die vollständige Unterstützung bedeutet, dass alle allgemein verfügbaren Funktionen für Lese- und Schreibvorgänge unterstützt werden.
| Merkmal | Erfordert Databricks Runtime-Version oder höher | Dokumentation |
|---|---|---|
CHECK Einschränkungen |
Alle unterstützten Databricks Runtime-Versionen |
Festlegen einer CHECK Einschränkung in Azure Databricks |
| Ändern des Datenfeeds | Alle unterstützten Databricks Runtime-Versionen | Verwenden Sie den Delta Lake-Änderungs-Datenfeed in Azure Databricks |
| Generierte Spalten | Alle unterstützten Databricks Runtime-Versionen | Von Delta Lake generierte Spalten |
| Spaltenzuordnung | Alle unterstützten Databricks Runtime-Versionen | Umbenennen und Löschen von Spalten mit Delta Lake-Spaltenzuordnung |
| Identitätsspalten | Alle unterstützten Databricks Runtime-Versionen | Verwenden von Identitätsspalten in Delta Lake |
| Tabellenfunktionen | Databricks Runtime 12.2 LTS | Tabellenfeatures zur Protokollkompatibilität |
| Löschvektoren | Databricks Runtime 12.2 LTS | Was sind Löschvektoren? |
| ZeitstempelNTZ | Databricks Runtime 13.3 LTS |
TIMESTAMP_NTZ Typ |
| Uniform | Databricks Runtime 13.3 LTS | Lesen von Delta-Tabellen mit Iceberg-Clients |
| Flüssigkeitsclusterbildung | Databricks Runtime 13.3 LTS | Verwenden von Flüssigclustering für Tabellen |
| Zeilenverfolgung | Databricks Runtime 14.3 LTS | Verwenden der Zeilenverfolgung für Delta-Tabellen |
| Typerweiterung | Databricks Runtime 15.4 LTS | Typerweiterung |
| Variante | Databricks Runtime 15.4 LTS | Unterstützung von Varianten in Delta Lake |
| Sortierungen | Databricks Runtime 16.1 | Sortierungsunterstützung für Delta Lake |
| Geschützte Prüfpunkte | Databricks Runtime 16.3 | Ein Delta Lake-Tabellenfeature entfernen und das Tabellenprotokoll herabstufen |
Weitere Informationen finden Sie unter Versionshinweise, Versionen und Kompatibilität von Databricks Runtime.
Hinweis
Lakeflow Spark Declarative Pipelines und Databricks SQL aktualisieren Laufzeitumgebungen automatisch mit regelmäßigen Versionen, um neue Features zu unterstützen. Lesen Sie die Versionshinweise zu Lakeflow Spark Declarative Pipelines und den Release-Upgradeprozess und Databricks SQL-Versionshinweise.
Features nach Protokollversion
Das OSS Delta Lake-Protokoll hat auf Tabellenfeatures standardisiert, aber einige Lese- und Writer-Clients haben keine Unterstützung für Tabellenfeatures implementiert und verwenden weiterhin Legacy minWriterVersion - und minReaderVersion Protokolle.
Einige Clients haben möglicherweise keine Unterstützung für alle Delta Lake-Features, einschließlich Features, die legacyprotokollversionsverwaltung verwenden. Lesen Sie die Dokumentation für Ihren Delta Lake-Client, um die Unterstützung für Features zu bestätigen. Testen Sie immer die Kompatibilität, bevor Sie neue Features in Produktionstabellen aktivieren.
In der folgenden Tabelle sind die Mindestversionen der Lese- und Schreibprotokolle aufgeführt, die für Delta Lake-Features erforderlich sind, und zeigt an, ob ein Tabellenfeature nur für Schreibvorgänge oder sowohl Lese- als auch Schreibvorgänge berücksichtigt werden muss.
Hinweis
Wenn Sie sich nur mit der Kompatibilität von Databricks Runtime befassen, lesen Sie , wie verwaltet Azure Databricks die Delta Lake-Featurekompatibilität?.
| Merkmal | minWriterVersion |
minReaderVersion |
Tabellenfunktion |
|---|---|---|---|
| Grundlegende Funktionalität | 2 | 1 | Schriftsteller |
CHECK Zwänge |
3 | 1 | Schriftsteller |
| Ändern des Datenfeeds | 4 | 1 | Schriftsteller |
| Generierte Spalten | 4 | 1 | Schriftsteller |
| Spaltenzuordnung | 5 | 2 | Leser und Autor |
| Identitätsspalten | 6 | 1 | Schriftsteller |
| Zeilennachverfolgung | 7 | 1 | Schriftsteller |
| Vektoren löschen | 7 | 3 | Leser und Autor |
| ZeitstempelNTZ | 7 | 3 | Leser und Autor |
| Clusterbildung von Flüssigkeiten | 7 | 3 | Leser und Autor |
| Iceberg-Leser (UniForm) | 7 | 2 | Schriftsteller (1) |
| Typerweiterung | 7 | 3 | Leser und Autor |
| Variante | 7 | 3 | Leser und Autor |
| Kollationen | 7 | 3 | Leser und Autor |
| Geschützte Prüfpunkte | 7 | 1 | Schriftsteller |
(1): Erfordert, dass die Spaltenzuordnung aktiviert ist.