Sdílet prostřednictvím

Souběžnost na úrovni řádků

Souběžnost na úrovni řádků snižuje konflikty mezi souběžnými operacemi zápisu tím, že detekuje změny na úrovni řádku a automaticky řeší konflikty, ke kterým dochází při souběžné aktualizaci zápisu nebo odstranění různých řádků ve stejném datovém souboru.

Požadavky na souběžnost na úrovni řádků

Tabulky nepodporují souběžnost na úrovni řádků, pokud mají definované oddíly nebo nemají povolené vektory odstranění. Souběžnost na úrovni řádků vyžaduje Databricks Runtime 14.2 a vyšší.

Tabulky s oddíly nepodporují konkurenci na úrovni řádků, ale při povolení vektorů odstranění se mohou vyhnout konfliktům mezi OPTIMIZE a všemi ostatními operacemi zápisu. Viz Omezení souběžnosti na úrovni řádků.

Informace o verzích Databricks Runtime starších než 14.2 najdete v tématu Chování při souběžnosti na úrovni řádků (starší verze).

Poznámka:

MERGE INTO Podpora souběžnosti na úrovni řádků vyžaduje Photon v Databricks Runtime 14.2. Ve službě Databricks Runtime 14.3 LTS a novější není Photon vyžadován.

Matice konfliktů se souběžností na úrovni řádků

Následující tabulka ukazuje, které páry operací zápisu můžou kolidovat v jednotlivých úrovních izolace s povolenou souběžností na úrovni řádků:

INSERT (1) UPDATEVYMAZATMERGE INTO OPTIMIZE
INSERT Nemůže být v rozporu
UPDATEVYMAZATMERGE INTO Nelze zpracovat konflikt v WriteSerializable. Při úpravě stejného řádku může dojít ke konfliktu v režimu Serializable. Může dojít ke konfliktu při úpravě stejného řádku.
OPTIMIZE Nemůže být v rozporu Může dojít ke konfliktu použitím ZORDER BY. Nemůže to být v rozporu jinak. Může dojít ke konfliktu použitím ZORDER BY. Nemůže to být v rozporu jinak.

(1) Všechny INSERT operace v této tabulce popisují operace připojení, které před potvrzením nepřečtou žádná data ze stejné tabulky. INSERT operace, které obsahují poddotazy, které čtou stejnou tabulku, podporují stejnou souběžnost jako MERGE.

Poznámka:

  • Tabulky se sloupci identit nepodporují souběžné transakce. Viz Použití sloupců identit v Delta Lake.
  • REORG operace mají sémantiku izolace stejnou jako OPTIMIZE při přepisování datových souborů. Když použijete REORG ke spuštění upgradu, dojde ke změně protokolů tabulek, což je v rozporu se všemi probíhajícími operacemi.

Konflikty zápisu při absenci konkurence na úrovni řádků

Tabulky nepodporují souběžnost na úrovni řádků, pokud mají definované oddíly nebo nemají povolené vektory odstranění. Databricks Runtime 14.2 nebo vyšší se vyžaduje pro souběžnost na úrovni řádků.

Konfliktní matice bez souběžnosti na úrovni řádků

Následující tabulka ukazuje, které páry operací zápisu můžou kolidovat v jednotlivých úrovních izolace:

INSERT (1) UPDATEVYMAZATMERGE INTO OPTIMIZE
INSERT Nemůže být v rozporu
UPDATEVYMAZATMERGE INTO Nelze zpracovat konflikt v WriteSerializable. Může být v konfliktu se serializovatelností. Viz Zabránění konfliktům pomocí dělení. Může dojít ke konfliktu v Serializable a WriteSerializable. Viz Zabránění konfliktům pomocí dělení.
OPTIMIZE Nemůže být v rozporu Nelze v tabulkách kolidovat s povolenými vektory odstranění, pokud ZORDER BY se nepoužívá. Může se dostat do konfliktu jinak. Nelze v tabulkách kolidovat s povolenými vektory odstranění, pokud ZORDER BY se nepoužívá. Může se dostat do konfliktu jinak.

(1) Všechny INSERT operace v této tabulce popisují operace přidání, které před potvrzením nepřečtou žádná data ze stejné tabulky. INSERT operace, které obsahují poddotazy, které čtou stejnou tabulku, podporují stejnou souběžnost jako MERGE.

Poznámka:

  • Tabulky se sloupci identit nepodporují souběžné transakce. Viz Použití sloupců identit v Delta Lake.
  • REORG operace mají sémantiku izolace stejnou jako OPTIMIZE při přepisování datových souborů. Když použijete REORG ke spuštění upgradu, dojde ke změně protokolů tabulek, což je v rozporu se všemi probíhajícími operacemi.

Omezení souběžnosti na úrovni řádků

Omezení platí pro souběžnost na úrovni řádků. Řešení konfliktů u následujících operací se řídí obvyklou souběžností pro konflikty zápisu. Viz Konflikty zápisu bez souběžnosti na úrovni řádků.

