Wat zijn ACID-garanties in Azure Databricks?

Azure Databricks maakt standaard gebruik van Delta Lake voor alle lees- en schrijfbewerkingen en bouwt voort op de ACID-garanties die worden geboden door het opensource Delta Lake-protocol. ACID staat voor atomiciteit, consistentie, isolatie en duurzaamheid.

• Atomiciteit betekent dat alle transacties volledig slagen of mislukken.
• Consistentiegaranties hebben betrekking op hoe een bepaalde status van de gegevens wordt waargenomen door gelijktijdige bewerkingen.
• Isolatie verwijst naar hoe gelijktijdige bewerkingen mogelijk met elkaar conflicteren.
• Duurzaamheid betekent dat doorgevoerde wijzigingen permanent zijn.

Hoewel veel technologieën voor gegevensverwerking en opslag het hebben van ACID-transacties beschrijven, verschillen specifieke garanties per systeem en kunnen transacties in Azure Databricks verschillen van andere systemen waarmee u hebt gewerkt.

Notitie

Op deze pagina worden garanties beschreven voor tabellen die worden ondersteund door Delta Lake. Andere gegevensindelingen en geïntegreerde systemen bieden mogelijk geen transactionele garanties voor lees- en schrijfbewerkingen.

Alle Azure Databricks-schrijfbewerkingen naar de cloudobjectopslag maken gebruik van transactionele doorvoeringen, die metagegevensbestanden maken die beginnen met _started_<id> en _committed_<id> naast gegevensbestanden. U hoeft niet te communiceren met deze bestanden, omdat Azure Databricks regelmatig verouderde doorvoermetagegevensbestanden opschoont.

Hoe vallen transacties binnen het bereik van Azure Databricks?

Azure Databricks beheert transacties op tabelniveau. Transacties zijn altijd van toepassing op één tabel tegelijk. Voor het beheren van gelijktijdige transacties maakt Azure Databricks gebruik van optimistisch gelijktijdigheidsbeheer. Dit betekent dat er geen vergrendelingen zijn voor lezen of schrijven tegen een tabel, en impasse is geen mogelijkheid.

Azure Databricks biedt standaard isolatie van momentopnamen voor lees- en schrijfserialisatie voor schrijfbewerkingen. Isolatie met schrijfserialisatie biedt sterkere garanties dan isolatie van momentopnamen, maar past die sterkere isolatie alleen toe voor schrijfbewerkingen.

Leesbewerkingen die verwijzen naar meerdere tabellen retourneren de huidige versie van elke tabel op het moment van toegang, maar onderbreken geen gelijktijdige transacties die mogelijk verwijzen naar tabellen waarnaar wordt verwezen.

Azure Databricks heeft BEGIN/END geen constructies waarmee meerdere bewerkingen als één transactie kunnen worden gegroepeerd. Toepassingen die meerdere tabellen doorvoeren transacties doorvoeren naar elke tabel op een seriële manier. U kunt invoegingen, updates en verwijderingen combineren voor een tabel in één schrijftransactie met behulp van MERGE INTO.

Hoe implementeert Azure Databricks atomiciteit?

Het transactielogboek bepaalt atomische doorvoer. Tijdens een transactie worden gegevensbestanden naar de bestandsmap geschreven die de tabel back-up maken. Wanneer de transactie is voltooid, wordt een nieuwe vermelding doorgevoerd in het transactielogboek met de paden naar alle bestanden die tijdens de transactie zijn geschreven. Met elke doorvoering wordt de tabelversie verhoogd en worden nieuwe gegevensbestanden zichtbaar voor leesbewerkingen. De huidige status van de tabel bestaat uit alle gegevensbestanden die in de transactielogboeken geldig zijn gemarkeerd.

Gegevensbestanden worden niet bijgehouden, tenzij in het transactielogboek een nieuwe versie wordt vastgelegd. Als een transactie mislukt na het schrijven van gegevensbestanden naar een tabel, zullen deze gegevensbestanden de tabelstatus niet beschadigen, maar worden de bestanden geen deel van de tabel. Met de VACUUM bewerking worden alle niet-bijgehouden gegevensbestanden in een tabelmap verwijderd, inclusief resterende niet-doorgevoerde bestanden van mislukte transacties.

