DataOps alkalmazása az Azure Data Factoryre
A következőkre vonatkozik: 
Azure Data Factory Azure Synapse Analytics
Tipp.
Próbálja ki a Data Factoryt a Microsoft Fabricben, amely egy teljes körű elemzési megoldás a nagyvállalatok számára. A Microsoft Fabric az adattovábbítástól az adatelemzésig, a valós idejű elemzésig, az üzleti intelligenciáig és a jelentéskészítésig mindent lefed. Ismerje meg, hogyan indíthat új próbaverziót ingyenesen!
Az Azure Data Factory a Microsoft adatintegráció- és ETL-szolgáltatása a felhőben. Ez a dokumentum útmutatást nyújt a DataOpshoz a Data Factoryben. Ez nem a CI/CD, a Git vagy a DevOps teljes oktatóanyaga. Ehelyett a Data Factory csapata útmutatást talál a DataOps szolgáltatásban való eléréséhez, és részletes megvalósítási hivatkozásokat tartalmaz a Data Factory üzembe helyezési ajánlott eljárásaihoz, a gyárkezeléshez és a szabályozáshoz. A dokumentum végén található egy erőforrás-szakasz, amely az oktatóanyagokra mutató hivatkozásokat tartalmaz.
Mi az a DataOps?
A DataOps egy olyan folyamat, amelyet az adatszervezetek az együttműködésen alapuló adatkezelés terén gyakorolnak, hogy gyorsabb értéket nyújtsanak a döntéshozóknak.
A Gartner a DataOps alábbi egyértelmű definícióját biztosítja:
A DataOps egy együttműködésen alapuló adatkezelési gyakorlat, amely az adatkezelők és az adatfelhasználók közötti adatáramlások kommunikációjának, integrációjának és automatizálásának javítására összpontosít a szervezeten belül. A DataOps célja az érték gyorsabb elérése az adatok, adatmodellek és kapcsolódó összetevők kiszámítható kézbesítésének és változáskezelésének létrehozásával. A DataOps technológia segítségével automatizálja az adatkézbesítés tervezését, üzembe helyezését és kezelését a megfelelő szabályozási szinteken, és metaadatok használatával javítja az adatok használhatóságát és értékét egy dinamikus környezetben.
Hogyan érhető el a DataOps az Azure Data Factoryben?
Az Azure Data Factory vizuálisan alapuló adatfolyamat-paradigmát biztosít az adatmérnökök számára a felhőalapú adatintegráció és az ETL-projektek egyszerű létrehozásához. A Data Factory natív integrációra támaszkodik az olyan fejlett verziókövetési eszközökkel, mint a GitHub és az Azure DevOps, valamint a szélesebb körű Azure-ökoszisztéma, hogy számos beépített funkciót biztosítson a dataOps megkönnyítése érdekében, amelyek gazdag együttműködésre, irányításra és összetevőkre vonatkozó kapcsolatokat tartalmaznak.
Amikor saját GitHub- vagy Azure DevOps-adattárat hoz létre a Data Factoryben, a szolgáltatás intuitív beépített felhasználói felületi lehetőségeket biztosít a gyakori parancsokhoz, például véglegesítésekhez, összetevők mentéséhez és verziókövetéshez. A szolgáltatás a CI/CD és a kód beadásának ajánlott eljárásait is biztosítja az éles környezet higiéniájának és állapotának védelme érdekében.
"Kód" az Azure Data Factoryben
Az Azure Data Factory összes összetevője, függetlenül attól, hogy folyamatokról, társított szolgáltatásokról, eseményindítókról stb. van-e szó, a JSON-ban a vizuális felhasználói felület integrációja mögött megfelelő "kód" ábrázolásokkal rendelkezik. Ezek az összetevők az Azure Resource Manager-sablonok szabványainak megfelelően működnek. A kódot a vászon jobb felső sarkában található zárójel ikonra kattintva találja meg. A JSON-mintakód a következőképpen nézne ki:
Élő mód és Git-verziókövetés
Minden gyár egyetlen igazságforrással rendelkezik: a szolgáltatásban tárolt folyamatok, társított szolgáltatások és triggerdefiníciók. Ez az igazságforrás az, amit a folyamat futtat, és mi határozza meg az eseményindítók viselkedését. Ha élő módban van, minden közzétételkor közvetlenül módosítja az igazság egyetlen forrását. Az alábbi képen az Összes közzététele gomb látható élő módban.
Az élő mód kényelmes lehet a mellékprojekteken dolgozó egyetlen személy számára, mivel lehetővé teszi a fejlesztők számára a kódmódosítások azonnali hatásait. Ez azonban nem ajánlott az éles szintű munkaprojekteken dolgozó fejlesztők csapatának. A veszélyek közé tartoznak a kövér ujjak, a kritikus erőforrások véletlen törlése, a nem tesztelt kódok közzététele stb., csak hogy néhányat említsünk. Amikor kritikus fontosságú projekteken és platformokon dolgozik, érdemes egy Git-adattárat létrehozni, és a Git módot használni az adat-előállítóban a fejlesztési folyamat gördülékenyebbé tételéhez. A Git mód verziókövetési és kapus bejelentkezési képességei segítenek megelőzni az élő mód közvetlen érintésével járó balesetek többségét, ha nem is az összeset.
Feljegyzés
Git módban a Publish or Publish All (Az összes közzététele) gombot a Mentés vagy Az összes mentése gombra cseréljük, és a módosítások a saját ágakra lesznek kötelezve (nem módosítva közvetlenül az élő kódbázisokat).
A GitHub és az Azure DevOps integrációjának beállítása
Az Azure Data Factoryben erősen ajánlott az adattárat a GitHubon vagy az Azure DevOpsban tárolni. A szolgáltatás teljes mértékben támogatja mindkét módszert, és az egyes szervezeti szabványoktól függ, hogy melyik adattárat használja. Az új adattár beállítására vagy egy meglévő adattárhoz való csatlakozásra két módszer létezik: az Azure Portal használatával vagy az Azure Data Factory Studio felhasználói felületéről történő létrehozással
Az Azure Portal-gyár létrehozása
Amikor új adat-előállítót hoz létre az Azure Portalról, az alapértelmezett Git-adattár az Azure DevOps. A GitHubot is kiválaszthatja adattárként, és konfigurálhatja az adattár beállításait.
Az Azure Portalon válassza ki az adattár típusát, és adja meg az adattár és az ágneveket egy új, a Gittel natívan integrált gyár létrehozásához.
A Git és az Azure Policy használatának kényszerítése a szervezetben
A Git használata az Azure Data Factory-projektekben ajánlott eljárás. Még ha nem is implementál teljes CI/CD-folyamatot, az ADF-vel való Git-integráció lehetővé teszi az erőforrás-összetevők mentését a saját tesztkörnyezetében (Git-ág), ahol a módosításokat a többi gyárágtól függetlenül tesztelheti. Az Azure Policy használatával kényszerítheti a Git használatát a szervezet gyárában.
Azure Data Factory Studio
Az adat-előállító létrehozása után az Azure Data Factory Studióban is csatlakozhat az adattárhoz. A Kezelés lapon megjelenik az adattár és az adattár beállításainak konfigurálására szolgáló lehetőség.
Egy irányított folyamaton keresztül több lépésből áll, amelyek segítségével egyszerűen konfigurálhatja és csatlakozhat a választott adattárhoz. A teljes beállítás után megkezdheti a közös munkát, és mentheti az erőforrásokat az adattárba.
Folyamatos integráció és folyamatos teljesítés (CI/CD)
A CI/CD a kódfejlesztés paradigmája, ahol a módosítások vizsgálata és tesztelése különböző fázisokban történik – fejlesztés, tesztelés, előkészítés stb. Miután áttekintették és tesztelték az egyes fázisokat, végül közzé lesznek téve az éles környezetben lévő élő kódbázisokban.
A folyamatos integráció (CI) az a gyakorlat, amely automatikusan teszteli és ellenőrzi minden alkalommal, amikor egy fejlesztő módosítja a kódbázist. A folyamatos teljesítés (CD) azt jelenti, hogy a folyamatos integrációs tesztek sikeres elvégzése után a módosítások folyamatosan a következő fázisba kerülnek.
A korábban röviden tárgyalt "kód" az Azure Data Factoryben az Azure Resource Manager JSON-sablon formájában történik. Ezért a folyamatos integrációs és kézbesítési (CI/CD) folyamaton átmenő módosítások JSON-blobok hozzáadását, törlését és szerkesztését foglalják magukban.
Folyamatfuttatások az Azure Data Factoryben
Mielőtt az Azure Data Factoryben a CI/CD-ről beszélnénk, először arról kell beszélnünk, hogy a szolgáltatás hogyan futtat egy folyamatot. Mielőtt a Data Factory futtat egy folyamatot, a következő műveleteket hajtja végre:
- Lekéri a folyamat legújabb közzétett definícióját és a hozzá tartozó eszközöket, például adatkészlet(ek), társított szolgáltatás(ok) stb.
- Leforditja műveletekre; Ha a Data Factory a közelmúltban hajtotta végre, lekéri a műveleteket a gyorsítótárazott fordításokból.
- Futtatja a folyamatot.
A folyamat futtatása a következő lépésekkel jár:
- A szolgáltatás pillanatképet készít a folyamatdefinícióról.
- A folyamat időtartama alatt a definíciók nem változnak.
- Még akkor is, ha a folyamatok hosszú ideig futnak, az indításuk után végrehajtott későbbi módosítások nem érintik őket. Ha a futtatás során módosításokat tesz közzé a társított szolgáltatásban, folyamatokban stb., ezek nem befolyásolják a folyamatban lévő futtatásokat.
- A módosítások közzétételekor a későbbi futtatások a közzététel után kezdődtek a frissített definíciók használatával.
Közzététel az Azure Data Factoryben
Függetlenül attól, hogy az Azure Release Pipeline-nal üzembe helyezi-e a folyamatokat a közzététel automatizálásához, vagy a Resource Manager-sablonok manuális üzembe helyezésével, a közzététel az egyes összetevőkhöz tartozó adathalmazokon, társított szolgáltatásokon, folyamatokon és eseményindítókon végzett létrehozási/frissítési műveletek sorozata. A hatás ugyanaz, mint a mögöttes Rest API-hívások közvetlen indítása.
Néhány dolog az itt található műveletekből származik:
- Ezen API-hívások mindegyike szinkron, ami azt jelenti, hogy a hívás csak akkor ad vissza, ha a közzététel sikeres vagy sikertelen. Az összetevő nem lesz részleges üzembe helyezési állapotban.
- Az API-hívások nagy mértékben szekvenciálisak. Megpróbáljuk párhuzamosítani a hívásokat, miközben fenntartjuk az összetevők hivatkozási függőségeit. Az üzemelő példányok sorrendje társított szolgáltatás –> adathalmaz/integrációs modul –> folyamat –> eseményindító. Ez a sorrend biztosítja, hogy a függő összetevők megfelelően hivatkozhassanak a függőségekre. A folyamatok például az adathalmazoktól függenek, ezért a Data Factory az adathalmazok után telepíti őket.
- A társított szolgáltatások, adathalmazok stb. üzembe helyezése független a folyamatoktól. Vannak olyan helyzetek, amikor a Data Factory a folyamatfrissítések előtt frissíti a csatolt szolgáltatásokat. Erről a helyzetről a When to Stop a Trigger (Eseményindító leállítása) című szakaszban fogunk beszélni.
- Az üzembe helyezés nem törli az összetevőket a gyárakból. Az egyes összetevőtípusokhoz (folyamat, adatkészlet, társított szolgáltatás stb.) explicit módon kell meghívnia a törlési API-kat a gyárak törléséhez. Tekintse meg például az Azure Data Factory üzembe helyezését követő példaszkriptet.
- Még ha nem is nyúlt hozzá egy folyamathoz, adatkészlethez vagy társított szolgáltatáshoz, akkor is meghív egy gyors frissítési API-hívást a gyárba.
Közzétételi eseményindítók
- Az eseményindítók állapotai: elindítva vagy leállítva.
- Indítási módban nem módosíthatja az eseményindítót. A módosítások közzététele előtt le kell állítania egy eseményindítót.
- Indítási módban meghívhatja a Trigger létrehozása vagy frissítése API-t egy eseményindítón.
- Ha a hasznos adatok megváltoznak, az API meghiúsul.
- Ha a hasznos adatok változatlanok maradnak, az API sikeres lesz.
- Ez a viselkedés jelentős hatással van arra, hogy mikor kell leállítani egy eseményindítót.
Mikor kell leállítani egy eseményindítót?
Amikor éles adat-előállítóba való üzembe helyezésről van szó, és az élő eseményindítók folyamatosan elindítják a folyamatfuttatásokat, a kérdés a következő lesz: "Leállítjuk őket?".
A rövid válasz az, hogy csak a következő néhány esetben érdemes megfontolni az eseményindító leállítását:
- Az eseményindítót le kell állítania, ha frissíti az eseményindító definícióit, beleértve a mezőket, például a befejezési dátumot, a gyakoriságot és a folyamattársítást.
- Javasoljuk, hogy állítsa le az eseményindítót, ha egy élő folyamatban hivatkozott adathalmazokat vagy társított szolgáltatásokat frissít. Ha például az SQL Server hitelesítő adatait forgatja.
- Az eseményindítót akkor állíthatja le, ha a társított folyamat hibákat okoz, és sikertelen lesz, és megterheli a kiszolgálókat.
Az alábbi néhány szempontot érdemes figyelembe venni a triggerek leállításával kapcsolatban:
- Amint azt a Folyamatfuttatások az Azure Data Factoryben című szakasz ismerteti, amikor egy eseményindító elindít egy folyamatfuttatást, pillanatképet készít a folyamatról, az adatkészletről, az integrációs modulról és a társított szolgáltatásdefiníciókról. Ha a folyamat a módosítások háttérrendszerbe való feltöltése előtt fut, az eseményindító a régi verzióval indítja el a futtatásokat. A legtöbb esetben ennek rendben kell lennie.
- A közzétételi eseményindítók szakaszban leírtak szerint. Ha egy eseményindító indítási állapotban van, az nem frissíthető. Ezért ha módosítania kell az eseményindító definíciójának részleteit, állítsa le az eseményindítót a módosítások közzététele előtt.
- Az Azure Data Factory közzétételi szakaszában leírtak szerint az adathalmazok vagy a társított szolgáltatások módosításai a folyamatmódosítások előtt közzétehetők. Annak érdekében, hogy a folyamatfuttatások a megfelelő hitelesítő adatokat használják, és kommunikáljanak a megfelelő kiszolgálókkal, javasoljuk, hogy állítsa le a társított eseményindítót is.
A "kód" módosításainak előkészítése
Javasoljuk, hogy kövesse a lekéréses kérelmekre vonatkozó ajánlott eljárásokat.
- Minden fejlesztőnek saját ágakon kell dolgoznia, és a nap végén lekéréses kérelmeket kell létrehoznia az adattár fő ágához. A Lekéréses kérelmek a GitHubon és a DevOpsban című témakörben talál oktatóanyagokat.
- Amikor a kaputartók jóváhagyják a lekéréses kérelmeket, és egyesítik a módosításokat a főágban, a CI/CD folyamat elindulhat. Két javasolt módszer van a módosítások előléptetésére a környezetekben: automatizált és manuális.
- Ha készen áll a CI-/CD-folyamatok elindítására, ezt általában az Azure Pipeline Release használatával teheti meg, vagy üzembe helyezhet bizonyos egyes folyamatokat az Azure Player ezen nyílt forráskód segédprogramjának használatával.
Módosítások automatikus üzembe helyezése
Az automatizált üzembe helyezéshez az Azure Data Factory segédprogramok npm-csomagjának használatát javasoljuk. Az npm-csomag használatával ellenőrizheti a folyamat összes erőforrását, és létrehozhatja az ARM-sablonokat a felhasználó számára.
Az Azure Data Factory segédprogramok npm-csomagjának használatbavételéhez tekintse meg az automatikus közzétételt a folyamatos integráció és teljesítés érdekében.
Módosítások manuális üzembe helyezése
Miután újra egyesítette az ágat a Git-adattár fő együttműködési ágával, manuálisan közzéteheti a módosításokat az élő Azure Data Factory szolgáltatásban. A szolgáltatás felhasználói felületi vezérlést biztosít a nem fejlesztési gyárakból történő közzététel felett a Közzététel letiltása (az ADF Studióból) lehetőséggel.
Szelektív üzembe helyezés
A szelektív üzembe helyezés a GitHub és az Azure DevOps egyik funkciójára támaszkodik, más néven cseresznyeszedésre. Ez a funkció lehetővé teszi, hogy csak bizonyos módosításokat helyezzen üzembe, másokat nem. Egy fejlesztő például több folyamaton végzett módosításokat, de a mai üzembe helyezés során előfordulhat, hogy csak egyen szeretnénk módosításokat üzembe helyezni.
Kövesse az Azure DevOps és a GitHub oktatóanyagait a szükséges folyamathoz kapcsolódó véglegesítések kiválasztásához. Győződjön meg arról, hogy az összes módosítást, beleértve az eseményindítókon, a társított szolgáltatásokon és a folyamathoz társított függőségeken végzett módosításokat is, a program kiválasztotta.
Miután kiválasztotta a módosításokat, és egyesítette a fő együttműködési folyamatba, elindíthatja a CI/CD folyamatot a javasolt módosításokhoz. További információ a külső keretrendszerek szelektív üzembe helyezéséhez való gyorsjavításáról, kiválasztásáról vagy használatáról a cikk Automatizált tesztelés szakaszában leírtak szerint.
Egységtesztelés
Az egységtesztelés fontos része az új folyamatok fejlesztésének vagy a meglévő data factory-összetevők szerkesztésének, amelyek a kód összetevőinek tesztelésére összpontosítanak. A Data Factory lehetővé teszi az egyes egységek tesztelését a folyamat és az adatfolyam összetevő szintjén is a folyamat hibakeresési funkciójával.
Az adatfolyamok fejlesztésekor betekintést nyerhet az egyes átalakításokba és kódmódosításokba az adatelőnézet funkcióval , hogy egységtesztelést érjen el, mielőtt üzembe helyezené a módosításokat az éles környezetben.
A szolgáltatás élő és interaktív visszajelzést nyújt a folyamat tevékenységeiről a felhasználói felületen, amikor hibakeresést és egységtesztelést végez az Azure Data Factoryben.
Automatizált tesztelés
Az Azure Data Factoryvel több eszköz is használható az automatizált teszteléshez. Mivel a szolgáltatás JSON-entitásokként tárolja az objektumokat a szolgáltatásban, kényelmes lehet a nyílt forráskódú .NET egységtesztelési keretrendszer NUnit használata a Visual Studióval. Tekintse meg ezt a bejegyzést az Azure Data Factory automatizált tesztelésének beállítása című bejegyzésben, amely részletesen ismerteti, hogyan állíthat be automatizált egységtesztelési környezetet a gyár számára. (Külön köszönet Richard Swinbank engedélyt, hogy használja ezt a blogot.)
Az ügyfelek a CI/CD-folyamat részeként futtathatnak TEST-folyamatokat a PowerShell-lel vagy az AZ CLI-vel az üzembe helyezés előtti és utáni lépésekhez.
Az adat-előállító fő erőssége az adathalmazok paraméterezésében rejlik. Ez a funkció lehetővé teszi az ügyfelek számára, hogy ugyanazokat a folyamatokat különböző adatkészletekkel futtathassák, hogy az új fejlesztésük megfeleljen az összes forrás- és célkövetelményeknek.
Az Azure Data Factory egyéb CI/CD-keretrendszerei
A korábban ismertetett módon a beépített Git-integráció natív módon érhető el az Azure Data Factory felhasználói felületén keresztül, beleértve az egyesítést, az elágaztatást, az összehasonlítást és a közzétételt. Vannak azonban más hasznos CI/CD-keretrendszerek is, amelyek népszerűek az Azure-közösségben, amelyek alternatív mechanizmusokat biztosítanak a hasonló képességek biztosításához. Az Azure Data Factory Git módszertana ARM-sablonokon alapul, míg a Kamil Nowinski által készített ADFToolshoz hasonló keretrendszerek más megközelítést alkalmaznak, ha a gyárból származó egyes JSON-összetevőkre támaszkodnak. Azok az adatmérnökök, akik hozzáértők az Azure DevOpsban, és szívesebben dolgoznak ebben a környezetben (szemben a szolgáltatás által kínált ARM-alapú felhasználói felületi megközelítéssel), azt tapasztalhatják, hogy ez a keretrendszer jól működik számukra és olyan gyakori forgatókönyvek esetében, mint a részleges üzembe helyezés. Ez a keretrendszer egyszerűsítheti az eseményindítók kezelését is, amikor triggerállapotokat futtató környezetekben helyezik üzembe őket.
Adatszabályozás az Azure Data Factoryben
A hatékony DataOps egyik fontos eleme az adatszabályozás. Az adatintegrációs ETL-eszközök esetében az adatsorok és az összetevők kapcsolatának biztosítása fontos információkat nyújthat az adatszakértők számára az alsóbb rétegbeli változások hatásának megértéséhez. A Data Factory beépített kapcsolódó összetevőnézeteket biztosít, amelyek a gyár implementációját alkotják.
A Microsoft Purview natív integrációja tovább biztosítja az életút, a hatáselemzés és az adatkatalógus használatát.
A Microsoft Purview egységes adatszabályozási megoldást biztosít a helyszíni, többfelhős és szolgáltatási (SaaS-) adatok kezeléséhez és szabályozásához. Lehetővé teszi, hogy egyszerűen hozzon létre egy holisztikus, naprakész térképet az adatkörnyezetről automatizált adatfelderítéssel, bizalmas adatbesorolással és teljes körű adatsorokkal. Ezek a funkciók lehetővé teszik, hogy az adatfelhasználók értékes, megbízható adatkezeléshez férjenek hozzá.
A Purview-adatkatalógus natív integrációjával a Data Factory lehetővé teszi az adategységek egyszerű keresését és felderítését az adatintegrációs folyamatokban a szervezet adattulajdonának teljes területén.
Az Azure Data Factory Studio fő keresősávját használhatja adategységek kereséséhez a Purview-katalógusban.
