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.
Dataflow
Azure Data Factory (ADF) orchestre et Azure Data Lake Storage (ADLS) Gen2 stocke les données :
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.
Il existe un travail de copie ADF qui transfère les données dans le schéma Atterrissage.
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.
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 ADLS. 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 à ADLS, les données endommagées sont inutiles, car vous ne pouvez pas relire votre pipeline.
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.
Enfin, le pipeline utilise les données de deux manières différentes :
Databricks met les données à la disposition du scientifique des données afin qu’il puisse former des modèles.
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
La solution utilise les composants suivants :
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.
Exigences de 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 (AAS) 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 supervision.
Configuration centralisée dans un stockage sécurisé comme Azure Key Vault.
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.
Considérations
La liste suivante résume les apprentissages clés et les meilleures pratiques présentés dans cette solution :
Notes
Chaque élément de la liste ci-dessous contient des liens vers la section Apprentissages clés associée dans la documentation de l’exemple de solution sur les capteurs de stationnement sur GitHub.
Faire en sorte que vos pipelines de données puissent être relus et soient idempotents.
Vérifier que le code de transformation des données est testable.
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
Installation initiale : Installez les prérequis, importez le dépôt GitHub d’exemples Azure dans votre propre dépôt et définissez les variables d’environnement requises.
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.
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é.
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 une liste détaillée de toutes les ressources, consultez la section Ressources déployées du fichier Lisez-moi DataOps - Démonstration des capteurs de stationnement.
Intégration continue et livraison continue
Le diagramme ci-dessous 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.
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>.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 la demande de tirage, qui exécute les tests unitaires, le linting et les builds de package d’application de la couche Données (DACPAC).
À 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.
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 d’ADF.
Les développeurs publient manuellement dans l’ADF de développement à partir de la branche de collaboration (primaire). La publication manuelle met à jour les modèles ARM (Azure Resource Manager) dans la branche
adf_publish.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.
Exécutez des tests d’intégration pour tester les modifications dans l’environnement stg.
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 Pipeline de build et de mise en production du fichier Lisez-moi.
Test
La solution prend en charge les tests unitaires et les tests d’intégration. Elle utilise pytest-adf et le framework de test Nutter. Pour plus d’informations, consultez la section Test du fichier Lisez-moi.
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 Observabilité/Supervision du fichier Lisez-moi.
É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
Observabilité/Supervision
Azure Databricks
- Supervision d’Azure Databricks avec Azure Monitor
- Supervision des travaux Azure Databricks avec Application Insights
Data Factory
- Superviser Azure Data Factory avec Azure Monitor
- Créer des alertes pour superviser de manière proactive vos pipelines Data Factory
Synapse Analytics
- Supervision de l’utilisation des ressources et de l’activité des requêtes dans Azure Synapse Analytics
- Superviser la charge de travail de votre pool SQL Azure Synapse Analytics à l’aide de vues de gestion dynamique
Stockage Azure
Résilience et reprise d’activité après sinistre
Azure Databricks
Data Factory
Synapse Analytics
Stockage Azure
- Récupération d'urgence et basculement de compte de stockage
- Bonnes pratiques d’utilisation d’Azure Data Lake Storage Gen2 : Haute disponibilité et reprise d’activité
- Redondance de Stockage Azure
Procédure pas à pas
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