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

A nem használt adatfájlok eltávolítása vákuummal

  • Cikk

A prediktív optimalizálás automatikusan fut VACUUM a Unity Catalog által felügyelt táblákon. A Databricks azt javasolja, hogy minden Unity Catalog által felügyelt tábla esetében engedélyezze a prediktív optimalizálást az adatkarbantartás egyszerűsítése és a tárolási költségek csökkentése érdekében. Lásd a Delta Lake prediktív optimalizálása című témakört.

A tábla parancsának futtatásával VACUUM eltávolíthatja a megőrzési küszöbértéknél régebbi Delta-tábla által már nem hivatkozott adatfájlokat. A rendszeres futtatás VACUUM a költségek és a megfelelőség szempontjából a következő szempontok miatt fontos:

  • A nem használt adatfájlok törlése csökkenti a felhőbeli tárolási költségeket.
  • Az eltávolított VACUUM adatfájlok olyan rekordokat tartalmazhatnak, amelyeket módosítottak vagy töröltek. Ezeknek a fájloknak a felhőbeli tárolóból való végleges eltávolítása biztosítja, hogy ezek a rekordok többé nem lesznek elérhetők.

Kikötések a vákuumhoz

Az adatfájlok alapértelmezett megőrzési küszöbértéke a futtatás VACUUM után 7 nap. Ennek a viselkedésnek a módosításához tekintse meg az időutazási lekérdezések adatmegőrzésének konfigurálását.

VACUUM az összes fájl eltávolítását követően üres könyvtárakat hagyhat hátra. A későbbi VACUUM műveletek törlik ezeket az üres könyvtárakat.

A Databricks prediktív optimalizálást javasol a Delta-táblák automatikus futtatásához VACUUM . Lásd a Delta Lake prediktív optimalizálása című témakört.

Egyes Delta Lake-funkciók metaadatfájlokkal jelölik meg az adatokat töröltként az adatfájlok újraírása helyett. Ezeket a törléseket véglegesítheti, és átírhatja REORG TABLE ... APPLY (PURGE) az adatfájlokat. Lásd: Csak metaadatok törlése az adatok újraírásának kényszerítéséhez.

Fontos

  • A Databricks Runtime 13.3 LTS-ben és újabb VACUUM verziókban a Unity Catalog által felügyelt táblákkal rendelkező sekély klónok szemantikája eltér a többi Delta-táblától. Lásd: Vacuum és Unity Catalog sekély klónok.
  • VACUUMEltávolítja az összes fájlt a Delta Lake által nem felügyelt könyvtárakból, figyelmen kívül hagyva a kezdő vagy .a _ . Ha további metaadatokat, például strukturált streamelési ellenőrzőpontokat tárol egy Delta táblakönyvtárban, használjon például _checkpointsegy könyvtárnevet.
  • A megőrzési időnél régebbi táblaverziók lekérdezésének képessége a futtatás VACUUMután elveszik.
  • A naplófájlok automatikusan és aszinkron módon törlődnek az ellenőrzőpont-műveletek után, és azokra nem vonatkoznak VACUUM. Bár a naplófájlok alapértelmezett megőrzési ideje 30 nap, a táblán való futtatás VACUUM eltávolítja az időutazáshoz szükséges adatfájlokat.

Feljegyzés

Ha engedélyezve van a lemez gyorsítótárazása, előfordulhat, hogy egy fürt olyan Parquet-fájlokból származó adatokat tartalmaz, amelyek a következővel VACUUMlettek törölve: . Ezért előfordulhat, hogy lekérdezhető azoknak a korábbi táblaverzióknak az adatai, amelyek fájljait törölték. A fürt újraindítása eltávolítja a gyorsítótárazott adatokat. Lásd : A lemezgyorsítótár konfigurálása.

Példa a vákuum szintaxisára

VACUUM eventsTable   -- vacuum files not required by versions older than the default retention period

VACUUM '/data/events' -- vacuum files in path-based table

VACUUM delta.`/data/events/`

VACUUM delta.`/data/events/` RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

VACUUM eventsTable DRY RUN    -- do dry run to get the list of files to be deleted

A Spark SQL szintaxisának részleteiért lásd: VÁKUUM.

A Scala, a Java és a Python szintaxisának részleteit a Delta Lake API dokumentációjában találja.

Feljegyzés

RETAIN A kulcsszóval megadhatja az adatfájl eltávolításának megállapításához használt küszöbértéket. A VACUUM parancs ezzel a küszöbértékgel visszatekint a megadott időmennyiségre, és azonosítja az adott pillanatban a legújabb táblaverziót. A Delta megőrzi az adott táblaverzió és az összes újabb táblaverzió lekérdezéséhez szükséges összes adatfájlt. Ez a beállítás más táblatulajdonságokkal is együttműködik. Lásd: Adatmegőrzés konfigurálása időutazásos lekérdezésekhez.

Csak metaadat-törlések törlése az adatok újraírásának kényszerítéséhez

A REORG TABLE parancs szintaxist biztosít az APPLY (PURGE) adatok újraírásához a helyreállítható törlések alkalmazásához. A helyreállítható törlések nem írnak át adatokat és nem törölnek adatfájlokat, hanem metaadatfájlok használatával jelzik, hogy egyes adatértékek megváltoztak. Lásd: REORG TABLE.

A Helyreállítható törléseket a Delta Lake-ben létrehozó műveletek közé tartoznak a következők:

