Utforma och implementera ett datapartitioneringsschema

Datapartitionering påverkar direkt hur effektivt dina frågor körs och hur mycket beräkningsresurser du förbrukar. När du partitionerar en tabell delar du upp data i diskreta segment baserat på kolumnvärden, vilket gör att frågemotorn endast kan läsa relevanta delar av datamängden. Den här metoden, som kallas partitionsrensning, kan avsevärt minska datagenomsökningar när filter överensstämmer med partitionsgränser.

Överväg att ett detaljhandelsföretag bearbetar miljontals dagliga försäljningstransaktioner. Analytiker frågar ofta efter datumintervall för att generera veckorapporter, jämföra trender månad för månad och analysera säsongsmönster. Utan partitionering genomsöker varje fråga hela transaktionshistoriken. Med rätt partitionering efter datum berör frågor för en viss vecka bara en bråkdel av de lagrade filerna.

Avgöra när partitionering gäller

Databricks rekommenderar att du inte partitionerar tabeller som innehåller mindre än 1 TB data. För mindre tabeller uppväger kostnaderna för att hantera partitionsmetadata och möjligheten att skapa många små filer eventuella fördelar med frågeprestanda. Opartitionerade Delta-tabeller i de senaste Databricks Runtime-versionerna drar automatiskt nytta av inmatningstidsklustring, vilket ger liknande frågefördelar utan explicit konfiguration.

När dina tabeller överskrider 1 TB blir partitionering en värdefull optimeringsteknik. I den här skalan kompenserar fördelarna med att bara läsa relevanta datasegment avsevärt kostnaderna för partitionshantering. Partitionering möjliggör också parallell bearbetning eftersom Spark kan distribuera olika partitioner mellan klusternoder för samtidig körning.

För mycket stora tabeller i hundratals terabyte ger partitionering ännu större fördelar. I den här skalan minskar partitionsrensning avsevärt mängden data som frågemotorn behöver bearbeta, vilket förbättrar både prestanda och kostnadseffektivitet.

Välj effektiva partitionsnycklar

Val av partitionsnyckel kräver att du förstår dina dataegenskaper och frågemönster. Effektiva partitionsnycklar har gemensamma egenskaper som maximerar prestandafördelar samtidigt som vanliga fallgropar undviks.

Kolumner med låg kardinalitet fungerar bäst

Välj kolumner med ett begränsat antal distinkta värden. Datumkolumner, geografiska regioner, produktkategorier och statusfält ger utmärkta partitionsnycklar eftersom de skapar ett hanterbart antal partitioner. En kolumn med tusentals eller miljontals unika värden, till exempel kund-ID eller transaktions-ID, leder till överpartitionering och dåliga prestanda.

Om du till exempel partitionerar en försäljningstabell sale_date efter på daglig nivå kan det skapa 365 partitioner per år. Om varje dag innehåller tillräckligt med datavolym fungerar den här detaljnivån bra. Partitionering efter sale_timestamp på den andra nivån skulle dock skapa miljontals partitioner som var och en innehåller minimala data.

Anpassa efter frågemönster

Partitionsnyckeln ska matcha de kolumner som användarna filtrerar på oftast. Om analytiker konsekvent frågar efter försäljningsdata efter datumintervall möjliggör partitionering efter datum effektiv beskärning. Om frågor främst filtreras efter region bör du överväga region som partitionsnyckel i stället.

När det finns flera filtermönster prioriterar du de vanligaste eller mest prestandakritiska frågorna. Du kan definiera ett partitioneringsschema per tabell, så välj kolumner som gynnar merparten av din arbetsbelastning. För betydligt olika frågemönster bör du överväga att skapa separata optimerade materialiserade vyer eller sammanfattningstabeller för specifika användningsfall.

Överväg datatillväxt över tid

Välj ett partitionsschema som skalar på rätt sätt när dina data växer. Partitionering efter år fungerar bra från början men kan skapa partitioner som är för stora över tid. Omvänt kan partitionering per timme fungera för data med stora volymer men skapar för många små partitioner för måttliga volymer.

Utvärdera din förväntade datatillväxthastighet när du väljer partitionskornighet. En balans mellan partitionsstorlek och antalet partitioner bidrar till att upprätthålla konsekventa frågeprestanda när datauppsättningen expanderar.

Överväg även datadistribution mellan partitioner. Kraftigt ojämna partitionsstorlekar kan skapa flaskhalsar i bearbetningen eftersom noder som hanterar större partitioner tar längre tid att slutföra medan andra förblir inaktiva.

Implementera partitioner i Azure Databricks

Du definierar partitioner när du skapar en tabell med hjälp av PARTITIONED BY -satsen i SQL eller partitionBy metoden i PySpark. När du har upprättat partitioner dirigerar Azure Databricks automatiskt inkommande data till lämpliga partitionskataloger baserat på kolumnvärden.

