DataOps voor het moderne datawarehouse

Data Factory
Databricks
Azure DevOps
Key Vault
Synapse Analytics

Met een modern datawarehouse (MDW) kunt u al uw gegevens eenvoudig op elke schaal samenbrengen. 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 essentieel. Het helpt de productiviteit te verhogen en het risico op fouten te minimaliseren.

In dit artikel wordt beschreven hoe een fictief planbureau deze oplossing kan gebruiken. De oplossing biedt een end-to-end gegevenspijplijn die het MDW-architectuurpatroon volgt, samen met de bijbehorende DevOps- en DataOps-processen, om het gebruik van parkeerplaatsen te beoordelen en beter geïnformeerde zakelijke beslissingen te nemen.

Oplossingsvereisten

  • De mogelijkheid om gegevens te verzamelen uit verschillende bronnen of systemen.

  • Infrastructuur als code: implementeer nieuwe dev- en faseringsomgevingen (stg) op een geautomatiseerde manier.

  • Implementeer toepassingswijzigingen in verschillende omgevingen op een geautomatiseerde manier:

    • Implementeert pijplijnen voor continue integratie/continue levering (CI/CD).

    • Gebruik implementatiepoorten voor handmatige goedkeuringen.

  • Pijplijn als code: zorg ervoor dat de CI/CD-pijplijndefinities zich in broncodebeheer hebben.

  • Integratietests uitvoeren op wijzigingen met behulp van een voorbeeldgegevensset.

  • Pijplijnen uitvoeren op een geplande basis.

  • Toekomstige flexibele ontwikkeling ondersteunen, met inbegrip van de toevoeging 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 (AAS) en Power BI.

  • Ondersteuning voor 10 gelijktijdige dashboardgebruikers en 20 gelijktijdige energiegebruikers.

  • De gegevenspijplijn moet gegevensvalidatie uitvoeren en slecht presterende records naar een opgegeven archief filteren.

  • Ondersteuning voor bewaking.

  • Gecentraliseerde configuratie in een beveiligde opslag zoals Azure Key Vault.

Potentiële gebruikscases

In dit artikel wordt de fictieve stad Contoso gebruikt om het use-casescenario te beschrijven. In het verhaal is Contoso eigenaar van en beheert contoso de sensoren voor de stad. Het is ook eigenaar van de API's die verbinding maken met en gegevens van de sensoren op halen. Ze hebben een platform nodig waarmee gegevens uit veel verschillende bronnen worden verzameld. De gegevens moeten vervolgens worden gevalideerd, opschoond en getransformeerd naar een bekend schema. Contoso-planners kunnen vervolgens rapportgegevens over het gebruik van parkeerplaatsen verkennen en beoordelen met hulpprogramma's voor gegevensvisualisatie, zoals Power BI, om te bepalen of ze meer parkeerplaatsen of gerelateerde resources nodig hebben.

Beschikbaarheid van streetparking

Architectuur

In het volgende diagram ziet u de algehele architectuur van de oplossing.

Architectuurdiagram

Azure Data Factory (ADF) orchestrates en Azure Data Lake Storage (ADLS) Gen2 slaat de gegevens op:

  1. De webservice-API voor het parkeerplaats van Contoso is beschikbaar voor het overdragen van gegevens van de parkeerplaatsen.

  2. Er is een ADF-kopieer-taak die de gegevens over brengt naar het landingsschema.

  3. Vervolgens worden Azure Databricks gegevens opsschoont en standaardiseren. De onbewerkte gegevens en voorwaarden worden gebruikt, zodat gegevenswetenschappers deze kunnen gebruiken.

  4. Als de validatie slechte gegevens aan het licht komt, wordt deze in het verkeerd vormgevormde schema gegooid.

    Belangrijk

    Mensen hebben gevraagd waarom de gegevens niet worden gevalideerd voordat ze worden opgeslagen in ADLS. De reden hiervoor is dat de validatie een fout kan introduceren die de gegevensset kan beschadigd. Als u in deze stap een bug introduceert, kunt u de fout oplossen en de pijplijn opnieuw afspelen. Als u de beschadigde gegevens hebt vernietigd voordat u deze aan ADLS hebt toegevoegd, zijn de beschadigde gegevens onbruikbaar omdat u de pijplijn niet opnieuw kunt afspelen.

  5. Er is een tweede stap Azure Databricks gegevens converteert naar een indeling die u in het datawarehouse kunt opslaan.

  6. Ten slotte worden de gegevens op twee verschillende manieren door de pijplijn gebruikt:

    1. Databricks maakt de gegevens beschikbaar voor de data scientist, zodat ze modellen kunnen trainen.

    2. Polybase verplaatst de gegevens van de data lake naar Azure Synapse Analytics en Power BI toegang tot de gegevens en geeft deze aan de zakelijke gebruiker weer.

Onderdelen

De oplossing maakt gebruik van de volgende onderdelen:

De oplossing implementeren

