Best practices voor Delta Lake

In dit artikel worden aanbevolen procedures beschreven bij het gebruik van Delta Lake.

Databricks raadt aan om voorspellende optimalisatie te gebruiken. Zie Voorspellende optimalisatie voor beheerde tabellen in Unity Catalog.

Wanneer u een tabel op dezelfde locatie verwijdert en opnieuw wilt maken, moet u altijd een CREATE OR REPLACE TABLE instructie gebruiken. Zie Een Delta-tabel neerzetten of vervangen.

Verouderde Delta-configuraties verwijderen

Databricks raadt u aan om de meest expliciete verouderde Delta-configuraties uit Spark-configuraties en tabeleigenschappen te verwijderen wanneer u een upgrade uitvoert naar een nieuwe Databricks Runtime-versie. Verouderde configuraties kunnen voorkomen dat nieuwe optimalisaties en standaardwaarden die door Databricks worden geïntroduceerd, worden toegepast op gemigreerde workloads.

Liquid clustering gebruiken voor geoptimaliseerde gegevens overslaan

Databricks raadt het gebruik van liquide clustering aan in plaats van partitionering, Z-order of andere strategieën voor gegevensorganisatie te gebruiken om de gegevensindeling te optimaliseren voor het overslaan van gegevens. Zie Liquid clustering gebruiken voor Delta-tabellen.

Bestanden comprimeren

Voorspellende optimalisatie wordt automatisch uitgevoerd OPTIMIZE en VACUUM opdrachten in beheerde tabellen van Unity Catalog. Zie Voorspellende optimalisatie voor beheerde tabellen in Unity Catalog.

Databricks raadt aan regelmatig de opdracht OPTIMIZE uit te voeren om kleine bestanden te comprimeren.

Notitie

Met deze bewerking worden de oude bestanden niet verwijderd. Als u ze wilt verwijderen, voert u de opdracht VACUUM uit.

De inhoud of het schema van een tabel vervangen

Soms wilt u een Delta-tabel vervangen. Voorbeeld:

• U ontdekt dat de gegevens in de tabel onjuist zijn en de inhoud willen vervangen.
• U wilt de hele tabel opnieuw schrijven om incompatibele schemawijzigingen uit te voeren (zoals het wijzigen van kolomtypen).

Hoewel u de hele map van een Delta-tabel kunt verwijderen en een nieuwe tabel op hetzelfde pad kunt maken, wordt dit niet aanbevolen omdat:

• Het verwijderen van een map is niet efficiënt. Het kan uren of zelfs dagen duren voordat een map met zeer grote bestanden is verwijderd.
• U verliest alle inhoud in de verwijderde bestanden; Het is moeilijk om te herstellen als u de verkeerde tabel verwijdert.
• Het verwijderen van de map is niet atomisch. Terwijl u de tabel verwijdert, kan een gelijktijdige query die de tabel leest mislukken of een gedeeltelijke tabel zien.

Als u het tabelschema niet hoeft te wijzigen, kunt u gegevens verwijderen uit een Delta-tabel en uw nieuwe gegevens invoegen of de tabel bijwerken om de onjuiste waarden op te lossen.

Als u het tabelschema wilt wijzigen, kunt u de hele tabel atomisch vervangen. Voorbeeld:

Python

dataframe.write \
  .mode("overwrite") \
  .option("overwriteSchema", "true") \
  .saveAsTable("<your-table>") # Managed table

dataframe.write \
  .mode("overwrite") \
  .option("overwriteSchema", "true") \
  .option("path", "<your-table-path>") \
  .saveAsTable("<your-table>") # External table

SQL

REPLACE TABLE <your-table> AS SELECT ... -- Managed table
REPLACE TABLE <your-table> LOCATION "<your-table-path>" AS SELECT ... -- External table

Scala

dataframe.write
  .mode("overwrite")
  .option("overwriteSchema", "true")
  .saveAsTable("<your-table>") // Managed table

dataframe.write
  .mode("overwrite")
  .option("overwriteSchema", "true")
  .option("path", "<your-table-path>")
  .saveAsTable("<your-table>") // External table

Er zijn meerdere voordelen met deze aanpak:

• Het overschrijven van een tabel is veel sneller omdat de map niet recursief hoeft te worden weergegeven of bestanden hoeft te verwijderen.
• De oude versie van de tabel bestaat nog steeds. Als u de verkeerde tabel verwijdert, kunt u de oude gegevens eenvoudig ophalen met behulp van tijdreizen. Raadpleeg Werken met de tabelgeschiedenis van Delta Lake.
• Het is een atomische bewerking. Gelijktijdige query's kunnen de tabel nog steeds lezen terwijl u de tabel verwijdert.
• Vanwege de garanties van Delta Lake ACID-transacties, als het overschrijven van de tabel mislukt, heeft de tabel de vorige status.

Als u bovendien oude bestanden wilt verwijderen om opslagkosten te besparen nadat u de tabel hebt overschreven, kunt u VACUUM gebruiken om ze te verwijderen. Het is geoptimaliseerd voor het verwijderen van bestanden en is meestal sneller dan het verwijderen van de hele map.

