Automatikus betöltő konfigurálása éles üzemi munkaterhelésekhez

Az automatikus betöltő beállításával kapcsolatos átfogó ajánlott eljárásokért, beleértve a fájlfelderítési mód kiválasztását, a sémakezelést és az adatminőség-kezelést, tekintse meg az Automatikus betöltő ajánlott eljárásait.

A Databricks az Automatikus betöltő használatát javasolja a Lakeflow-folyamatokban a növekményes adatbetöltéshez. A Lakeflow-folyamatok kibővítik az Apache Spark strukturált streamelési funkcióit, és lehetővé teszik néhány sor deklaratív Python vagy SQL írását egy éles minőségű adatfolyam üzembe helyezéséhez a következőkkel:

A Databricks azt is javasolja, hogy kövesse az Auto Loader futtatására vonatkozó ajánlott streamelési gyakorlatokat a production környezetben. Lásd a strukturált streameléssel kapcsolatos gyártási megfontolások.

Note

A Lakeflow pipeline-ok jelentik az Auto Loader futtatásának ajánlott módját a legtöbb éles környezeti adatbeolvasás esetén. Ha a munkaterhelésnek nincsenek alacsony késleltetési követelményei, és az elsődleges szempont a számítási költségek minimalizálása, akkor az Auto Loadert ehelyett triggerelt kötegelt feladatként is ütemezheti, amely a(z) Trigger.AvailableNow használja. Lásd a költséggel kapcsolatos szempontokat.

Automatikus betöltő figyelése

A következő szakaszok bemutatják, hogyan monitorozható az Auto Loader éles környezetben, beleértve a metrikákat, naplókat, riasztásokat és a gyakori hibaelhárítási munkafolyamatokat. Az irányítópult-mintákra, a késéselemzésre és a sémaeltérések észlelésére vonatkozó átfogó referenciaért tekintse meg az Automatikus betöltő figyelése és megfigyelése című témakört.

Az automatikus betöltő által felderített fájlok lekérdezése

Az Automatikus betöltő egy SQL API-t biztosít a stream állapotának vizsgálatához. A cloud_files_state függvény használatával metaadatokat talál az automatikus betöltő stream által felderített fájlokról. Lekérdezés cloud_files_state, amely megadja az automatikus betöltő streamhez társított ellenőrzőpont-helyet.

Note

A cloud_files_state függvény a Databricks Runtime 11.3 LTS-ben és újabb verziókban érhető el.

SELECT * FROM cloud_files_state('path/to/checkpoint');

Streamfrissítések figyelése

Az automatikus betöltő streamek további figyeléséhez a Databricks az Apache Spark Stream Query Listener felületének használatát javasolja. Lásd Azure Databricks Structured Streaming lekérdezések figyelése.

Az Automatikus betöltő minden kötegben jelentést készít a streamelési lekérdezés figyelőjének. Megtekintheti, hogy hány fájl található a hátralékban, és hogy mekkora a hátralék a numFilesOutstanding fül alatt található streamelési lekérdezés előrehaladási irányítópultján, a numBytesOutstanding és metrikákban:

{
  "sources": [
    {
      "description": "CloudFilesSource[/path/to/source]",
      "metrics": {
        "numFilesOutstanding": "238",
        "numBytesOutstanding": "163939124006"
      }
    }
  ]
}

Ha a Databricks Runtime 10.4 LTS vagy újabb verziójában a fájlértesítési módot használja, a metrikák az AWS és Azure felhő üzenetsorában található fájlesemények hozzávetőleges számát is tartalmazzák approximateQueueSize.

Költségekkel kapcsolatos szempontok

Az automatikus betöltő futtatásakor a fő költségforrások a számítási erőforrások és a fájlfelderítés.

Ha a munkaterhelésnek nincsenek alacsony késleltetési követelményei, csökkentheti a számítási költségeket, ha a Lakeflow Jobs használatával az Auto Loadert kötegelt feladatként ütemezi a(z) Trigger.AvailableNow használatával a folyamatos futtatás helyett. Lásd: Strukturált streamelési eseményindítók időközeinek konfigurálása. Ezek a kötegfeladatok fájlérkezés-eseményindítókkal aktiválhatók, hogy tovább csökkentsük a fájl érkezése és feldolgozása közötti késést.

