Freigeben über

Parallelität auf Zeilenebene

Die Parallelität auf Zeilenebene reduziert Konflikte zwischen gleichzeitigen Schreibvorgängen, indem Änderungen auf Zeilenebene erkannt und Konflikte automatisch aufgelöst werden, die auftreten, wenn gleichzeitige Schreibvorgänge in derselben Datendatei aktualisiert oder gelöscht werden.

Anforderungen für Zeilenebenkonkurrenz

Tabellen unterstützen keine Parallelität auf Zeilenebene, wenn sie Partitionen definiert haben oder keine Löschvektoren aktiviert sind. Parallelität auf Zeilenebene erfordert Databricks Runtime 14.2 und höher.

Tabellen mit Partitionen unterstützen keine Parallelität auf Zeilenebene, können aber weiterhin Konflikte zwischen OPTIMIZE und allen anderen Schreibvorgängen vermeiden, wenn Vektoren für Löschungen aktiviert sind. Siehe Einschränkungen für Parallelität auf Zeilenebene.

Informationen zu Databricks-Runtime-Versionen vor 14.2 finden Sie unter Konkurrenzverhalten auf Zeilenebene (Legacy).

Hinweis

Um die Unterstützung von MERGE INTO für Parallelität auf Zeilenebene zu ermöglichen, ist Photon in Databricks Runtime 14.2 erforderlich. In Databricks Runtime 14.3 LTS und höher ist Photon nicht erforderlich.

Konfliktmatrix mit Zeilenebenengleichzeitigkeit

Die folgende Tabelle zeigt, welche Schreibvorgängepaare in jeder Isolationsebene mit aktivierter Parallelität auf Zeilenebene in Konflikt stehen können:

INSERT (1) UPDATELÖSCHEN MERGE INTO OPTIMIZE
INSERT Kann nicht in Konflikt geraten
UPDATELÖSCHEN MERGE INTO In WriteSerializable ist kein Konflikt möglich. Kann in einem serialisierbaren Kontext beim Ändern derselben Zeile einen Konflikt verursachen. Kann beim Ändern derselben Zeile Konflikte verursachen.
OPTIMIZE Kann nicht in Konflikt geraten Kann einen Konflikt verursachen, wenn ZORDER BY verwendet wird. Andernfalls kann es keinen Konflikt geben. Kann einen Konflikt verursachen, wenn ZORDER BY verwendet wird. Andernfalls kann es keinen Konflikt geben.

(1) Alle INSERT Vorgänge in dieser Tabelle beschreiben Anfügeoperationen, die keine Daten aus derselben Tabelle vor dem Abschließen lesen. INSERT-Vorgänge, die Unterabfragen enthalten, die dieselbe Tabelle lesen, unterstützen die gleiche Parallelität wie MERGE.

Hinweis

  • Tabellen mit Identitätsspalten unterstützen keine gleichzeitigen Transaktionen. Weitere Informationen finden Sie unter Verwenden von Identitätsspalten in Delta Lake.
  • REORG Vorgänge verfügen über isolationssemantische Semantik, die OPTIMIZE beim Umschreiben von Datendateien identisch ist. Wenn Sie mit REORG ein Upgrade anwenden, ändern sich die Tabellenprotokolle, was für Konflikte mit allen laufenden Vorgängen sorgt.

Schreibkonflikte ohne Konkurrenz auf Zeilenebene

Tabellen unterstützen keine Parallelität auf Zeilenebene, wenn für sie Partitionen definiert oder keine Löschvektoren aktiviert sind. Databricks Runtime 14.2 oder höher ist für die Parallelität auf Zeilenebene erforderlich.

Konfliktmatrix ohne Reihenebenenkonkurrenz

Die folgende Tabelle zeigt, welche Schreibvorgängepaare in den einzelnen Isolationsstufen in Konflikt stehen können:

