Ajánlott eljárások a megbízhatósághoz

Ezek az ajánlott eljárások segítenek olyan rendszerek létrehozásában Azure Databricks, amelyek helyreállnak a hibákból, és folyamatosan futnak, az alábbi szakaszok architekturális alapelvei szerint rendezve.

A hibák tervezése során figyelembe vétel

ACID-tranzakciókat támogató adatformátum használata

Az ACID-tranzakciók kritikus fontosságúak az adatintegritás és -konzisztencia fenntartásához. Ha olyan adatformátumot választ, amely támogatja az ACID-tranzakciókat, egyszerűbb és sokkal megbízhatóbb folyamatokat hozhat létre.

A Delta Lake egy nyílt forráskódú tárolási keretrendszer, amely ACID-tranzakciókat, valamint sémakényszerítést, skálázható metaadatok kezelését, valamint a streamelési és kötegelt adatfeldolgozás egységesítését biztosítja. A Delta Lake teljes mértékben kompatibilis az Apache Spark API-kkal, és a strukturált streameléssel való szoros integrációra lett kialakítva, lehetővé téve az adatok egyetlen másolatának használatát a kötegelt és a streamelési műveletekhez, valamint növekményes feldolgozást biztosít nagy méretekben.

Rugalmas elosztott adatmotor használata minden számítási feladathoz

Az Apache Spark, mint a Azure Databricks számítási motorja rugalmas elosztott adatfeldolgozáson alapul. Ha egy belső Spark-tevékenység nem a várt eredményt adja vissza, az Apache Spark automatikusan átütemezi a hiányzó tevékenységeket, és továbbra is végrehajtja a teljes feladatot. Ez hasznos lehet a kódon kívül eső hibák esetén, például egy rövid hálózati probléma vagy egy visszavont Spot VM esetén. Az SQL API-val és a Spark DataFrame API-val együttműködve ez a rugalmasság be van építve a motorba.

A Databricks platformon a Photon, a teljes egészében C++-ban írt natív vektorizált motor egy nagy teljesítményű számítás, amely kompatibilis az Apache Spark API-kkal.

Érvénytelen vagy nem formázott adatok automatikus mentése

Érvénytelen vagy nem formázott adatok miatt a létrehozott adatformátumra támaszkodó számítási feladatok összeomlhatnak. A teljes folyamat teljes rugalmasságának növelése érdekében ajánlott kiszűrni az érvénytelen és nem konformáló adatokat a betöltéskor. A mentett adatok támogatása biztosítja, hogy a betöltés vagy az ETL során soha ne veszítse el vagy hagyja ki az adatokat. A mentett adatoszlop olyan adatokat tartalmaz, amelyeket nem elemeztek, vagy azért, mert hiányzott az adott sémából, mert típuseltérés történt, vagy mert a rekord vagy fájl oszloptörzse nem egyezett meg a sémában lévővel.

  • A Databricks Auto Loader:Auto Loader ideális eszköz a fájlbetöltés streamelésére. Támogatja a JSON és a CSV kimentett adatait. JSON esetén például a mentett adatoszlop olyan adatokat tartalmaz, amelyeket nem elemeztek, esetleg azért, mert hiányzott az adott sémából, mert típuseltérés történt, vagy mert az oszlop burkolata nem egyezett. A mentett adatokat tartalmazó oszlop az Auto Loader által visszaadott séma része, amely alapértelmezésből _rescued_data jelölésű, amikor a séma következtetése történik.

  • Csővezetékek: A munkafolyamatok rugalmassági célú kiépítésének másik lehetősége a Lakeflow-folyamatok minőségi korlátozásokkal történő használata. Lásd: Adatminőség kezelése csővezeték elvárásokkal. A Lakeflow-folyamatok alapértelmezés szerint három módot támogatnak: érvénytelen rekordok megőrzése, elvetése és meghiúsulása. Az érvénytelen rekordok karanténba helyezéséhez a várakozási szabályok meghatározott módon határozhatók meg, hogy az érvénytelen rekordok egy másik táblában legyenek tárolva ("karanténba"). Lásd: Érvénytelen rekordok karanténba helyezése.

Feladatok konfigurálása automatikus újrapróbálkozáshoz és leállításhoz