A fájlfelderítési költségek felmerülhetnek LIST műveletek formájában tárfiókokon könyvtárlistázási módban, illetve API-kérések formájában az előfizetési szolgáltatásban, valamint az üzenetsor-szolgáltatásban fájlértesítő módban. A folyamatos eseményindítók, például Trigger.ProcessingTime különösen drágák a címtár-lista módban, mivel az Automatikus betöltő folyamatosan listázza a teljes könyvtárat az új fájlok megkereséséhez. Ha a számítási feladat folyamatos eseményindítókat igényel, a Databricks a késési követelményeknek megfelelően javasolja a fájlfelderítési mód kiválasztását:

  • Kis késés és egyszerűség: Az Automatikus betöltő használata fájleseményekkel. A fájleseményekhez tárolónként csak egy sor szükséges, és a későbbi futtatások során inkrementális felderítést használnak. További információkért lásd: Az Auto Loader áttekintése fájleseményekkel.
  • Nagyon késésre érzékeny alkalmazások: Használjon klasszikus fájlértesítési módot. A klasszikus mód közvetlenül a felhőbeli üzenetsorból olvassa be a fájlesemények által bevezetett további gyorsítótárazási ugrás nélkül. Ebben a módban címkézheti az Automatikus betöltő által létrehozott erőforrásokat a költségek erőforráscímkék használatával történő nyomon követéséhez. Részletekért lásd: Fájlértesítés.

Forrásadatok megőrzése

Note

A Databricks Runtime 16.4 LTS-ben és újabb verziókban érhető el.

Ahogy a fájlok halmozódnak fel a forráskönyvtárban, a tárolási költségek növekednek, és a fájlfelderítés lelassul, különösen címtár-lista módban. Az Automatikus betöltő lehetővé teszi a cloudFiles.cleanSource fájlok megőrzésének automatikus kezelését a fájlok archiválásával vagy törlésével a feldolgozásuk után.

Fájlok archiválása a forráskönyvtárban a költségek csökkentése érdekében

Warning

  • A beállítás cloudFiles.cleanSource törli vagy áthelyezi a fájlokat a forráskönyvtárban.
  • Ha az adatfeldolgozáshoz használja foreachBatch, a fájlok azonnal áthelyezési vagy törlési jelöltté válnak, amint a foreachBatch művelet sikerrel teljesül, még akkor is, ha a művelet csak a köteg egyes fájljait használta fel.

A Databricks az Auto Loader használatát javasolja fájleseményekkel a felderítési költségek csökkentése érdekében. Ez csökkenti a számítási költségeket is, mivel a felderítés növekményes.

Ha nem tudja használni a fájleseményeket, és a fájlok felderítéséhez címtárlistát kell használnia, a beállítással automatikusan archiválhatja vagy törölheti a cloudFiles.cleanSource fájlokat, miután az Automatikus betöltő feldolgozza őket a felderítési költségek csökkentése érdekében. Mivel az Automatikus betöltő a feldolgozás után törli a fájlokat a forráskönyvtárból, kevesebb fájlt kell listázni a felderítés során.

Amikor a cloudFiles.cleanSource-t használja a MOVE opcióval, vegye figyelembe a következő követelményeket:

  • A forráskönyvtárnak és az áthelyezési célkönyvtárnak is ugyanazon a külső helyen, köteten vagy DBFS-csatoláson kell lennie. A vödrök közötti és tartályok közötti áthelyezések nem támogatottak, és hibát okoznak.
  • Az áthelyezési cél lehet egy kötet útvonala (például /Volumes/my_catalog/my_schema/my_volume/archive/).
  • Ha a forrás- és célkönyvtár ugyanabban a külső helyen található, akkor nem lehetnek felügyelt tárakat (például felügyelt kötetet vagy katalógust) tartalmazó testvérkönyvtárak. Ezekben az esetekben az Automatikus betöltő nem tudja lekérni a célkönyvtárba való íráshoz szükséges engedélyeket.

A Databricks a következő esetekben javasolja ezt a lehetőséget:

  • A forráskönyvtár sok fájlt halmoz fel az idő során.
  • A feldolgozott fájlokat meg kell őriznie a megfelelőség vagy a naplózás érdekében (beállítás: cloudFiles.cleanSourceMOVE).
  • A tárolási költségeket úgy szeretné csökkenteni, hogy eltávolítja a fájlokat a betöltés után (a beállítás értéke cloudFiles.cleanSourceDELETE). < c0 /> mód használatakor a Databricks javasolja a verziókezelés engedélyezését a tárolóban, hogy az Auto Loader törlések puha törlésként működjenek, és téves konfiguráció esetén elérhetők legyenek. Ezenkívül a Databricks azt javasolja, hogy a helyreállítási követelmények alapján állítson be felhőbeli életciklus-szabályzatokat a régi, helyreállíthatóan törölt verziók törléséhez egy megadott türelmi időszak (például 60 vagy 90 nap) után.

