Megosztás a következőn keresztül:

Ajánlott eljárások: Delta Lake

  • Cikk

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 Delta Lake prediktív optimalizálása című témakört.

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 VACUUM parancsokat futtat OPTIMIZE a Unity Catalog által felügyelt táblákon. Lásd a Delta Lake prediktív optimalizálása című témakört.

A Databricks azt javasolja, hogy a kis méretű fájlok tömörítéséhez gyakran futtassa az 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 VÁKUUM 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 \
  .format("delta") \
  .mode("overwrite") \
  .option("overwriteSchema", "true") \
  .saveAsTable("<your-table>") # Managed table

dataframe.write \
  .format("delta") \
  .mode("overwrite") \
  .option("overwriteSchema", "true") \
  .option("path", "<your-table-path>") \
  .saveAsTable("<your-table>") # External table

SQL

REPLACE TABLE <your-table> USING DELTA AS SELECT ... -- Managed table
REPLACE TABLE <your-table> USING DELTA LOCATION "<your-table-path>" AS SELECT ... -- External table

Scala

dataframe.write
  .format("delta")
  .mode("overwrite")
  .option("overwriteSchema", "true")
  .saveAsTable("<your-table>") // Managed table

dataframe.write
  .format("delta")
  .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 működése.
  • 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 DataFramehelyezett 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ásra REFRESH 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 MSCKa .ALTER TABLE [ADD|DROP] PARTITION
  • 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ékot WHERE az adatok kihagyására, például spark.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ás merge 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, amely country particionált, és date 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ója spark.sql.shuffle.partitionsszabá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.

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.writeStatsAsStructa . Ha mindkét táblatulajdonság az, a falseDelta Lake nem hajthat végre adatkiugrást.

  • A Batch JSON és struct formátumban is ír statisztikát. delta.checkpoint.writeStatsAsJson az true.
  • 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.writeStatsAsJsonfalse 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>|delta.`<path-to-table>`] 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>|delta.`<path-to-table>`] 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.