När du ska partitionera tabeller på Azure Databricks

De flesta tabeller på Azure Databricks med mindre än 100 TB data behöver inte partitionering. Azure Databricks använder Delta Lake för alla tabeller som standard och klustrar automatiskt data i opartitionerade tabeller efter inmatningstid, så att du får partitioneringsliknande prestanda utan manuell justering. Överväg endast en anpassad partitioneringsstrategi när den överträffar dessa standardvärden. Se Använda inmatningstidsklustring.

Anpassade partitioneringsstrategier

Avancerade användare av Apache Spark och Delta Lake kan identifiera en partitioneringsstrategi som överträffar standardinmatningens tidsklustring.

Innan du använder anpassade partitioneringsstrategier rekommenderar Databricks flytande klustring för alla tabeller och förutsägelseoptimering för hanterade Unity Catalog-tabeller. Se Använda flytande klustring för tabeller och förutsägande optimering för hanterade Unity Catalog-tabeller.

Om du vill konvertera en befintlig partitionerad Delta Lake-tabell till flytande klustring använder du ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. Flytande klustring fungerar för både kolumner med låg och hög kardinalitet och undviker fasta partitionsgränser och små filproblem som är vanliga med statisk partitionering. Se Konvertera en partitionerad tabell till flytande klustring.

Datatyper som stöds för partitionskolumner

Partitionering stöder dessa datatyper för partitionskolumner:

• Date
• Tidsstämpel
• TimestampNTZ
• Intervall
• String
• Binary
• Boolean
• Heltal, Lång, Kort, Byte
• Flyttal, dubbel, decimal

Partitionskolumner måste vara kolumner på den översta nivån. Du kan inte partitionera efter något av följande:

• Komplexa typer, till exempel StructType, MapType, ArrayTypeeller VariantType
• Struct-fält, till exempel struct_col.field. Delta Lake behandlar ett fält i en struct i PARTITIONED BY som ett uttryck snarare än en kolumnreferens.

Om du vill organisera en tabell efter ett structfält använder du flytande klustring i stället, som identifierar ett struct-fält som en klustringsnyckel. Flytande klustring är det enda sättet att hoppa över data i ett struct-fält utan att först extrahera det till en kolumn på den översta nivån. Se Använda flytande klustring för tabeller.

Rekommendationer för minsta storlek

Partitionering under dessa minimistorlekar kommer sannolikt att påverka frågeprestanda negativt i stället för att förbättra den. Tänk på följande när du bestämmer om du vill partitionera en tabell:

• För tabeller:
  • Om du har mindre än 1 TB data, partitionera inte.
  • Med mer än 1 TB till 100 TB data använder du flytande klustring i stället för partitionering. Partitionering påverkar sannolikt prestanda oftare än det hjälper.
  • Med 100 TB eller mer data kan partitionering förbättra prestanda, men Databricks rekommenderar att du använder flytande klustring först och verifierar prestandaförbättringar.
• För partitioner kontrollerar du att varje partition innehåller minst 1 GB data. Tabeller med färre, större partitioner tenderar att överträffa tabeller med många mindre partitioner.

Använda inmatningstidsklustring

Med hjälp av Delta Lake använder opartitionerade tabeller automatiskt inmatningstidsklustring. Inmatningstid ger förbättrad frågeprestanda i likhet med partitioneringsstrategier med datetime-fält, utan att du behöver optimera eller justera dina data manuellt.

Delta Lake- och Parquet-partitioneringskompatibilitet

Delta Lake använder Parquet för att lagra data, och vissa partitionerade Delta Lake-tabeller har datalayouter som liknar Parquet-tabeller som lagras med Apache Spark. Apache Spark använder Hive-partitionering när data sparas i Parquet-format. Partitionering i Hive-stil är inte en del av Delta Lake-protokollet, och arbetsflöden bör inte förlita sig på denna partitioneringsstrategi för att interagera med Delta Lake-tabeller.

Databricks rekommenderar att du interagerar med data som lagras i Delta Lake med hjälp av klienter och API:er som stöds officiellt. Många Delta Lake-funktioner bryter antaganden om datalayout som kan ha använts med Parquet, Hive eller ännu tidigare Delta Lake-protokollversioner.

Delta Lake-partitionering jämfört med andra datasjöar

Partitioneringstekniker som är användbara i andra open-source tekniker (till exempel Apache Spark, Parquet, Hive och Hadoop) gäller inte alltid för Azure Databricks. Om du väljer att partitionera tabellen bör du tänka på följande:

• Transaktioner definieras inte av partitionsgränser. Eftersom Delta Lake säkerställer ACID via transaktionsloggar behöver du inte separera en batch med data med en partition för att garantera atomiteten.
• 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.

Z-ordning och partitioner

Du kan använda Z-orderindex tillsammans med partitioner för att påskynda frågor på stora datauppsättningar. De flesta tabeller använder inmatningstidsklustring för att undvika att behöva justera Z-ordning och partitioner.

Tänk på följande regler när du planerar en strategi för frågeoptimering baserat på partitionsgränser och Z-ordning:

• Z-order kräver kommandot OPTIMIZE . 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-order på fält som används för partitionering.

Så här optimerar Azure Databricks befintliga partitioner

Många kunder migrerar till Delta Lake från Parquet-baserade datasjöar, till exempel genom att använda -instruktionen CONVERT TO DELTA för att konvertera en befintlig Parquet-baserad tabell till en Delta Lake-tabell utan att skriva om befintliga data. Eftersom konverteringen inte skriver om befintliga data kan stora tabeller ärva tidigare partitioneringsstrategier.

Vissa Databricks-optimeringar använder dessa partitioner när det är möjligt, vilket minskar negativa prestandaeffekter för partitioneringsstrategier som inte är optimerade för Delta Lake.

Delta Lake och Apache Spark är tekniker med öppen källkod. Även om Databricks har funktioner som minskar beroendet av partitionering kan open-source communityn skapa nya funktioner som ökar komplexiteten.