Az opciók és az alapértelmezett beállítások teljes körű megismerésére cleanSourcelásd: Feldolgozott fájlok tisztítása automatikus betöltővel.

Feldolgozott fájlok áthelyezése hideg tárolási útvonalra

Az alábbi példa úgy konfigurálja az Auto Loadert, hogy a feldolgozott fájlokat 14 nap elteltével ugyanabban a tárolóban helyezze át egy archív könyvtárba. Alkalmazhatja a felhő életciklus-szabályzatot az archív útvonalakon, hogy az állományokat olcsóbb tárolási szintekre átvigyék (például AWS S3 Glacier, Azure Cool/Archive vagy GCS Coldline/Archive).

Python

# Step 1: Configure Auto Loader to move processed files to an archive path.
checkpoint = "/Volumes/my_catalog/my_schema/my_volume/checkpoints/ingest_stream"
archive_path = "s3://my-bucket/archive/landing/"

df = (spark.readStream.format("cloudFiles")
  .option("cloudFiles.format", "json")
  .option("cloudFiles.cleanSource", "MOVE")
  .option("cloudFiles.cleanSource.moveDestination", archive_path)
  .option("cloudFiles.cleanSource.retentionDuration", "14 days")
  .option("cloudFiles.schemaLocation", checkpoint)
  .load("s3://my-bucket/landing/")
)

# Step 2: Write to a Delta table.
(df.writeStream
  .option("checkpointLocation", checkpoint)
  .trigger(availableNow=True)
  .toTable("my_catalog.my_schema.raw_events")
)

# Step 3 (outside Databricks): Set up a cloud lifecycle policy on the
# archive path to transition files to cold storage after a grace period.
# For example, in AWS you can configure an S3 Lifecycle rule to move
# objects under s3://my-bucket/archive/landing/ to S3 Glacier after
# 30 days.

SQL

-- Step 1: Configure Auto Loader to move processed files to an archive path
-- using a Lakeflow Declarative Pipeline.
CREATE OR REFRESH STREAMING TABLE raw_events
AS SELECT * FROM STREAM read_files(
  's3://my-bucket/landing/',
  format => 'json',
  cleanSource => 'MOVE',
  `cleanSource.moveDestination` => 's3://my-bucket/archive/landing/',
  `cleanSource.retentionDuration` => '14 days'
);

-- Step 2 (outside Databricks): Set up a cloud lifecycle policy on the
-- archive path to transition files to cold storage.
-- For example, in AWS configure an S3 Lifecycle rule to move objects
-- under s3://my-bucket/archive/landing/ to S3 Glacier after 30 days.

A Trigger.AvailableNow és a sebességkorlátozás használata

Note

A Databricks Runtime 10.4 LTS-ben és újabb verziókban érhető el.

Az automatikus betöltő ütemezhető úgy, hogy a Lakeflow-feladatokban kötegelt feladatként fusson a használatával Trigger.AvailableNow. Az AvailableNow eseményindító utasítja az Automatikus betöltőt, hogy dolgozza fel a lekérdezés kezdési időpontja előtt érkezett összes fájlt. A stream indítása után érkező új fájlokat a rendszer a következő eseményindítóig figyelmen kívül hagyja.

A Trigger.AvailableNowfájlfelderítés aszinkron módon történik az adatfeldolgozással, és az adatok több, sebességkorlátozással rendelkező mikro kötegben is feldolgozhatók. Az automatikus betöltő alapértelmezés szerint mikrokötegenként legfeljebb 1000 fájlt dolgoz fel. Konfigurálhatja cloudFiles.maxFilesPerTrigger és cloudFiles.maxBytesPerTrigger konfigurálhatja, hogy hány fájlt vagy hány bájtot kell feldolgozni egy mikrokötegben. A fájlkorlát egy szigorú korlát, de a bájtkorlát egy rugalmas korlát, ami azt jelenti, hogy több bájt dolgozható fel, mint a megadott maxBytesPerTrigger. Ha a beállítások egyszerre vannak megadva, az Automatikus betöltő annyi fájlt dolgoz fel, amennyi a korlátok egyikének eléréséhez szükséges.

Ellenőrzőpont helye

Az ellenőrzőpont helye a stream állapot- és folyamatinformációinak tárolására szolgál. A Databricks azt javasolja, hogy az ellenőrzőpont helyét felhőobjektum-életciklus-szabályzat nélküli helyre állítsa. Ha az ellenőrzőpont helyén lévő fájlok a szabályzatnak megfelelően vannak megtisztítva, a stream állapota sérült. Ha ez történik, újra kell indítania a streamet az alapoktól.

