Sdílet prostřednictvím

Kdy partitiontables na Azure Databricks

  • Článek

Poznámka:

Databricks doporučuje používat kapalinové seskupování pro všechny nové Delta tables. Viz Použijte kapalné shlukování pro Delta tables.

Clustery Liquid se někdy označují také jako "oddíly liquid". Tento článek se týká pouze starší verze dělení Delta, nikoli clusteringu liquid.

Tento článek obsahuje přehled toho, jak můžete partitiontables v Azure Databricks a konkrétní doporučení týkající se toho, kdy byste měli použít rozdělování pro tables podporované Delta Lake. Vzhledem k integrovaným funkcím a optimalizací nevyžaduje většina tables s méně než 1 TB dat oddíly.

Azure Databricks ve výchozím nastavení používá Delta Lake pro všechny tables. Následující doporučení předpokládají, že pracujete s Delta Lake v rámci všech tables.

Ve službě Databricks Runtime 11.3 LTS a novějších služba Azure Databricks automaticky clusteruje data v nerozdělených tables podle času příjmu dat. Viz Použití clusteringu času příjmu dat.

Je potřeba rozdělit malé tables?

Databricks doporučuje, abyste neprováděli partitiontables, které obsahují méně než terabajt dat.

Jaká je minimální velikost pro každou partition v table?

Databricks doporučuje, aby všechny oddíly obsahovaly aspoň gigabajt dat. Tables s menším počtem větších oddílů mají tendenci překonávat tables s mnoha menšími oddíly.

Použití clusteringu času příjmu dat

Pokud používáte Delta Lake a Databricks Runtime 11.3 LTS nebo novější, jsou nerozdělené tables, které vytvoříte, výhodu automaticky z clusteringu času příjmu dat. Doba příjmu dat poskytuje podobné výhody dotazů jako strategie dělení na základě polí data a času, aniž by bylo nutné optimize nebo ladit data.

Poznámka:

Pokud chcete zachovat seskupení podle času příjmu, když provádíte velké množství úprav pomocí příkazů UPDATE nebo MERGE na table, doporučuje Databricks spouštět OPTIMIZE s ZORDER BY a použít column, který odpovídá pořadí příjmu. Může to být například column obsahující časové razítko události nebo datum vytvoření.

Sdílí Delta Lake a Parquet strategie dělení?

Delta Lake používá Parquet jako primární formát pro ukládání dat a některé Delta tables se zadanými partice ukazují organizaci podobně jako Parquet tables uložené pomocí Apache Spark. Apache Spark při ukládání dat ve formátu Parquet používá dělení ve stylu Hive. Dělení ve stylu Hive je není součástí protokolu Delta Lake a úlohy by neměly spoléhat na tuto strategii dělení na interakci s delta tables.

Mnoho funkcí Delta Lake přerušuje předpoklady týkající se rozložení dat, které mohlo být přeneseno z Parquet, Hive nebo dokonce starších verzí protokolu Delta Lake. Vždy byste měli pracovat s daty uloženými v Delta Lake pomocí oficiálně podporovaných klientů a rozhraní API.

Jak se liší oddíly Delta Lake od oddílů v jiných datových jezerech?

Zatímco Azure Databricks a Delta Lake vycházejí z opensourcových technologií, jako je Apache Spark, Parquet, Hive a Hadoop, dělení motivací a strategií užitečných v těchto technologiích obecně neplatí pro Azure Databricks. Pokud se rozhodnete partition své table, před výběrem strategie zvažte následující skutečnosti:

  • Transakce nejsou definovány hranicemi partition. Delta Lake zajišťuje ACID prostřednictvím transakčních protokolů, takže není nutné oddělit dávku dat partition, aby se zajistilo atomické zjišťování.
  • Výpočetní clustery Azure Databricks nemají umístění dat svázané s fyzickými médium. Data přijatá do jezera se ukládají v cloudovém úložišti objektů. 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í.

Jak fungují pořadí Z a oddíly společně?

Indexy pořadí Z můžete použít společně s oddíly k urychlení dotazů na velké datové sady.

Poznámka:

Většina tables může využívat clustering podle času příjmu , abyste se nemuseli starat o Z-order a partition ladění.

Při plánování strategie optimalizace dotazů na základě partition hranic a pořadí Z je důležité mít na paměti následující pravidla:

  • Pořadí Z funguje společně s příkazem OPTIMIZE . Nelze kombinovat soubory přes hranice partition, takže ke shlukování podle Z-řádu dochází pouze v rámci partition. Pro tablesbez oddílů lze soubory kombinovat v celé table.
  • 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-úroveň funguje pro všechna pole, včetně polí s vysokou kardinálností a polí, která se mohou nekonečně zvětšovat (například časová razítka nebo ID zákazníka transakcí nebo objednávek table).
  • Pořadí vykreslování u polí použitých k dělení nelze.

Pokud jsou oddíly tak špatné, proč je některé funkce Azure Databricks používají?

Oddíly mohou být přínosné, zejména pro velmi velké tables. Řada vylepšení výkonu týkajících se particionování se zaměřuje na velmi rozsáhlé tables (stovky terabajtů a více).

Mnoho zákazníků migruje na Delta Lake z datových jezer založených na Parquet. Příkaz CONVERT TO DELTA vám umožňuje převést existující table, které je založeno na Parquet, na Delta table bez přepsání existujících dat. Mnoho zákazníků má velké tables, které dědí předchozí strategie dělení. Některé optimalizace vyvinuté službou Databricks se snaží tyto oddíly využít, pokud je to možné, a snižují některé potenciální nevýhody pro strategie dělení, které nejsou optimalizované pro Delta Lake.

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

Je možné předdefinovat integrované optimalizace Azure Databricks s využitím vlastního dělení?

Někteří zkušení uživatelé Apache Sparku a Delta Lake můžou navrhovat a implementovat vzor, který poskytuje lepší výkon než clustering času příjmu dat. Implementace špatného stavu dělení může mít velmi negativní dopady na výkon podřízených dat a může vyžadovat úplné přepsání dat k opravě. Databricks doporučuje, aby většina uživatelů používala výchozí nastavení, aby nedocházelo k nákladným neekiciencím.