Ez a cikk azt ismerteti, hogyan használhatja ezt a megoldást egy fiktív várostervezési iroda. A megoldás egy, az MDW architektúra mintáját követő, végpontok közötti adatfolyamot biztosít a megfelelő DevOps- és DataOps-folyamatokkal együtt a parkolási használat felméréséhez és a megalapozottabb üzleti döntések meghozatalához.
Architektúra
Az alábbi ábra a megoldás általános architektúráját mutatja be.
Töltse le az architektúra Visio-fájlját.
Adatfolyam
Az Azure Data Factory (ADF) vezénylése és az Azure Data Lake Storage (ADLS) Gen2 a következő adatokat tárolja:
A Contoso városi parkolási webszolgáltatás API-jával adatokat továbbíthat a parkolóhelyről.
Van egy ADF másolási feladat, amely az adatokat a landing sémába továbbítja.
Ezután az Azure Databricks megtisztítja és szabványosítja az adatokat. A nyers adatokat és feltételeket az adattudósok használhatják.
Ha az ellenőrzés rossz adatokat jelenít meg, azokat a rendszer a hibásan formázott sémába alakítja.
Fontos
Kapcsolatok megkérdezte, hogy az adatok miért nincsenek érvényesítve az ADLS-ben való tárolás előtt. Ennek az az oka, hogy az ellenőrzés olyan hibát okozhat, amely az adathalmazt megsérülheti. Ha ebben a lépésben hibát vezet be, kijavíthatja a hibát, és lejátszhatja a folyamatot. Ha a rossz adatokat az ADLS-hez való hozzáadás előtt dobta, akkor a sérült adatok használhatatlanok, mert nem tudja visszajátszani a folyamatot.
Van egy második Azure Databricks-átalakítási lépés, amely az adatokat az adattárházban tárolható formátummá alakítja.
Végül a folyamat két különböző módon szolgálja ki az adatokat:
A Databricks elérhetővé teszi az adatokat az adatelemző számára, hogy betaníthassa a modelleket.
A Polybase áthelyezi az adatokat a data lake-ből az Azure Synapse Analyticsbe, és a Power BI hozzáfér az adatokhoz, és bemutatja azokat az üzleti felhasználónak.
Összetevők
A megoldás a következő összetevőket használja:
Forgatókönyv részletei
A modern adattárház (MDW) lehetővé teszi, hogy az összes adatot egyszerűen összehozza bármilyen léptékben. Nem számít, hogy strukturált, strukturálatlan vagy félig strukturált adatokról van-e szó. Az MDW-hez elemzési irányítópultokkal, operatív jelentésekkel vagy speciális elemzésekkel juthat elemzéseket az összes felhasználó számára.
Az MDW-környezet beállítása fejlesztési (fejlesztői) és éles (prod) környezetekhez egyaránt összetett. A folyamat automatizálása kulcsfontosságú. Segít növelni a termelékenységet, miközben minimalizálja a hibák kockázatát.
Ez a cikk azt ismerteti, hogyan használhatja ezt a megoldást egy fiktív várostervezési iroda. A megoldás egy, az MDW architektúra mintáját követő, végpontok közötti adatfolyamot biztosít a megfelelő DevOps- és DataOps-folyamatokkal együtt a parkolási használat felméréséhez és a megalapozottabb üzleti döntések meghozatalához.
Megoldási követelmények
Különböző forrásokból vagy rendszerekből származó adatok gyűjtésének képessége.
Infrastruktúra kódként: új fejlesztői és átmeneti (stg) környezetek automatikus üzembe helyezése.
Alkalmazásmódosítások automatikus üzembe helyezése különböző környezetekben:
Folyamatos integrációs/folyamatos kézbesítési (CI/CD) folyamatok implementálása.
Használja az üzembehelyezési kapukat a manuális jóváhagyásokhoz.
Folyamat kódként: győződjön meg arról, hogy a CI-/CD-folyamatdefiníciók forráskontrollban vannak.
Integrációs teszteket végezhet a változásokon egy mintaadatkészlet használatával.
Folyamatok ütemezett futtatása.
A jövőbeli agilis fejlesztés támogatása, beleértve az adatelemzési számítási feladatok hozzáadását is.
A sorszintű és az objektumszintű biztonság támogatása:
A biztonsági funkció az SQL Database-ben érhető el.
Az Azure Synapse Analyticsben, az Azure Analysis Servicesben (AAS) és a Power BI-ban is megtalálható.
10 egyidejű irányítópult-felhasználó és 20 egyidejű energiafelhasználó támogatása.
Az adatfolyamnak adatérvényesítést kell végeznie, és szűrnie kell a hibásan formázott rekordokat egy adott tárolóba.
Támogatás a monitorozáshoz.
Központosított konfiguráció egy biztonságos tárolóban, például az Azure Key Vaultban.
Lehetséges használati esetek
Ez a cikk Contoso fiktív városát használja a használati eset forgatókönyvének leírására. A narratívában Contoso birtokolja és kezeli a város parkolási érzékelőit. Az érzékelőkhöz csatlakozó és az adatok lekéréséhez használt API-k is a tulajdonában van. Olyan platformra van szükségük, amely számos különböző forrásból gyűjt adatokat. Az adatokat ezután ellenőrizni, megtisztítani és ismert sémává kell alakítani. A Contoso várostervezői ezután adatvizualizációs eszközökkel (például a Power BI-val) megvizsgálhatják és értékelhetik a parkolással kapcsolatos jelentésadatokat, hogy eldönthessék, több parkolásra vagy kapcsolódó erőforrásra van-e szükségük.
Megfontolások
Az alábbi lista a megoldás által bemutatott legfontosabb tanulságokat és ajánlott eljárásokat foglalja össze:
Feljegyzés
Az alábbi lista minden eleme a GitHubon elérhető parkolásérzékelős megoldás példáját tartalmazó dokumentum dokumentációjának kapcsolódó Key Tanulás s szakaszára mutat.
Az adatok ellenőrzése a folyamat korai szakaszában.
Győződjön meg arról, hogy az adatátalakítási kód tesztelhető.
A konfiguráció biztonságossá és központosítottsá tételét.
Infrastruktúra, folyamatok és adatok monitorozása.
A forgatókönyv üzembe helyezése
Az alábbi lista tartalmazza a parkolási érzékelők megoldásának megfelelő buildelési és kiadási folyamatokkal való beállításához szükséges magas szintű lépéseket. Ebben az Azure Samples-adattárban részletes beállítási lépéseket és előfeltételeket talál.
Telepítés és üzembe helyezés
Kezdeti beállítás: Telepítse az előfeltételeket, importálja az Azure Samples GitHub-adattárat a saját adattárába, és állítsa be a szükséges környezeti változókat.
Azure-erőforrások üzembe helyezése: A megoldáshoz egy automatizált üzembehelyezési szkript tartozik. Környezetenként üzembe helyezi az összes szükséges Azure-erőforrást és Microsoft Entra-szolgáltatásnevet. A szkript üzembe helyezi az Azure Pipelinest, a változócsoportokat és a szolgáltatáskapcsolatokat is.
Git-integráció beállítása a dev Data Factoryben: Konfigurálja a Git-integrációt az importált GitHub-adattárral való együttműködéshez.
Végezzen el egy kezdeti buildelést és kiadást: Hozzon létre egy mintamódosítást a Data Factoryben, például engedélyezze az ütemezési eseményindítót, majd figyelje meg, hogy a módosítás automatikusan üzembe helyezhető a környezetekben.
Üzembe helyezett erőforrások
Ha az üzembe helyezés sikeres, három erőforráscsoportnak kell lennie az Azure-ban, amelyek három környezetet jelölnek: dev, stg és prod. Az Azure DevOpsban teljes körű buildelési és kiadási folyamatoknak kell lenniük, amelyek automatikusan üzembe helyezhetik a módosításokat ebben a három környezetben.
Az összes erőforrás részletes listáját a DataOps – Parking Sensor Demo README üzembe helyezett erőforrások szakaszában találja.
Folyamatos integráció és folyamatos szolgáltatásnyújtás
Az alábbi ábra a ci/CD-folyamatot és a buildelési és kiadási folyamatok sorrendjét mutatja be.
Töltse le az architektúra Visio-fájlját.
A fejlesztők saját tesztkörnyezetekben fejlesztenek a fejlesztői erőforráscsoporton belül, és véglegesítik a módosításokat a saját rövid élettartamú git-ágaikban. Például:
<developer_name>/<branch_name>.Ha a módosítások befejeződnek, a fejlesztők lekéréses kérelmet (PR) vetnek be a fő ágra felülvizsgálat céljából. Ezzel automatikusan elindítja a PR-ellenőrzési folyamatot, amely az egységteszteket, a lintinget és az adatréteg-alkalmazáscsomagokat (DACPAC) futtatja.
A lekéréses kérelem érvényesítése után a fő véglegesítés elindít egy buildfolyamatot, amely közzéteszi az összes szükséges buildösszetevőt.
A sikeres buildelési folyamat befejezése elindítja a kiadási folyamat első szakaszát. Ezzel üzembe helyezi a közzétételi buildösszetevőket a fejlesztői környezetben, az ADF kivételével.
A fejlesztők manuálisan teszik közzé a fejlesztői ADF-ben az együttműködési ágból (fő). A manuális közzététel frissíti az Azure Resource Manager-sablonokat az
adf_publishágban.Az első szakasz sikeres befejezése manuális jóváhagyási kaput aktivál.
Jóváhagyáskor a kiadási folyamat a második fázissal folytatódik, és módosításokat helyez üzembe az stg-környezetben.
Integrációs tesztek futtatásával tesztelje az stg környezet változásait.
A második szakasz sikeres befejezése után a folyamat elindít egy második manuális jóváhagyási kaput.
Jóváhagyáskor a kiadási folyamat a harmadik fázissal folytatódik, és módosításokat helyez üzembe a prod környezetben.
További információkért olvassa el a README Build and Release Pipeline (Build and Release Pipeline ) szakaszát.
Tesztelés
A megoldás támogatja az egységtesztelést és az integrációs tesztelést is. A pytest-adf és a Nutter tesztelési keretrendszert használja. További információt a README Tesztelés szakaszában talál.
Megfigyelhetőség és monitorozás
A megoldás támogatja a Databricks és a Data Factory megfigyelhetőségét és monitorozását. További információkért lásd a README Megfigyelhetőség/Monitorozás szakaszát.
Következő lépések
Ha telepíteni szeretné a megoldást, kövesse a DataOps – Parkolóérzékelő bemutató README mintaszakaszának használati útmutatójában leírt lépéseket.
Megoldáskódminták a GitHubon
Megfigyelhetőség/monitorozás
Azure Databricks
- Az Azure Databricks monitorozása az Azure Monitorral
- Azure Databricks-feladatok monitorozása az Alkalmazás Elemzések
Data Factory
- Az Azure Data Factory monitorozása az Azure Monitorral
- Riasztások létrehozása az adat-előállítói folyamatok proaktív figyeléséhez
Synapse Analytics
- Erőforrás-kihasználtság és lekérdezési tevékenység monitorozása az Azure Synapse Analyticsben
- Az Azure Synapse Analytics SQL-készlet számítási feladatainak monitorozása DMV-k használatával
Azure Storage
Rugalmasság és vészhelyreállítás
Azure Databricks
Data Factory
Synapse Analytics
Azure Storage
- Vészhelyreállítás és tárfiók feladatátvétele
- Ajánlott eljárások az Azure Data Lake Storage Gen2 használatához – Magas rendelkezésre állás és vészhelyreállítás
- Azure Storage-redundancia
Részletes bemutató
A megoldás és a fő fogalmak részletes bemutatásához tekintse meg a következő videófelvételt: DataDevOps a Microsoft Azure modern adattárházához