Spark-caching

Databricks raadt u niet aan om Spark-caching te gebruiken om de volgende redenen:

• U verliest gegevens die kunnen worden overgeslagen door extra filters die boven op de cache DataFramezijn toegevoegd.
• De gegevens die in de cache worden opgeslagen, worden mogelijk niet bijgewerkt als de tabel wordt geopend met behulp van een andere id.

Verschillen tussen Delta Lake en Parquet in Apache Spark

Delta Lake verwerkt de volgende bewerkingen automatisch. U moet deze bewerkingen nooit handmatig uitvoeren:

• REFRESH TABLE: Delta-tabellen retourneren altijd de meest recente informatie, zodat u na wijzigingen niet handmatig hoeft aan te roepen REFRESH TABLE .
• Partities toevoegen en verwijderen: Delta Lake houdt automatisch de set partities bij die aanwezig zijn in een tabel en werkt de lijst bij wanneer gegevens worden toegevoegd of verwijderd. Als gevolg hiervan is het niet nodig om te worden uitgevoerd ALTER TABLE [ADD|DROP] PARTITION of MSCK.
• Eén partitie laden: leespartities rechtstreeks is niet nodig. U hoeft bijvoorbeeld niet te worden uitgevoerd spark.read.format("parquet").load("/data/date=2017-01-01"). Gebruik in plaats daarvan een WHERE component voor het overslaan van gegevens, zoals spark.read.table("<table-name>").where("date = '2017-01-01'").
• Wijzig geen gegevensbestanden handmatig: Delta Lake gebruikt het transactielogboek om wijzigingen in de tabel atomisch door te voeren. U kunt Parquet-gegevensbestanden niet rechtstreeks wijzigen, toevoegen of verwijderen in een Delta-tabel, omdat dit kan leiden tot verloren gegevens of tabelbeschadiging.

Prestaties verbeteren voor Delta Lake-samenvoeging

U kunt de tijd beperken die nodig is om samen te voegen met behulp van de volgende methoden:

• Verminder de zoekruimte voor overeenkomsten: de merge bewerking doorzoekt standaard de hele Delta-tabel om overeenkomsten in de brontabel te vinden. Een manier om de zoekruimte te versnellen, is door bekende beperkingen toe te merge voegen in de voorwaarde voor overeenkomst. Stel dat u een tabel hebt die is gepartitioneerd country en date die u wilt gebruiken om informatie voor de laatste dag en een specifiek land bij te werken merge . Als u de volgende voorwaarde toevoegt, wordt de query sneller, omdat deze alleen zoekt naar overeenkomsten in de relevante partities:

  events.date = current_date() AND events.country = 'USA'
  

  Bovendien vermindert deze query ook de kans op conflicten met andere gelijktijdige bewerkingen. Zie Isolatieniveaus en schrijfconflicten in Azure Databricks voor meer informatie.

• Compacte bestanden: als de gegevens worden opgeslagen in veel kleine bestanden, kunnen het lezen van de gegevens om te zoeken naar overeenkomsten traag worden. U kunt kleine bestanden comprimeren in grotere bestanden om de leesdoorvoer te verbeteren. Zie De indeling gegevensbestand optimaliseren voor meer informatie.

• Beheer de willekeurige partities voor schrijfbewerkingen: met de merge bewerking worden gegevens meerdere keren in willekeurige volgorde geplaatst om de bijgewerkte gegevens te berekenen en te schrijven. Het aantal taken dat wordt gebruikt om een willekeurige volgorde te geven, wordt bepaald door de configuratie van de Spark-sessie spark.sql.shuffle.partitions. Het instellen van deze parameter bepaalt niet alleen de parallelle uitvoering, maar bepaalt ook het aantal uitvoerbestanden. Het verhogen van de waarde verhoogt parallelle uitvoering, maar genereert ook een groter aantal kleinere gegevensbestanden.

• Geoptimaliseerde schrijfbewerkingen inschakelen: voor gepartitioneerde tabellen merge kan een veel groter aantal kleine bestanden worden geproduceerd dan het aantal willekeurige partities. Dit komt doordat elke willekeurige taak meerdere bestanden in meerdere partities kan schrijven en een knelpunt voor prestaties kan worden. U kunt het aantal bestanden verminderen door geoptimaliseerde schrijfbewerkingen in te schakelen. Zie Geoptimaliseerde schrijfbewerkingen voor Delta Lake in Azure Databricks.

• Bestandsgrootten afstemmen in tabel: Azure Databricks kan automatisch detecteren of een Delta-tabel frequente merge bewerkingen heeft die bestanden herschrijven en ervoor kiezen om de grootte van herschreven bestanden te verkleinen in afwachting van verdere bestandsherschrijvingen in de toekomst. Zie de sectie over het afstemmen van de bestandsgrootten voor meer informatie.

• Low Shuffle Merge: Low Shuffle Merge biedt een geoptimaliseerde implementatie van MERGE die betere prestaties biedt voor de meest voorkomende workloads. Daarnaast blijven bestaande optimalisaties voor gegevensindelingen behouden, zoals Z-volgorde op ongewijzigde gegevens.