Ha engedélyezve van a helyreállítható törlés, előfordulhat, hogy a régi adatok fizikailag megmaradnak a tábla aktuális fájljaiban, még az adatok törlése vagy frissítése után is. Ha fizikailag el szeretné távolítani ezeket az adatokat a táblából, hajtsa végre az alábbi lépéseket:

  1. Futtassa az REORG TABLE ... APPLY (PURGE) parancsot. Ezt követően a régi adatok már nem szerepelnek a táblázat aktuális fájljaiban, de továbbra is megtalálhatók az időutazáshoz használt régebbi fájlokban.
  2. Futtassa VACUUM a régebbi fájlok törlését.

REORG TABLE a művelet befejeződése után létrehozza a tábla új verzióját. A tranzakció előtti előzmények összes táblaverziója régebbi adatfájlokra hivatkozik. Elméletileg ez hasonló a parancshoz, ahol az OPTIMIZE adatfájlok újraírása akkor is történik, ha az aktuális táblaverzió adatai konzisztensek maradnak.

Fontos

Az adatfájlok csak akkor törlődnek, ha a fájlok a megőrzési VACUUM időszaknak megfelelően lejártak. Ez azt jelenti, hogy a VACUUM régebbi fájlok lejártát követő REORG késéssel kell elvégezni. A megőrzési VACUUM időtartam csökkenthető a szükséges várakozási idő lerövidítése érdekében, a megtartott előzmények maximális számának csökkentése érdekében.

Milyen méretű fürtre van szüksége a vákuumnak?

A megfelelő fürtméret VACUUMkiválasztásához segít megérteni, hogy a művelet két fázisban történik:

  1. A feladat azzal kezdődik, hogy az összes elérhető végrehajtó csomópontot használja a forráskönyvtárban lévő fájlok párhuzamos listázásához. Ezt a listát összehasonlítjuk a Delta tranzakciónaplójában jelenleg hivatkozott összes fájllal a törölni kívánt fájlok azonosításához. Ez idő alatt a sofőr tétlenül ül.
  2. Az illesztő ezután a törölni kívánt fájlok törlési parancsaival foglalkozik. A fájltörlés csak illesztőprogram-művelet, ami azt jelenti, hogy minden művelet egyetlen csomóponton történik, miközben a feldolgozó csomópontok tétlenül ülnek.

A költségek és a teljesítmény optimalizálása érdekében a Databricks a következőket javasolja, különösen a hosszú ideig futó vákuumfeladatok esetében:

  • Futtasson vákuumot egy 1-4 feldolgozóhoz készült automatikus méretezési készlettel rendelkező fürtön, ahol minden feldolgozó 8 maggal rendelkezik.
  • Válasszon egy 8 és 32 mag közötti illesztőprogramot. Növelje az illesztőprogram méretét a memóriahiányos (OOM) hibák elkerülése érdekében.

Ha VACUUM a műveletek rendszeresen törölnek több mint 10 ezer fájlt, vagy több mint 30 perc feldolgozási időt vesznek igénybe, érdemes lehet növelni az illesztőprogram méretét vagy a feldolgozók számát.

Ha úgy találja, hogy a lassulás az eltávolítandó fájlok azonosítása közben következik be, adjon hozzá további feldolgozó csomópontokat. Ha a lassulás a törlési parancsok futtatása közben következik be, próbálja meg növelni az illesztőprogram méretét.

Milyen gyakran kell vákuumot futtatni?

A Databricks azt javasolja, hogy rendszeresen fusson VACUUM minden táblán a felhőbeli adattárolás többletköltségeinek csökkentése érdekében. A vákuum alapértelmezett megőrzési küszöbértéke 7 nap. A magasabb küszöbérték beállításával nagyobb előzményekhez férhet hozzá a táblához, de növeli a tárolt adatfájlok számát, és ennek következtében a felhőszolgáltató nagyobb tárolási költségekkel jár.

Miért nem lehet kis megőrzési küszöbértékkel rendelkező Delta-táblázatot porszívózni?

Figyelmeztetés

Javasoljuk, hogy legalább 7 napos megőrzési időközt állítson be, mert a régi pillanatképeket és a nem véglegesített fájlokat továbbra is használhatják az egyidejű olvasók vagy írók a táblához. Ha VACUUM eltávolítja az aktív fájlokat, az egyidejű olvasók meghibásodhatnak, vagy rosszabb esetben a táblák megsérülhetnek, ha VACUUM törli a még nem véglegesített fájlokat. Olyan időközt kell választania, amely hosszabb, mint a leghosszabb ideig futó egyidejű tranzakció, és azt a leghosszabb időtartamot, amelyig bármely stream késhet a tábla legutóbbi frissítéséhez képest.

A Delta Lake biztonsági ellenőrzéssel megakadályozza, hogy veszélyes VACUUM parancsot futtasson. Ha biztos abban, hogy ezen a táblán nem hajtanak végre olyan műveleteket, amelyek a megadott megőrzési időköznél hosszabb időt vesznek igénybe, kikapcsolhatja ezt a biztonsági ellenőrzést a Spark konfigurációs tulajdonságának spark.databricks.delta.retentionDurationCheck.enabledfalsebeállításával.

Naplózási információk

VACUUM A Delta tranzakciónaplóba való véglegesítések naplózási információkat tartalmaznak. A naplózási eseményeket a következővel DESCRIBE HISTORYkérdezheti le: .