Processus d’ingestion avec analytique à l’échelle du cloud dans Azure
Azure fournit plusieurs services pour l’ingestion et la publication de données sur des plateformes natives et tierces. Différents services peuvent être utilisés, en fonction du volume, de la vélocité, de la variété et de la direction. Ces services comprennent notamment :
- Azure Data Factory est un service conçu pour tous les besoins d’application de données (alignées sur la source) et les niveaux de compétence. Écrivez votre propre code ou créez, extrayez, chargez et transformez les processus au sein de l’environnement visuel intuitif et sans code. Avec plus de 90 connecteurs créés en mode natif et sans maintenance, intégrez visuellement des sources de données sans coût supplémentaire. Les ingénieurs peuvent utiliser des points de terminaison privés et des services de liaison pour se connecter en toute sécurité aux ressources PaaS (platform as a service) Azure sans utiliser les points de terminaison publics de la ressource PaaS. Les ingénieurs peuvent utiliser des runtimes d’intégration pour étendre des pipelines à des environnements tiers, tels que des sources de données locales et d’autres clouds.
Certains de ces connecteurs prennent en charge l’utilisation en tant que source (lecture) ou en tant que récepteur (écriture). Les services natifs Azure, Oracle, SAP, etc. peuvent être utilisés en tant que sources ou récepteurs, mais tous les connecteurs ne prennent pas cette possibilité en charge. Dans ce cas, vous pouvez utiliser des connecteurs génériques comme Open Database Connectivity (ODBC), le système de fichiers ou les connecteurs SFTP (SSH File Transfer Protocol).
Azure Databricks est un service d’analyse rapide, simple et collaboratif basé sur Apache Spark. Pour un pipeline de Big Data, vous pouvez ingérer les données (brutes ou structurées) en lots dans Azure par le biais d’Azure Data Factory ou diffusées en continu en temps quasi réel avec Apache Kafka, Azure Event Hubs ou IoT Hub. Ces données aboutissent dans un lac de données en vue d’un stockage persistant à long terme dans Azure Data Lake Storage. Azure Databricks peut lire les données de plusieurs sources de données dans le cadre du workflow.
Microsoft Power Platform fournit des connecteurs à des centaines de services qui peuvent être basés sur les événements, les calendriers ou les notifications push. Microsoft Power Automate ne peut agir que sur les événements et déclencher des workflows optimisés pour des enregistrements uniques ou de petits volumes de données.
Les outils propriétaires natifs et tiers fournissent des fonctionnalités de niche pour une intégration à des systèmes spécialisés et une réplication en temps quasi réel.
- Azure Data Share prend en charge les organisations pour partager leurs données avec plusieurs clients et partenaires externes en toute sécurité. Une fois que vous avez créé un compte de partage de données et ajouté des produits de données, les clients et les partenaires peuvent être invités au partage de données. Les fournisseurs de données gardent toujours le contrôle des données qu’ils ont partagées. Azure Data Share simplifie la gestion et la supervision des données qui peuvent être partagées, du moment auquel elles ont été partagées et de celui qui les a partagées.
Important
Chaque zone d’atterrissage de données possède un groupe de ressources d’ingestion des métadonnées qui existe pour les entreprises avec un moteur d’ingestion agnostique de données. Si vous ne disposez pas de ce moteur d’infrastructure, la seule ressource recommandée est le déploiement d’un espace de travail d’analytique Azure Databricks, qui est utilisé par les intégrations de données pour exécuter une ingestion complexe. Consultez le moteur d’ingestion agnostique de données pour les modèles d’automatisation potentiels.
Considérations en matière d’ingestion pour Azure Data Factory
Si vous disposez d’un moteur d’ingestion agnostique de données, vous devez déployer un Data Factory unique pour chaque zone d’atterrissage de données dans le groupe de ressources d’ingestion et de traitement. L’espace de travail Data Factory doit être verrouillé pour les utilisateurs, et seuls les identités managées et les principaux de service auront accès au déploiement. Les opérations de zone d’atterrissage de données doivent disposer d’un accès en lecture pour permettre le débogage de pipeline.
L’application de données peut avoir son propre Data Factory pour le déplacement des données. Le fait de disposer d’un Data Factory dans chaque groupe de ressources d’application de données prend en charge une expérience complète d’intégration continue (CI) et de déploiement continu (CD) en autorisant uniquement le déploiement de pipelines à partir d’Azure DevOps ou de GitHub.
Tous les espaces de travail Data Factory utilisent principalement la fonctionnalité de réseau virtuel managé (VNet) dans Data Factory ou le runtime d’intégration auto-hébergé pour leur zone d’atterrissage de données au sein de la zone d’atterrissage de gestion des données. Les ingénieurs sont encouragés à utiliser la fonctionnalité de réseau virtuel managé pour se connecter en toute sécurité à la ressource PaaS Azure.
Toutefois, il est possible de créer des runtimes d’intégration supplémentaires pour les ingérer à partir de clouds locaux tiers et de sources de données SaaS (software as a service) tierces.
Considérations en matière d’ingestion pour Azure Databricks
Ce guide s’appuie sur les informations contenues dans :
Sécurisation de l’accès à Azure Data Lake Storage Gen2 à partir d’Azure Databricks
Utiliser Azure Databricks dans l'analytique à l'échelle du cloud dans Azure
Pour le développement, les opérations d’intégration doivent avoir leurs propres environnements Azure Databricks avant d’archiver le code à déployer dans le seul espace de travail Azure Databricks lors des tests et de la production.
Data Factory dans le groupe de ressources d’application de données (alignée sur la source) doit fournir l’infrastructure pour appeler des travaux Azure Databricks.
Les principaux de service peuvent vous aider à monter des lacs de données dans cet espace de travail. Pour plus d’informations, consultez Modèle 1 - Accès via le principal de service.
Les équipes d’applications de données peuvent déployer des travaux courts et automatisés sur Azure Databricks et s’attendre à ce que leurs clusters démarrent rapidement, exécutent le travail et se terminent. Il est recommandé de configurer des pools Azure Databricks pour réduire le temps nécessaire aux clusters pour créer des travaux.
Nous recommandons aux organisations d’utiliser Azure DevOps pour implémenter une infrastructure de déploiement pour les nouveaux pipelines. L’infrastructure sera utilisée pour créer les dossiers de jeux de données, affecter des listes de contrôle d’accès et créer une table en appliquant ou sans appliquer les contrôles d’accès à la table Databricks.
Ingestion de flux
Les organisations peuvent avoir besoin de prendre en charge des scénarios dans lesquels les éditeurs génèrent des flux d’événements très rapides. Pour ce modèle, une file d’attente de messages est recommandée, par exemple Event Hubs ou IoT Hub, pour ingérer ces flux.
Event Hubs et IoT Hub sont des services de traitement d’événements évolutifs qui peuvent ingérer et traiter de grands volumes d’événements et des données avec une faible latence et une haute fiabilité. Event Hubs est une plateforme de diffusion en continu de Big Data et un service d’ingestion d’événements. IoT Hub est un service géré qui sert de hub de messages central pour la communication bidirectionnelle entre une application IoT et les appareils qu’il gère. À partir de là, les données peuvent être exportées vers un lac de données à intervalles réguliers (lots) et traitées avec Azure Databricks en temps quasi réel via Apache Spark Streaming, Azure Data Explorer, Stream Analytics ou Time Series Insights.
La dernière zone d’atterrissage Event Hubs ou Apache Kafka au sein de la zone d’atterrissage spécifique du cas d’usage doit envoyer ses données agrégées à la couche brute du lac de données dans l’une des zones d’atterrissage de données et à Event Hubs associé groupe de ressources d’application de données (alignées sur la source) dans la zone d’atterrissage de données.
Surveiller l’ingestion
La surveillance de pipeline Azure Data Factory prête à l’emploi permet de surveiller et de résoudre les problèmes des exceptions des pipelines Data Factory. Elle réduit l’effort de développement d’une solution de surveillance et de création de rapports personnalisée.
La surveillance intégrée est l’une des principales raisons d’utiliser Azure Data Factory en tant qu’outil d’orchestration principal et Azure Policy peut aider à automatiser cette configuration.
Mapper des sources de données à des services
Les instructions de cette section mappent les services d’ingestion et de traitement aux sources qui doivent généralement être ingérées ou publiées à partir d’Azure.
Service d’ingestion :
| id | Mechanism | Notes |
|---|---|---|
| Un | Data Factory | Connecteurs intégrés et génériques (ODBC, SFTP et REST) |
| B | Azure Databricks | Code personnalisé (JDBC, JAR, etc.) |
| C | Tiers | WANdisco, Qlik et Oracle GoldenGate |
| D | Autre | Par exemple, fonctionnalités natives |
| E | Microsoft Power Platform et Azure Logic Apps | Connecteurs Microsoft Power Automate |
Mappage des sources de données aux services :
| Fournisseur | Type | Hébergée | Category | Notes | Réception de charge complète | Réception de charge incrémentielle | Ingestion en temps réel | Sortie de charge complète | Réception de charge incrémentielle | Sortie en temps réel |
|---|---|---|---|---|---|---|---|---|---|---|
| Oracle | Tabulaire | IaaS | Base de données | GoldenGate vers Azure Data Lake Storage | A, B | A, B | C | A, B | A, B | C |
| Microsoft SQL Server | Tabulaire | IaaS | Base de données | SAP Landscape Transformation et Qlik | A, B | A, B | C, D2 | A, B | A, B | C, D2 |
| MySQL | Tabulaire | IaaS | Base de données | SAP Landscape Transformation et Qlik | A, B | A, B | C, D2 | A, B | A, B | C, D2 |
| SAP BW/4HANA | Tabulaire | IaaS | Base de données | SAP Landscape Transformation et Qlik | A, B, C, D | A, B, C, D | C | - | - | - |
| SAP HANA | Tabulaire | IaaS | Base de données | SAP Landscape Transformation et Qlik | A, B, C, D | A, B, C, D | C | A, B | A, B | - |
| Apache Impala | Tabulaire | IaaS | Base de données | - | A, B | A, B | - | B | B | - |
| Microsoft SharePoint | List | SaaS | Magasin d’enregistrements | - | A, E | A, E | E | A, E | A, E | E |
| REST | REST | Divers | REST | XML, JSON, CSV | A, B, E | A, B, E | A, B, E | A, B, E | A, B, E | A, B, E |
| Microsoft Outlook | Courrier | SaaS | REST | XML, JSON, CSV | E | E | E | E | E | E |
En fonction de la destination, Azure Database Migration Service peut répliquer à partir de bases de données locales et tierces, comme Microsoft SQL Server, PostgreSQL, MySQL ou Oracle, vers un magasin de données basé sur Azure.
Étapes suivantes
Ingestion SAP avec l’analytique à l’échelle du cloud dans Azure