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

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.

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

Flux de données

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

Le flux de données suivant correspond au diagramme précédent :

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 processus de copie dans Data Factory transfère les données dans le schéma de réception.

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 malformé.

   Important

   Les personnes ont demandé pourquoi les données ne sont pas validées avant qu'elles ne soient 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 l'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 dans un format que vous pouvez stocker dans l'entrepôt de données.

6. Enfin, le pipeline fournit 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 du lac de données 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 du service web de stationnement de la ville Contoso dans la zone de réception 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 relectibles. Dans cette architecture, elle sert de référentiel central pour les données brutes et traitées parmi les zones d’atterrissage, malformées 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 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 informations 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 informations sur un entrepôt MDW via des tableaux de bord analytiques, des rapports d'activité opérationnels, ou de l'analyse avancée 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 le 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 flux de données doit effectuer la validation des données et éliminer les enregistrements mal formés vers un magasin spécifié.

• Soutien à 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 urbanistes de Contoso peuvent ensuite explorer et évaluer les données de rapport sur l’utilisation du stationnement avec des outils de visualisation des données, comme Power BI, pour déterminer s’ils ont besoin de davantage de places de stationnement ou de ressources connexes.

Considerations

Ces considérations implémentent les piliers du cadre Azure Well-Architected, comprenant des principes directeurs qui peuvent être utilisés pour améliorer la qualité de la 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 :

• Utilisez la hiérarchisation des données dans votre lac de données. Conservez les données sources non modifiées dans la zone d’atterrissage, routez les enregistrements qui échouent à la validation vers la zone mal formée et transformez les données validées dans un format prêt pour l’entrepôt. La conservation des données sources vous permet de les retraiter sans avoir à retourner au système source. Pour le modèle de lakehouse analogue en bronze, argent et or, consultez l’architecture en médaillon.

• Rendez vos pipelines de données réexécutables et idempotents. Concevez les étapes de transformation de sorte que leur réexécution sur la même entrée produise le même résultat. La relecture d’un pipeline vous permet de corriger un défaut dans la logique de transformation et de retraiter les données historiques au lieu de les ignorer.

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 plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

• Sécuriser et centraliser la configuration. Stockez des chaînes de connexion, des clés et d’autres secrets dans Key Vault au lieu des notebooks, des définitions de pipeline ou du contrôle de code source. Référencez-les à partir des services liés Data Factory et à partir de Azure Databricks étendues secrètes afin que chaque environnement résolve ses propres valeurs.

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 Liste de vérification de la conception pour l'excellence opérationnelle.

• Validez les données dès le début de votre pipeline. Appliquez des contrôles de schéma et de qualité lors de la première étape de transformation et routez les enregistrements qui échouent dans le schéma mal formé. La validation anticipée conserve les enregistrements défectueux hors des niveaux en aval et vous donne un enregistrement de ce qui a été rejeté et pourquoi.

• Vérifiez que le code de transformation des données est testable. Décomposez la logique de transformation en fonctions et modules qui s’exécutent en dehors d’un notebook afin de pouvoir les tester à l’aide de tests unitaires dans le pipeline de validation des pull requests.

• Disposer d’un pipeline CI/CD. Générez et déployez chaque environnement à partir de la gestion de versions plutôt que manuellement. Pour connaître les mécanismes spécifiques à la technologie, consultez CI/CD dans Azure Data Factory et CI/CD sur Azure Databricks.

• Surveillez l’infrastructure, les pipelines et les données. Collectez les métriques et les journaux à partir de chaque couche afin qu’une défaillance s’affiche en tant qu’alerte au lieu d’un rapport obsolète. Pour plus d’informations, consultez Monitor Data Factory.

Déployer ce scénario

La liste suivante contient les étapes générales requises pour configurer cette solution avec les pipelines de build et de mise en production correspondants.

Installation et déploiement

1. Configuration initiale : installez les prérequis, créez le référentiel Git qui contient l’infrastructure, le notebook et le code de pipeline, et définissez les variables d’environnement requises.

