Den här artikeln beskriver hur ett fiktivt stadsplaneringskontor kan använda den här lösningen. Lösningen tillhandahåller en datapipeline från slutpunkt till slutpunkt som följer MDW-arkitekturmönstret, tillsammans med motsvarande DevOps- och DataOps-processer, för att utvärdera parkeringsanvändning och fatta mer välgrundade affärsbeslut.
Arkitektur
Följande diagram visar lösningens övergripande arkitektur.
Ladda ned en Visio-fil med den här arkitekturen.
Dataflöde
Azure Data Factory-orkestrering och Azure Data Lake Storage Gen2 lagrar data:
Webbtjänst-API:et för contosos stadsparkering är tillgängligt för överföring av data från parkeringsplatserna.
Det finns ett datafabrikskopieringsjobb som överför data till landningsschemat.
Därefter rensar Och standardiserar Azure Databricks data. Den tar rådata och villkor så att dataexperter kan använda dem.
Om valideringen visar felaktiga data dumpas de i det felaktiga schemat.
Viktigt!
Personer har frågat varför data inte verifieras innan de lagras i Data Lake Storage. Anledningen är att valideringen kan medföra en bugg som kan skada datauppsättningen. Om du introducerar en bugg i det här steget kan du åtgärda felet och spela upp pipelinen igen. Om du dumpade felaktiga data innan du lade till dem i Data Lake Storage är skadade data värdelösa eftersom du inte kan spela upp pipelinen igen.
Det finns ett andra Azure Databricks-transformeringssteg som konverterar data till ett format som du kan lagra i informationslagret.
Slutligen hanterar pipelinen data på två olika sätt:
Databricks gör data tillgängliga för dataexperten så att de kan träna modeller.
Polybase flyttar data från datasjön till Azure Synapse Analytics och Power BI kommer åt data och presenterar dem för företagsanvändaren.
Komponenter
Lösningen använder följande komponenter:
Information om scenario
Med ett modernt informationslager (MDW) kan du enkelt samla alla dina data i valfri skala. Det spelar ingen roll om det är strukturerade, ostrukturerade eller halvstrukturerade data. Du kan få insikter om en MDW via analytiska instrumentpaneler, driftrapporter eller avancerad analys för alla dina användare.
Det är komplext att konfigurera en MDW-miljö för både utvecklingsmiljöer (dev) och produktionsmiljöer (prod). Det är viktigt att automatisera processen. Det bidrar till att öka produktiviteten samtidigt som risken för fel minimeras.
Den här artikeln beskriver hur ett fiktivt stadsplaneringskontor kan använda den här lösningen. Lösningen tillhandahåller en datapipeline från slutpunkt till slutpunkt som följer MDW-arkitekturmönstret, tillsammans med motsvarande DevOps- och DataOps-processer, för att utvärdera parkeringsanvändning och fatta mer välgrundade affärsbeslut.
Lösningskrav
Möjlighet att samla in data från olika källor eller system.
Infrastruktur som kod: distribuera nya utvecklings- och mellanlagringsmiljöer (stg) på ett automatiserat sätt.
Distribuera programändringar i olika miljöer på ett automatiserat sätt:
Implementera CI/CD-pipelines (continuous integration and continuous delivery).
Använd distributionsportar för manuella godkännanden.
Pipeline som kod: se till att CI/CD-pipelinedefinitionerna finns i källkontrollen.
Utför integreringstester på ändringar med hjälp av en exempeldatauppsättning.
Kör pipelines enligt schemat.
Stöd för framtida agil utveckling, inklusive tillägg av datavetenskapsarbetsbelastningar.
Stöd för säkerhet på både radnivå och objektnivå:
Säkerhetsfunktionen är tillgänglig i SQL Database.
Du hittar den också i Azure Synapse Analytics, Azure Analysis Services och Power BI.
Stöd för 10 samtidiga instrumentpanelsanvändare och 20 samtidiga power-användare.
Datapipelinen ska utföra dataverifiering och filtrera bort felaktiga poster till ett angivet lager.
Stöd för övervakning.
Centraliserad konfiguration i en säker lagring som Azure Key Vault.
Potentiella användningsfall
Den här artikeln använder den fiktiva staden Contoso för att beskriva användningsfallsscenariot. I berättelsen äger och hanterar Contoso parkeringssensorer för staden. Den äger också de API:er som ansluter till och hämtar data från sensorerna. De behöver en plattform som samlar in data från många olika källor. Data måste sedan verifieras, rensas och omvandlas till ett känt schema. Contosos stadsplanerare kan sedan utforska och utvärdera rapportdata om parkeringsanvändning med datavisualiseringsverktyg, till exempel Power BI, för att avgöra om de behöver fler parkeringsresurser eller relaterade resurser.
Att tänka på
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Övervägandena i det här avsnittet sammanfattar viktiga lärdomar och metodtips som visas i den här lösningen:
Kommentar
Varje övervägande i det här avsnittet länkar till det relaterade avsnittet Key Learnings i dokumenten för exemplet med parkeringssensorlösningen på GitHub.
Säkerhet
Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.
Driftseffektivitet
Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.
Distribuera det här scenariot
Följande lista innehåller de övergripande steg som krävs för att konfigurera lösningen Parkeringssensorer med motsvarande bygg- och versionspipelines. Du hittar detaljerade installationssteg och krav i den här Azure Samples-lagringsplatsen.
Installation och distribution
Inledande installation: Installera eventuella krav, importera GitHub-lagringsplatsen Azure Samples till din egen lagringsplats och ange nödvändiga miljövariabler.
Distribuera Azure-resurser: Lösningen levereras med ett automatiserat distributionsskript. Den distribuerar alla nödvändiga Azure-resurser och Microsoft Entra-tjänstens huvudnamn per miljö. Skriptet distribuerar även Azure Pipelines, variabelgrupper och tjänstanslutningar.
Konfigurera Git-integrering i dev Data Factory: Konfigurera Git-integrering så att den fungerar med den importerade GitHub-lagringsplatsen.
Utför en första version och version: Skapa en exempeländring i Data Factory, som att aktivera en schemautlösare och se sedan ändringen distribueras automatiskt mellan miljöer.
Distribuerade resurser
Om distributionen lyckas bör det finnas tre resursgrupper i Azure som representerar tre miljöer: dev, stg och prod. Det bör också finnas bygg- och versionspipelines från slutpunkt till slutpunkt i Azure DevOps som automatiskt kan distribuera ändringar i dessa tre miljöer.
En detaljerad lista över alla resurser finns i avsnittet Distribuerade resurser i README för dataops – parkeringssensor.
Kontinuerlig integrering och kontinuerlig leverans (CI/CD)
Diagrammet nedan visar CI/CD-processen och sekvensen för bygg- och versionspipelines.
Ladda ned en Visio-fil med den här arkitekturen.
Utvecklare utvecklar i sina egna sandbox-miljöer i utvecklingsresursgruppen och genomför ändringar i sina egna kortlivade Git-grenar. Exempel:
<developer_name>/<branch_name>När ändringarna är klara skapar utvecklare en pull-begäran (PR) till huvudgrenen för granskning. Om du gör det startas automatiskt PR-valideringspipelinen, som kör versionerna enhetstester, linting och datanivåprogrampaket (DACPAC).
När PR-valideringen har slutförts utlöser incheckningen till main en bygg-pipeline som publicerar alla nödvändiga byggartefakter.
Slutförandet av en lyckad bygg-pipeline utlöser den första fasen i versionspipelinen. På så sätt distribueras publiceringsgenereringsartefakter till utvecklingsmiljön, med undantag för Data Factory.
Utvecklare publicerar manuellt till dev Data Factory från samarbetsgrenen (main). Den manuella publiceringen uppdaterar Azure Resource Manager-mallarna i grenen
adf_publish.Det lyckade slutförandet av den första fasen utlöser en manuell godkännandegrind.
Vid godkännande fortsätter versionspipelinen med den andra fasen och distribuerar ändringar till stg-miljön.
Kör integreringstester för att testa ändringar i stg-miljön.
När den andra fasen har slutförts utlöser pipelinen en andra manuell godkännandegrind.
Vid godkännande fortsätter versionspipelinen med den tredje fasen och distribuerar ändringar till prod-miljön.
Mer information finns i avsnittet Bygg- och versionspipeline i README.
Testning
Lösningen innehåller stöd för både enhetstestning och integreringstestning. Den använder pytest-Data Factory och Nutter Testing Framework. Mer information finns i avsnittet Testning i README.
Observerbarhet och övervakning
Lösningen stöder observerbarhet och övervakning för Databricks och Data Factory. Mer information finns i avsnittet Observerbarhet/övervakning i README.
Nästa steg
Om du vill distribuera lösningen följer du stegen i avsnittet Så här använder du exempelavsnittet i README för dataops – parkeringssensor.
Lösningskodexempel på GitHub
Observerbarhet/övervakning
Azure Databricks
Data Factory
- Övervaka Azure Data Factory med Azure Monitor
- Skapa aviseringar för att proaktivt övervaka dina datafabrikspipelines
Azure Synapse Analytics
- Övervaka resursanvändning och frågeaktivitet i Azure Synapse Analytics
- Övervaka din Azure Synapse Analytics SQL-poolarbetsbelastning med DMV:er
Azure Storage
Återhämtning och haveriberedskap
Azure Databricks
Data Factory
Azure Synapse Analytics
Azure Storage
- Haveriberedskap och lagringskontoredundans
- Metodtips för att använda Azure Data Lake Storage Gen2 – Hög tillgänglighet och haveriberedskap
- Azure Storage-redundans
Detaljerad genomgång
En detaljerad genomgång av lösningen och nyckelbegreppen finns i följande videoinspelning: DataDevOps för Modern Data Warehouse på Microsoft Azure