Sdílet prostřednictvím

Přeskočení dat pro Delta Lake

  • Článek

Poznámka:

V Databricks Runtime 13.3 a novějších doporučuje Databricks používat clustering liquid pro rozložení tabulky Delta. Clustering není kompatibilní s řazením Z. Viz Použití liquid clusteringu pro tabulky Delta.

Při zápisu dat do tabulky Delta se informace o přeskočení dat shromažďují automaticky. Delta Lake v Azure Databricks využívá tyto informace (minimální a maximální hodnoty, počty null a celkový počet záznamů na soubor) v době dotazu, aby bylo možné poskytovat rychlejší dotazy.

Je nutné shromáždit statistiky pro sloupce, které se používají v ZORDER příkazech. Podívejte se, co je řazení Z?

Určení sloupců statistiky Delta

Delta Lake ve výchozím nastavení shromažďuje statistiky o prvních 32 sloupcích definovaných ve schématu tabulky. Pro tuto kolekci se každé pole ve vnořeném sloupci považuje za jednotlivý sloupec. Toto chování můžete upravit nastavením jedné z následujících vlastností tabulky:

Table – vlastnost Podporováno prostředí Databricks Runtime Popis
delta.dataSkippingNumIndexedCols Všechny podporované verze Databricks Runtime Zvyšte nebo zmenšete počet sloupců, u kterých Delta shromažďuje statistiky. Závisí na pořadí sloupců.
delta.dataSkippingStatsColumns Databricks Runtime 13.3 LTS a vyšší Zadejte seznam názvů sloupců, pro které Delta Lake shromažďuje statistiky. dataSkippingNumIndexedColsNahrazuje .

Vlastnosti tabulky lze nastavit při vytváření tabulky nebo pomocí ALTER TABLE příkazů. Viz odkaz na vlastnosti tabulky Delta.

Aktualizace této vlastnosti automaticky nepřepočítává statistiky pro existující data. Místo toho ovlivňuje chování budoucí shromažďování statistik při přidávání nebo aktualizaci dat v tabulce. Delta Lake nevyužít statistiky pro sloupce, které nejsou zahrnuté v aktuálním seznamu sloupců statistiky.

Ve službě Databricks Runtime 14.3 LTS a novějších můžete pomocí následujícího příkazu ručně aktivovat výpočet statistiky pro tabulku Delta:

ANALYZE TABLE table_name COMPUTE DELTA STATISTICS

Poznámka:

Dlouhé řetězce jsou během shromažďování statistik zkráceny. Můžete se rozhodnout vyloučit dlouhé řetězcové sloupce z kolekce statistik, zejména pokud se sloupce nepoužívají často pro filtrování dotazů.

Co je řazení Z?

Poznámka:

Databricks doporučuje používat clustering liquid pro všechny nové tabulky Delta. V kombinaci s kapalinovým shlukováním nelze použít ZORDER .

Řazení Z je technika pro společné umístění souvisejících informací ve stejné sadě souborů. Toto společné umístění automaticky používá Delta Lake v algoritmech přeskakování dat v Azure Databricks. Toto chování výrazně snižuje množství dat, která Delta Lake v Azure Databricks potřebuje číst. Do dat pořadí vykreslování zadáte sloupce, které se mají v klauzuli ZORDER BY objednat:

OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)

Pokud očekáváte, že se sloupec běžně používá v predikátech dotazů a pokud má tento sloupec vysokou kardinalitu (tj. velký počet jedinečných hodnot), použijte ZORDER BY.

Jako seznam oddělený čárkami můžete zadat více sloupců ZORDER BY . Účinnost lokality však klesne s každým sloupcem navíc. Pořadí vykreslování sloupců, které nemají statistiky shromážděné na nich, by bylo neefektivní a plýtvání zdroji. Důvodem je to, že přeskočení dat vyžaduje statistiky místních sloupců, jako jsou min, maximum a počet. Shromažďování statistik pro určité sloupce můžete nakonfigurovat tak, že změníte pořadí sloupců ve schématu, nebo můžete zvýšit počet sloupců pro shromažďování statistik.

Poznámka:

  • Řazení Z není idempotentní , ale má za cíl být přírůstkovou operací. Doba, po které trvá řazení Z, není zaručeno, že se během několika spuštění sníží. Pokud se ale do oddílu, který byl pouze seřazený od Z, nepřidali žádná nová data, nebude mít jiné řazení Z tohoto oddílu žádný vliv.

  • Pořadí vykreslování má za cíl vytvořit rovnoměrně vyvážené datové soubory s ohledem na počet řazených kolekcí členů, ale ne nutně velikost dat na disku. Dvě míry jsou nejčastěji korelovány, ale v situacích, kdy tomu tak není, což vede k nerovnoměrné distribuci v době optimalizace úloh.

    Pokud například datum ZORDER BY a nejnovější záznamy jsou mnohem širší (například delší matice nebo řetězcové hodnoty), než jsou hodnoty v minulosti, očekává se, že OPTIMIZE doby trvání úkolů úlohy se zkosí a výsledné velikosti souborů. Jedná se ale pouze o problém samotného OPTIMIZE příkazu, který by neměl mít žádný negativní dopad na následné dotazy.