Fájlesemények nyomon követése

Az Automatikus betöltő nyomon követi a felderített fájlokat az ellenőrzőpont helyén a RocksDB használatával, hogy pontosan egyszeri betöltési garanciákat biztosítson. Nagy mennyiségű vagy hosszú élettartamú betöltési streamek esetén a Databricks azt javasolja, hogy frissítsen a Databricks Runtime 15.4 LTS vagy újabb verziójára. Ezekben a verziókban az Automatikus betöltő nem várja meg a teljes RocksDB-állapot letöltését a stream elindítása előtt, ami felgyorsíthatja a stream indítási idejét. Ha meg szeretné akadályozni, hogy a fájlállapotok korlátok nélkül növekedjenek, érdemes lehet egy bizonyos kornál régebbi fájlesemények lejáratát is elvégezni cloudFiles.maxFileAge . A cloudFiles.maxFileAge-ra megadható minimális érték "14 days". A RocksDB-beli törlések sírköves bejegyzésként jelennek meg. Ezért előfordulhat, hogy a tárterület kihasználtsága átmenetileg növekedni fog, ahogy az események lejárnak, mielőtt elkezd stabilizálódni.

Warning

cloudFiles.maxFileAge a nagy mennyiségű adathalmazok költségszabályozási mechanizmusaként érhető el. A túl agresszív hangolás cloudFiles.maxFileAge adatminőségi problémákat, például duplikált betöltést vagy hiányzó fájlokat okozhat. Ezért a Databricks egy konzervatív beállítást cloudFiles.maxFileAgejavasol , például 90 napig, ami hasonló ahhoz, amit az összehasonlítható adatbetöltési megoldások javasolnak.

A beállítás finomhangolása azt eredményezheti, hogy az cloudFiles.maxFileAge automatikus betöltő figyelmen kívül hagyja a feldolgozatlan fájlokat, vagy a már feldolgozott fájlok lejárnak, majd újra feldolgozzák, ami ismétlődő adatokat okoz. Az alábbiakat érdemes figyelembe venni egy cloudFiles.maxFileAge választásakor:

  • Ha a stream hosszú idő után újraindul, a rendszer figyelmen kívül hagyja azokat a fájlértesítési eseményeket, amelyeket az üzenetsorból cloudFiles.maxFileAge időnél régebben kértek le. Hasonlóképpen, ha címtárlistát használ, a leállás ideje alatt megjelent, cloudFiles.maxFileAge-nél régebbi fájlokat figyelmen kívül hagyják.
  • Ha címtár-listázási módot használ, és cloudFiles.maxFileAge(például "1 month") használja, állítsa le a streamet, és indítsa újra a streamet cloudFiles.maxFileAge"2 months"beállítással, az 1 hónapnál régebbi, de 2 hónapnál frissebb fájlok újra feldolgozásra kerülnek.

Ha ezt a beállítást a stream első indításakor állítja be, akkor a cloudFiles.maxFileAge-nél régebbi adatokat nem fogja betölteni, ezért ha régi adatokat szeretne befogni, ne állítsa be ezt a beállítást a stream első indításakor. Ezt a beállítást azonban a későbbi futtatásokhoz kell beállítania.

Rendszeres visszatöltések aktiválása a cloudFiles.backfillInterval használatával

Ritkán előfordulhat, hogy a fájlok kimaradnak vagy késnek, ha csak az értesítési rendszerektől függenek, például amikor elérik az értesítési üzenetek adatmegőrzési korlátait. Ha szigorú követelmények vonatkoznak az adatok teljességére és az SLA-ra, fontolja meg cloudFiles.backfillInterval az aszinkron visszatöltések meghatározott időközönként történő aktiválását. Beállíthatja például egy napra a napi utántöltések esetében, vagy egy hétre a heti utántöltések esetében. A normál visszatöltések aktiválása nem okoz duplikációkat.

Fájlesemények használatakor legalább 7 naponta futtassa a streamet

Fájlesemények használatakor legalább 7 naponta futtassa az Auto Loader streameket, hogy elkerülje a teljes könyvtárlistázást. Az automatikus betöltő streamjeinek ilyen gyakran történő futtatása biztosítja a fájlfelderítés növekményes működését.

A felügyelt fájlesemények átfogó ajánlott eljárásaiért tekintse meg a fájleseményekkel rendelkező automatikus betöltő ajánlott eljárásait.

  • Last updated on