Best practices voor Delta Lake

Artikel
01/21/2025

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

Databricks raadt aan om voorspellende optimalisatie te gebruiken. Zie Predictieve optimalisatie voor Unity Catalog beheerd tables.

Wanneer u een table op dezelfde locatie verwijdert en opnieuw wilt maken, moet u altijd een CREATE OR REPLACE TABLE instructie gebruiken. Zie Laat een Delta vallen of vervang table.

Remove verouderde Delta-configuraties

Databricks raadt aan om de meest expliciete verouderde Delta-configuraties te verwijderen uit Spark-configuraties en table eigenschappen bij het upgraden naar een nieuwe Databricks Runtime-versie. Verouderde configuraties kunnen voorkomen dat nieuwe optimalisaties en standaard values die door Databricks worden geïntroduceerd, worden toegepast op gemigreerde workloads.

Liquid clustering gebruiken voor geoptimaliseerde gegevens overslaan

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

Bestanden comprimeren

Voorspellende optimalisatie voert automatisch OPTIMIZE en VACUUM opdrachten uit op door Unity Catalog beheerde tables. Zie Predictive Optimization voor Unity Catalog beheerde tables.

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

Notitie

Deze bewerking voert remove niet uit op de oude bestanden. Als u ze wilt remove, voert u de opdracht VACUUM uit.

De inhoud of schema van een table vervangen

Soms wilt u misschien een Delta-tablevervangen. Voorbeeld:

U ontdekt dat de gegevens in de table onjuist zijn en de inhoud wilt vervangen.
U wilt het hele table herschrijven om incompatibele schema wijzigingen uit te voeren (zoals het wijzigen van column typen).

Hoewel u de hele map van een Delta-table kunt verwijderen en een nieuwe table op hetzelfde pad kunt maken, wordt het 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 tableverwijdert.
Het verwijderen van de map is niet atomisch. Terwijl je de table verwijdert, kan een gelijktijdige query die de table leest mislukken of slechts een gedeeltelijke tablezien.

Als u de tableschemaniet hoeft te wijzigen, kunt u gegevens verwijderen uit een Delta-table en uw nieuwe gegevens insert, of de tableupdate om de onjuiste valuesop te lossen.

Als u de tableschemawilt wijzigen, kunt u het hele table 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 table is veel sneller omdat het niet nodig is om de map recursief te list of bestanden te verwijderen.
De oude versie van de table bestaat nog steeds. Als u de verkeerde table verwijdert, kunt u de oude gegevens eenvoudig ophalen met behulp van tijdreizen. Zie Werken met Delta Lake table geschiedenis.
Het is een atomische bewerking. Gelijktijdige query's kunnen nog steeds de table lezen terwijl u de tableverwijdert.
Vanwege de garanties van Delta Lake ACID-transacties, als het overschrijven van de table mislukt, bevindt de table zich in de vorige status.

Als u oude bestanden wilt verwijderen om opslagkosten te besparen nadat u de tablehebt 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 table wordt geopend met behulp van een andere identifier.

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 tables zal altijd de meest recente up-to-gegevens retourneren, zodat het niet nodig is om REFRESH TABLE handmatig aan te passen na wijzigingen.
Voeg partities toe en remove: Delta Lake houdt automatisch de set van de aanwezige partities in een table bij en werkt de list 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.
Één partitionladen: het is niet nodig om leespartities direct te benaderen. 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 table atomisch door te voeren. Wijzig Parquet-gegevensbestanden niet rechtstreeks, voeg ze toe of verwijder ze in een Delta-table, omdat dit kan leiden tot verloren gegevens of table beschadiging.

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-table om overeenkomsten in de bron-tablete 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 table hebt die is gepartitioneerd door country en date en dat u merge wilt gebruiken om informatie voor de laatste dag en voor een specifiek land te update. 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 Optimize indeling van gegevensbestanden 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 tableskan merge een veel groter aantal kleine bestanden produceren 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 table: Azure Databricks kan automatisch detecteren of een Delta-table vaak merge bewerkingen heeft die bestanden herschrijven en ervoor kiezen om de grootte van herschreven bestanden in de toekomst te verminderen. 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 voert Delta tables automatischupdate uit naar de nieuwste versie van de table. 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 table, hebt u mogelijk niet per se up-to-the-last-minute gegevens nodig, vooral wanneer tableswhere streaminggegevens regelmatig worden opgenomen. In dergelijke gevallen kunnen query's worden uitgevoerd op verouderde momentopnamen van uw Delta-table. 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 table. Wanneer de table-status is bijgewerkt binnen de niet-actuele limit, retourneert een zoekopdracht op de table resultaten zonder te wachten op de meest recente tableupdate. Met deze instelling voorkomt u nooit dat uw table wordt bijgewerkt en wanneer verouderde gegevens worden geretourneerd, worden de update op de achtergrond verwerkt. Als de laatste tableupdate ouder is dan de veroudering limit, retourneert de query geen resultaten totdat de table status update is voltooid.

Verbeterde controlepunten voor query's met lage latentie

Delta Lake schrijft controlepunten als een geaggregeerde status van een Delta-table met een geoptimaliseerde frequentie. Deze controlepunten dienen als uitgangspunt om de meest recente status van de tablete berekenen. Zonder controlepunten moet Delta Lake een grote verzameling JSON-bestanden ('delta'-bestanden) lezen die doorvoeringen vertegenwoordigen in het transactielogboek om de status van een tablete berekenen. Daarnaast worden de column-niveaustatistieken van Delta Lake gebruikt om gegevens over te slaan worden opgeslagen in het controlepunt.

Belangrijk

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

Column-niveaustatistieken worden opgeslagen als een struct en een JSON (voor compatibiliteit met oudere versies). De struct-indeling zorgt ervoor dat Delta Lake veel sneller leest, omdat:

Delta Lake voert geen dure JSON-parsering uit om statistieken op column-niveau te verkrijgen.
Parquet column snoeifunctionaliteiten verminderen de I/O die nodig is om de statistieken voor een columnte lezen.

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 niveau van columnbeheren in controlepunten

U beheert hoe statistieken in controlepunten worden geschreven met behulp van de table eigenschappen delta.checkpoint.writeStatsAsJson en delta.checkpoint.writeStatsAsStruct. Als beide table eigenschappen 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 struct column indien beschikbaar en vallen anders terug op het gebruik van de JSON-column.

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 schrijflatentie van controlepunten verbeteren door de volgende table eigenschappen 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 set op false. Vervolgens worden er geen statistieken verzameld of geschreven. Databricks raadt deze configuratie niet aan.

Delen via