Partager via

DataOps pour l’entrepôt de données moderne

Azure Data Factory
Azure Databricks
Azure DevOps
Azure Key Vault
Azure Synapse Analytics

Cet article décrit comment le bureau de planification d’une ville fictive peut utiliser cette solution. La solution fournit un pipeline de données de bout en bout qui suit le modèle architectural MDW ainsi que les processus DevOps et DataOps correspondants pour évaluer l’utilisation des parkings et prendre des décisions métier plus éclairées.

Architecture

Le diagramme suivant représente l’architecture globale de la solution.

Diagramme de l’architecture illustrant DataOps pour l’entrepôt de données moderne.

Téléchargez un fichier Visio de cette architecture.

Dataflow

Azure Data Factory orchestre les données et Azure Data Lake Storage Gen2 les stocke :

  1. L’API du service web des parkings de la ville de Contoso est disponible pour transférer des données à partir des places de stationnement.

  2. Un travail de copie Data Factory transfère les données dans le schéma Atterrissage.

  3. Ensuite, Azure Databricks nettoie et normalise les données. Il prend les données brutes et les conditionne afin que les scientifiques des données puissent les utiliser.

  4. Si la validation révèle des données incorrectes, elles sont vidées dans le schéma Incorrect.

    Important

    Des personnes ont demandé pourquoi les données ne sont pas validées avant d’être stockées dans Data Lake Storage. Cela est dû au fait que la validation peut introduire un bogue qui pourrait endommager le jeu de données. Si vous introduisez un bogue à cette étape, vous pouvez le corriger et relire votre pipeline. Si vous avez vidé les données incorrectes avant de les ajouter à Data Lake Storage, les données endommagées sont inutiles, car vous ne pouvez pas relire votre pipeline.

  5. Il existe une deuxième étape de transformation Azure Databricks qui convertit les données en un format que vous pouvez stocker dans l’entrepôt de données.

  6. Enfin, le pipeline utilise les données de deux manières différentes :

    1. Databricks met les données à la disposition du scientifique des données afin qu’il puisse former des modèles.

    2. PolyBase déplace les données de Data Lake vers Azure Synapse Analytics et Power BI accède aux données et les présente à l’utilisateur professionnel.

Components

  • Azure Data Factory est un service d’intégration de données basé sur le cloud qui permet le déplacement et l’orchestration des données. Dans cette architecture, elle lance le pipeline en copiant des données à partir de l’API de service web de stationnement de la ville contoso dans la zone d’atterrissage du lac de données.

  • Azure Data Lake Storage Gen2 est un lac de données évolutif et sécurisé basé sur stockage Blob Azure qui prend en charge le stockage hiérarchisé et les pipelines relectables. Dans cette architecture, elle sert de référentiel central pour les données brutes et traitées entre les zones d’atterrissage, incorrectes et validées.

  • Azure Databricks est une plateforme d’analytique basée sur Apache Spark conçue pour le Big Data et le Machine Learning. Dans cette architecture, elle effectue deux étapes de transformation critiques. Tout d’abord, il nettoie et normalise les données brutes tout en filtrant des enregistrements mal formés vers un schéma distinct. Ensuite, il convertit les données validées dans un format adapté au stockage de l’entrepôt de données et met les données traitées à la disposition des scientifiques des données pour l’apprentissage du modèle.

  • Azure Key Vault est un service cloud sécurisé pour la gestion des secrets, des clés et des certificats. Dans cette architecture, elle stocke les paramètres de configuration sensibles et les informations d’identification utilisés dans tout le pipeline, fournissant une gestion centralisée et sécurisée de la configuration.

  • Azure Synapse Analytics est un service d’analytique intégré qui combine les fonctionnalités de Big Data et d’entreposage de données. Dans cette architecture, elle sert d’entrepôt de données qui ingère des données transformées à partir de Data Lake Storage via PolyBase pour l’interrogation et la création de rapports.

  • Power BI est un outil d’analytique métier qui fournit des visualisations interactives et des tableaux de bord. Dans cette architecture, elle se connecte à Azure Synapse Analytics pour présenter des insights sur l’utilisation du stationnement aux planificateurs de ville pour prendre des décisions éclairées.

