In dit artikel wordt beschreven hoe een fictief kantoor voor stadsplanning deze oplossing kan gebruiken. De oplossing biedt een end-to-end gegevenspijplijn die het architectuurpatroon MDW volgt, samen met de bijbehorende DevOps- en DataOps-processen, om parkeren te beoordelen en meer geïnformeerde zakelijke beslissingen te nemen.
Architectuur
In het volgende diagram ziet u de algehele architectuur van de oplossing.
Een Visio-bestand van deze architectuur downloaden.
Gegevensstroom
Azure Data Factory organiseert en Azure Data Lake Storage Gen2 slaat de gegevens op:
De webservice-API van Contoso city parking is beschikbaar om gegevens over te dragen van de parkeerplaatsen.
Er is een data factory-kopieertaak waarmee de gegevens worden overgedragen naar het landingsschema.
Vervolgens worden de gegevens door Azure Databricks opgeschoond en gestandaardiseerde. Hierbij worden de onbewerkte gegevens en voorwaarden gebruikt, zodat gegevenswetenschappers deze kunnen gebruiken.
Als tijdens de validatie ongeldige gegevens worden weergegeven, worden deze gedumpt in het ongeldige schema.
Belangrijk
Mensen hebben gevraagd waarom de gegevens niet worden gevalideerd voordat ze worden opgeslagen in Data Lake Storage. De reden hiervoor is dat de validatie een fout kan veroorzaken die de gegevensset kan beschadigen. Als u tijdens deze stap een bug introduceert, kunt u de fout oplossen en uw pijplijn opnieuw afspelen. Als u de slechte gegevens hebt gedumpt voordat u deze aan Data Lake Storage hebt toegevoegd, zijn de beschadigde gegevens nutteloos omdat u uw pijplijn niet opnieuw kunt afspelen.
Er is een tweede azure Databricks-transformatiestap waarmee de gegevens worden geconverteerd naar een indeling die u in het datawarehouse kunt opslaan.
Ten slotte dient de pijplijn de gegevens op twee verschillende manieren:
Databricks maakt de gegevens beschikbaar voor de data scientist, zodat ze modellen kunnen trainen.
Polybase verplaatst de gegevens van de data lake naar Azure Synapse Analytics en Power BI opent de gegevens en presenteert deze aan de zakelijke gebruiker.
Onderdelen
De oplossing maakt gebruik van deze onderdelen:
Scenariodetails
Met een modern datawarehouse (MDW) kunt u eenvoudig al uw gegevens samenbrengen op elke schaal. Het maakt niet uit of het gestructureerde, ongestructureerde of semi-gestructureerde gegevens zijn. U kunt inzicht krijgen in een MDW via analytische dashboards, operationele rapporten of geavanceerde analyses voor al uw gebruikers.
Het instellen van een MDW-omgeving voor zowel ontwikkel- als productieomgevingen (prod) is complex. Het automatiseren van het proces is belangrijk. Het helpt de productiviteit te verhogen terwijl het risico op fouten wordt geminimaliseerd.
In dit artikel wordt beschreven hoe een fictief kantoor voor stadsplanning deze oplossing kan gebruiken. De oplossing biedt een end-to-end gegevenspijplijn die het architectuurpatroon MDW volgt, samen met de bijbehorende DevOps- en DataOps-processen, om parkeren te beoordelen en meer geïnformeerde zakelijke beslissingen te nemen.
Oplossingsvereisten
Mogelijkheid om gegevens uit verschillende bronnen of systemen te verzamelen.
Infrastructuur als code: implementeer nieuwe ontwikkel- en faseringsomgevingen (stg) op een geautomatiseerde manier.
Toepassingswijzigingen implementeren in verschillende omgevingen op een geautomatiseerde manier:
Implementeer pijplijnen voor continue integratie en continue levering (CI/CD).
Gebruik implementatiepoorten voor handmatige goedkeuringen.
Pijplijn als code: zorg ervoor dat de CI/CD-pijplijndefinities zich in broncodebeheer bevinden.
Voer integratietests uit op wijzigingen met behulp van een voorbeeldgegevensset.
Pijplijnen op geplande basis uitvoeren.
Ondersteuning voor toekomstige flexibele ontwikkeling, waaronder het toevoegen van data science-workloads.
Ondersteuning voor beveiliging op rij- en objectniveau:
De beveiligingsfunctie is beschikbaar in SQL Database.
U vindt deze ook in Azure Synapse Analytics, Azure Analysis Services en Power BI.
Ondersteuning voor 10 gelijktijdige dashboardgebruikers en 20 gelijktijdige energiegebruikers.
De gegevenspijplijn moet gegevensvalidatie uitvoeren en onjuiste records filteren op een opgegeven archief.
Ondersteuning voor bewaking.
Gecentraliseerde configuratie in een beveiligde opslag, zoals Azure Key Vault.
Potentiële gebruikscases
In dit artikel wordt gebruikgemaakt van de fictieve stad Contoso om het use-casescenario te beschrijven. In het verhaal beheert Contoso parkeersensoren voor de stad en beheert deze. Het is ook eigenaar van de API's die verbinding maken met en gegevens ophalen van de sensoren. Ze hebben een platform nodig dat gegevens uit veel verschillende bronnen verzamelt. De gegevens moeten vervolgens worden gevalideerd, opgeschoond en getransformeerd naar een bekend schema. Contoso-stadsplanners kunnen vervolgens rapportgegevens over parkeren verkennen en beoordelen met hulpprogramma's voor gegevensvisualisatie, zoals Power BI, om te bepalen of ze meer parkeer- of gerelateerde resources nodig hebben.
Overwegingen
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.
De overwegingen in deze sectie bevatten een overzicht van belangrijke leertrajecten en best practices die door deze oplossing worden gedemonstreerd:
Notitie
Elke overweging in deze sectie is gekoppeld aan de gerelateerde sectie Key Learnings in de documenten voor het voorbeeld van de parkeersensoroplossing op GitHub.
Beveiliging
Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie de controlelijst ontwerpbeoordeling voor beveiliging voor meer informatie.
Operationele topprestaties
Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie de controlelijst ontwerpbeoordeling voor Operational Excellence voor meer informatie.
Dit scenario implementeren
De volgende lijst bevat de stappen op hoog niveau die nodig zijn om de oplossing Parkeersensoren in te stellen met bijbehorende Build- en Release Pipelines. U vindt gedetailleerde installatiestappen en vereisten in deze opslagplaats met Azure Samples.
Installatie en implementatie
Eerste installatie: Installeer eventuele vereisten, importeer de GitHub-opslagplaats van Azure Samples in uw eigen opslagplaats en stel vereiste omgevingsvariabelen in.
Azure-resources implementeren: de oplossing wordt geleverd met een geautomatiseerd implementatiescript. Het implementeert alle benodigde Azure-resources en Microsoft Entra-service-principals per omgeving. Het script implementeert ook Azure Pipelines, variabele groepen en serviceverbindingen.
Git-integratie instellen in dev Data Factory: Git-integratie configureren voor gebruik met de geïmporteerde GitHub-opslagplaats.
Voer een eerste build en release uit: Maak een voorbeeldwijziging in Data Factory, zoals het inschakelen van een schematrigger en bekijk vervolgens hoe de wijziging automatisch wordt geïmplementeerd in omgevingen.
Geïmplementeerde resources
Als de implementatie is geslaagd, moeten er drie resourcegroepen in Azure zijn die drie omgevingen vertegenwoordigen: dev, stg en prod. Er moeten ook end-to-end build- en release-pijplijnen in Azure DevOps zijn die automatisch wijzigingen in deze drie omgevingen kunnen implementeren.
Zie de sectie Geïmplementeerde resources van de README van DataOps - Parking Sensor Demo voor een gedetailleerde lijst met alle resources.
Continue integratie en continue levering (CI/CD)
In het onderstaande diagram ziet u het CI/CD-proces en de volgorde voor de build- en release-pijplijnen.
Een Visio-bestand van deze architectuur downloaden.
Ontwikkelaars ontwikkelen zich in hun eigen sandbox-omgevingen binnen de ontwikkelresourcegroep en voeren wijzigingen door in hun eigen kortdurende Git-vertakkingen. Bijvoorbeeld:
<developer_name>/<branch_name>.Wanneer de wijzigingen zijn voltooid, verzenden ontwikkelaars een pull-aanvraag (PR) naar de hoofdbranch voor controle. Als u dit doet, wordt de PULL-validatiepijplijn automatisch gestart, waarmee de eenheidstests, linting en DACPAC-builds (Data Tier Application Package) worden uitgevoerd.
Na voltooiing van de pull-aanvraagvalidatie activeert de doorvoer naar de hoofdmap een build-pijplijn die alle benodigde buildartefacten publiceert.
De voltooiing van een geslaagde build-pijplijn activeert de eerste fase van de release-pijplijn. Als u dit doet, worden de buildartefacten in de ontwikkelomgeving geïmplementeerd, met uitzondering van Data Factory.
Ontwikkelaars publiceren handmatig naar de dev Data Factory vanuit de samenwerkingsbranch (hoofd). De handmatige publicatie werkt de Azure Resource Manager-sjablonen in de
adf_publishvertakking bij.De geslaagde voltooiing van de eerste fase activeert een handmatige goedkeuringspoort.
Bij goedkeuring gaat de release-pijplijn verder met de tweede fase, waarbij wijzigingen in de stg-omgeving worden geïmplementeerd.
Voer integratietests uit om wijzigingen in de stg-omgeving te testen.
Wanneer de tweede fase is voltooid, activeert de pijplijn een tweede handmatige goedkeuringspoort.
Bij goedkeuring gaat de release-pijplijn verder met de derde fase, waarbij wijzigingen in de prod-omgeving worden geïmplementeerd.
Lees de sectie Build- en Release Pipeline van de README voor meer informatie.
Testen
De oplossing bevat ondersteuning voor zowel eenheidstests als integratietests. Het maakt gebruik van pytest-Data Factory en het Nutter Testing Framework. Zie de sectie Testen van het LEESMIJ-bestand voor meer informatie.
Waarneembaarheid en bewaking
De oplossing ondersteunt waarneembaarheid en bewaking voor Databricks en Data Factory. Zie de sectie Waarneembaarheid/bewaking van het LEESMIJ-bestand voor meer informatie.
Volgende stappen
Als u de oplossing wilt implementeren, volgt u de stappen in de sectie How to use the sample section of the DataOps - Parking Sensor Demo README.
Voorbeelden van oplossingscode op GitHub
Waarneembaarheid/bewaking
Azure Databricks
Data Factory
- Azure Data Factory bewaken met Azure Monitor
- Waarschuwingen maken om uw data factory-pijplijnen proactief te bewaken
Azure Synapse Analytics
- Resourcegebruik en queryactiviteit bewaken in Azure Synapse Analytics
- De workload van uw Azure Synapse Analytics SQL-pool bewaken met behulp van DMV's
Azure Storage
Tolerantie en herstel na noodgevallen
Azure Databricks
Data Factory
- Een zelf-hostende Integration Runtime maken en configureren - Hoge beschikbaarheid en schaalbaarheid
Azure Synapse Analytics
Azure Storage
- Herstel na noodgeval en failover van opslagaccount
- Aanbevolen procedures voor het gebruik van Azure Data Lake Storage Gen2 : hoge beschikbaarheid en herstel na noodgevallen
- Azure Storage-redundantie
Gedetailleerd overzicht
Bekijk de volgende video-opname voor een gedetailleerd overzicht van de oplossing en de belangrijkste concepten: DataDevOps voor het moderne datawarehouse in Microsoft Azure