Share via

Kdy rozdělit tabulky v Azure Databricks

  • Článek

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

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

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

Je potřeba rozdělit malé tabulky?

Databricks doporučuje nedělat tabulky oddílů, které obsahují méně než terabajt dat.

Jaká je minimální velikost každého oddílu v tabulce?

Databricks doporučuje, aby všechny oddíly obsahovaly aspoň gigabajt dat. Tabulky s menším počtem větších oddílů mají tendenci překračovat tabulky s mnoha menšími oddíly.

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

S využitím Delta Lake a Databricks Runtime 11.3 LTS nebo novějších tabulek, které vytvoříte, budou nedělené tabulky přínosné 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é optimalizovat nebo ladit data.

Poznámka:

Pokud chcete zachovat clustering času příjmu dat při provádění velkého počtu úprav pomocí UPDATE nebo MERGE příkazů v tabulce, databricks doporučuje spustit OPTIMIZE s ZORDER BY použitím sloupce, který odpovídá objednávce příjmu dat. Může to být například sloupec 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é tabulky Delta se zadanými oddíly ukazují organizaci podobnou 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 se neměly spoléhat na tuto strategii dělení na interakci s tabulkami Delta.

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 tabulku rozdělit, před výběrem strategie zvažte následující fakta:

  • Transakce nejsou definovány hranicemi oddílů. Delta Lake zajišťuje ACID prostřednictvím transakčních protokolů, takže nemusíte oddělit dávku dat oddílem, abyste zajistili 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 tabulek může využívat clustering času příjmu dat, abyste se nemuseli starat o pořadí vykreslování a ladění oddílů.

Při plánování strategie optimalizace dotazů na základě hranic oddílů 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 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. Pořadí vykreslování funguje pro všechna pole, včetně polí s vysokou kardinalitou a polí, která se můžou nekonečně zvětšovat (například časová razítka nebo ID zákazníka v tabulce transakcí nebo objednávek).
  • 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 můžou být užitečné, zejména pro velmi velké tabulky. Mnoho vylepšení výkonu týkající se dělení se zaměřuje na velmi velké tabulky (stovky terabajtů nebo vyšší).

Mnoho zákazníků migruje na Delta Lake z datových jezer založených na Parquet. Příkaz CONVERT TO DELTA umožňuje převést existující tabulku založenou na Parquet na tabulku Delta bez přepsání existujících dat. Mnoho zákazníků má například velké tabulky, 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.