Egyszerű, hatékony és alacsony késésű adatfolyamok létrehozása

A mai adatvezérelt vállalkozások folyamatosan termelnek adatokat, ami szükségessé teszi azokat a mérnöki adatfolyamokat, amelyek folyamatosan betöltik és átalakítják ezeket az adatokat. Ezeknek a folyamatoknak képesnek kell lenniük arra, hogy pontosan egyszer dolgozzák fel és kézbesítsék az adatokat, 200 ezredmásodpercnél kisebb késéssel hozhassanak létre eredményeket, és mindig törekedjenek a költségek minimalizálására.

Ez a cikk bemutatja a kötegelt és az inkrementális streamfeldolgozási megközelítéseket a mérnöki adatokkal kapcsolatos adatcsatornák esetében, miért az inkrementális streamfeldolgozás a jobb választás, valamint a következő lépéseket a Databricks inkrementális streamfeldolgozási ajánlatainak elindításához. Továbbá, tartalmazza a Streamelés az Azure Databricks és a Mi a DLT?témaköröket. Ezek a funkciók lehetővé teszik a folyamatok gyors írását és futtatását, amelyek garantálják a szállítási szemantikát, a késést, a költségeket és egyebeket.

Az ismétlődő kötegelt munkafeladatok buktatói

Az adatfolyam beállításakor előfordulhat, hogy kezdetben ismétlődő tételes munkákat ír az adatok importálásához. Például óránként elindíthat egy Spark-feladatot, amely a forrásból olvas, és adatokat ír egy célba, például a Delta Lake-be. Ezzel a megközelítéssel a probléma a forrás növekményes feldolgozása, mivel az óránként futó Spark-feladatnak ott kell kezdődnie, ahol az utolsó befejeződött. Rögzítheti a feldolgozott adatok legújabb időbélyegét, majd kiválaszthatja az összes olyan sort, amelynek időbélyegei az adott időbélyegnél újabbak, de vannak buktatók:

Folyamatos adatfolyam futtatásához megpróbálhat ütemezni egy óránkénti kötegelt feladatot, amely növekményesen olvas a forrásból, elvégzi az átalakításokat, és az eredményt egy fogadóba írja, például a Delta Lake-be. Ennek a megközelítésnek lehetnek buktatói:

• Egy Spark-feladat, amely az időbélyeg után lekérdezi az összes új adatot, lemarad a késői adatokról.
• Egy sikertelen Spark-feladat megszakíthatja a pontosan egyszeri garanciákat, ha nem kezelik gondosan.
• Az új fájlok megkereséséhez a felhőbeli tárolóhelyek tartalmát listázó Spark-feladat költségessé válik.

Ezután is újra át kell alakítania ezeket az adatokat. Előfordulhat, hogy ismétlődő kötegelt feladatokat hoz létre, amelyek összesítik az adatokat, vagy más műveleteket alkalmaznak, ami tovább bonyolítja a folyamatot és rontja annak hatékonyságát.

Köteg példa

A folyamat kötegbetöltésének és átalakításának buktatóinak teljes megértéséhez vegye figyelembe az alábbi példákat.

Kihagyott adatok

Egy használati adatokat tartalmazó Kafka-témakör esetén, amely meghatározza, hogy mennyit kell felszámítani az ügyfeleknek, és a folyamata kötegekben dolgozik, az események sorrendje így nézhet ki:

1. Az első kötegnek két rekordja van 8:00-kor és 8:30-kor.
2. A legújabb időpontot 8:30-ra frissíted.
3. 8:15-kor kap egy újabb rekordot.
4. A második lekérdezési köteg mindent lekérdez 8:30 után, így lemarad a 8:15-kor lévő rekordról.

Emellett nem szeretné túlszámlázni vagy alulszámlázni ügyfeleit, ezért gondoskodnia kell arról, hogy minden rekordot pontosan egyszer dolgozzon fel.

Redundáns feldolgozás

Tegyük fel, hogy az adatok felhasználói vásárlások sorait tartalmazzák, és az óránkénti értékesítéseket szeretné összesíteni, hogy megismerje az áruház legnépszerűbb időszakait. Ha az egy órára vonatkozó vásárlások különböző kötegekben érkeznek, akkor több köteg is lesz, amelyek egy órán keresztül hoznak létre kimeneteket:

A 8:00–9:00-ig tartó ablakban két elem (az 1. köteg kimenete), egy elem (a 2. köteg kimenete) vagy három (egyik köteg kimenete sem) van? Az adott időkeret létrehozásához szükséges adatok több átalakítási kötegben jelennek meg. A probléma megoldásához napról napra particionálhatja az adatokat, és újra feldolgozhatja a teljes partíciót, amikor ki kell számítania egy eredményt. Ezután felülírhatja az eredményeket a fogadóban:

Ez azonban a késés és a költségek rovására megy, mivel a második kötegnek el kell végeznie az adatok feldolgozásának szükségtelen munkáját, amelyet esetleg már feldolgoztak.

Nincsenek buktatók növekményes streamfeldolgozással

Az adatok folyamatos adatfolyam-feldolgozásával egyszerűen elkerülheti az ismétlődő kötegelt feladatok összes buktatóját az adatok betöltéséhez és átalakításához. A Databricks strukturált streamelés és DLT felügyelik a streamelés implementációs összetettségeit, hogy Ön csak az üzleti logikára összpontosíthasson. Csak azt kell megadnia, hogy melyik forráshoz kell csatlakoznia, milyen átalakításokat kell végrehajtania az adatokon, és hol kell írnia az eredményt.

Növekményes betöltés

A Databricksben a fokozatos betöltést az Apache Spark strukturált streamelés hajtja végre, amely fokozatosan képes adatokat feldolgozni és egy célhelyre írni. A strukturált streamelési motor pontosan egyszer képes adatokat felhasználni, a motor pedig képes a rendelésen kívüli adatok kezelésére. A motoregység futtatható jegyzetfüzetekben, vagy a DLT-ben lévő streamelési táblák használatával.

A Databricks strukturált streamelési motorja olyan védett streamforrásokat biztosít, mint például az AutoLoader, amely költséghatékony módon képes növekményesen feldolgozni a felhőfájlokat. A Databricks más népszerű üzenetbuszokhoz is biztosít összekötőket, például Apache Kafka, Amazon Kinesis, Apache Pulsarés Google Pub/Sub.

Növekményes átalakítás

A strukturált streamelést alkalmazó növekményes transzformáció a Databricksben lehetővé teszi, hogy a Batch-lekérdezésekkel megegyező API-val DataFrame-ek transzformációit határozza meg. Az adatok kötegek között és az idő múlásával összesített értékek formájában vannak nyomon követve, így erre önnek nincs szüksége. Soha nem kell újra feldolgoznia az adatokat, így gyorsabb és költséghatékonyabb, mint az ismétlődő kötegelt feladatok. A strukturált streaming olyan adatfolyamot hoz létre, amelyet hozzáfűzhet az adattárolóhoz, mint például a Delta Lake, a Kafka vagy bármely más támogatott csatlakozó.

A DLT-ben a materializált nézeteket az Enzyme motor hajtja. Az enzim továbbra is növekményesen dolgozza fel a forrást, de stream létrehozása helyett létrehoz egy materializált nézetet, amely egy előre kiszámított tábla, amely tárolja az Ön által megadott lekérdezés eredményeit. Az enzim képes hatékonyan meghatározni, hogy az új adatok hogyan befolyásolják a lekérdezés eredményeit, és megtartja az előre kiszámított táblát up-to-date.

A materializált nézetek létrehoznak egy nézetet az összesítés felett, amely mindig hatékonyan frissíti magát, így például a fent leírt forgatókönyvben tudja, hogy a 8–9 óra ablak három elemet biztosít.

Strukturált streamelés vagy DLT?

A strukturált streamelés és a DLT közötti jelentős különbség az, ahogyan a streamelési lekérdezéseket üzembe helyezi. A strukturált streamelésben manuálisan adhat meg számos konfigurációt, és manuálisan kell összefűznie a lekérdezéseket. Explicit módon el kell indítania a lekérdezéseket, meg kell várnia, amíg a leállításukra sor kerülhet, a sikertelenség után pedig le kell mondania őket, és egyéb műveleteket kell végrehajtania. A DLT-ben deklaratív módon adja meg a DLT-nek a folyamatok futtatását, és az továbbra is fut.

A DLT olyan funkciókkal is rendelkezik, mint a Materialized Views, amelyek hatékonyan és fokozatosan előre lefordítják az adatok átalakítását.

További információ ezekről a funkciókról: Az Azure Databricks adatfolyam és Mi az a DLT?.

Következő lépések

• Hozza létre első adatcsatornáját a DLT használatával. Lásd oktatóanyagot: Az első DLT-folyamat futtatása.
• Futtassa első strukturált streamelési lekérdezéseit a Databricks platformon. Lásd: Az első strukturált streamelési számítási feladat futtatása.

• Használj materializált nézetet. Lásd a -as bejegyzést: materializált nézetek használata a Databricks SQL-ben.