Współbieżność na poziomie wiersza

Współbieżność na poziomie wiersza zmniejsza konflikty między współbieżnych operacji zapisu, wykrywając zmiany na poziomie wiersza i automatycznie rozwiązując konflikty występujące podczas współbieżnej aktualizacji zapisu lub usuwania różnych wierszy w tym samym pliku danych.

Wymagania dotyczące współbieżności na poziomie wiersza

Współbieżność na poziomie wiersza jest automatycznie włączana po spełnieniu wszystkich następujących wymagań:

  • Korzystanie z środowiska Databricks Runtime 14.3 LTS lub nowszego.
  • Tabela źródłowa nie używa partycji.
  • Tabela źródłowa ma włączone wektory usuwania. Zobacz Wektory usuwania w usłudze Databricks.

Partycjonowane tabele nie zezwalają na współbieżność na poziomie wiersza. Jednak gdy włączone są wektory usuwania, tabele partycjonowane nadal mogą unikać konfliktów między OPTIMIZE a operacjami zapisu. Zobacz Ograniczenia dotyczące współbieżności na poziomie wiersza.

Aby uzyskać informacje o starszych wersjach środowiska Databricks Runtime przed wersją 14.3 LTS, zobacz Zachowanie starszej współbieżności na poziomie wiersza.

Macierz konfliktów ze współbieżnością na poziomie wiersza

Dla tabel źródłowych z równobieżnością na poziomie wiersza, poniższa tabela pokazuje, jak każda para współbieżnych operacji zapisu zachowuje się na każdym poziomie izolacji.

Równoczesne zmiany metadanych są wyjątkiem od każdego wyniku w tabeli. Zmiana metadanych, taka jak ALTER TABLE polecenie lub zapis aktualizujący schemat tabeli, może spowodować niepowodzenie wszystkich współbieżnych operacji zapisu, w tym INSERT. Zobacz konflikty zmian metadanych.

Para operacji WriteSerializable (domyślnie) Seryjny
INSERT (1) + INSERT Nie może być konfliktu Nie może być konfliktu
INSERT + UPDATE, USUŃ, MERGE INTO Nie może być konfliktu Może powodować konflikt podczas modyfikowania tego samego wiersza. Operacja UPDATE, DELETE, lub MERGE nie .INSERT
INSERT + OPTIMIZE Nie może być konfliktu Nie może być konfliktu
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Może być konflikt podczas modyfikacji tego samego wiersza Może być konflikt podczas modyfikacji tego samego wiersza
UPDATE, DELETE, MERGE INTO + OPTIMIZE Może powodować konflikt, gdy ZORDER BY jest używany. Inaczej nie może dojść do konfliktu. Może powodować konflikt, gdy ZORDER BY jest używany. Inaczej nie może dojść do konfliktu.
OPTIMIZE + OPTIMIZE Może powodować konflikt, gdy ZORDER BY jest używany. Inaczej nie może dojść do konfliktu. Może powodować konflikt, gdy ZORDER BY jest używany. Inaczej nie może dojść do konfliktu.

(1) Wszystkie INSERT operacje w tej tabeli opisują operacje dołączania, które nie zawierają podzapytania odczytujących dane z tej samej tabeli. INSERT operacje zawierające podzapytania odczytane z tej samej tabeli obsługują tę samą współbieżność co MERGE.

Uwaga / Notatka

  • Gdy para może kolidować, nie ulega jedynie operacja odczytująca dotknięte dane. Operacja INSERT , która dodaje dane bez czytania tabeli, nie jest operacją, która się nie udaje, więc logika powtórki należy do współbieżnego UPDATE, DELETE, lub MERGE.
  • Tabele z kolumnami tożsamości nie obsługują transakcji współbieżnych. Zobacz Kolumny tożsamości.
  • REORG operacje mają semantyki izolacji identyczną jak OPTIMIZE podczas ponownego zapisywania plików danych. W przypadku zastosowania REORG uaktualnienia, protokoły tabel zmieniają się, co stwarza konflikt ze wszystkimi trwającymi operacjami.

Konflikty zapisu bez współbieżności na poziomie wierszy

Dla tabel źródłowych bez współbieżności na poziomie wiersza, poniższa tabela pokazuje, jak każda para współbieżnych operacji zapisu zachowuje się na każdym poziomie izolacji.