De volgende lijst bevat de stappen op hoog niveau die nodig zijn om de oplossing Voor sensoren in te stellen met bijbehorende build- en releasepijplijnen. U vindt gedetailleerde installatiestappen en vereisten in deze opslagplaats met Azure-voorbeelden.

Installatie en implementatie

  1. Eerste installatie:installeer eventuele vereisten, importeer de Azure Samples GitHub opslagplaats in uw eigen opslagplaats en stel de vereiste omgevingsvariabelen in.

  2. Azure-resources implementeren:de oplossing wordt geleverd met een geautomatiseerd implementatiescript. Het implementeert alle benodigde Azure-resources en AAD service-principals per omgeving. Met het script worden ook Azure DevOps-pijplijnen, variabele groepen en serviceverbindingen geïmplementeerd.

  3. Git-integratie instellen in dev Data Factory:configureer git-integratie om te werken met de geïmporteerde GitHub opslagplaats.

  4. Een eerste builden release uitvoeren: maak een voorbeeldwijziging in Data Factory, zoals het inschakelen van een schematrigger, en kijk vervolgens hoe de wijziging automatisch wordt geïmplementeerd in omgevingen.

Geïmplementeerde resources

Als de implementatie is geslaagd, moeten er drie resourcesgroepen 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 deReadME DataOps - Demo van de parkeerplaatssensor voor een gedetailleerde lijst met alle resources.

Continue integratie en continue levering

In het onderstaande diagram worden het CI/CD-proces en de volgorde voor de build- en release-pijplijnen gedemonstreerd.

Afbeelding van proces en volgorde voor build en release

  1. Ontwikkelaars ontwikkelen in hun eigen sandbox-omgevingen binnen de ontwikkelaarsresourcegroep en voeren wijzigingen door in hun eigen kortd levende Git-vertakkingen. Bijvoorbeeld <developer_name>/<branch_name>.

  2. Wanneer de wijzigingen zijn voltooid, brengen ontwikkelaars een pull-aanvraag (PR) naar de main branch ter beoordeling. Als u dit doet, wordt automatisch de pijplijn voor pr-validatie in gebruik nemen, waarmee de eenheidstests, linting en DACPAC-builds (Data Tier Application Package) worden uitgevoerd.

  3. Als de validatie van de pr is voltooid, activeert de door commit naar main een build-pijplijn die alle benodigde buildartefacten publiceert.

  4. De voltooiing van een geslaagde build-pijplijn activeert de eerste fase van de release-pijplijn. Hierdoor worden de buildartefacten voor publiceren geïmplementeerd in de dev-omgeving, met uitzondering van ADF.

    Ontwikkelaars publiceren handmatig naar de ontwikkelaars-ADF vanuit de samenwerkingsvertakking (main). Met de handmatige publicatie worden Azure Resource Manager ARM-sjablonen in de adf_publish -vertakking bijgewerkt.

  5. Als de eerste fase is voltooid, wordt een handmatige goedkeuringspoort activeert.

    Bij goedkeuring gaat de release-pijplijn verder met de tweede fase, waarin wijzigingen in de stg-omgeving worden geïmplementeerd.

  6. Voer integratietests uit om wijzigingen in de stg-omgeving te testen.

  7. Wanneer de tweede fase is voltooid, activeert de pijplijn een tweede handmatige goedkeuringspoort.

    Bij goedkeuring gaat de release-pijplijn verder met de derde fase, waarin wijzigingen in de prod-omgeving worden geïmplementeerd.

Lees de sectie Build and Release Pipeline van de README voor meer informatie.

Testen

De oplossing biedt ondersteuning voor zowel eenheidstests als integratietests. Er wordt gebruikgemaakt van pytest-adf en het Nutter Testing Framework. Zie de sectie Testen van de LEESMIJ voor meer informatie.

Waarneembaarheid en bewaking

De oplossing ondersteunt waarneembaarheid en bewaking voor Databricks en Data Factory. Zie de sectie Waarneembaarheid/bewaking van de LEESMIJ voor meer informatie.

Overwegingen

De volgende lijst bevat een overzicht van de belangrijkste leerprocessen en best practices die in deze voorbeeldoplossing worden gedemonstreerd:

Notitie

Elk item in de onderstaande lijst bevat een koppeling naar de gerelateerde sectie Key Learnings in de documenten voor het voorbeeld van de oplossing voor de parkeerplaatssensor op GitHub.

Volgende stappen

Als u de oplossing wilt implementeren, volgt u de stappen in de sectie Het voorbeeld gebruiken van de Leesmij-demo DataOps - Parkeerplaatssensor.

Codevoorbeelden voor oplossingen op GitHub

Waarneembaarheid/bewaking

Azure Databricks

Data Factory

Synapse Analytics

Azure Storage

Tolerantie en herstel na noodgevallen

Azure Databricks

Data Factory

Synapse Analytics

Azure Storage

Video's

Bekijk de volgende video-opname voor een gedetailleerd overzicht van de oplossing en de belangrijkste concepten: DataDevOps for the Modern Data Warehouse on Microsoft Azure