Vad är ACID-garantier på Azure Databricks?

Azure Databricks använder Delta Lake som standard för alla läsningar och skrivningar och bygger vidare på ACID-garantierna som tillhandahålls av öppen källkod Delta Lake-protokollet. ACID står för atomicitet, konsekvens, isolering och hållbarhet.

• Atomicitet innebär att alla transaktioner antingen lyckas eller misslyckas helt.
• Konsekvensgarantier gäller hur ett givet tillstånd för data observeras av samtidiga åtgärder.
• Isolering syftar på hur samtidiga åtgärder kan komma i konflikt med varandra.
• Hållbarhet innebär att de incheckade ändringarna är permanenta.

Även om många databehandlings- och lagertekniker beskriver att acid-transaktioner finns, varierar specifika garantier beroende på system och transaktioner i Azure Databricks kan skilja sig från andra system som du har arbetat med.

Kommentar

På den här sidan beskrivs garantier för tabeller som backas upp av Delta Lake. Andra dataformat och integrerade system kanske inte ger transaktionsgarantier för läsningar och skrivningar.

Alla Azure Databricks-skrivningar till molnobjektlagring använder transaktionella incheckningar, som skapar metadatafiler som börjar med och _committed_<id> tillsammans med _started_<id> datafiler. Du behöver inte interagera med dessa filer eftersom Azure Databricks rutinmässigt rensar inaktuella incheckningsmetadatafiler.

Hur begränsas transaktioner i Azure Databricks?

Azure Databricks hanterar transaktioner på tabellnivå. Transaktioner gäller alltid för en tabell i taget. För att hantera samtidiga transaktioner använder Azure Databricks optimistisk samtidighetskontroll. Det innebär att det inte finns några lås på läsning eller skrivning mot en tabell, och dödläge är inte en möjlighet.

Som standard tillhandahåller Azure Databricks ögonblicksbildisolering vid läsningar och serialiserbar isolering av skrivningar. Isolering som kan skrivas serialiseras ger starkare garantier än isolering av ögonblicksbilder, men den gäller endast starkare isolering för skrivningar.

Läsåtgärder som refererar till flera tabeller returnerar den aktuella versionen av varje tabell vid tidpunkten för åtkomsten, men avbryter inte samtidiga transaktioner som kan ändra refererade tabeller.

Azure Databricks har BEGIN/END inte konstruktioner som gör att flera åtgärder kan grupperas tillsammans som en enda transaktion. Program som ändrar flera tabeller checkar in transaktioner till varje tabell på ett seriellt sätt. Du kan kombinera infogningar, uppdateringar och borttagningar mot en tabell till en enda skrivtransaktion med hjälp av MERGE INTO.

Hur implementerar Azure Databricks atomitet?

Transaktionsloggen styr incheckningens atomitet. Under en transaktion skrivs datafiler till filkatalogen som stöder tabellen. När transaktionen är klar checkas en ny post in i transaktionsloggen som innehåller sökvägarna till alla filer som skrivits under transaktionen. Varje incheckning ökar tabellversionen och gör nya datafiler synliga för läsåtgärder. Tabellens aktuella tillstånd omfattar alla datafiler som markerats som giltiga i transaktionsloggarna.

Datafiler spåras inte om inte transaktionsloggen registrerar en ny version. Om en transaktion misslyckas när datafilerna har skrivits till en tabell skadas inte tabelltillståndet, men filerna blir inte en del av tabellen. Åtgärden VACUUM tar bort alla ospårade datafiler i en tabellkatalog, inklusive återstående ogenomförda filer från misslyckade transaktioner.

Hur implementerar Azure Databricks hållbarhet?

Azure Databricks använder molnobjektlagring för att lagra alla datafiler och transaktionsloggar. Molnobjektlagring har hög tillgänglighet och hållbarhet. Eftersom transaktioner antingen lyckas eller misslyckas helt och transaktionsloggen finns tillsammans med datafiler i molnobjektlagring ärver tabeller i Azure Databricks hållbarhetsgarantierna för molnobjektlagringen som de lagras på.

Hur implementerar Azure Databricks konsekvens?

Delta Lake använder optimistisk samtidighetskontroll för att tillhandahålla transaktionsgarantier mellan skrivningar. Enligt den här mekanismen fungerar skrivningar i tre steg:

1. Läs: Läser (om det behövs) den senaste tillgängliga versionen av tabellen för att identifiera vilka filer som behöver ändras (dvs. skrivas om).
   • Skrivningar som endast är tillägg läser inte det aktuella tabelltillståndet innan du skriver. Schemaverifiering utnyttjar metadata från transaktionsloggen.
2. Skriv: Skriver datafiler till den katalog som används för att definiera tabellen.
3. Verifiera och checka in:
   • Kontrollerar om de föreslagna ändringarna står i konflikt med andra ändringar som kan ha checkats in samtidigt sedan ögonblicksbilden som lästes.
   • Om det inte finns några konflikter checkas alla mellanlagrade ändringar in som en ny version av ögonblicksbilden och skrivåtgärden lyckas.
   • Om det finns konflikter misslyckas skrivåtgärden med ett undantag för samtidig ändring. Det här felet förhindrar att data skadas.

Optimistisk conccurency förutsätter att de flesta samtidiga transaktioner på dina data inte kan komma i konflikt med varandra, men konflikter kan uppstå. Se Isoleringsnivåer och skrivkonflikter i Azure Databricks.

Hur implementerar Azure Databricks isolering?

Azure Databricks använder skriv serialiserbar isolering som standard för alla tabellskrivningar och uppdateringar. Ögonblicksbildisolering används för alla tabellläsningar.

Skriv serialisering och optimistisk samtidighetskontroll fungerar tillsammans för att ge högt dataflöde för skrivningar. Det aktuella giltiga tillståndet för en tabell är alltid tillgängligt och en skrivning kan startas mot en tabell när som helst. Samtidiga läsningar begränsas endast av dataflödet för metaarkivet och molnresurserna.

Se Isoleringsnivåer och skrivkonflikter i Azure Databricks.

Har Delta Lake stöd för transaktioner med flera tabeller?

Delta Lake stöder inte transaktioner med flera tabeller. Delta Lake stöder transaktioner på tabellnivå .

Primära nyckel- och sekundärnyckelrelationer i Azure Databricks är informationsbaserade och tillämpas inte. Se Deklarera primärnyckel och sekundärnyckelrelationer.

Vad innebär det att Delta Lake stöder skrivningar med flera kluster?

Delta Lake förhindrar att data skadas när flera kluster skriver till samma tabell samtidigt. Vissa skrivåtgärder kan vara i konflikt vid samtidig körning, men skadade inte tabellen. Se Isoleringsnivåer och skrivkonflikter i Azure Databricks.

Kan jag ändra en Delta-tabell från olika arbetsytor?

Ja, du kan samtidigt ändra samma Delta-tabell från olika arbetsytor. Om en process dessutom skrivs från en arbetsyta visas en konsekvent vy för läsare i andra arbetsytor.