2. Déployer des ressources Azure : utilisez un déploiement de type infrastructure as code, tel que Bicep ou Terraform, pour déployer les ressources Azure et les principaux de service Microsoft Entra pour chaque environnement. Configurez séparément les définitions Azure Pipelines, les groupes de variables et les connexions de service qui appellent le déploiement de l’infrastructure.

3. Configurer l’intégration Git dans la fabrique de données de développement : configurer l’intégration Git afin que la fabrique de données de développement valide ses modifications dans votre dépôt.

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.

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.

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 pull request à la branche principale pour examen. Cette opération lance automatiquement le pipeline de validation de la pull request, qui effectue des compilations de tests unitaires, d'analyse statique, et de construction de package d'application de la couche de données (DACPAC).

3. À la fin de la validation de la demande de fusion, l’engagement auprès de la branche principale déclenche un pipeline de construction qui publie tous les artefacts de construction nécessaires.

4. La fin d’un pipeline de build réussi déclenchera la première phase du pipeline de déploiement. 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 le Data Factory de dev à partir de la branche de collaboration (principale). 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. Une fois la deuxième phase réussie, le pipeline déclenche un deuxième portail d’approbation manuelle.

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

Pour plus d’informations sur l’implémentation de ces étapes, consultez CI/CD dans Azure Data Factory.

Testing

La solution prend en charge les tests unitaires et les tests d’intégration. Les tests unitaires couvrent les modules Python de transformation, et les tests d’intégration déclenchent un pipeline de Data Factory et en vérifient la sortie dans le cadre du déploiement vers l’environnement de préproduction. Pour plus d’informations, consultez Tests unitaires des notebooks.

Observabilité et supervision

La solution prend en charge l’observabilité et la supervision pour Databricks et Data Factory. Pour Databricks, utilisez la journalisation d’audit intégrée de la plateforme (la table system.access.audit) ainsi que la surveillance de l’exécution des tâches, plutôt que d’exporter tous les diagnostics par défaut. Si vous devez fournir des journaux de diagnostic Databricks à un espace de travail Log Analytics pour les alertes centralisées, cette fonctionnalité nécessite le plan Premium, s’applique aux journaux plutôt qu’aux métriques et a besoin d’un contrôle d’accès prudent, car les journaux d’audit peuvent contenir des détails sensibles sur votre déploiement. Pour Data Factory, routez les journaux de diagnostic et les métriques vers un espace de travail Log Analytics et configurez des alertes sur les échecs de pipeline et la latence des travaux. Pour plus d’informations, consultez Monitor Data Factory.

Étapes suivantes

Les ressources suivantes vous aident à implémenter les pratiques DataOps décrites dans cet article.

Intégration et livraison continues

• CI/CD dans Azure Data Factory
• CI/CD sur Azure Databricks

Observability/monitoring

Azure Databricks

• Surveillance des tâches Azure Databricks à l'aide de Application Insights

Data Factory

• Surveillez Azure Data Factory avec Azure Monitor
• Créez des alertes pour superviser de manière proactive vos pipelines Data Factory

Azure Synapse Analytics

• Surveillance de l’utilisation des ressources et de l’activité de requête dans Azure Synapse Analytics
• Surveillez la charge de travail de votre pool SQL Azure Synapse Analytics à l’aide des VMD

stockage Azure

• Superviser le stockage Azure

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

Azure Databricks

• Récupération d’urgence régionale pour les clusters Azure Databricks

Data Factory

• Créer et configurer un runtime d’intégration auto-hébergé - Haute disponibilité et scalabilité

Azure Synapse Analytics

• Géosauvegardes et reprise d’activité
• Géorestauration d'un pool SQL

stockage Azure

• Récupération d’urgence et basculement de compte de stockage
• Meilleures pratiques pour l’utilisation d’Azure Data Lake Storage Gen2 – Haute disponibilité et reprise après sinistre
• Redondance du stockage Azure

Vue d’ensemble détaillée

Pour obtenir une vue d’ensemble détaillée de la solution et des concepts clés, regardez l’enregistrement vidéo suivant : DataDevOps pour le Data Warehouse moderne sur Microsoft Azure