A folyamatok magas inicializálási idejének javítása

A csővezetékek sok adatállományt tartalmazhatnak, amelyek sok folyamatot tartalmaznak, hogy naprakészek maradjanak. A pipeline-ek automatikusan kezelik a frissítéseket és fürtöket a hatékony frissítéshez. A nagy mennyiségű folyamat kezelésével azonban van némi többletterhelés, és ez időnként a vártnál nagyobb inicializáláshoz vagy akár felügyeleti többletterheléshez is vezethet a feldolgozás során.

Ha késések lépnek fel az aktivált folyamatok inicializálására várva, például az inicializálási idő öt perc alatt, fontolja meg a feldolgozás több folyamatra való felosztását, még akkor is, ha az adathalmazok ugyanazokat a forrásadatokat használják.

Megjegyzés:

Az aktivált folyamatok minden egyes aktiválásakor végrehajtják az inicializálási lépéseket. A folyamatos folyamatok csak akkor hajtják végre az inicializálási lépéseket, ha le vannak állítva és újraindulnak. Ez a szakasz leginkább az aktivált folyamat inicializálásának optimalizálására használható.

Mikor érdemes megfontolni egy csővezeték felosztását?

A folyamat felosztása több esetben is előnyös lehet a teljesítmény szempontjából.

• A INITIALIZING és SETTING_UP_TABLES fázisok tovább tarthatnak a kívántnál, ami hatással van a folyamatlánc teljes működési idejére. Ha ez több mint 5 perc, a folyamatlánc felosztásával gyakran javul.
• A fürtöt kezelő illesztőprogram szűk keresztmetszetet jelenthet, ha több (több mint 30-40) streamtáblát futtat egyetlen folyamaton belül. Ha az illesztőprogram nem válaszol, akkor a streamelési lekérdezések időtartama nő, ami hatással van a frissítés teljes idejére.
• Előfordulhat, hogy egy több streamelési táblafolyamatot tartalmazó aktivált folyamat nem tudja párhuzamosan végrehajtani az összes párhuzamos streamfrissítést.

A teljesítményproblémák részletei

Ez a szakasz néhány olyan teljesítményproblémát ismertet, amelyek abból adódhatnak, hogy egyetlen folyamat több táblája és folyamata van.

Az INICIALIZÁLÁS és TÁBLÁK_BEÁLLÍTÁSA fázisok szűk keresztmetszetei

A futtatás kezdeti fázisai teljesítménybeli szűk keresztmetszetet jelenthetnek a folyamat összetettségétől függően.

INICIALIZÁLÁSI fázis

Ebben a fázisban logikai tervek jönnek létre, beleértve a függőségi gráf készítésére és a táblafrissítések sorrendjének meghatározására szolgáló terveket.

Táblák beállításának fázisa

Ebben a fázisban a következő folyamatok lesznek végrehajtva az előző fázisban létrehozott tervek alapján:

• Séma érvényesítése és feloldása a folyamatban definiált összes táblához.
• Hozza létre a függőségi gráfot, és határozza meg a táblavégrehajtás sorrendjét.
• Ellenőrizze, hogy az egyes adathalmazok aktívak-e a folyamatban, vagy újak-e az előző frissítés óta.
• Hozzon létre streamelési táblákat az első frissítésben, és a materializált nézetekhez hozzon létre ideiglenes nézeteket vagy biztonsági mentési táblákat, amelyekre minden folyamatfrissítés során szükség van.

Miért tart tovább az inicializálás és a táblák beállítása?

A sok adathalmazhoz sok folyamattal rendelkező nagy folyamatok több okból is tovább tarthatnak:

• A sok folyamattal és összetett függőségekkel rendelkező folyamatok esetében ezek a fázisok hosszabb időt is igénybe vehetnek, mivel a munka mennyisége elvégzendő.
• Az összetett átalakítások, beleértve az Auto CDC átalakításokat, teljesítménybeli szűk keresztmetszetet okozhatnak, mivel a táblák létrehozásához szükséges műveletek a definiált átalakítások alapján történnek.
• Vannak olyan forgatókönyvek is, amelyekben jelentős számú folyamat okozhat lassúságot, még akkor is, ha ezek a folyamatok nem részei a frissítésnek. Vegyük például azt a folyamatot, amely több mint 700 folyamatból áll, amelyek közül kevesebb mint 50 frissül minden eseményindítóhoz egy konfiguráció alapján. Ebben a példában minden futtatásnak végig kell mennie a 700 tábla néhány lépésén, le kell szereznie az adatkereteket, majd ki kell választania a futtatandókat.