Az elosztott rendszerek összetettek, és egy adott ponton bekövetkező hiba az egész rendszerre kihathat.

  • A Lakeflow Jobs támogatja az újrapróbálkoztatási szabályzatokat olyan tevékenységekhez, amelyek meghatározzák, hogy mikor és hányszor történjen újra a sikertelen futtatások újrapróbálkozása. Lásd: Újrapróbálkozési szabályzat beállítása.
  • Konfigurálhatja egy tevékenységhez a választható időtartam küszöbértékeit, beleértve a tevékenység várható befejezési idejét és a tevékenység maximális befejezési idejét.
  • A Lakeflow-folyamatok a hibák helyreállítását is automatizálják az újrapróbálkozások eszkalálásával a sebesség és a megbízhatóság egyensúlya érdekében. Lásd a frissítés futtatási viselkedését.

Másrészt egy elakadt feladat megakadályozhatja a teljes munka befejezését, ami magas költségeket eredményez. A Lakeflow-feladatok támogatják az időtúllépési konfigurációt a vártnál hosszabb ideig tartó feladatok megszakításához.

Skálázható és éles üzemű modellkiszolgáló infrastruktúra használata.

Csomag- és adatfolyam-következtetés esetén használja a Lakeflow-feladatokat és az MLflow-t, hogy a modelleket Apache Spark UDF-ként telepítse, így kihasználhatja a feladatütemezést, újrapróbálkozásokat, automatikus skálázást és hasonlókat. Lásd A modellek üzembe helyezése kötegelt következtetéshez és előrejelzéshez.

A modellkiszolgáló skálázható és éles szintű infrastruktúrát biztosít a valós idejű modell-kiszolgáláshoz. MLflow használatával dolgozza fel a gépi tanulási modelleket, és REST API-végpontként teszi elérhetővé őket. Ez a funkció kiszolgáló nélküli számítást használ, ami azt jelenti, hogy a végpontok és a kapcsolódó számítási erőforrások kezelése és futtatása az Azure Databricks felhőfiókjában történik.

Felügyelt szolgáltatások használata, ahol lehetséges

A Databricks Adatintelligencia-platform felügyelt szolgáltatásainak (kiszolgáló nélküli számítás) kihasználása, például:

Ezeket a szolgáltatásokat a Databricks megbízható és méretezhető módon üzemelteti, így a számítási feladatok megbízhatóbbak.

2. Az adatminőség kezelése

Rétegzett tárolási architektúra használata

Rétegzett architektúra létrehozásával és annak biztosításával, hogy az adatok a rétegeken áthaladva javuljon az adatminőség. Ezt a mintát medál architektúraként ismerjük. Gyakori rétegzési módszer:

  • Nyers réteg (bronz): A forrásadatok bekerülnek a lakehouse első rétegébe, és ott tárolva kell maradjanak. Ha az összes alsóbb rétegbeli adat a nyers rétegből jön létre, szükség szerint újraépítheti a réteg további rétegeit. Külső táblák használata a bronzréteg-adatokhoz a nyers adatok megőrzéséhez, még akkor is, ha a táblák törlésre kerülnek.
  • Válogatott réteg (ezüst): A második réteg célja, hogy megtisztított, finomított, szűrt és összesített adatokat tároljon. Ennek a rétegnek a célja, hogy szilárd, megbízható alapot biztosítson az elemzéshez és a jelentéskészítéshez minden szerepkörben és funkcióban. Felügyelt táblák használata sémakényszerítéssel és adatminőség-ellenőrzéssel.
  • Végső réteg (arany): A harmadik réteg az üzleti vagy projektigények köré épül. Más üzleti egységeknek vagy projekteknek biztosít adattermékként eltérő nézetet, előkészíti az adatokat a biztonsági igények (például anonimizált adatok) köré, vagy optimalizálja a teljesítményt (például előre összesített nézetekkel). Az ebben a rétegben található adattermékeket a vállalat igazságának tekintik. Felügyelt táblák használata üzletilogika-ellenőrzéssel és SLA-garanciával.

Az utolsó rétegnek csak kiváló minőségű adatokat kell tartalmaznia, és üzleti szempontból teljes mértékben megbízhatónak kell lennie.