Détails du scénario

Un entrepôt de données moderne (MDW) vous permet de rassembler facilement toutes vos données à n’importe quelle échelle. Peu importe s’il s’agit de données structurées, non structurées ou semi-structurées. Vous pouvez obtenir des insights sur un entrepôt MDW via des tableaux de bord analytiques, des rapports opérationnels ou des analytiques avancées pour tous vos utilisateurs.

La configuration d’un environnement MDW pour les environnements de développement (dev) et de production (prod) est complexe. L’automatisation du processus est essentielle. Cela permet d’augmenter la productivité tout en minimisant les risques d’erreurs.

Cet article décrit comment le bureau de planification d’une ville fictive peut utiliser cette solution. La solution fournit un pipeline de données de bout en bout qui suit le modèle architectural MDW ainsi que les processus DevOps et DataOps correspondants pour évaluer l’utilisation des parkings et prendre des décisions métier plus éclairées.

Configuration requise pour la solution

  • Capacité à collecter des données à partir de sources ou de systèmes différents.

  • Infrastructure as code : déployez de nouveaux environnements dev et de préproduction (stg) de manière automatisée.

  • Déploiement de modifications d’application dans différents environnements de manière automatisée :

    • Implémentation de pipelines d’intégration continue/de livraison continue (CI/CD).

    • Utilisation de portes de déploiement pour les approbations manuelles.

  • Pipeline en tant que code : vérifiez que les définitions de pipeline CI/CD sont dans le contrôle de code source.

  • Exécution de tests d’intégration sur les modifications à l’aide d’un exemple de jeu de données.

  • Exécution de pipelines selon une planification.

  • Prise en charge du futur développement agile, dont l’ajout de charges de travail de science des données.

  • Prise en charge de la sécurité au niveau des lignes et des objets :

    • La fonctionnalité de sécurité est disponible dans SQL Database.

    • Vous pouvez également la trouver dans Azure Synapse Analytics, Azure Analysis Services et Power BI.

  • Prise en charge de 10 utilisateurs du tableau de bord simultanés et 20 utilisateurs avec pouvoir simultanés.

  • Le pipeline de données doit effectuer la validation des données et filtrer les enregistrements incorrects dans un magasin spécifié.

  • Prise en charge de la surveillance.

Cas d’usage potentiels

Cet article utilise la ville fictive de Contoso pour décrire le scénario d’utilisation. Dans le scénario, Contoso possède et gère les capteurs de stationnement de la ville. La ville est également propriétaire des API qui se connectent aux capteurs et récupèrent des données de ceux-ci. Elle a besoin d’une plateforme qui collecte les données de nombreuses sources différentes. Les données doivent ensuite être validées, nettoyées et transformées en un schéma connu. Les planificateurs de la ville de Contoso peuvent ensuite explorer et évaluer les données de rapport sur l’utilisation des parkings avec des outils de visualisation de données, comme Power BI, afin de déterminer s’ils ont besoin de plus de parkings ou de ressources associées.

Disponibilité des stationnements sur rue

Considerations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Les considérations de cette section résument les apprentissages clés et les meilleures pratiques illustrées par cette solution :

Note

Chaque considération de cette section est liée à la section Apprentissages clés connexes dans la documentation de l’exemple de solution de capteur de stationnement sur GitHub.

Security

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

Déployer ce scénario

La liste suivante contient les étapes principales requises pour configurer la solution des capteurs de stationnement avec les pipelines de build et de mise en production correspondants. Vous trouverez les étapes de configuration détaillées et les prérequis dans ce dépôt d’exemples Azure.

