A Delta Lake ajánlott eljárásai
Ez a cikk a Delta Lake használatakor ajánlott eljárásokat ismerteti.
A Databricks prediktív optimalizálás használatát javasolja. Lásd: A Unity Catalog által felügyelt táblák prediktív optimalizálása.
Ha ugyanazon a helyen töröl és újra egy táblát, mindig használjon utasítást CREATE OR REPLACE TABLE
. Lásd: Delta-tábla elvetése vagy cseréje.
Régi Delta-konfigurációk eltávolítása
A Databricks azt javasolja, hogy az új Databricks Runtime-verzióra való frissítéskor távolítsa el a leg explicitebb örökölt Delta-konfigurációkat a Spark-konfigurációkból és a táblatulajdonságokból. Az örökölt konfigurációk megakadályozhatják a Databricks által bevezetett új optimalizálásokat és alapértelmezett értékeket a migrált számítási feladatokra.
Folyékony fürtözés használata optimalizált adatkiugráshoz
A Databricks azt javasolja, hogy particionálás, Z-sorrend vagy más adatszervezési stratégiák helyett használjon folyékony fürtözést az adatelrendezés optimalizálásához az adatkiugráshoz. Lásd: Folyékony fürtözés használata Delta-táblákhoz.
Fájlok tömörítése
A prediktív optimalizálás automatikusan fut és OPTIMIZE
parancsokat futtat VACUUM
a Unity Catalog által felügyelt táblákon. Lásd: A Unity Catalog által felügyelt táblák prediktív optimalizálása.
A Databricks azt javasolja, hogy a kis méretű fájlok tömörítéséhez gyakran futtassa a OPTIMIZE parancsot.
Feljegyzés
Ez a művelet nem távolítja el a régi fájlokat. Az eltávolításukhoz futtassa a VACUUM parancsot.
Tábla tartalmának vagy sémájának cseréje
Előfordulhat, hogy egy Delta-táblát szeretne lecserélni. Példa:
- Felfedezheti, hogy a táblában lévő adatok helytelenek, és lecserélik a tartalmat.
- A teljes táblát át szeretné írni a nem kompatibilis sémamódosítások (például az oszloptípusok módosítása) érdekében.
Bár törölheti egy Delta-tábla teljes könyvtárát, és létrehozhat egy új táblát ugyanazon az útvonalon, ez nem ajánlott, mert:
- A címtár törlése nem hatékony. A nagyon nagy fájlokat tartalmazó címtárak törlése órákig vagy akár napokig is eltarthat.
- A törölt fájlokban lévő összes tartalom elveszik; nehéz helyreállítani, ha nem a megfelelő táblát törli.
- A címtár törlése nem atomi. A tábla törlése közben a táblát olvasó egyidejű lekérdezés meghiúsulhat, vagy részleges táblázat jelenhet meg.
Ha nem kell módosítania a táblázatsémát, törölheti az adatokat egy Delta-táblából, és beszúrhatja az új adatokat, vagy frissítheti a táblát a helytelen értékek kijavítása érdekében.
Ha módosítani szeretné a táblázatsémát, a teljes táblázatot atomilag lecserélheti. Példa:
Python
dataframe.write \
.mode("overwrite") \
.option("overwriteSchema", "true") \
.saveAsTable("<your-table>") # Managed table
dataframe.write \
.mode("overwrite") \
.option("overwriteSchema", "true") \
.option("path", "<your-table-path>") \
.saveAsTable("<your-table>") # External table
SQL
REPLACE TABLE <your-table> AS SELECT ... -- Managed table
REPLACE TABLE <your-table> LOCATION "<your-table-path>" AS SELECT ... -- External table
Scala
dataframe.write
.mode("overwrite")
.option("overwriteSchema", "true")
.saveAsTable("<your-table>") // Managed table
dataframe.write
.mode("overwrite")
.option("overwriteSchema", "true")
.option("path", "<your-table-path>")
.saveAsTable("<your-table>") // External table
Ennek a megközelítésnek több előnye is van:
- A táblák felülírása sokkal gyorsabb, mert nem kell rekurzív módon listáznia a könyvtárat, és nem kell fájlokat törölnie.
- A tábla régi verziója továbbra is létezik. Ha nem a megfelelő táblát törli, az időutazással egyszerűen lekérheti a régi adatokat. Lásd: A Delta Lake-táblaelőzmények használata.
- Ez egy atomi művelet. Az egyidejű lekérdezések továbbra is elolvashatják a táblát a tábla törlésekor.
- A Delta Lake ACID tranzakciós garanciái miatt, ha a tábla felülírása meghiúsul, a tábla az előző állapotában lesz.
Ezenkívül ha régi fájlokat szeretne törölni, hogy a tábla felülírása után tárolási költségeket takarítson meg, a VACUUM használatával törölheti őket. A fájltörléshez van optimalizálva, és általában gyorsabb, mint a teljes könyvtár törlése.
Spark-gyorsítótárazás
A Databricks nem javasolja a Spark-gyorsítótárazást az alábbi okokból:
- Elveszíti az adatátugrásokat, amelyek a gyorsítótárba
DataFrame
helyezett további szűrőkből származhatnak. - Előfordulhat, hogy a gyorsítótárazott adatok nem frissülnek, ha a tábla más azonosítóval érhető el.
Különbségek a Delta Lake és a Parquet között az Apache Sparkon
A Delta Lake automatikusan kezeli a következő műveleteket. Ezeket a műveleteket soha ne hajtsa végre manuálisan:
-
REFRESH TABLE
: A deltatáblák mindig a legfrissebb információkat adják vissza, így a módosítások után nincs szükség manuálisan a hívásraREFRESH TABLE
. -
Partíciók hozzáadása és eltávolítása: A Delta Lake automatikusan nyomon követi a táblázatban található partíciókat, és frissíti a listát az adatok hozzáadásakor vagy eltávolításakor. Ennek eredményeképpen nincs szükség a futtatásra vagy
ALTER TABLE [ADD|DROP] PARTITION
a .MSCK
-
Egyetlen partíció betöltése: A partíciók közvetlen olvasása nem szükséges. Például nem kell futtatnia
spark.read.format("parquet").load("/data/date=2017-01-01")
. Ehelyett használjon egy záradékotWHERE
az adatok kihagyására, példáulspark.read.table("<table-name>").where("date = '2017-01-01'")
. - Ne módosítsa manuálisan az adatfájlokat: A Delta Lake a tranzakciónaplóval véglegesíti a módosításokat a táblában. Ne módosítsa, ne vegye fel vagy törölje közvetlenül a Parquet-adatfájlokat egy Delta-táblában, mert ez adatvesztéshez vagy táblasérüléshez vezethet.
A Delta Lake-egyesítés teljesítményének javítása
Az alábbi módszerekkel csökkentheti az egyesítéshez szükséges időt:
Csökkentse az egyezések keresési területét: Alapértelmezés szerint a művelet a
merge
teljes Delta-táblában keres egyezéseket a forrástáblában. A gyorsításmerge
egyik módja a keresési terület csökkentése a találati feltétel ismert megkötéseinek hozzáadásával. Tegyük fel például, hogy van egy táblája, amelycountry
particionált, ésdate
az utolsó napra és egy adott országra vonatkozó információkat szeretnémerge
frissíteni. Az alábbi feltétel hozzáadása gyorsabbá teszi a lekérdezést, mivel csak a megfelelő partíciókban keres egyezéseket:events.date = current_date() AND events.country = 'USA'
Emellett ez a lekérdezés csökkenti az egyéb egyidejű műveletekkel való ütközések esélyét is. További részletekért tekintse meg az elkülönítési szinteket és az Azure Databricks-ütközések írását.
Tömörített fájlok: Ha az adatok sok kis fájlban találhatók, az adatok beolvasása az egyezések kereséséhez lassú lehet. A kis méretű fájlokat nagyobb fájlokba tömörítheti az olvasási sebesség javítása érdekében. Részletekért lásd: Adatfájlelrendezés optimalizálása.
Az írások shuffle partícióinak szabályozása: A
merge
művelet többször is elfojtja az adatokat a frissített adatok kiszámításához és megírásához. Az elosztáshoz használt feladatok számát a Spark-munkamenet konfigurációjaspark.sql.shuffle.partitions
szabályozza. A paraméter beállítása nem csak a párhuzamosságot vezérli, hanem a kimeneti fájlok számát is meghatározza. Az érték növelése növeli a párhuzamosságot, de nagyobb számú kisebb adatfájlt is létrehoz.Optimalizált írások engedélyezése: Particionált táblák esetén sokkal több kis fájlt hozhat létre,
merge
mint a shuffle partíciók száma. Ennek az az oka, hogy minden shuffle-feladat több fájlt is írhat több partícióba, és teljesítménybeli szűk keresztmetszetté válhat. Az optimalizált írások engedélyezésével csökkentheti a fájlok számát. Lásd: Optimalizált írások a Delta Lake-hez az Azure Databricksben.Fájlméretek finomhangolása a táblázatban: Az Azure Databricks képes automatikusan észlelni, hogy egy Delta-tábla gyakran
merge
végez-e átírási műveleteket, és úgy is dönthet, hogy csökkenti az újraírt fájlok méretét, és a jövőben további fájl újraírásokra készül. A részletekért tekintse meg a fájlméretek finomhangolásáról szóló szakaszt.Alacsony sorrendű egyesítés: Az alacsony egyesítési egyesítés optimalizált implementációt
MERGE
biztosít, amely jobb teljesítményt nyújt a leggyakoribb számítási feladatokhoz. Emellett megőrzi a meglévő adatelrendezési optimalizálásokat, például a Z-rendezést a nem módosított adatokon.
Az adatok szavatosságának kezelése
Az egyes lekérdezések elején a Delta-táblák automatikusan frissülnek a tábla legújabb verziójára. Ez a folyamat a jegyzetfüzetekben figyelhető meg, amikor a parancs állapota a következőt jelenti: Updating the Delta table's state
. Ha azonban előzményelemzést futtat egy táblán, előfordulhat, hogy nem feltétlenül van szükség az utolsó percben tárolt adatokra, különösen az olyan táblák esetében, ahol a streamelési adatok gyakran kerülnek betöltésre. Ezekben az esetekben a lekérdezések futtathatók a Delta-tábla elavult pillanatképén. Ez a megközelítés csökkentheti a lekérdezések eredményeinek lekérésével kapcsolatos késést.
Az elavult adatok tűrőképességét úgy konfigurálhatja, hogy a Spark-munkamenet konfigurációját spark.databricks.delta.stalenessLimit
egy idősztring-értékkel, például 1h
vagy 15m
(1 órára vagy 15 percre) állítja be. Ez a konfiguráció munkamenet-specifikus, és nem érinti a táblához hozzáférő többi ügyfelet. Ha a tábla állapota az elavultsági korláton belül lett frissítve, a tábla lekérdezése az eredményeket a legújabb táblafrissítésre való várakozás nélkül adja vissza. Ez a beállítás soha nem akadályozza meg a tábla frissítését, és elavult adatok visszaadásakor a frissítés a háttérben zajlik. Ha az utolsó táblafrissítés régebbi az elavultsági korlátnál, a lekérdezés nem ad vissza eredményeket, amíg a táblaállapot frissítése be nem fejeződik.
Továbbfejlesztett ellenőrzőpontok kis késésű lekérdezésekhez
A Delta Lake az ellenőrzőpontokat egy Delta-tábla összesített állapotaként, optimalizált gyakorisággal írja. Ezek az ellenőrzőpontok kiindulópontként szolgálnak a tábla legújabb állapotának kiszámításához. Ellenőrzőpontok nélkül a Delta Lake-nek egy nagy JSON-fájlgyűjteményt ("delta" fájlokat) kellene olvasnia, amelyek a tranzakciónaplóban véglegesítéseket jelentenek a tábla állapotának kiszámításához. Emellett a Delta Lake oszlopszintű statisztikái az adatkiugrás végrehajtásához az ellenőrzőponton vannak tárolva.
Fontos
A Delta Lake ellenőrzőpontjai eltérnek a strukturált streamelési ellenőrzőpontoktól. Lásd: Strukturált streamelési ellenőrzőpontok.
Az oszlopszintű statisztikák struktúraként és JSON-ként vannak tárolva (a visszamenőleges kompatibilitás érdekében). A strukturálási formátum sokkal gyorsabb olvasást tesz lehetővé a Delta Lake-ben, mert:
- A Delta Lake nem végez költséges JSON-elemzést az oszlopszintű statisztikák beszerzéséhez.
- A parquet oszlopmetsző képességei jelentősen csökkentik az oszlop statisztikáinak olvasásához szükséges I/O-t.
A strukturálási formátum lehetővé teszi olyan optimalizálási műveletek gyűjteményét, amelyek másodpercről több tízezredmásodpercre csökkentik a Delta Lake olvasási műveleteinek többletterhelését, ami jelentősen csökkenti a rövid lekérdezések késését.
Oszlopszintű statisztikák kezelése ellenőrzőpontokban
A statisztikai adatok ellenőrzőpontokban való megírásának módját a táblatulajdonságok delta.checkpoint.writeStatsAsJson
és delta.checkpoint.writeStatsAsStruct
a . Ha mindkét táblatulajdonság az, a false
Delta Lake nem hajthat végre adatkiugrást.
- A Batch JSON és struct formátumban is ír statisztikát.
delta.checkpoint.writeStatsAsJson
aztrue
. -
delta.checkpoint.writeStatsAsStruct
alapértelmezés szerint nincs definiálva. - Az olvasók a struktúra oszlopot használják, ha elérhetőek, és máskülönben visszaesnek a JSON oszlop használatára.
Fontos
A továbbfejlesztett ellenőrzőpontok nem szakítják meg a nyílt forráskód Delta Lake-olvasókkal való kompatibilitást. A beállítás delta.checkpoint.writeStatsAsJson
false
azonban hatással lehet a védett Delta Lake-olvasókra. A teljesítményre gyakorolt hatásokkal kapcsolatban forduljon a szállítókhoz.
Továbbfejlesztett ellenőrzőpontok engedélyezése strukturált streamelési lekérdezésekhez
Ha a strukturált streamelési számítási feladatok nem rendelkeznek alacsony késési követelményekkel (késések csökkentése), a továbbfejlesztett ellenőrzőpontokat a következő SQL-parancs futtatásával engedélyezheti:
ALTER TABLE <table-name> SET TBLPROPERTIES
('delta.checkpoint.writeStatsAsStruct' = 'true')
Az ellenőrzőpont írási késését az alábbi táblázattulajdonságok beállításával is javíthatja:
ALTER TABLE <table-name> SET TBLPROPERTIES
(
'delta.checkpoint.writeStatsAsStruct' = 'true',
'delta.checkpoint.writeStatsAsJson' = 'false'
)
Ha az adatok kihagyása nem hasznos az alkalmazásban, mindkét tulajdonságot beállíthatja hamisra. Ezután a rendszer nem gyűjt vagy ír statisztikákat. A Databricks nem javasolja ezt a konfigurációt.