Táblák particionálása az Azure Databricksben

Feljegyzés

A Databricks azt javasolja, hogy az összes új Delta-táblához használjuk a folyékony fürtözést. Lásd: Folyékony fürtözés használata Delta-táblákhoz.

A folyékony fürtöket néha "folyékony partícióknak" is nevezik. Ez a cikk csak az örökölt Delta particionálásra vonatkozik, a folyékony fürtözésre nem.

Ez a cikk áttekintést nyújt arról, hogyan particionálhatja a táblákat az Azure Databricksben, és konkrét javaslatokat tartalmaz arra vonatkozóan, hogy mikor érdemes particionálást használnia a Delta Lake által támogatott táblákhoz. A beépített funkciók és optimalizálások miatt a legtöbb, 1 TB-nál kevesebb adattal rendelkező tábla nem igényel partíciókat.

Az Azure Databricks alapértelmezés szerint a Delta Lake-t használja az összes táblához. Az alábbi javaslatok feltételezik, hogy a Delta Lake-et minden táblához használhatja.

A Databricks Runtime 11.3 LTS-ben és újabb verziókban az Azure Databricks automatikusan csoportosítja az adatokat nem particionált táblákban a betöltési idő alapján. Lásd: Betöltési időfürtök használata.

Particionálásra van szükség a kis táblákhoz?

A Databricks azt javasolja, hogy ne particionáljon olyan táblákat, amelyek kevesebb mint egy terabájtnyi adatot tartalmaznak.

Mi a minimális méret a táblák egyes partícióihoz?

A Databricks azt javasolja, hogy minden partíció legalább egy gigabájtnyi adatot tartalmazzon. A kevesebb, nagyobb partícióval rendelkező táblák általában túlteljesítettek a sok kisebb partícióval rendelkező táblákon.

Betöltési időfürtök használata

A Delta Lake és a Databricks Runtime 11.3 LTS vagy újabb, nem particionált táblák használatával automatikusan kihasználhatja a betöltési idő fürtözését. A betöltési idő hasonló lekérdezési előnyöket biztosít a datetime mezőkön alapuló particionálási stratégiákhoz anélkül, hogy optimalizálnia vagy finomhangolnia kellene az adatokat.

Feljegyzés

A betöltési idő fürtözésének fenntartása érdekében, ha nagy számú módosítást UPDATE hajt végre egy táblán vagy MERGE utasításon, a Databricks azt javasolja, hogy a betöltési sorrendnek megfelelő oszlop használatával ZORDER BY fussonOPTIMIZE. Ez lehet például egy esemény-időbélyeget vagy létrehozási dátumot tartalmazó oszlop.

A Delta Lake és a Parquet osztozik a particionálási stratégiákon?

A Delta Lake a Parquetet használja az adatok tárolásának elsődleges formátumaként, és egyes, megadott partíciókkal rendelkező Delta-táblák az Apache Sparkban tárolt Parquet-táblákhoz hasonló szervezetet mutatnak be. Az Apache Spark Hive-stílusú particionálást használ az adatok Parquet formátumú mentésekor. A Hive-stílusú particionálás nem része a Delta Lake protokollnak, és a számítási feladatok nem támaszkodhatnak erre a particionálási stratégiára a Delta-táblák használatához.

Számos Delta Lake-funkció megszakítja a Parquet, Hive vagy akár korábbi Delta Lake protokollverziókból átvitt adatelrendezések feltételezéseit. A Delta Lake-ben tárolt adatokkal mindig hivatalosan támogatott ügyfeleket és API-kat kell használnia.

Miben különböznek a Delta Lake-partíciók a többi adattó partícióitól?

Míg az Azure Databricks és a Delta Lake olyan nyílt forráskód technológiákra épül, mint az Apache Spark, a Parquet, a Hive és a Hadoop, az ezekben a technológiákban hasznos motivációk és stratégiák particionálása általában nem igaz az Azure Databricksre. Ha a táblázat particionálását választja, a stratégia kiválasztása előtt vegye figyelembe a következő tényeket:

• A tranzakciókat nem partícióhatárok határozzák meg. A Delta Lake a tranzakciónaplókon keresztül biztosítja az ACID-t , így nem kell partícióval elválasztania egy adatköteget az atomi felderítés biztosításához.
• Az Azure Databricks számítási fürtöi nem rendelkeznek fizikai adathordozóhoz kötött adat honossággal. A tóházba betöltött adatok a felhőobjektum-tárolóban vannak tárolva. Bár az adatok gyorsítótárazva lesznek a helyi lemeztárolóba az adatfeldolgozás során, az Azure Databricks fájlalapú statisztikákkal azonosítja a párhuzamos betöltéshez szükséges minimális adatmennyiséget.

Hogyan működnek együtt a Z-rendelések és a partíciók?

A partíciók mellett Z-megrendelési indexek is használhatók a nagy adathalmazok lekérdezéseinek felgyorsításához.

Feljegyzés

A legtöbb tábla kihasználhatja a betöltési idő fürtözését , hogy ne kelljen aggódnia a Z-sorrend és a partícióhangolás miatt.

A következő szabályokat fontos szem előtt tartani a partícióhatárok és A-sorrend alapján történő lekérdezésoptimalizálási stratégia tervezésekor:

• A Z-order a paranccsal OPTIMIZE párhuzamosan működik. A fájlok nem egyesíthetők a partícióhatárok között, ezért a Z-sorrendű fürtözés csak egy partíción belül történhet. Nem particionált táblák esetén a fájlok a teljes táblában kombinálhatók.
• A particionálás csak alacsony vagy ismert számosságú mezőknél (például dátummezőknél vagy fizikai helyeknél) működik jól, magas számosságú mezőknél, például időbélyegekhez nem. A Z-rendelés minden mezőnél működik, beleértve a nagy számosságú mezőket és a végtelenül növekedő mezőket (például időbélyegeket vagy egy tranzakció vagy rendelési tábla ügyfélazonosítóját).
• A particionáláshoz használt mezőkre nem lehet Z-sorrendet rendelni.

Ha a partíciók olyan rosszak, miért használják az Azure Databricks egyes funkciói?

A partíciók előnyösek lehetnek, különösen a nagyon nagy táblák esetében. A particionálás számos teljesítménybeli fejlesztése a nagyon nagy (több száz terabájtos vagy nagyobb) táblákra összpontosít.

Számos ügyfél parquet-alapú adattóból migrál a Delta Lake-be. Az CONVERT TO DELTA utasítás lehetővé teszi egy meglévő Parquet-alapú tábla deltatáblává alakítását a meglévő adatok újraírása nélkül. Ezért sok ügyfél nagy táblával rendelkezik, amelyek öröklik a korábbi particionálási stratégiákat. A Databricks által kifejlesztett egyes optimalizálások lehetőség szerint ezeket a partíciókat próbálják kihasználni, ami enyhíti a Delta Lake-hez nem optimalizált particionálási stratégiák lehetséges hátrányait.

A Delta Lake és az Apache Spark nyílt forráskódú technológiák. Bár a Databricks továbbra is olyan funkciókat vezet be, amelyek csökkentik a particionálásra való támaszkodást, a nyílt forráskód közösség továbbra is új, összetettséget csökkentő funkciókat építhet ki.

Túlléphető az Azure Databricks beépített optimalizálása egyéni particionálással?

Az Apache Spark és a Delta Lake néhány tapasztalt felhasználója olyan mintát tervezhet és implementálhat, amely jobb teljesítményt nyújt, mint a betöltési idő fürtözése. A rossz particionálási állapot implementálása nagyon negatív hatással lehet az alsóbb rétegbeli teljesítményre, és az adatok teljes újraírását igényelheti a javításhoz. A Databricks azt javasolja, hogy a felhasználók többsége használja az alapértelmezett beállításokat, hogy elkerülje a költséges hatékonysági problémákat.