Szűk keresztmetszetek az illesztőprogramban

Az illesztőprogram a futtatáson belül kezeli a frissítéseket. Minden táblához végre kell hajtania bizonyos logikai műveleteket, hogy eldöntse, hogy a fürt melyik példányai feleljenek az egyes adatfolyamok kezeléséért. Ha több (több mint 30-40) streamelési táblát futtat egy folyamaton belül, az illesztőprogram szűk keresztmetszetet jelenthet a CPU-erőforrások számára, mivel a fürt teljes munkáját kezeli.

Az illesztőprogram memóriaproblémákba is ütközhet. Ez gyakrabban fordulhat elő, ha a párhuzamos folyamatok száma 30 vagy több. Nincs meghatározott számú folyamat vagy adatkészlet, amely okozhatja az illesztőprogram memóriaproblémáit, de a párhuzamosan futó feladatok összetettségétől függ.

A streamfolyamatok párhuzamosan is futhatnak, de ehhez az illesztőprogramnak egyidejűleg kell használnia a memóriát és a CPU-t az összes streamhez. Az aktivált folyamatokban az illesztő egyidejűleg feldolgozhatja a streamek egy részhalmazát, hogy elkerülje a memória- és CPU-korlátozásokat.

Ezekben az esetekben a folyamatok felosztása, hogy mindegyikben optimális folyamatkészlet legyen, felgyorsíthatja az inicializálást és a feldolgozási időt.

Kompromisszumok a folyamatok láncának felosztásával

Ha az összes folyamat ugyanazon a folyamaton belül található, az a folyamat kezeli a függőségeket. Ha több folyamat is van, a folyamatok közötti függőségeket kell kezelnie.

• Függőségek Előfordulhat, hogy egy alárendelt folyamat több felsőbb rétegbeli folyamattól függ (egy helyett). Ha például három folyamat van, pipeline_A, pipeline_B és pipeline_C, és pipeline_C függ mind pipeline_A-tól, mind pipeline_B-tól, akkor azt szeretné, hogy pipeline_C csak azután frissüljön, hogy mind pipeline_A és pipeline_B a saját frissítéseiket befejezték. Ennek egyik módja a függőségek vezénylése azáltal, hogy az egyes csővezetékeket feladatként kezeli a függőségek megfelelő modellezésével, így pipeline_C csak akkor frissül, miután mind a pipeline_A, mind a pipeline_B befejeződött.

• Konkurencia Előfordulhat, hogy egy folyamat különböző folyamatokat tartalmaz, amelyek végrehajtása nagyon különböző időt vesz igénybe, például ha flow_A a frissítések 15 másodpercen belül történnek, és flow_B több percet is igénybe vesznek. Hasznos lehet áttekinteni a lekérdezések idejét a folyamatok felosztása előtt, és csoportosítani a rövidebb lekérdezéseket.

Az adatcsővezetékek felosztásának megtervezése

A csővezeték felosztását a kezdés előtt vizualizálhatja. Íme egy 25 táblát feldolgozó forrásfolyamat gráfja. Egyetlen gyökéradatforrás 8 szegmensre van felosztva, amelyek mindegyike 2 megtekintéssel rendelkezik.

A csővezeték felosztása után két csővezeték van. Az egyik feldolgozza az egyetlen gyökéradatforrást, valamint 4 szegmenst és kapcsolódó nézetet. A második folyamat feldolgozza a többi 4 szegmenst és azok kapcsolódó nézeteit. A második folyamat az elsőre támaszkodik a fő adatforrás frissítéséhez.

Az adatfolyam szétválasztása teljes frissítés nélkül

Miután megtervezte a folyamat felosztását, hozzon létre minden szükséges új folyamatot, és helyezze át a táblákat a folyamatok között a folyamat terheléselosztásához. A táblákat teljes frissítés nélkül is áthelyezheti.

További részleteket lásd: Táblák áthelyezése pipeline-ok között.

Ennek a megközelítésnek van néhány korlátozása:

• A csővezetékeknek a Unity Katalógusban kell lenniük.
• A forrás- és célfolyamatoknak ugyanabban a munkaterületen kell lenniük. A munkaterületek közötti áthelyezések nem támogatottak.
• A célfolyamatot az áthelyezés előtt legalább egyszer létre kell hozni és futtatni (még akkor is, ha a futtatás sikertelen).
• Az alapértelmezett közzétételi módot használó folyamatból nem helyezhet át táblát az örökölt közzétételi módot használó folyamatba. További részletekért lásd a LIVE sémát (örökölt).