Metodtips: Delta Lake

I den här artikeln beskrivs metodtips när du använder Delta Lake.

Översikt över metodtips

Följande är allmänna rekommendationer som gäller för de flesta Delta Lake-arbetsbelastningar:

• Använd hanterade Unity Catalog-tabeller. Se Unity Catalog-hanterade tabeller i Azure Databricks för Delta Lake och Apache Iceberg.
• Använd förutsägelseoptimering. Se Förutsägande optimering för hanterade Unity Catalog-tabeller.
• Använd flytande klustring. Se Använda flytande klustring för tabeller.
• När du tar bort och återskapar en tabell på samma plats bör du alltid använda en CREATE OR REPLACE TABLE instruktion. Se Släpp eller ersätt en Delta-tabell.

Ta bort äldre Delta-konfigurationer

Databricks rekommenderar att du tar bort de flesta explicita äldre Delta-konfigurationer från Spark-konfigurationer och tabellegenskaper när du uppgraderar till en ny Databricks Runtime-version. Äldre konfigurationer kan förhindra att nya optimeringar och standardvärden som introduceras av Databricks tillämpas på migrerade arbetsbelastningar.

Komprimera filer

Förutsägande optimering körs OPTIMIZE automatiskt och VACUUM kommandon i hanterade Unity Catalog-tabeller. Se Förutsägande optimering för hanterade Unity Catalog-tabeller.

Databricks rekommenderar att du ofta kör OPTIMIZE kommandot för att komprimera små filer.

Använd inte Spark-cachelagring med Delta Lake

Databricks rekommenderar inte att du använder Spark-cachelagring av följande skäl:

• Du förlorar alla data som hoppar över som kan komma från ytterligare filter som läggs till ovanpå den cachelagrade DataFrame.
• Data som cachelagras kanske inte uppdateras om tabellen används med en annan identifierare.

Skillnader mellan Delta Lake och Parquet på Apache Spark

Delta Lake hanterar följande åtgärder automatiskt. Du bör aldrig utföra dessa åtgärder manuellt:

• REFRESH TABLE: Deltatabeller returnerar alltid den senaste informationen, så du behöver inte anropa REFRESH TABLE manuellt efter ändringar.
• Lägg till och ta bort partitioner: Delta Lake spårar automatiskt uppsättningen partitioner som finns i en tabell och uppdaterar listan när data läggs till eller tas bort. Därför behöver du inte köra ALTER TABLE [ADD|DROP] PARTITION eller MSCK.
• Läs in en enskild partition: Det är inte nödvändigt att läsa partitioner direkt. Du behöver till exempel inte köra spark.read.format("parquet").load("/data/date=2017-01-01"). Använd i stället en WHERE sats för att hoppa över data, till exempel spark.read.table("<table-name>").where("date = '2017-01-01'").
• Ändra inte datafiler manuellt: Delta Lake använder transaktionsloggen för att checka in ändringar i tabellen atomiskt. Ändra, lägg inte till eller ta bort Parquet-datafiler direkt i en Delta-tabell, eftersom detta kan leda till förlorade data eller skadade tabeller.

Förbättra prestanda för Delta Lake-sammanslagning

Du kan minska tiden det tar att slå samman med hjälp av följande metoder:

• Minska sökutrymmet för matchningar: Som standard merge söker åtgärden igenom hela Delta-tabellen för att hitta matchningar i källtabellen. Ett sätt att påskynda merge är att minska sökutrymmet genom att lägga till kända begränsningar i matchningsvillkoret. Anta till exempel att du har en tabell som partitioneras av country och date som du vill använda merge för att uppdatera information för den senaste dagen och ett visst land. Om du lägger till följande villkor blir frågan snabbare eftersom den endast söker efter matchningar i relevanta partitioner:

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

  Dessutom minskar den här frågan också risken för konflikter med andra samtidiga åtgärder. Mer information finns i Isoleringsnivåer och skrivkonflikter i Azure Databricks .

• Kompakta filer: Om data lagras i många små filer kan det ta lång tid att läsa data för att söka efter matchningar. Du kan komprimera små filer till större filer för att förbättra läsdataflödet. Mer information finns i Optimera datafillayout .

• Kontrollera shuffle-partitionerna för skrivningar: Åtgärden merge blandar data flera gånger för att beräkna och skriva uppdaterade data. Antalet uppgifter som används för att blanda styrs av Spark-sessionskonfigurationen spark.sql.shuffle.partitions. Om du anger den här parametern styrs inte bara parallelliteten utan även antalet utdatafiler. Att öka värdet ökar parallelliteten men genererar också ett större antal mindre datafiler.

• Aktivera optimerade skrivningar: För partitionerade tabeller merge kan du skapa ett mycket större antal små filer än antalet shuffle-partitioner. Det beror på att varje shuffle-uppgift kan skriva flera filer i flera partitioner och kan bli en flaskhals för prestanda. Du kan minska antalet filer genom att aktivera optimerade skrivningar. Se Optimerade skrivningar för Delta Lake på Azure Databricks.

• Justera filstorlekar i tabellen: Azure Databricks kan automatiskt identifiera om en Delta-tabell har frekventa merge åtgärder som skriver om filer och kan välja att minska storleken på omskrivna filer i väntan på ytterligare filomskrivningar i framtiden. Mer information finns i avsnittet om hur du justerar filstorlekar .

• Low Shuffle Merge: Low Shuffle Merge ger en optimerad implementering av MERGE som ger bättre prestanda för de vanligaste arbetsbelastningarna. Dessutom bevaras befintliga optimeringar av datalayouten, till exempel Z-order på oförändrade data.