Gegevens recency beheren

Aan het begin van elke query worden Delta-tabellen automatisch bijgewerkt naar de nieuwste versie van de tabel. Dit proces kan worden waargenomen in notebooks wanneer de opdrachtstatus rapporteert: Updating the Delta table's state. Wanneer u echter historische analyses uitvoert op een tabel, hebt u mogelijk niet per se up-to-the-last-minute gegevens nodig, met name voor tabellen waarin streaminggegevens regelmatig worden opgenomen. In deze gevallen kunnen query's worden uitgevoerd op verouderde momentopnamen van uw Delta-tabel. Deze benadering kan de latentie verlagen bij het ophalen van resultaten van query's.

U kunt tolerantie voor verouderde gegevens configureren door de Configuratie van de Spark-sessie spark.databricks.delta.stalenessLimit in te stellen met een tijdreekswaarde zoals 1h of 15m (respectievelijk gedurende 1 uur of 15 minuten). Deze configuratie is sessiespecifiek en heeft geen invloed op andere clients die toegang hebben tot de tabel. Als de tabelstatus is bijgewerkt binnen de verouderingslimiet, retourneert een query op basis van de tabel resultaten zonder te wachten op de meest recente tabelupdate. Deze instelling voorkomt nooit dat de tabel wordt bijgewerkt en wanneer verouderde gegevens worden geretourneerd, worden de updateprocessen op de achtergrond verwerkt. Als de laatste tabelupdate ouder is dan de limiet voor veroudering, retourneert de query geen resultaten totdat de update van de tabelstatus is voltooid.

Verbeterde controlepunten voor query's met lage latentie

Delta Lake schrijft controlepunten als een geaggregeerde status van een Delta-tabel met een geoptimaliseerde frequentie. Deze controlepunten dienen als uitgangspunt voor het berekenen van de meest recente status van de tabel. Zonder controlepunten moet Delta Lake een grote verzameling JSON-bestanden ('delta'-bestanden) lezen die doorvoeringen vertegenwoordigen in het transactielogboek om de status van een tabel te berekenen. Daarnaast worden de statistieken op kolomniveau die Delta Lake gebruikt voor het overslaan van gegevens, opgeslagen in het controlepunt.

Belangrijk

Delta Lake-controlepunten verschillen van structured streaming-controlepunten. Zie Controlepunten voor gestructureerd streamen.

Statistieken op kolomniveau worden opgeslagen als een struct en een JSON (voor achterwaartse compatibiliteit). De struct-indeling zorgt ervoor dat Delta Lake veel sneller leest, omdat:

• Delta Lake voert geen dure JSON-parsering uit om statistieken op kolomniveau te verkrijgen.
• De functionaliteit voor het verwijderen van parquet-kolommen vermindert de I/O die nodig is om de statistieken voor een kolom te lezen aanzienlijk.

De struct-indeling maakt een verzameling optimalisaties mogelijk die de overhead van Delta Lake-leesbewerkingen van seconden tot tientallen milliseconden verminderen, waardoor de latentie voor korte query's aanzienlijk wordt verminderd.

Statistieken op kolomniveau beheren in controlepunten

U beheert hoe statistieken in controlepunten worden geschreven met behulp van de tabeleigenschappen delta.checkpoint.writeStatsAsJson en delta.checkpoint.writeStatsAsStruct. Als beide tabeleigenschappen zijn false, kan Delta Lake geen gegevens overslaan.

• Batch schrijft schrijfstatistieken in zowel JSON- als struct-indeling. delta.checkpoint.writeStatsAsJson is true.
• delta.checkpoint.writeStatsAsStruct is standaard niet gedefinieerd.
• Lezers gebruiken de structkolom indien beschikbaar en vallen anders terug op het gebruik van de JSON-kolom.

Belangrijk

Verbeterde controlepunten breken de compatibiliteit met open source Delta Lake-lezers niet. Instelling delta.checkpoint.writeStatsAsJson kan false echter gevolgen hebben voor eigen Delta Lake-lezers. Neem contact op met uw leveranciers voor meer informatie over de gevolgen voor de prestaties.

Verbeterde controlepunten inschakelen voor Structured Streaming-query's

Als uw Structured Streaming-workloads geen lage latentievereisten (subminute latenties) hebben, kunt u verbeterde controlepunten inschakelen door de volgende SQL-opdracht uit te voeren:

ALTER TABLE <table-name> SET TBLPROPERTIES
('delta.checkpoint.writeStatsAsStruct' = 'true')

U kunt ook de latentie van het schrijftijdpunt verbeteren door de volgende tabeleigenschappen in te stellen:

ALTER TABLE <table-name> SET TBLPROPERTIES
(
 'delta.checkpoint.writeStatsAsStruct' = 'true',
 'delta.checkpoint.writeStatsAsJson' = 'false'
)

Als het overslaan van gegevens niet nuttig is in uw toepassing, kunt u beide eigenschappen instellen op onwaar. Vervolgens worden er geen statistieken verzameld of geschreven. Databricks raadt deze configuratie niet aan.