Równoczesne zmiany metadanych są wyjątkiem od każdego wyniku w tabeli. Zmiana metadanych, taka jak ALTER TABLE polecenie lub zapis aktualizujący schemat tabeli, może spowodować niepowodzenie wszystkich współbieżnych operacji zapisu, w tym INSERT. Zobacz konflikty zmian metadanych.

Para operacji WriteSerializable (domyślnie) Seryjny
INSERT (1) + INSERT Nie może być konfliktu Nie może być konfliktu
INSERT + UPDATE, USUŃ, MERGE INTO Nie może być konfliktu Może się konfliktować. Operacja UPDATE, DELETE, lub MERGE nie .INSERT Zobacz Unikanie konfliktów przy użyciu partycjonowania.
INSERT + OPTIMIZE Nie może być konfliktu Nie może być konfliktu
UPDATE, DELETE, MERGE INTO + UPDATE, DELETE, MERGE INTO Może się konfliktować. Zobacz Unikanie konfliktów przy użyciu partycjonowania. Może się konfliktować. Zobacz Unikanie konfliktów przy użyciu partycjonowania.
UPDATE, DELETE, MERGE INTO + OPTIMIZE Nie ma możliwości konfliktu w tabelach z włączonymi wektorami usuwania, chyba że używany jest ZORDER BY. W przeciwnym razie może powodować konflikt. Nie ma możliwości konfliktu w tabelach z włączonymi wektorami usuwania, chyba że używany jest ZORDER BY. W przeciwnym razie może powodować konflikt.
OPTIMIZE + OPTIMIZE Nie ma możliwości konfliktu w tabelach z włączonymi wektorami usuwania, chyba że używany jest ZORDER BY. W przeciwnym razie może powodować konflikt. Nie ma możliwości konfliktu w tabelach z włączonymi wektorami usuwania, chyba że używany jest ZORDER BY. W przeciwnym razie może powodować konflikt.

(1) Wszystkie INSERT operacje w tej tabeli opisują operacje dołączania, które nie zawierają podzapytania odczytujących dane z tej samej tabeli. INSERT operacje zawierające podzapytania odczytane z tej samej tabeli obsługują tę samą współbieżność co MERGE.

Uwaga / Notatka

  • Gdy para może kolidować, nie ulega jedynie operacja odczytująca dotknięte dane. Operacja INSERT , która dodaje dane bez czytania tabeli, nie jest operacją, która się nie udaje, więc logika powtórki należy do współbieżnego UPDATE, DELETE, lub MERGE.
  • Tabele z kolumnami tożsamości nie obsługują transakcji współbieżnych. Zobacz Kolumny tożsamości.
  • REORG operacje mają semantyki izolacji identyczną jak OPTIMIZE podczas ponownego zapisywania plików danych. Gdy używasz REORG, aby zastosować aktualizację, protokoły tabel zmieniają się i wchodzą w konflikt ze wszystkimi trwającymi operacjami.

Ograniczenia współbieżności na poziomie wiersza

Ograniczenia dotyczą współbieżności na poziomie wiersza. W przypadku następujących operacji rozwiązywanie konfliktów odbywa się zgodnie z normalnym trybem współbieżnego przetwarzania podczas konfliktów zapisu. Zobacz Konflikty zapisu przy braku współbieżności na poziomie wierszy.

Limitation Opis
Złożone klauzule warunkowe Warunki dotyczące złożonych typów danych (struktur, tablic, map), wyrażeń niedeterministycznych, podzapytania i skorelowanych podzapytania
MERGE wymaganie predykatu W środowisku Databricks Runtime 14.2 MERGE polecenia muszą używać jawnego predykatu w tabeli docelowej, aby filtrować wiersze, które odpowiadają tabeli źródłowej.
Kompromis w zakresie wydajności Wykrywanie konfliktów na poziomie wiersza może zwiększyć całkowity czas wykonywania. W przypadku wielu równoczesnych transakcji piszący priorytetuje niskie opóźnienia kosztem rozwiązywania konfliktów.

Obowiązują również wszystkie ograniczenia dotyczące wektorów usuwania. Zobacz Ograniczenia.

Unikanie konfliktów przy użyciu partycjonowania