Megvalósítási szempontok:

  • A Unity Catalog sémáinak használatával rendszerezheti a bronz, ezüst és arany rétegeket (például sales.bronze_transactions, sales.silver_transactions, sales.gold_metrics)
  • A Delta Lake-tábla tulajdonságainak konfigurálása a delta.enableChangeDataFeed rétegek közötti változások nyomon követéséhez
  • Az automatikus optimalizálás engedélyezése az optimális fájlméretek fenntartásához, ahogy az adatok rétegeken haladnak előre
  • Növekményes feldolgozás megvalósítása Delta Live-táblák vagy strukturált streamelés használatával a hatékony rétegfrissítésekhez
  • Egyértelmű adatminőségi elvárások kialakítása minden réteghatáron

A medallion architektúra implementálásának részletes útmutatóját a Medallion architektúra tervezése című témakörben találja.

Az adatintegritás javítása az adatredundancia csökkentésével

Az adatok másolása vagy duplikálása adatredundanciát okoz, és az integritás elvesztéséhez, az adatsorok elvesztéséhez és gyakran különböző hozzáférési engedélyekhez vezet. Ez csökkenti a Databricksben tárolt adatok minőségét.

Az adatok ideiglenes vagy eldobható másolata önmagában nem káros – néha szükség van az agilitás, a kísérletezés és az innováció növelésére. Ha azonban ezek a másolatok működőképesek lesznek, és rendszeresen használják őket üzleti döntések meghozatalára, adatsilókká válnak. Ha ezek az adatsilók nem szinkronizálódnak, az jelentős negatív hatással van az adatintegritásra és a minőségre, és olyan kérdéseket vet fel, mint a "Melyik adathalmaz a fő?" vagy "Aktuális az adatkészlet?

Sémák aktív kezelése

A nem ellenőrzött sémamódosítások érvénytelen adatokhoz és az adatkészleteket használó sikertelen feladatokhoz vezethetnek. Az Azure Databricks számos módszerrel érvényesíti és érvényesíti a sémát:

  • A Delta Lake támogatja a sémaérvényesítést és a sémakényszerítést a sémaváltozatok automatikus kezelésével, hogy megakadályozza a helytelen rekordok beszúrását a betöltés során. Lásd: Sémakényszerítés.
  • Az Automatikus betöltő észleli az új oszlopok hozzáadását az adatok feldolgozása során. Alapértelmezés szerint egy új oszlop hozzáadása az adatfolyamok leállását okozza egy UnknownFieldException-vel. Az Automatikus betöltő számos módot támogat a sémafejlődéshez.

Korlátozások és adatelvárások használata

A Delta-táblák támogatják a szabványos SQL-kényszerkezelési záradékokat, amelyek biztosítják, hogy a rendszer automatikusan ellenőrizze a táblához hozzáadott adatok minőségét és integritását. Ha egy korlátozás sérül, a Delta Lake hibát jelez InvariantViolationException , amely jelzi, hogy az új adatok nem adhatók hozzá. Lásd : Az Azure Databricks korlátozásai.

A kezelés további javítása érdekében a Lakeflow-folyamatok támogatják az elvárásokat: Az elvárások adatminőségi korlátozásokat határoznak meg az adathalmazok tartalmára. Az elvárás egy leírásból, egy invariánsból és egy végrehajtandó műveletből áll, ha egy rekord megsérti az invariánst. A lekérdezésekkel kapcsolatos elvárások Python-dekorátorokat vagy SQL-korlátozási záradékokat használnak. Lásd: Adatminőség kezelése csővezeték elvárásokkal.

Adatközpontú megközelítés használata a gépi tanuláshoz

A Databricks Adatintelligencia-platform AI-víziójának középpontjában álló vezérelv a gépi tanulás adatközpontú megközelítése. Ahogy a generatív MI egyre elterjedtebbé válik, ez a szemlélet ugyanolyan fontos marad.

Az ML-projektek alapvető összetevői egyszerűen adatfolyamként is felfoghatók: A szolgáltatásfejlesztés, a betanítás, a modell üzembe helyezése, a következtetés és a monitorozási folyamatok mind adatfolyamok. Ezért az ml-megoldások üzembe helyezéséhez össze kell egyesíteni az adatokat az előrejelzési, monitorozási és funkciótáblákból más releváns adatokkal. Ennek legegyszerűbb módja alapvetően az, ha az éles adatok kezeléséhez használt platformon fejleszt mesterséges intelligenciával rendelkező megoldásokat. Lásd : Adatközpontú MLOps és LLMOps

3. Automatikus skálázás tervezése

