När du ska partitioneras tabeller i Azure Databricks

Den här artikeln innehåller en översikt över hur du kan partitionera tabeller i Azure Databricks och specifika rekommendationer kring när du ska använda partitionering för tabeller som backas upp av Delta Lake. På grund av inbyggda funktioner och optimeringar kräver de flesta tabeller med mindre än 1 TB data inte partitioner.

Azure Databricks använder Delta Lake för alla tabeller som standard. Följande rekommendationer förutsätter att du arbetar med Delta Lake för alla tabeller.

I Databricks Runtime 11.3 LTS och senare klustrade Azure Databricks automatiskt data i opartitionerade tabeller efter inmatningstid. Se Använda inmatningstidsklustring.

Behöver små tabeller partitioneras?

Databricks rekommenderar att du inte partitionera tabeller som innehåller mindre än en terabyte data.

Vad är minsta storlek för varje partition i en tabell?

Databricks rekommenderar att alla partitioner innehåller minst en gigabyte data. Tabeller med färre, större partitioner tenderar att överträffa tabeller med många mindre partitioner.

Använda inmatningstidsklustring

Genom att använda Delta Lake och Databricks Runtime 11.3 LTS eller senare skapar opartitionerade tabeller automatiskt fördelar med inmatningstidsklustring. Inmatningstiden ger liknande frågefördelar som partitioneringsstrategier baserat på datetime-fält utan att du behöver optimera eller finjustera dina data.

Kommentar

För att upprätthålla inmatningstidsklustring när du utför ett stort antal ändringar med hjälp UPDATE av eller MERGE instruktioner i en tabell rekommenderar Databricks att du kör OPTIMIZE med ZORDER BY en kolumn som matchar inmatningsordningen. Det kan till exempel vara en kolumn som innehåller en händelsetidsstämpel eller ett skapandedatum.

Delar Delta Lake och Parquet partitioneringsstrategier?

Delta Lake använder Parquet som primärt format för att lagra data, och vissa Delta-tabeller med angivna partitioner visar en organisation som liknar Parquet-tabeller som lagras med Apache Spark. Apache Spark använder Hive-partitionering när data sparas i Parquet-format. Hive-partitionering är inte en del av Delta Lake-protokollet, och arbetsbelastningar bör inte förlita sig på den här partitioneringsstrategin för att interagera med Delta-tabeller.

Många Delta Lake-funktioner bryter antaganden om datalayout som kan ha överförts från Parquet, Hive eller ännu tidigare Delta Lake-protokollversioner. Du bör alltid interagera med data som lagras i Delta Lake med hjälp av klienter och API:er som stöds officiellt.

Hur skiljer sig Delta Lake-partitioner från partitioner i andra datasjöar?

Azure Databricks och Delta Lake bygger på öppen källkod tekniker som Apache Spark, Parquet, Hive och Hadoop, men partitioneringsmotiveringar och strategier som är användbara i dessa tekniker gäller vanligtvis inte för Azure Databricks. Om du väljer att partitionera tabellen bör du överväga följande fakta innan du väljer en strategi:

• Transaktioner definieras inte av partitionsgränser. Delta Lake säkerställer ACID via transaktionsloggar, så du behöver inte separera en batch med data med en partition för att säkerställa atomisk identifiering.
• Azure Databricks-beräkningskluster har inte datalokalitet kopplad till fysiska medier. Data som matas in i lakehouse lagras i molnobjektlagring. Medan data cachelagras till lokal disklagring under databearbetningen använder Azure Databricks filbaserad statistik för att identifiera den minimala mängden data för parallell inläsning.

Hur fungerar Z-ordning och partitioner tillsammans?

Du kan använda Z-orderindex tillsammans med partitioner för att påskynda frågor på stora datauppsättningar.

Kommentar

De flesta tabeller kan använda inmatningstidsklustring för att undvika att behöva oroa sig för Z-ordning och partitionsjustering.

Följande regler är viktiga att tänka på när du planerar en strategi för frågeoptimering baserat på partitionsgränser och Z-ordning:

• Z-order fungerar tillsammans med OPTIMIZE kommandot . Du kan inte kombinera filer över partitionsgränser, så Z-orderkluster kan bara ske inom en partition. För opartitionerade tabeller kan filer kombineras i hela tabellen.
• Partitionering fungerar endast bra för fält med låg eller känd kardinalitet (till exempel datumfält eller fysiska platser), men inte för fält med hög kardinalitet, till exempel tidsstämplar. Z-order fungerar för alla fält, inklusive fält med hög kardinalitet och fält som kan växa oändligt (till exempel tidsstämplar eller kund-ID i en transaktions- eller ordertabell).
• Du kan inte Z-beställa på fält som används för partitionering.

Varför använder vissa Azure Databricks-funktioner dem om partitionerna är så dåliga?

Partitioner kan vara bra, särskilt för mycket stora tabeller. Många prestandaförbättringar kring partitionering fokuserar på mycket stora tabeller (hundratals terabyte eller större).

Många kunder migrerar till Delta Lake från Parquet-baserade datasjöar. Med instruktionen CONVERT TO DELTA kan du konvertera en befintlig Parquet-baserad tabell till en Delta-tabell utan att skriva om befintliga data. Därför har många kunder stora tabeller som ärver tidigare partitioneringsstrategier. Vissa optimeringar som utvecklats av Databricks försöker utnyttja dessa partitioner när det är möjligt, vilket minimerar vissa potentiella nackdelar för partitioneringsstrategier som inte är optimerade för Delta Lake.

Delta Lake och Apache Spark är tekniker med öppen källkod. Databricks fortsätter att introducera funktioner som minskar beroendet av partitionering, men öppen källkod communityn kan fortsätta att skapa nya funktioner som ökar komplexiteten.

Går det att överträffa inbyggda optimeringar i Azure Databricks med anpassad partitionering?

Vissa erfarna användare av Apache Spark och Delta Lake kanske kan utforma och implementera ett mönster som ger bättre prestanda än inmatningstidsklustring. Implementering av en felaktig partitioneringsstatus kan få mycket negativa återverkningar på nedströmsprestanda och kan kräva en fullständig omskrivning av data som ska åtgärdas. Databricks rekommenderar att de flesta användare använder standardinställningar för att undvika att införa dyra ineffektiviteter.