Skapa en partitionerad tabell med SQL

I följande exempel skapas en tabell med försäljningstransaktioner som partitionerats efter transaktionsdatumet:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_id STRING,
    quantity INT,
    unit_price DECIMAL(10,2),
    total_amount DECIMAL(12,2),
    transaction_date DATE
)
PARTITIONED BY (transaction_date);

När du frågar den här tabellen med ett datumfilter läser frågemotorn endast de partitioner som matchar dina filtervillkor:

SELECT product_id, SUM(total_amount) AS revenue
FROM sales.transactions
WHERE transaction_date BETWEEN '2024-01-01' AND '2024-01-31'
GROUP BY product_id;

Skapa en partitionerad tabell med PySpark

När du använder PySpark anger du partitionering under skrivåtgärden:

df.write.format("delta") \
    .partitionBy("transaction_date") \
    .saveAsTable("sales.transactions")

För efterföljande skrivningar ska du upprätthålla konsekvens genom att inkludera samma partitionsspecifikation:

new_transactions_df.write.format("delta") \
    .mode("append") \
    .partitionBy("transaction_date") \
    .saveAsTable("sales.transactions")

Använda genererade kolumner för partitionsflexik

Genererade kolumner ger ett sätt att härleda partitionsvärden från befintliga kolumner utan att lagra redundanta data. Den här metoden är användbar när källdata innehåller tidsstämplar men du vill partitionera efter datum:

CREATE TABLE sales.transactions (
    transaction_id STRING,
    customer_id STRING,
    product_id STRING,
    quantity INT,
    unit_price DECIMAL(10,2),
    total_amount DECIMAL(12,2),
    transaction_timestamp TIMESTAMP,
    transaction_date DATE GENERATED ALWAYS AS (CAST(transaction_timestamp AS DATE))
)
PARTITIONED BY (transaction_date);

Undvik vanliga partitioneringsfel

Att förstå vad man ska undvika är lika viktigt som att veta vad man ska göra. Flera vanliga misstag kan avsevärt försämra prestanda och komplicera datahanteringen.

Överpartitionering skapar små filproblem

Att skapa för många partitioner, som var och en innehåller otillräckliga data, leder till små filproblem. När partitioner innehåller filer som är mindre än målfilens storlek drabbas frågeprestanda av överdrivna metadataåtgärder och minskad läseffektivitet. Sikta på partitioner med minst 1 GB data.

Tecken på överpartitionering inkluderar långsamma frågeprestanda trots partitionsrensning, ett stort antal små filer i partitionskataloger och långa optimeringstider för tabeller. Om du ser dessa symtom bör du överväga att välja en grov partitionskornighet.

Partitionering på kolumner med hög kardinalitet misslyckas

Kolumner med många unika värden gör att partitionsnycklarna är dåliga. Partitionering efter kund-ID, transaktions-ID eller andra kolumner med hög kardinalitet skapar miljontals partitioner som försämras i stället för att förbättra prestandan. Reservera kolumnoptimering med hög kardinalitet för andra tekniker som är utformade för detta ändamål.

Om du ändrar partitioner måste du skriva om data

Partitionskolumner ingår i tabellstrukturen. Om du ändrar partitioneringsstrategin måste du skriva om hela tabellen till en ny plats med olika partitionsgränser. Den här åtgärden förbrukar betydande beräkningsresurser och tid för stora tabeller.

Planera partitioneringsstrategin noggrant innan du läser in data i stor skala. Överväg framtida frågemönster och datatillväxt för att undvika kostsamma omstruktureringar senare.

Beslut om dokumentpartitionering

Registrera dina partitionsnyckelval och resonemanget bakom dem. Den här dokumentationen hjälper teammedlemmar att förstå möjligheter till frågeoptimering och förhindrar oavsiktliga ändringar som kan påverka prestanda. Inkludera information om förväntade partitionsstorlekar, frågemönster som drar nytta av schemat och eventuella begränsningar som påverkar dina beslut.

Överväg flytande klustring som ett alternativ

När du stöter på partitioneringsutmaningar – särskilt med kolumner med hög kardinalitet som tidsstämplar eller när frågemönster är osäkra – är flytande klustring ett modernt alternativ. Till skillnad från traditionell partitionering erbjuder flytande klustring:

• Flexibilitet att justera optimeringsstrategier utan att skriva om data
• Automatiskt underhåll när tabellerna växer
• Minskade kostnader för partitionshantering

Flytande klustring är den rekommenderade metoden för nya tabeller där partitioneringsbegränsningar skulle begränsa prestanda eller skapa alltför stora underhållsbelastningar. Det är särskilt effektivt för tabeller som överskrider 1 TB och kräver filtrering på kolumner som skulle skapa för många partitioner med traditionella metoder.

Information om implementering, syntax, och strategier för optimering finns i enheten för att designa och implementera en klusterstrategi senare i denna modul.