Hoe implementeert Azure Databricks duurzaamheid?

Azure Databricks maakt gebruik van cloudobjectopslag om alle gegevensbestanden en transactielogboeken op te slaan. Cloudobjectopslag heeft hoge beschikbaarheid en duurzaamheid. Omdat transacties volledig slagen of mislukken en het transactielogboek zich naast gegevensbestanden in de opslag van cloudobjecten bevindt, nemen tabellen in Azure Databricks de duurzaamheidsgaranties over van de opslag van cloudobjecten waarop ze zijn opgeslagen.

Hoe implementeert Azure Databricks consistentie?

Delta Lake maakt gebruik van optimistisch gelijktijdigheidsbeheer om transactionele garanties tussen schrijfbewerkingen te bieden. Onder dit mechanisme worden schrijfbewerkingen in drie fasen uitgevoerd:

1. Lezen: Leest (indien nodig) de meest recente beschikbare versie van de tabel om te bepalen welke bestanden moeten worden gewijzigd (dat wil gezegd, herschreven).
   • Schrijfbewerkingen die alleen worden toegevoegd, lezen de huidige tabelstatus niet voordat ze worden geschreven. Schemavalidatie maakt gebruik van metagegevens uit het transactielogboek.
2. Schrijven: Hiermee schrijft u gegevensbestanden naar de map die wordt gebruikt om de tabel te definiëren.
3. Valideren en doorvoeren:
   • Controleert of de voorgestelde wijzigingen conflicteren met eventuele andere wijzigingen die gelijktijdig zijn doorgevoerd sinds de momentopname die is gelezen.
   • Als er geen conflicten zijn, worden alle gefaseerde wijzigingen doorgevoerd als een momentopname met een nieuwe versie en slaagt de schrijfbewerking.
   • Als er conflicten zijn, mislukt de schrijfbewerking met een uitzondering voor gelijktijdige wijziging. Deze fout voorkomt beschadiging van gegevens.

Optimistische onvoorziene situaties gaan ervan uit dat de meeste gelijktijdige transacties op uw gegevens niet met elkaar kunnen conflicteren, maar conflicten kunnen optreden. Bekijk isolatieniveaus en schrijfconflicten in Azure Databricks.

Hoe implementeert Azure Databricks isolatie?

Azure Databricks maakt standaard gebruik van serialiseerbare isolatie voor alle tabelschrijfbewerkingen en -updates. Isolatie van momentopnamen wordt gebruikt voor alle tabelleesbewerkingen.

Serialiseerbaarheid en optimistisch gelijktijdigheidsbeheer werken samen om een hoge doorvoer voor schrijfbewerkingen te bieden. De huidige geldige status van een tabel is altijd beschikbaar en een schrijfbewerking kan op elk gewenst moment worden gestart op basis van een tabel. Gelijktijdige leesbewerkingen worden alleen beperkt door de doorvoer van de metastore en cloudresources.

Bekijk isolatieniveaus en schrijfconflicten in Azure Databricks.

Ondersteunt Delta Lake transacties met meerdere tabellen?

Delta Lake biedt geen ondersteuning voor transacties met meerdere tabellen. Delta Lake ondersteunt transacties op tabelniveau .

Relaties tussen primaire sleutels en refererende sleutels in Azure Databricks zijn informatief en worden niet afgedwongen. Zie Relaties tussen primaire sleutels en refererende sleutels declareren.

Wat betekent het dat Delta Lake schrijfbewerkingen met meerdere clusters ondersteunt?

Delta Lake voorkomt beschadiging van gegevens wanneer meerdere clusters gelijktijdig naar dezelfde tabel schrijven. Sommige schrijfbewerkingen kunnen conflicteren tijdens gelijktijdige uitvoering, maar de tabel niet beschadigen. Bekijk isolatieniveaus en schrijfconflicten in Azure Databricks.

Kan ik een Delta-tabel wijzigen vanuit verschillende werkruimten?

Ja, u kunt dezelfde Delta-tabel gelijktijdig wijzigen vanuit verschillende werkruimten. Bovendien zien lezers in andere werkruimten een consistente weergave als het ene proces vanuit een werkruimte schrijft.