Parallelität auf Zeilenebene

Parallelität auf Zeilenebene reduziert Konflikte zwischen gleichzeitigen Schreibvorgängen, indem Änderungen auf Zeilenebene erkannt und Konflikte bei gleichzeitigen Schreibvorgängen automatisch aufgelöst werden, die unterschiedliche Zeilen in derselben Datendatei aktualisieren oder löschen.

Anforderungen für Zeilenebenkonkurrenz

Parallelität auf Zeilenebene wird automatisch aktiviert, wenn alle folgenden Anforderungen erfüllt sind:

  • Verwenden von Databricks Runtime 14.3 LTS und höher.
  • Die Quelltabelle verwendet keine Partitionen.
  • Die Quelltabelle hat Löschvektoren aktiviert. Siehe Löschungsvektoren in Databricks.

Partitionierte Tabellen lassen keine Parallelität auf Zeilenebene zu. Wenn Löschvektoren aktiviert sind, können partitionierte Tabellen jedoch weiterhin Konflikte zwischen OPTIMIZE und Schreibvorgängen vermeiden. Siehe Einschränkungen für Parallelität auf Zeilenebene.

Für Databricks Runtime-Versionen vor 14.3 LTS siehe Legacyverhalten der Parallelität auf Zeilenebene.

Konfliktmatrix mit Zeilenebenengleichzeitigkeit

Bei Quelltabellen mit Parallelität auf Zeilenebene zeigt die folgende Tabelle, welche Schreibvorgängepaare in den einzelnen Isolationsstufen in Konflikt stehen können:

Vorgang 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ügevorgänge, die keine Unterabfragen enthalten, die Daten aus derselben Tabelle lesen. INSERT Vorgänge, die Unterabfragen enthalten, die aus derselben Tabelle gelesen werden, unterstützen dieselbe Parallelität wie MERGE.

Hinweis

  • Tabellen mit Identitätsspalten unterstützen keine gleichzeitigen Transaktionen. Siehe Identitätsspalten.
  • 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 Parallelität auf Zeilenebene

Bei Quelltabellen ohne Parallelität auf Zeilenebene zeigt die folgende Tabelle, welche Schreibvorgängepaare in den einzelnen Isolationsstufen in Konflikt stehen können:

Vorgang 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 in „Serializable“ und „WriteSerializable“ in Konflikt stehen. 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 wird verwendet. Andernfalls kann ein Konflikt auftreten.

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

Hinweis

  • Tabellen mit Identitätsspalten unterstützen keine gleichzeitigen Transaktionen. Siehe Identitätsspalten.
  • 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 und geraten in Konflikt mit allen laufenden Vorgängen.

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 Parallelität 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 Schreiber 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

Das Partitionieren einer Tabelle anhand einer Spalte mit hoher Kardinalität kann durch eine große Anzahl von Unterverzeichnissen zu Leistungsproblemen führen.

Vermeiden von Konflikten mit expliziten Partitionsfiltern

Diese Ausnahme wird häufig bei gleichzeitigen DELETE-, UPDATE- oder MERGE-Vorgängen ausgelöst, die möglicherweise dieselbe Partition lesen, selbst wenn dabei 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.

Mit der standardmäßigen Isolationsstufe WriteSerializable stehen Dateien, die von INSERT-Vorgängen hinzugefügt werden, welche Daten anhängen, ohne dabei Daten zu lesen, mit keinem Vorgang in Konflikt. Wenn die Isolationsstufe serialisierbar ist, können Anfügekonflikte auftreten.

Von Bedeutung

INSERT-Vorgänge können im WriteSerializable-Modus in Konflikt geraten, wenn mehrere gleichzeitige DELETE-, UPDATE- oder MERGE-Vorgänge möglicherweise auf Werte verweisen, die durch den INSERT-Vorgang angehängt 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.

ConcurrentDeleteReadException

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 Lake-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 Writer schreiben gleichzeitig in einen leeren Pfad.

Siehe Delta Lake Featurekompatibilität und Protokolle.

Legacyverhalten bei Nebenläufigkeit auf Zeilenebene

In Databricks Runtime 13.3 LTS verwendet die Parallelität auf Zeilenebene das Legacyverhalten:

  • Erfordert Löschvektoren. Siehe Löschungsvektoren in Databricks.
  • Tabellen mit flüssiger Clusterung ermöglichen automatisch die Parallelität auf Zeilenebene.

Weitere Ressourcen

  • Last updated on