Installation et déploiement

  1. Configuration initiale : installez les prérequis, importez le référentiel GitHub d’exemples Azure dans votre propre référentiel et définissez les variables d’environnement requises.

  2. Déployer des ressources Azure : La solution est fournie avec un script de déploiement automatisé. Il déploie toutes les ressources Azure nécessaires et tous les principaux de service Microsoft Entra par environnement. Le script déploie également des pipelines Azure, des groupes de variables et des connexions de service.

  3. Configurer l’intégration Git dans Data Factory de développement : configurez l’intégration Git pour fonctionner avec le dépôt GitHub importé.

  4. Effectuer une build et une mise en production initiales : Créez un exemple de modification dans Data Factory, comme l’activation d’un déclencheur de planification, puis observez la modification qui se déploie automatiquement dans les environnements.

Ressources déployées

Si le déploiement réussit, trois groupes de ressources dans Azure doivent représenter trois environnements : dev, stg et prod. Il doit également exister des pipelines de build et de mise en production de bout en bout dans Azure DevOps qui peuvent déployer automatiquement des modifications dans ces trois environnements.

Pour obtenir la liste détaillée de toutes les ressources, consultez la section Ressources déployées de DataOps - Parking Sensor Demo README.

Intégration continue et livraison continue (CI/CD)

Le diagramme suivant illustre le processus CI/CD et la séquence pour les pipelines de build et de mise en production.

Diagramme montrant le processus et la séquence pour la build et la mise en production.

Téléchargez un fichier Visio de cette architecture.

  1. Les développeurs travaillent dans leurs propres environnements sandbox au sein du groupe de ressources dev et valident les modifications dans leurs propres branches Git à durée de vie courte. Par exemple : <developer_name>/<branch_name>.

  2. Une fois les modifications terminées, les développeurs soumettent une demande de tirage (pull request) à la branche primaire pour examen. Cette opération lance automatiquement le pipeline de validation de demande de tirage, qui exécute les builds de tests unitaires, de linting et de package d’application de la couche Données (DACPAC).

  3. À la fin de la validation de la demande de tirage, la validation auprès de la branche primaire déclenche un pipeline de build qui publie tous les artefacts de build nécessaires.

  4. La fin d’un pipeline de build qui a abouti déclenchera la première phase du pipeline de mise en production. Cette opération permet de déployer les artefacts de build de publication dans l’environnement de développement, à l’exception de Data Factory.

    Les développeurs publient manuellement dans Data Factory de développement à partir de la branche de collaboration (primaire). La publication manuelle met à jour les modèles Azure Resource Manager dans la branche adf_publish.

  5. La réussite de la première phase déclenche une porte d’approbation manuelle.

    Lors de l’approbation, le pipeline de mise en production passe à la deuxième phase, en déployant les modifications dans l’environnement stg.

  6. Exécutez des tests d’intégration pour tester les modifications dans l’environnement stg.

  7. Avec la réussite de la deuxième phase, le pipeline déclenche une deuxième porte d’approbation manuelle.

    Lors de l’approbation, le pipeline de mise en production passe à la troisième phase, en déployant les modifications dans l’environnement prod.

Pour plus d’informations, consultez la section Build et Release Pipeline du fichier README.

Testing

La solution prend en charge les tests unitaires et les tests d’intégration. Elle utilise pytest-Data Factory et le framework de test Nutter. Pour plus d’informations, consultez la section Test du fichier README.

Observabilité et supervision

La solution prend en charge l’observabilité et la supervision pour Databricks et Data Factory. Pour plus d’informations, consultez la section Observability/Monitoring de readME.

Étapes suivantes

Si vous souhaitez déployer la solution, suivez les étapes décrites dans la section Guide pratique pour utiliser l’exemple du fichier Lisez-moi DataOps - Démonstration des capteurs de stationnement.

Exemples de code de solution sur GitHub

Observability/monitoring

Azure Databricks

Data Factory

Azure Synapse Analytics

Azure Storage

Résilience et reprise d’activité après sinistre

Azure Databricks

Data Factory

Azure Synapse Analytics

Azure Storage

Procédure pas à pas détaillée

Pour obtenir une procédure détaillée de la solution et des concepts clés, regardez l’enregistrement vidéo suivant : DataDevOps pour l’entrepôt de données moderne sur Microsoft Azure