Kdy rozdělit tabulky v Azure Databricks

Poznámka:

Databricks doporučuje liquid clustering pro všechny spravované tabulky. Pro spravované tabulky využívající Apache Iceberg podporuje Unity Catalog pouze liquid clustering a sloupce PARTITION BY interpretuje jako klíče pro clustering. Viz Převést particionovanou tabulku na liquid clustering.

Většina tabulek na Azure Databricks s méně než 100 TB dat nepotřebuje dělení. Azure Databricks ve výchozím nastavení používá Delta Lake pro všechny tabulky a automaticky shlukuje data v nerozdělených tabulkách podle času příjmu dat, takže získáte výkon podobný dělení bez ručního ladění. Vlastní strategii rozdělení zvažte pouze tehdy, pokud překoná tato výchozí nastavení. Viz také Clustrování podle času příjmu dat.

Vlastní strategie rozdělování

Pokročilí uživatelé Apache Sparku a Delta Lake mohou určit strategii dělení na oddíly, která překonává výchozí shlukování podle času ingestce.

Warning

Neefektivní strategie dělení může negativně ovlivnit výkon dotazů a k opravě vyžadovat úplné přepsání dat. Úplné přepsání může být pro velké tabulky velmi nákladné a pomalé.

Před použitím vlastních strategií dělení oddílů Databricks doporučuje liquid clustering pro všechny tabulky a prediktivní optimalizaci pro spravované tabulky v Unity Catalogu. Viz Použití liquid clusteringu pro tabulky a Prediktivní optimalizace pro spravované tabulky v katalogu Unity.

Chcete-li převést existující oddílovanou tabulku Delta Lake na liquid clustering, použijte ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY. Liquid clustering funguje u sloupců s nízkou i vysokou kardinalitou a vyhýbá se pevným hranicím oddílů i problémům s malými soubory, které jsou běžné u statického particionování. Viz Převést particionovanou tabulku na liquid clustering.

Podporované datové typy pro sloupce oddílů

Pro sloupce dělení na oddíly jsou podporovány tyto datové typy:

  • Date
  • Časová značka
  • TimestampNTZ
  • Rozmezí
  • String
  • Binary
  • logický
  • Celé číslo, Dlouhé, Krátké, Bajt
  • Float (float), Double (dvojitý), Decimal (desetinný)

Sloupce oddílů musí být sloupce nejvyšší úrovně. Oddíly nejde rozdělit podle žádné z následujících možností:

  • Komplexní typy, například StructType, MapType, ArrayTypenebo VariantType
  • Strukturní pole, například struct_col.field. Delta Lake považuje pole struktury v PARTITIONED BY za výraz, nikoli za odkaz na sloupec.

Pokud chcete tabulku uspořádat podle pole struktury, použijte místo toho clustering liquid, který rozpozná pole struktury jako klíč clusteringu. Liquid clustering je jediný způsob, jak přeskakovat data u pole typu struct, aniž by bylo nutné je nejprve extrahovat do sloupce nejvyšší úrovně. Viz Použití metody 'liquid clustering' pro tabulky.

Doporučení minimální velikosti

Dělení pod těmito minimálními velikostmi pravděpodobně negativně ovlivní výkon dotazů a nelepší je. Při rozhodování o rozdělení tabulky zvažte následující skutečnosti:

  • Pro tabulky:
    • S méně než 1 TB dat nedělejte oddíly.
    • Pro data v rozsahu od více než 1 TB do 100 TB použijte liquid clustering místo dělení na oddíly. Dělení pravděpodobně negativně ovlivňuje výkon častěji, než pomáhá.
    • Při objemu dat 100 TB a více může rozdělení na oddíly zlepšit výkon, ale Databricks doporučuje nejprve použít liquid clustering a ověřit zlepšení výkonu.
  • V případě oddílů ověřte, že každý oddíl obsahuje alespoň 1 GB dat. Tabulky s menším počtem větších oddílů mají tendenci překonávat tabulky s mnoha menšími oddíly.

Použití klastrace podle času ingesce

Při použití Delta Lake nepartitionované tabulky automaticky používají shlukování podle času ingestování. Doba příjmu dat má vylepšení výkonu dotazů podobně jako strategie dělení s poli datetime, aniž by bylo nutné data ručně optimalizovat nebo ladit.

Poznámka:

