Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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.
Architecture
In het volgende diagram ziet u de algehele architectuur van de oplossing.
Download een Visio-bestand van deze architectuur.
Gegevensstroom
Azure Data Factory orkestreert en Azure Data Lake Storage Gen2 slaat de gegevens op.
De volgende gegevensstroom komt overeen met het vorige diagram:
De webservice-API van Contoso city parking is beschikbaar om gegevens over te dragen van de parkeerplaatsen.
Er is een Data Factory-kopieertaak die de gegevens overdraagt naar het Landing schema.
Vervolgens Azure Databricks de gegevens opschonen en standaardiseren. Hierbij worden de onbewerkte gegevens bewerkt zodat gegevenswetenschappers ze kunnen gebruiken.
Als tijdens de validatie ongeldige gegevens worden weergegeven, worden deze gedumpt in het ongeldige schema.
Important
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 verstrekt 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 toegang heeft tot de gegevens en presenteert deze aan de zakelijke gebruiker.
Components
Azure Data Factory is een cloudservice voor gegevensintegratie waarmee gegevensverplaatsing en indeling mogelijk is. In deze architectuur wordt de pijplijn gestart door gegevens van de webservice-API voor parkeren van Contoso naar de landingszone van de data lake te kopiëren.
Azure Data Lake Storage Gen2 is een schaalbare en veilige Data Lake die is gebouwd op Azure Blob Storage die ondersteuning biedt voor gelaagde opslag en herbruikbare pijplijnen. In deze architectuur fungeert het als de centrale opslagplaats voor zowel onbewerkte als verwerkte gegevens in landings-, vervormde en gevalideerde gegevenszones.
Azure Databricks is een op Apache Spark gebaseerd analyseplatform dat is ontworpen voor big data en machine learning. In deze architectuur worden twee kritieke transformatiestappen uitgevoerd. Ten eerste worden onbewerkte gegevens gereinigd en gestandaardiseerd, terwijl incorrecte records worden gefilterd naar een afzonderlijk schema. Vervolgens worden gevalideerde gegevens geconverteerd naar een indeling die geschikt is voor datawarehouseopslag en worden verwerkte gegevens beschikbaar gemaakt voor gegevenswetenschappers voor modeltraining.
Azure Key Vault is een veilige cloudservice voor het beheren van geheimen, sleutels en certificaten. In deze architectuur worden gevoelige configuratie-instellingen en referenties opgeslagen die in de pijplijn worden gebruikt, waardoor gecentraliseerd en veilig configuratiebeheer wordt geboden.
Azure Synapse Analytics is een geïntegreerde analyseservice die big data- en datawarehousingmogelijkheden combineert. In deze architectuur fungeert het als het datawarehouse dat getransformeerde gegevens uit Data Lake Storage via PolyBase opneemt voor query's en rapportage.
Power BI is een hulpprogramma voor bedrijfsanalyse waarmee interactieve visualisaties en dashboards worden geleverd. In deze architectuur maakt het verbinding met Azure Synapse Analytics om inzichten over parkeergebruiksgegevens te presenteren aan stadsplanners voor geïnformeerde besluitvorming.
Scenario-details
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.
Vereisten voor de oplossing
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 verkeerd gevormde records filteren naar een opgegeven opslaglocatie.
Ondersteuning voor bewaking.
Potentiële gebruikscases
In dit artikel wordt de fictieve stad Contoso gebruikt om het use case-scenario te beschrijven. In het verhaal bezit en beheert Contoso parkeersensoren voor de stad. 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.
Considerations
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:
Gebruik gegevenslagen in uw data lake. Behoud ongewijzigde brongegevens in de landingzone, stuur records die de validatie niet doorstaan door naar de malformed zone en transformeer gevalideerde gegevens naar een datawarehouse-klaar formaat. Door brongegevens te behouden, kunt u deze opnieuw verwerken zonder terug te keren naar het bronsysteem. Zie voor het overeenkomstige bronzen, zilveren en gouden lakehouse-patroon medaillonarchitectuur.
Maak uw gegevenspijplijnen opnieuw afspeelbaar en idempotent. Ontwerp de transformatiestappen zodanig dat ze, wanneer je ze opnieuw uitvoert op dezelfde invoer, hetzelfde resultaat opleveren. Door een pijplijn opnieuw af te spelen, kunt u een defect in transformatielogica herstellen en historische gegevens opnieuw verwerken in plaats van deze te verwijderen.
Security
Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Ontwerpcontrolelijst voor beveiliging voor meer informatie.
- Configuratie beveiligen en centraliseren. Sla verbindingsreeksen, sleutels en andere geheimen op in Key Vault in plaats van in notebooks, pijplijndefinities of broncodebeheer. Verwijs ernaar vanuit Data Factory-linked services en vanuit Azure Databricks-secret scopes, zodat elke omgeving zijn eigen waarden gebruikt.
Operationele uitmuntendheid
Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Voor meer informatie, zie Controlelijst voor ontwerpevaluatie voor Operational Excellence.
Valideer gegevens vroeg in uw pijplijn. Pas schema- en kwaliteitscontroles toe in de eerste transformatiestap en leid records die niet aan deze controles voldoen om naar het schema voor onjuist gevormde records. Vroegtijdige validatie bewaart defecte records uit downstreamlagen en geeft u een record van wat is geweigerd en waarom.
Zorg ervoor dat code voor gegevenstransformatie testbaar is. Logica voor factortransformatie in functies en modules die buiten een notebook worden uitgevoerd, zodat u deze kunt behandelen met eenheidstests in de pijplijn voor pull-aanvraagvalidatie.
Beschikken over een CI/CD-pijplijn. Bouw en breng elke omgeving uit vanuit versiebeheer in plaats van handmatig. Zie CI/CD in Azure Data Factory en CI/CD op Azure Databricks voor de technologiespecifieke mechanica.
Infrastructuur, pijplijnen en gegevens bewaken. Verzamel metrische gegevens en logboeken van elke laag, zodat een fout opduikt als een waarschuwing in plaats van als een verlopen rapport. Zie Data Factory bewaken voor meer informatie.
Dit scenario implementeren
De volgende lijst bevat de stappen op hoog niveau die nodig zijn om deze oplossing in te stellen met bijbehorende build- en release-pijplijnen.
Installatie en implementatie
Eerste installatie: Installeer eventuele vereisten, maak de Git-opslagplaats die de infrastructuur, notebook en pijplijncode bevat en stel vereiste omgevingsvariabelen in.
Implementeer Azure resources: gebruik een infrastructuur als code-implementatie, zoals Bicep of Terraform, om de Azure resources en Microsoft Entra service-principals voor elke omgeving te implementeren. Configureer afzonderlijk de Azure-pipelines definities, variabele groepen en serviceverbindingen die de infrastructuurimplementatie aanroepen.
Git-integratie instellen in ontwikkel-Data Factory: Git-integratie configureren zodat de ontwikkel-Data Factory wijzigingen vastlegt in uw 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.
Continue integratie en continue levering (CI/CD)
In het volgende diagram ziet u het CI/CD-proces en de volgorde voor de build- en release-pijplijnen.
Download een Visio-bestand van deze architectuur.
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 PR-validatiepijplijn automatisch gestart, waarmee de unittests, linting en DACPAC-builds (Data Tier Application Package) worden uitgevoerd.
Na voltooiing van de pull request validatie activeert de commit naar de hoofdbranch een build-pijplijn die alle benodigde build-artefacten publiceert.
De voltooiing van een geslaagde buildpipeline activeert de eerste fase van de releasepipeline. Door dit te doen worden de gepubliceerde buildartefacten in de ontwikkelomgeving ingezet, behalve voor Data Factory.
Ontwikkelaars publiceren handmatig naar de dev Data Factory vanuit de samenwerkingsbranch (hoofd). De handmatige publicatie zorgt ervoor dat de Azure Resource Manager-sjablonen worden bijgewerkt in de vertakking
adf_publish.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.
Zie CI/CD in Azure Data Factory voor meer informatie over het implementeren van deze fasen.
Testing
De oplossing bevat ondersteuning voor zowel eenheidstests als integratietests. Eenheidstests hebben betrekking op de Python transformatiemodules en integratietests activeren een Data Factory-pijplijn en verifiëren de uitvoer ervan als onderdeel van de release in de faseringsomgeving. Zie Unit-tests voor notebooks voor meer informatie.
Waarneembaarheid en bewaking
De oplossing ondersteunt waarneembaarheid en bewaking voor Databricks en Data Factory. Voor Databricks gebruikt u de ingebouwde auditlogboekregistratie van het platform (de system.access.audit tabel) en voert u taakbewaking uit in plaats van standaard alle diagnostische gegevens te exporteren. Als u diagnostische logboeken van Databricks moet leveren aan een Log Analytics werkruimte voor gecentraliseerde waarschuwingen, is het Premium-abonnement vereist, van toepassing op logboeken in plaats van metrische gegevens en moet u zorgvuldig toegangsbeheer uitvoeren omdat auditlogboeken gevoelige details over uw implementatie kunnen bevatten. Voor Data Factory kunt u diagnostische logboeken en metrische gegevens routeren naar een Log Analytics werkruimte en waarschuwingen instellen voor pijplijnfouten en taaklatentie. Zie Data Factory bewaken voor meer informatie.
Volgende stappen
De volgende bronnen helpen u bij het implementeren van de DataOps-procedures die in dit artikel worden beschreven.
Continue integratie en levering
Observability/monitoring
Azure Databricks
Data Factory
- Monitor Azure Data Factory met Azure Monitor
- Waarschuwingen maken om uw data factory-pijplijnen proactief te bewaken
Azure Synapse Analytics
- Resourcegebruik en queryactiviteit bewaken in Azure Synapse Analytics
- Houd de workload van uw Azure Synapse Analytics SQL-pool bij met behulp van DMVs
Azure Storage
Veerkracht en rampenherstel
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
- Best-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 de moderne Data Warehouse op Microsoft Azure