INSERT (1) UPDATELÖSCHEN MERGE INTO OPTIMIZE
INSERT Kann nicht in Konflikt geraten
UPDATELÖSCHEN MERGE INTO In WriteSerializable ist kein Konflikt möglich. Kann in Serialisierbar (serializable) einen Konflikt verursachen. Siehe Vermeiden von Konflikten mithilfe der Partitionierung. Kann zu Konflikten in „Serializable“ und „WriteSerializable“ führen. Siehe Vermeiden von Konflikten mithilfe der Partitionierung.
OPTIMIZE Kann nicht in Konflikt geraten In Tabellen mit aktivierten Löschvektoren kann kein Konflikt auftreten, es sei denn, ZORDER BY wird verwendet. Andernfalls kann ein Konflikt auftreten. In Tabellen mit aktivierten Löschvektoren kann kein Konflikt auftreten, es sei denn ZORDER BY verwendet wird. Andernfalls kann ein Konflikt auftreten.

(1) Alle INSERT Vorgänge in dieser Tabelle beschreiben Anfügevorgänge, die keine Daten aus derselben Tabelle vor dem Commit lesen. INSERT-Vorgänge, die Unterabfragen enthalten, die dieselbe Tabelle lesen, unterstützen die gleiche Parallelität wie MERGE.

Hinweis

  • Tabellen mit Identitätsspalten unterstützen keine gleichzeitigen Transaktionen. Weitere Informationen finden Sie unter Verwenden von Identitätsspalten in Delta Lake.
  • REORG Vorgänge verfügen über eine Isolationssemantik, die OPTIMIZE beim Umschreiben von Datendateien identisch ist. Wenn Sie mit REORG ein Upgrade anwenden, ändern sich die Tabellenprotokolle, was für Konflikte mit allen laufenden Vorgängen sorgt.

Einschränkungen für Konkurrenz auf Zeilenebene

Einschränkungen gelten für Zeilenebene-Konkurrenz. Für die folgenden Vorgänge folgt die Konfliktauflösung der normalen Parallelität für Schreibkonflikte. Siehe Schreibkonflikte ohne Gleichzeitigkeit auf Zeilenebene.

Einschränkung Beschreibung
Komplexe bedingte Klauseln Bedingungen für komplexe Datentypen (Strukturen, Arrays, Karten), nicht deterministische Ausdrücke, Unterabfragen und korrelierte Unterabfragen
MERGE Prädikatanforderung In Databricks Runtime 14.2 müssen Befehle ein explizites Prädikat für die Zieltabelle verwenden, um Zeilen zu filtern, MERGE die der Quelltabelle entsprechen.
Leistungskonflikt Die Konflikterkennung auf Zeilenebene kann die Gesamtausführungszeit erhöhen. Bei vielen gleichzeitigen Transaktionen priorisiert der Writer die Latenz gegenüber der Konfliktauflösung.

Alle Einschränkungen für Löschvektoren gelten ebenfalls. Informationen finden Sie unter Einschränkungen.

Vermeiden von Konflikten mithilfe der Partitionierung

Für alle Fälle, die in den Konfliktmatrizen als "Kann konflikt" gekennzeichnet sind, tritt ein Konflikt nur auf, wenn sich die beiden Vorgänge auf dieselbe Gruppe von Dateien auswirken. Um zwei Gruppen von Dateien getrennt zu machen, partitionieren Sie die Tabelle nach den gleichen Spalten, die in Vorgangsbedingungen verwendet werden.

Example:

Die Befehle UPDATE table WHERE date > '2010-01-01' ... und DELETE table WHERE date < '2010-01-01' konfliktieren, wenn die Tabelle nicht nach Datum partitioniert ist, da beide denselben Dateien gleichzeitig zu ändern versuchen können. Durch Partitionierung der Tabelle mittels date wird der Konflikt vermieden.

Hinweis

Die Partitionierung einer Tabelle nach einer Spalte mit hoher Kardinalität kann zu Leistungsproblemen aufgrund der großen Anzahl von Unterverzeichnissen führen.

Beispiel: Vermeiden von Konflikten mit expliziten Partitionsfiltern

Diese Ausnahme wird häufig während gleichzeitiger DELETE, UPDATE oder MERGE-Vorgänge ausgelöst, die möglicherweise dieselbe Partition lesen, selbst wenn verschiedene Partitionen aktualisiert werden. Die Trennung in der Vorgangsbedingung explizit festlegen:

// Problem: Condition can scan the entire table
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

// Solution: Add explicit partition filters
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country AND t.date = '" + date + "' AND t.country = '" + country + "'")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

Konfliktsausnahmen

Wenn ein Transaktionskonflikt auftritt, beobachten Sie eine der folgenden Ausnahmen:

ConcurrentAppendException

Diese Ausnahme tritt auf, wenn ein gleichzeitiger Vorgang Dateien in derselben Partition (oder an einer beliebigen Stelle in einer nicht partitionierten Tabelle) hinzufügt, die ihr Vorgang liest. Dieses Hinzufügen von Dateien kann durch INSERT-, DELETE-, UPDATE- oder MERGE-Vorgänge verursacht werden.

Bei der standardmäßigen Isolationsstufe "WriteSerializable" werden durch blinde INSERT Vorgänge (Vorgänge, die Daten anfügen, ohne Daten zu lesen) keine Konflikte mit anderen Vorgängen verursacht. Wenn die Isolationsstufe serialisierbar ist, können blinde Anhänge konfliktieren.

Von Bedeutung

Blindanfügungen können im WriteSerializable-Modus in Konflikt geraten, wenn mehrere gleichzeitige DELETE, UPDATE oder MERGE Vorgänge auf Werte verweisen können, die durch Blindanfügungen eingefügt wurden. Um dies zu vermeiden:

  • Sicherstellen, dass gleichzeitige DELETE, UPDATEoder MERGE Vorgänge die angefügten Daten nicht lesen
  • Verwenden Sie höchstens eine DELETE, UPDATE, oder MERGE Operation, die die angefügten Daten lesen kann.

GleichzeitigesDeleteReadException

Diese Ausnahme tritt auf, wenn ein gleichzeitiger Vorgang eine Datei löscht, die der Vorgang liest. Häufige Ursachen sind DELETE, UPDATEoder MERGE Vorgänge, die Dateien umschreiben.

ConcurrentDeleteDeleteException

Diese Ausnahme tritt auf, wenn ein gleichzeitiger Vorgang eine Datei löscht, die Ihre Operation ebenfalls löscht. Dies kann durch zwei gleichzeitige Komprimierungsvorgänge verursacht werden, die dieselben Dateien umschreiben.

MetadataChangedException

Diese Ausnahme tritt auf, wenn eine gleichzeitige Transaktion die Metadaten einer Delta-Tabelle aktualisiert. Häufige Ursachen sind ALTER TABLE Vorgänge oder Schreibvorgänge, die das Tabellenschema aktualisieren.

GleichzeitigeTransaktionsAusnahme

Diese Ausnahme tritt auf, wenn eine Streamingabfrage, die denselben Prüfpunktspeicherort verwendet, mehrmals gleichzeitig gestartet wird und versucht, gleichzeitig in die Delta-Tabelle zu schreiben. Führen Sie niemals zwei Streamingabfragen mit demselben Prüfpunktspeicherort gleichzeitig aus.

ProtocolChangedException

Diese Ausnahme kann auftreten, wenn:

  • Ihre Delta-Tabelle wird auf eine neue Protokollversion aktualisiert (Möglicherweise müssen Sie Ihre Databricks-Runtime aktualisieren)
  • Mehrere Autoren erstellen oder ersetzen gleichzeitig eine Tabelle
  • Mehrere Autoren schreiben gleichzeitig in einen leeren Pfad

Siehe Delta Lake Featurekompatibilität und Protokolle.

Vorschauverhalten für Parallelität auf Zeilenebene (Ältere Version)

In diesem Abschnitt werden Vorschauverhalten für Zeilenkonkurrenz in Databricks Runtime 14.1 und älter beschrieben.

Databricks-Runtimeversion Verhalten
Databricks Runtime 13.3 LTS und höher Tabellen mit flüssiger Clusterung ermöglichen automatisch parallele Zeilenebene
Databricks Runtime 14.0 und 14.1 Aktivieren der Parallelität auf Zeilenebene für Tabellen mit Löschvektoren mithilfe der folgenden Konfiguration
Databricks Runtime 14.1 und darunter Nicht-Photon-Computing unterstützt nur die Zeilenebenen-Parallelität für DELETE-Vorgänge.

So aktivieren Sie die Parallelität auf Zeilenebene in Databricks Runtime 14.0 und 14.1:

spark.databricks.delta.rowLevelConcurrencyPreview = true

Parallelität auf Zeilenebene erfordert immer Löschvektoren.

Nächste Schritte

  • Last updated on