Pokud chcete zachovat seskupení podle času příjmu dat při provádění velkého počtu úprav pomocí UPDATE nebo MERGE příkazů v tabulce, společnost Databricks doporučuje používat liquid clustering ve sloupci, který odpovídá chronologické přirozenosti příjmu dat, jako je časové razítko události nebo datum vytvoření. Viz Použití metody 'liquid clustering' pro tabulky.

Kompatibilita partitionování v Delta Lake a Parquet

Delta Lake používá Parquet k ukládání dat a některé dělené tabulky Delta Lake mají rozložení dat podobná tabulkám Parquet uloženým v Apache Sparku. Apache Spark při ukládání dat ve formátu Parquet používá dělení ve stylu Hive. Dělení ve stylu Hive není součástí protokolu Delta Lake a úlohy by neměly spoléhat na tuto strategii dělení na interakci s tabulkami Delta Lake.

Databricks doporučuje pracovat s daty uloženými v Delta Lake pomocí oficiálně podporovaných klientů a rozhraní API. Mnoho funkcí Delta Lake přerušuje předpoklady o rozložení dat, které mohlo být použito s Parquet, Hive nebo ještě staršími verzemi protokolu Delta Lake.

Poznámka:

Když povolíte mapování sloupců pro tabulku Delta Lake, náhodné předpony nahradí názvy sloupců v adresářích oddílů pro dělení ve stylu Hive. Viz Přejmenování a vyřazení sloupců v rámci mapování sloupců Delta Lake.

Dělení Delta Lake v porovnání s jinými datovými jezery

Techniky dělení dat, které jsou užitečné v jiných open-source technologiích (jako jsou Apache Spark, Parquet, Hive a Hadoop), neplatí pro Azure Databricks vždy. Pokud se rozhodnete tabulku rozdělit na oddíly, zvažte následující:

  • Transakce nejsou definovány hranicemi oddílů. Protože Delta Lake zajišťuje ACID prostřednictvím transakčních logů, není nutné rozdělovat dávku dat do oddílů, aby byla zaručena atomicita.
  • Výpočetní clustery Azure Databricks nemají umístění dat svázané s fyzickými médium. Data importovaná do lakehousu jsou uložena v cloudovém objektovém úložišti. Zatímco jsou data uložená v mezipaměti do místního diskového úložiště během zpracování dat, Azure Databricks používá statistiky založené na souborech k identifikaci minimálního množství dat pro paralelní načítání.

Pořadí Z a oddíly

Poznámka:

Databricks doporučuje pro všechny nové tabulky shlukování kapalin přes řazení Z. Viz Použití metody 'liquid clustering' pro tabulky.

Můžete použít indexy Z-řádu společně s partícemi k urychlení dotazů na velké datové sady. Většina tabulek používá shlukování podle času ingestování, aby nebylo nutné ladit Z-order a partice.

Při plánování strategie optimalizace dotazů na základě hranic oddílů a pořadí Z mějte na paměti následující pravidla:

  • Pořadí Z vyžaduje OPTIMIZE příkaz. Nelze kombinovat soubory přes hranice oddílů, takže clustering pořadí Z může probíhat pouze v rámci oddílu. U nesedělených tabulek je možné soubory zkombinovat napříč celou tabulkou.
  • Dělení funguje dobře jenom pro pole s nízkou nebo známou kardinalitou (například pole kalendářních dat nebo fyzická umístění), ale ne pro pole s vysokou kardinalitou, jako jsou časová razítka. Z-order funguje pro všechna pole, včetně polí s vysokou kardinalitou a polí, která mohou růst neomezeně (například časová razítka nebo ID zákazníka v tabulce transakcí či objednávek).
  • Nelze použít Z-order u polí použitých pro dělení.

Jak Azure Databricks optimalizuje s ohledem na existující oddíly

Mnoho zákazníků migruje na Delta Lake z datových jezer založených na Parquet, například pomocí CONVERT TO DELTA příkazu převést existující tabulku založenou na Parquet na tabulku Delta Lake, aniž by museli přepisovat existující data. Vzhledem k tomu, že převod nepřepíše existující data, můžou velké tabulky dědit předchozí strategie dělení.

Některé optimalizace Databricks tyto partice podle možností využívají, a tím zmírňují negativní dopady na výkon u strategií dělení dat, které nejsou optimalizované pro databázi Delta Lake.

Delta Lake a Apache Spark jsou opensourcové technologie. I když databricks obsahuje funkce, které snižují závislost na dělení, může komunita open source vytvářet nové funkce, které přidávají složitost.

  • Last updated on