Strukturált streamelési eseményindító időközeinek konfigurálása
Az Apache Spark strukturált streamelése növekményesen dolgozza fel az adatokat; A kötegelt feldolgozás eseményindító-időközének szabályozásával strukturált streamelést használhat számítási feladatokhoz, beleértve a közel valós idejű feldolgozást, az adatbázisok 5 percenkénti vagy óránkénti frissítését, vagy az összes új adat kötegelt feldolgozását egy napra vagy hétre.
Mivel a Databricks Auto Loader strukturált streamelést használ az adatok betöltéséhez, a triggerek működésének megértése biztosítja a legnagyobb rugalmasságot a költségek szabályozásához, miközben a kívánt gyakorisággal tölti be az adatokat.
Időalapú triggerintervallumok megadása
A strukturált streamelés az időalapú triggerintervallumokat "rögzített időközű mikrokötegekként" jelöli. processingTime A kulcsszó használatával adjon meg egy időtartamot sztringként, például.trigger(processingTime='10 seconds').
Ha túl kicsi (több tíz másodpercnél rövidebb) időközt trigger ad meg, a rendszer szükségtelen ellenőrzéseket végezhet annak ellenőrzésére, hogy új adatok érkeznek-e. Konfigurálja a feldolgozási időt a késési követelmények és a forrásba érkező adatok sebességének kiegyenlítésére.
Növekményes kötegelt feldolgozás konfigurálása
Fontos
A Databricks Runtime 11.3 LTS-ben és újabb verziókban a Trigger.Once beállítás elavult. A Databricks minden növekményes kötegfeldolgozási számítási feladathoz ajánlott használni Trigger.AvailableNow .
A jelenleg elérhető eseményindító beállítás növekményes kötegként használja fel az összes rendelkezésre álló rekordot, és konfigurálhatja a köteg méretét olyan beállításokkal, mint maxBytesPerTrigger például (a méretezési beállítások adatforrásonként eltérőek).
Az Azure Databricks számos strukturált streamforrás növekményes kötegelt feldolgozását támogatja Trigger.AvailableNow . Az alábbi táblázat tartalmazza az egyes adatforrásokhoz szükséges minimálisan támogatott Databricks Runtime-verziót:
| Forrás | A Databricks runtime minimális verziója |
|---|---|
| Fájlforrások (JSON, Parquet stb.) | 9.1 LTS |
| Delta Lake | 10.4 LTS |
| Automatikus betöltő | 10.4 LTS |
| Apache Kafka | 10.4 LTS |
| Kinézis | 13,1 |
Mi az alapértelmezett triggerintervallum?
A strukturált streamelés alapértelmezés szerint rögzített időközű, 500 ms-et tartalmazó mikro kötegekre van beállítva. A Databricks azt javasolja, hogy mindig adjon meg egy testre szabott trigger megoldást annak ellenőrzéséhez, hogy új adatok érkeztek-e, és hogy feldolgozzuk-e az alulméretezett kötegeket.
Az eseményindítók futások közötti időközeinek módosítása
Ugyanazzal az ellenőrzőponttal módosíthatja a futtatások közötti eseményindító-időközt.
Ha egy strukturált streamelési feladat leáll egy mikroköteg feldolgozása közben, a mikro kötegnek be kell fejeződnie az új eseményindító-időköz alkalmazása előtt. Ilyen esetben megfigyelhet egy mikroköteg-feldolgozást a korábban megadott beállításokkal az eseményindító időközének módosítása után.
Az időalapú intervallumról a használatra AvailableNowvaló áttérés esetén ez mikroköteg-feldolgozást eredményezhet az összes elérhető rekord növekményes kötegként való feldolgozása előtt.
Ha időalapú intervallumra vált AvailableNow , az azt eredményezheti, hogy az utolsó AvailableNow feladat aktiválásakor elérhető összes rekord feldolgozása folytatódik. Ez a várt viselkedés.
Feljegyzés
Ha növekményes köteghez társított lekérdezési hibákból próbál helyreállni, az eseményindító időközének módosítása nem oldja meg ezt a problémát, mert a köteget még be kell fejezni. A Databricks azt javasolja, hogy a probléma megoldásához a köteg feldolgozásához használt számítási kapacitást skálázzák fel. Ritkán előfordulhat, hogy újra kell indítania a streamet egy új ellenőrzőponttal.
Mi a folyamatos feldolgozási mód?
Az Apache Spark támogatja a folyamatos feldolgozásnak nevezett további triggerintervallumot. Ez a mód a Spark 2.3 óta kísérletiként van besorolva; forduljon az Azure Databricks-fiók csapatához, hogy biztosan tisztában legyen a feldolgozási modell kompromisszumaival.
Vegye figyelembe, hogy ez a folyamatos feldolgozási mód egyáltalán nem kapcsolódik a Delta Live Tablesben alkalmazott folyamatos feldolgozáshoz.