Omezení Description
Komplexní podmíněné klauzule Podmínky pro komplexní datové typy (struktury, pole, mapy), nedeterministické výrazy, poddotazy a korelované poddotazy
MERGE požadavek na predikát V Databricks Runtime 14.2 MERGE musí příkazy použít explicitní predikát v cílové tabulce k filtrování řádků odpovídajících zdrojové tabulce.
Výkonový kompromis Detekce konfliktů na úrovni řádků může zvýšit celkovou dobu provádění. Při mnoha souběžných transakcích zapisovač upřednostňuje latenci oproti řešení konfliktů.

Platí také všechna omezení pro vektory odstranění. Viz Omezení.

Vyhněte se konfliktům pomocí dělení

Ve všech případech označených jako "může kolidovat" v maticích konfliktů dojde ke konfliktu pouze v případě, že dvě operace ovlivňují stejnou sadu souborů. Pokud chcete vytvořit dvě sady souborů oddělené, rozdělte tabulku podle stejných sloupců, které se používají v podmínkách operací.

Příklad:

Pokud tabulka není rozdělena podle data, příkazy UPDATE table WHERE date > '2010-01-01' ... a DELETE table WHERE date < '2010-01-01' konfliktují, protože oba se mohou pokusit upravit stejné soubory. Rozdělením tabulky podle date se vyhnete konfliktu.

Poznámka:

Dělení tabulky podle sloupce s vysokou kardinalitou může vést k problémům s výkonem kvůli velkému počtu podadresářů.

Příklad: Jak se vyhnout konfliktům s explicitními filtry oddílů

Tato výjimka se často vyvolá během souběžných DELETEUPDATEoperací nebo MERGE operací, které mohou číst stejný oddíl i při aktualizaci různých oddílů. Explicitně stanovte oddělení v podmínkách provozu.

// 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()

Výjimky při konfliktech

Když dojde ke konfliktu transakcí, zjistíte jednu z následujících výjimek:

Výjimka při souběžném připojování

Tato výjimka nastane, když souběžná operace přidá soubory ve stejném oddílu (nebo kdekoli v tabulce bez oddílů), který vaše operace přečte. Doplňky souborů můžou být způsobeny operacemi INSERT, DELETE, UPDATE, nebo MERGE operacemi.

S výchozí úrovní izolace WriteSerializable nejsou soubory přidané slepými INSERT operacemi (operacemi, které připojují data bez čtení dat) v konfliktu s žádnou operací. Pokud je úroveň izolace serializovatelná, můžou být slepá připojení v konfliktu.

Důležité

Slepá připojení mohou při režimu WriteSerializable kolidovat, když více souběžných operací DELETE, UPDATE, nebo MERGE může odkazovat na hodnoty vložené slepými připojeními. Chcete-li se tomu vyhnout:

  • Ujistěte se, že souběžné operace DELETE, UPDATE, nebo MERGE nečtou připojená data.
  • Mít maximálně jednu DELETE, UPDATEnebo MERGE operaci, která může číst připojená data

ConcurrentDeleteReadException

K této výjimce dochází, když souběžná operace odstraní soubor, který operace přečte. Mezi běžné příčiny patří DELETE, UPDATE nebo MERGE operace, které přepisují soubory.

ConcurrentDeleteDeleteException

K této výjimce dochází, když souběžná operace odstraní také soubor, který vaše operace odstraní. Příčinou můžou být dvě souběžné operace komprimace, které přepisují stejné soubory.

MetadataChangedException

K této výjimce dochází, když souběžná transakce aktualizuje metadata tabulky Delta. Mezi běžné příčiny patří ALTER TABLE operace nebo zápisy, které aktualizují schéma tabulky.

VýjimkaSoučasnýchTransakcí

K této výjimce dochází, pokud je dotaz streamování používající stejné umístění kontrolního bodu spuštěn vícekrát souběžně a pokusí se zapisovat do tabulky Delta současně. Nikdy současně neprovozujte dva streamovací dotazy se stejným umístěním kontrolního bodu.

VýjimkaZměnaProtokolu

K této výjimce může dojít v těchto případech:

  • Vaše tabulka Delta se upgraduje na novou verzi protokolu (možná budete muset upgradovat databricks Runtime).
  • Více zapisovačů vytváří nebo nahrazuje tabulku ve stejnou dobu.
  • Více zapisovačů zapisuje současně na prázdnou cestu k souboru.

Viz kompatibilita a protokoly funkcí Delta Lake.

Chování souběžnosti na úrovni řádků (starší verze)

Tato část popisuje chování verze Preview pro souběžnost na úrovni řádků v Databricks Runtime 14.1 a níže.

Verze modulu Databricks Runtime Chování
Databricks Runtime 13.3 LTS a vyšší Tabulky s liquid clusteringem automaticky umožňují souběžnost na úrovni řádku.
Databricks Runtime 14.0 a 14.1 Povolení souběžnosti na úrovni řádků pro tabulky s vektory odstranění s využitím níže uvedené konfigurace
Databricks Runtime 14.1 a novější Výpočty bez technologie Photon podporují pouze souběžnost na úrovni řádků u operací DELETE.

Povolení souběžnosti na úrovni řádků v Databricks Runtime 14.0 a 14.1:

spark.databricks.delta.rowLevelConcurrencyPreview = true

Řádková souběžnost vždy vyžaduje vektory odstranění.

Další kroky

  • Last updated on