Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les entrepôts de données cloud et les lacs de données enrichissent les données, centralisent les informations et permettent une analytique puissante. Mais la valeur réelle des données réside dans la transformation des insights en décisions réelles et en expériences client. Pour atteindre cet objectif, les données propres et fiables doivent sortir de l’entrepôt/lacs de données dans des systèmes opérationnels. ETL inversé déplace les données de votre couche d’entrepôt de données, comme Delta Lake dans Azure Databricks ou Microsoft Fabric, vers des systèmes opérationnels. Cette étape de migration permet aux applications en aval d’utiliser les données les plus récentes et enrichies pour l’analytique opérationnelle en temps réel. Inverse ETL joue un rôle crucial dans le déverrouillage du plein potentiel de vos ressources de données en réduisant l’écart entre l’analytique et les opérations, ce qui permet une meilleure prise de décision.
Azure Cosmos DB pour NoSQL est conçu pour une latence ultra-faible, une distribution mondiale et une scalabilité NoSQL, ce qui le rend idéal pour les applications en temps réel. Avec ETL inverse, vous pouvez synchroniser des données enrichies delta dans Azure Cosmos DB, ce qui permet l’analytique opérationnelle en temps réel. Vous pouvez utiliser ce modèle pour envoyer (push) des données telles que des catalogues de produits, des informations client personnalisées, des mises à jour tarifaires, des données d’inventaire et des recommandations de fonctionnalités. Vous pouvez envoyer ces données dans votre magasin de données opérationnel, ce qui permet aux applications en aval de prendre instantanément des décisions pilotées par les données.
Architecture de la solution
Une architecture simplifiée pour implémenter l’ETL inverse est composée d’Apache Spark et d’Azure Databricks. Cette architecture extrait les données nettoyées et enrichies à partir de sources telles que les tables Delta et réécrit les données dans le magasin opérationnel dans Azure Cosmos DB pour NoSQL.
Ce diagramme comprend les composants suivants :
Sources de données qui incluent des données telles que ; données produit, données CRM, informations de commande et informations publicitaires.
Flux de travail ETL déplaçant les données des sources de données d’origine vers un entrepôt de données ou un lac de données pour stocker et enrichir les données à l’aide de solutions telles qu’Azure Databricks ou Microsoft Fabric.
Flux de travail ETL inversé pour migrer les données enrichies vers un magasin de données opérationnel à l’aide de tables Apache Spark et Delta
Magasin de données opérationnelles comme Azure Cosmos DB pour NoSQL afin d'utiliser les données enrichies dans des applications en temps réel.
Le processus ETL inverse active des scénarios tels que :
Décisions en temps réel : Les applications accèdent aux données les plus récentes sans dépendre des analystes ou des systèmes SQL.
Activation des données : Les insights sont envoyés (push) là où ils sont nécessaires, pas seulement dans les tableaux de bord.
Source unifiée de vérité : Delta Lake agit comme la couche canonique, garantissant ainsi la cohérence entre les systèmes.
Phases d’ingestion des données
Pour les scénarios tels que le magasin de fonctionnalités, les moteurs de recommandation, la détection des fraudes ou les catalogues de produits en temps réel, il est important de séparer le flux de données en deux étapes. Ces étapes supposent que vous disposez d’un pipeline ETL inversé de Delta Lake vers Azure Cosmos DB pour NoSQL.
Les étapes de ce diagramme sont les suivantes :
Chargement initial : la charge initiale est une étape de traitement par lots unique pour ingérer toutes les données historiques des tables Delta dans Azure Cosmos DB pour NoSQL. Il définit la base de votre pipeline ETL inversé en garantissant que le magasin de données opérationnel dispose de données historiques complètes. Cette charge est une étape fondamentale avant de commencer la synchronisation incrémentielle des données.
Synchronisation de capture de données modifiées (CDC) : cette étape implémente une synchronisation incrémentielle et continue des modifications des tables Delta vers Azure Cosmos DB pour NoSQL. Les modifications apportées à la table delta peuvent être capturées après l’activation du flux de données modifiées Delta (CDF). Vous pouvez implémenter la synchronisation de capture des changements de données selon une approche par lots ou basée sur le streaming.
Il existe deux options pour la synchronisation CDC (Capture des changements de données) dans Azure Cosmos DB for NoSQL :
Synchronisation CDC par lots : cette option s'exécute selon un calendrier (par exemple, tous les jours ou toutes les heures) et charge un instantané progressif des données en fonction des modifications capturées depuis la dernière version ou le dernier horodatage.
Conseil / Astuce
Basculez vers une capture instantanée Azure Cosmos DB plus récente pour éviter les incohérences de données lorsque de grands volumes incrémentiels sont chargés à partir d’une table delta vers Azure Cosmos DB pour NoSQL. Par exemple, lors de l’écriture dans un nouveau conteneur ou à l’aide d’un indicateur de version, retournez un pointeur vers une capture d’écran plus récente une fois que les nouvelles données sont entièrement chargées.
Synchronisation de la capture des changements de données modifiées en continu : cette option assure une synchronisation continue des changements incrémentiels en quasi-temps réel, maintenant le système cible à jour avec un décalage minimal. Cette option utilise le streaming structuré Apache Spark pour capturer et écrire en continu des modifications. La table delta agit comme une source de diffusion en continu avec
readChangeData = true, et le connecteur Azure Cosmos DB for NoSQL agit comme un récepteur de streaming.Conseil / Astuce
Spécifiez un emplacement de point de contrôle pour vous assurer que la progression est suivie et que les écritures en double sont évitées.
Meilleures pratiques
Utilisez des travaux par lots Apache Spark avec le connecteur Azure Cosmos DB pour NoSQL pour effectuer l’étape de chargement initiale.
Optimisez le débit d’ingestion en passant au débit provisionné standard si la charge initiale est censée consommer une grande quantité de RU/s par rapport à votre débit alloué. Plus précisément, utilisez le débit provisionné standard si les unités de requête maximales par seconde (RU/s) sont utilisées de manière cohérente pendant la plupart des durées du processus de chargement initial. N’utilisez pas le débit de mise à l’échelle automatique pour l’étape de chargement initiale dans ce scénario.
Conseil / Astuce
Si la métrique de consommation de RU normalisée est de façon cohérente 100%, la métrique indique que la charge initiale consomme de manière cohérente les unités de requête de mise à l’échelle automatique maximales (RU). Ce seuil est un indicateur clair que ce scénario s’applique à votre charge de travail et que vous devez utiliser le débit approvisionné standard.
Choisissez une clé de partition efficace qui optimise le parallélisme. Pour plus d’informations, consultez les recommandations relatives au partitionnement et à la clé de partition.
Planifiez le nombre total de partitions et le nombre total de RU/s sur toutes les partitions pour les ingestions de données volumineuses. Pour plus d’informations et de conseils, consultez les recommandations relatives au partitionnement et au débit.
Utilisez le contrôle de débit Apache Spark pour limiter la consommation d’unités de requête (RU) des travaux. Le contrôle de débit permet d’empêcher la surcharge du conteneur opérationnel cible.
Utilisez le débit de mise à l’échelle automatique lorsque cela est possible dans Azure Cosmos DB for NoSQL pour la synchronisation CDC, car les mises à l’échelle automatiques augmentent/diminuent dynamiquement les RU/s en fonction de l’utilisation. Le débit de mise à l’échelle automatique est idéal pour les charges de travail périodiques et irrégulières telles que les travaux de synchronisation CDC planifiés. Pour plus d’informations, consultez les recommandations de débit.
Estimer la durée d’ingestion de votre étape de chargement de données initiale. Pour plus d’informations et un exemple, consultez l’estimation du débit.