Adatátugrás a Delta Lake-hez

  • Cikk

A rendszer automatikusan összegyűjti az adatokat kihagyó adatokat, amikor adatokat ír egy Delta-táblába. A Delta Lake az Azure Databricksen a lekérdezési időben kihasználja ezeket az információkat (minimális és maximális értékek, null értékek és fájlonkénti összes rekord) a gyorsabb lekérdezés érdekében.

Feljegyzés

A Databricks Runtime 13.3-at vagy újabb verzióját használva a Databricks javasolja a fürtszolgáltatás használatát a Delta-táblaelrendezéshez. A fürtözés nem kompatibilis a Z-rendezéssel. Lásd: Folyékony fürtözés használata Delta-táblákhoz.

Az utasításokban ZORDER használt oszlopokra vonatkozó statisztikákat kell gyűjtenie. Lásd : Mi az a Z-rendelés?.

Delta-statisztikák oszlopainak megadása

A Delta Lake alapértelmezés szerint a táblasémában definiált első 32 oszlop statisztikáit gyűjti. Ebben a gyűjteményben a beágyazott oszlopok minden mezője önálló oszlopnak minősül. Ezt a viselkedést az alábbi táblatulajdonságok egyikének beállításával módosíthatja:

Táblatulajdonság A Databricks Runtime támogatott Leírás
delta.dataSkippingNumIndexedCols Minden támogatott Databricks Runtime-verzió Növelje vagy csökkentse azon oszlopok számát, amelyeken a Delta statisztikákat gyűjt. Az oszlopsorrendtől függ.
delta.dataSkippingStatsColumns Databricks Runtime 13.3 LTS és újabb verziók Adja meg azoknak az oszlopneveknek a listáját, amelyekhez a Delta Lake statisztikákat gyűjt. Felülírja dataSkippingNumIndexedCols.

A táblatulajdonságok a tábla létrehozásakor vagy utasításokkal állíthatók ALTER TABLE be. Lásd a Delta-tábla tulajdonságaira vonatkozó referenciát.

A tulajdonság frissítése nem jelenti automatikusan a meglévő adatok statisztikáinak újrafordítását. Ez inkább befolyásolja a jövőbeli statisztikák gyűjtésének viselkedését, amikor adatokat ad hozzá vagy frissít a táblában. A Delta Lake nem használja az aktuális statisztikai oszlopok listájában nem szereplő oszlopok statisztikáit.

A Databricks Runtime 14.3 LTS és újabb verzióiban manuálisan aktiválhatja a Delta-táblák statisztikáinak újraszámítását az alábbi paranccsal:

ANALYZE TABLE table_name COMPUTE DELTA STATISTICS

Feljegyzés

A statisztikai adatgyűjtés során a hosszú sztringek csonkulnak. Dönthet úgy, hogy kizárja a hosszú sztringoszlopokat a statisztikai gyűjteményből, különösen akkor, ha az oszlopokat nem használják gyakran lekérdezések szűrésére.

Mi az a Z-rendelés?

A Z-rendezés egy olyan technika , amely a kapcsolódó információkat ugyanabban a fájlkészletben helyezi el. Ezt a közös helységet a Delta Lake automatikusan használja az Azure Databricks adat-kihagyó algoritmusainál. Ez a viselkedés jelentősen csökkenti az Azure Databricks delta lake-beli olvasási adatmennyiségét. A Z-order adatokhoz a záradékban adja meg a sorrendbe ZORDER BY rendezendő oszlopokat:

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

Ha arra számít, hogy egy oszlopot gyakran használnak a lekérdezési predikátumokban, és ha az oszlop nagy számossággal rendelkezik (azaz nagy számú különböző érték), akkor használja a következőt ZORDER BY:

Vesszővel tagolt listaként több oszlopot ZORDER BY is megadhat. A helység hatékonysága azonban minden további oszlopnál csökken. A Z-rendezés olyan oszlopokon, amelyeken nem gyűjtenek statisztikákat, hatástalan lenne, és erőforrás-pazarlás lenne. Ennek az az oka, hogy az adatátugráshoz oszlopon belüli statisztikára van szükség, például min, max és darabszám. Bizonyos oszlopok statisztikáinak gyűjtését konfigurálhatja a séma oszlopainak átrendezésével, vagy növelheti az oszlopok számát a statisztikák gyűjtéséhez.

Feljegyzés

  • A Z-rendezés nem idempotens , hanem növekményes művelet. A Z-rendeléshez szükséges idő nem garantált, hogy több futtatáson keresztül csökkenjen. Ha azonban nem ad hozzá új adatokat egy csak Z sorrendben rendezett partícióhoz, a partíció egy másik Z sorrendbe helyezése nem lesz hatással.

  • A Z-rendezés célja, hogy egyenletesen kiegyensúlyozott adatfájlokat állíthasson elő a csuplok száma tekintetében, de nem feltétlenül lemezen lévő adatméretet. A két mérték leggyakrabban korrelál, de előfordulhatnak olyan helyzetek, amikor ez nem így van, ami a tevékenységidő optimalizálásához vezet.

    Ha például ZORDER BYa dátum és a legutóbbi rekordok mind sokkal szélesebbek (például hosszabb tömbök vagy sztringértékek), mint a korábbiak, akkor várhatóan a OPTIMIZE feladat tevékenységideje el lesz varrva, valamint az eredményül kapott fájlméretek. Ez azonban csak magának a parancsnak a OPTIMIZE problémája, nem lehet negatív hatással a későbbi lekérdezésekre.