We wszystkich przypadkach oznakowanych jako "może powodować konflikt" w macierzach konfliktów, konflikt występuje tylko wtedy, gdy obie operacje mają wpływ na ten sam zestaw plików. Aby rozdzielić dwa zestawy plików, podziel tabelę na partycje według tych samych kolumn używanych w warunkach operacyjnych.

Example:

Polecenia UPDATE table WHERE date > '2010-01-01' ... i DELETE table WHERE date < '2010-01-01' będą w konflikcie, jeśli tabela nie jest partycjonowana według daty, ponieważ oba mogą próbować zmodyfikować te same pliki. Partycjonowanie tabeli z użyciem date unika konfliktu.

Uwaga / Notatka

Partycjonowanie tabeli według kolumny o wysokiej kardynalności może prowadzić do problemów z wydajnością ze względu na dużą liczbę podkatalogów.

Unikaj konfliktów z jawnymi filtrami partycji

Ten wyjątek często występuje podczas współbieżnych operacji DELETE, UPDATE lub MERGE, które mogą odczytywać tę samą partycję nawet podczas aktualizowania różnych partycji. Ustaw separację jawną w warunku operacji:

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

Wyjątki od konfliktów

W przypadku wystąpienia konfliktu transakcji obserwujesz jeden z następujących wyjątków:

ConcurrentAppendException

Wyjątek ten występuje, gdy współbieżna operacja dodaje pliki w tej samej partycji (lub w dowolnym miejscu w niepartycjonowanej tabeli), którą odczytuje operacja. Dodatki plików mogą być spowodowane operacjami INSERT, DELETE, UPDATElub MERGE .

Przy domyślnym poziomie izolacji WriteSerializable pliki dodawane przez operacje INSERT, które dopisują dane bez uprzedniego odczytu danych, nie wchodzą w konflikt z żadną operacją. Jeśli poziom izolacji jest możliwy do serializacji, wszelkie dołączania mogą powodować konflikt.

Ważna

Konflikt może nadal wystąpić w trybie WriteSerializable, jeśli wiele równocześnie DELETEUPDATE, , lub MERGE operacji może odwoływać się do wartości dodanych przez operacjęINSERT. Operacja DELETE, UPDATE, czyli MERGE , to ta, która zawodzi, ponieważ odczytuje dołączone dane. Aby tego uniknąć:

  • Upewnij się, że DELETEoperacje współbieżne, UPDATElub MERGE nie odczytują dołączonych danych
  • Miej co najwyżej jedną operację DELETE, UPDATE, lub MERGE, która może odczytywać dołączone dane.

ConcurrentDeleteReadException

Ten wyjątek występuje, gdy operacja współbieżna usuwa plik odczytany przez operację. Typowe przyczyny to DELETE, UPDATElub MERGE operacje, które ponownie zapisują pliki.

ConcurrentDeleteDeleteException

Ten wyjątek występuje, gdy operacja współbieżna usuwa również plik, który operacja usuwa. Może to być spowodowane przez dwie współbieżne operacje kompaktowania przepisujące te same pliki.

MetadataChangedException

Ten wyjątek występuje, gdy transakcja równoczesna aktualizuje metadane tabeli Delta Lake. Typowe przyczyny to ALTER TABLE operacje lub zapisy, które aktualizują schemat tabeli.

ConcurrentTransactionException

Wyjątek ten występuje, gdy zapytanie strumieniowe z tej samej lokalizacji punktu kontrolnego jest uruchamiane wielokrotnie jednocześnie i próbuje zapisać do tabeli Delta Lake w tym samym czasie. Nigdy nie uruchamiaj dwóch zapytań przesyłanych strumieniowo z tą samą lokalizacją punktu kontrolnego jednocześnie.

ProtocolChangedException (WyjątekZmianyProtokołu)

Ten wyjątek może wystąpić, gdy:

  • Tabela usługi Delta Lake została uaktualniona do nowej wersji protokołu (może być konieczne uaktualnienie środowiska Databricks Runtime)
  • Wiele autorów tworzy lub zastępuje tabelę w tym samym czasie
  • Wielu autorów zapisuje w pustej ścieżce w tym samym czasie

Zobacz kompatybilność funkcji i protokoły Delta Lake.

Zachowanie starszej współbieżności na poziomie wiersza

W środowisku Databricks Runtime 13.3 LTS w przypadku współbieżności na poziomie wiersza obowiązuje starsze zachowanie:

Dodatkowe zasoby

  • Last updated on