Automatikus skálázás engedélyezése ETL-számítási feladatokhoz

Az automatikus méretezés lehetővé teszi, hogy a fürtök a számítási feladatok alapján automatikusan átméreteződjenek. Az automatikus skálázás számos használati eset és forgatókönyv számára előnyös lehet költség- és teljesítmény szempontból is. A dokumentáció megfontolja az automatikus skálázás használatának és a leghasznosabb használatnak a meghatározását.

Streaming munkaterhelésekhez a Databricks a Lakeflow-folyamatok automatikus skálázással történő használatát javasolja. A Databricks továbbfejlesztett automatikus skálázása úgy optimalizálja a fürt kihasználtságát, hogy automatikusan kiosztja a fürterőforrásokat a számítási feladatok mennyisége alapján, és minimális hatással van a folyamatok adatfeldolgozási késésére.

Automatikus skálázás engedélyezése az SQL Warehouse-hoz

Az SQL-raktár méretezési paramétere meghatározza azoknak a fürtöknek a minimális és maximális számát, amelyeken keresztül a rendszer elosztja a raktárnak küldött lekérdezéseket. Az alapértelmezett beállítás szerint egyetlen fürt létezik automatikus skálázás nélkül.

Ha több egyidejű felhasználót szeretne kezelni egy adott raktárban, növelje a klaszterek számát. Ha szeretné megtudni, hogyan ad hozzá fürtöket az Azure Databricks egy tárházhoz, és hogyan távolít el belőle fürtöket, tekintse meg az SQL tárház méretezési, skálázási és sorban állási viselkedését.

4. Helyreállítási eljárások tesztelése

A strukturált streamelés lekérdezési hibáinak helyreállítása

A strukturált streamelés hibatűrést és adatkonzisztenciát biztosít a streamelési lekérdezésekhez. A Lakeflow-feladatok használatával egyszerűen konfigurálhatja az adatfolyam-lekérdezéseket, hogy azok automatikusan újrainduljanak meghibásodás esetén. A streamelési lekérdezések ellenőrzőpont-engedélyezésével hiba után újraindíthatja a lekérdezést. Az újraindult lekérdezés onnan folytatódik, ahol a sikertelen lekérdezés abbahagyta. Lásd a strukturált streamelési ellenőrzőpontokat és a strukturált streamelés gyártási szempontjait.

ETL-feladatok helyreállítása adatidő-utazási képességekkel

Az alapos tesztelés ellenére előfordulhat, hogy egy feladat éles környezetben meghiúsul, vagy váratlan, akár érvénytelen adatokat eredményez. Néha ez egy további feladattal is javítható, miután megismerte a probléma forrását, és kijavította a problémát okozó folyamatot. Ez azonban gyakran nem egyszerű, és a kérdéses feladatot vissza kell állítani. A Delta Time Travel használatával a felhasználók egyszerűen visszaállíthatják a módosításokat egy régebbi verzióra vagy időbélyegre, kijavíthatják a folyamatot, és újraindíthatják a rögzített folyamatot.

Ennek kényelmes módja a RESTORE parancs.

Használjon egy feladat-automatizálási keretrendszert beépített helyreállítással.

A Lakeflow-feladatok helyreállításra vannak tervezve. Ha egy többfeladatos feladatban egy tevékenység meghiúsul (és mint ilyen, az összes függő tevékenység), a feladatok mátrixnézetet biztosítanak a futtatásokról, amely lehetővé teszi a hiba okozó probléma kivizsgálását, lásd : Futtatások megtekintése egyetlen feladathoz. Akár rövid hálózati probléma, akár valós adatprobléma áll fenn, megoldhatja, és elindíthatja a javítási műveletet a Lakeflow-feladatokban. Csak a sikertelen és függő feladatokat futtatja, és megtartja a korábbi futtatás sikeres eredményeit, időt és pénzt takarít meg, lásd a feladathibák hibaelhárítását és javítását.

Magas rendelkezésre állás és vészhelyreállítás konfigurálása

Magas rendelkezésre állási stratégiák megvalósítása

A Databricks üzembe helyezésének megtervezése a magas rendelkezésre állás érdekében az állásidő minimalizálása és az üzletmenet folytonosságának biztosítása érdekében:

Vezérlősík magas rendelkezésre állása: A Databricks 99,9% SLA-t biztosít a vezérlősíkhoz, ügyfélkonfiguráció nélkül. A vezérlősík automatikusan üzembe lesz helyezve több rendelkezésre állási zónában.

Magas rendelkezésre állás számítása: Fürtcsomópontok üzembe helyezése több rendelkezésre állási zónában, különböző zónák alhálózatainak biztosításával. A Databricks automatikusan elosztja a csomópontokat a hibatűrés érdekében. Konfigurálja a feladat újrapróbálkozását, hogy automatikusan helyreálljon az átmeneti hibákból.

Magas rendelkezésre állású tároló: A felhőszolgáltatók redundanciabeállításainak (ZRS az Azure-ban, több-AZ replikáció az AWS-en/GCP-n) használatával védheti a zónaszintű hibákat.

Hálózati magas rendelkezésre állás: Üzembe helyezheti a hálózati infrastruktúrát (alhálózatok, NAT-átjárók, VPN-kapcsolatok) több rendelkezésre állási zónában, hogy kiküszöbölje az egyetlen meghibásodási pontot.

A HA-konfigurációval kapcsolatos üzembe helyezési útmutatóért lásd : 10. fázis: Magas rendelkezésre állás és vészhelyreállítás tervezése.

Vészhelyreállítási minta konfigurálása

Egy natív felhőbeli adatelemzési platform, például az Azure Databricks esetében egy egyértelmű vészhelyreállítási minta kritikus fontosságú. Kritikus fontosságú, hogy az adatcsapatok az Azure Databricks platformot akkor is használhatják, ha egy felhőszolgáltató regionális, szolgáltatásszintű kimaradásáról van szó, akár regionális katasztrófa, például hurrikán, földrengés vagy más forrás miatt.

Az Azure Databricks gyakran egy átfogó adat-ökoszisztéma alapvető része, amely számos szolgáltatást tartalmaz, beleértve a felsőbb rétegbeli adatbetöltési szolgáltatásokat (batch/streaming), a natív felhőbeli tárolást, például az Azure Data Lake Storage-t, az alsóbb rétegbeli eszközöket és szolgáltatásokat, például az üzletiintelligencia-alkalmazásokat és a vezénylési eszközöket. Egyes használati esetek különösen érzékenyek lehetnek a regionális szolgáltatáskimaradásra.

A vészhelyreállítás olyan szabályzatokat, eszközöket és eljárásokat foglal magában, amelyek lehetővé teszik a létfontosságú technológiai infrastruktúra és rendszerek helyreállítását vagy folytatását természetes vagy ember által okozott katasztrófákat követően. Egy nagy felhőszolgáltatás, például az Azure számos ügyfelet kiszolgál, és beépített védelmet nyújt egyetlen hiba ellen. A régió például olyan épületek csoportja, amelyek különböző energiaforrásokhoz csatlakoznak, így biztosítva, hogy egyetlen áramkimaradás ne okozhasson le egy régiót. A felhőrégiók hibái azonban előfordulhatnak, és a hiba súlyossága és a vállalkozásra gyakorolt hatása eltérő lehet.

Vészhelyreállítás megvalósítása:

  • A helyreállítási idő célkitűzésének (RTO) és a helyreállítási pont célkitűzésének (RPO) meghatározása a szervezet számára
  • Infrastruktúra használata kódként (Terraform, Eszközcsomagok) a munkaterületek gyors újraépítéséhez egy DR-régióban
  • A Unity Catalog metaadatainak replikálás a metaadattár biztonsági mentési és importálási eljárásaival
  • Delta-táblareplikáció implementálása a DR-régióba a deep CLONE használatával a kritikus adathalmazokhoz
  • Felhőszolgáltatói tárolóreplikálás konfigurálása automatikus adatreplikáláshoz
  • DR-eljárások rendszeres tesztelése a helyreállítási folyamatok készenlétének és finomításának biztosítása érdekében

Részletes dr. konfigurációs útmutató: 10. fázis: Magas rendelkezésre állás és vészhelyreállítás tervezése.

5. Üzembe helyezések és számítási feladatok automatizálása

Lásd : Működési kiválóság – Üzembe helyezések és számítási feladatok automatizálása.

6. Rendszerek és számítási feladatok monitorozása

Lásd : Működési kiválóság – Figyelés, riasztás és naplózás beállítása.

  • Last updated on