Configurer la synchronisation en temps réel des modifications apportées aux données MongoDB Atlas dans Microsoft Fabric

Microsoft Fabric

Cet article explique comment intégrer MongoDB Atlas à Microsoft Fabric à l’aide de la fonctionnalité de mise en miroir ouverte dans Fabric. Nous recommandons cette architecture pour l’ingestion haute fidélité et à faible latence des données opérationnelles dans OneLake.

Architecture

L’accélérateur de mise en miroir MongoDB Atlas to Fabric implémente la fonctionnalité de mise en miroir ouverte. Une base de données mise en miroir ouverte dans Fabric expose une zone d’atterrissage dans OneLake. Les applications écrivent des fichiers Parquet qui contiennent des données de modification MongoDB dans cette zone d’atterrissage en suivant la spécification de mise en miroir ouverte.

Le diagramme suivant montre comment une application de réplication de référence déployée dans Azure App Service transmet des événements de changement MongoDB Atlas dans Fabric.

Diagramme d’architecture montrant comment Fabric s’intègre à MongoDB Atlas à l’aide de la mise en miroir ouverte.

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

Flux de données

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

  1. Créez une base de données mise en miroir ouverte dans Fabric via l’API REST ou le portail Fabric.

  2. Obtenez l’URL de zone d’atterrissage associée à la base de données mise en miroir.

  3. Déployez l’accélérateur de mise en miroir à l’aide de Terraform ou d’Azure Resource Manager.

  4. L’application effectue plusieurs fonctions clés :

    • Effectue le chargement initial des données historiques à partir de MongoDB
    • S’abonne aux flux de modification MongoDB pour capturer les opérations d’insertion, de mise à jour et de suppression en cours
    • Écrit les données modifiées capturées sous forme de fichiers Parquet dans la zone d’atterrissage Fabric

  5. Fabric effectue automatiquement les actions suivantes :

    1. Détecte les nouveaux fichiers Parquet dans la zone d’atterrissage
    2. Convertit les nouveaux fichiers Parquet en tables Delta qui prennent en charge l’évolution du schéma
    3. Maintient la synchronisation des tables mises en miroir avec les collections MongoDB sources
    4. Génère un modèle sémantique par défaut pour Power BI

  6. Les charges de travail Power BI, le lakehouse dans Fabric et le Fabric Data Warehouse peuvent exploiter les données synchronisées pour l'analyse des données et la création de rapports.

Components

  • La mise en miroir ouverte dans Fabric est une fonctionnalité de réplication de données managée qui synchronise les sources de données externes dans Fabric à l’aide de formats de table ouverts. Dans cette architecture, elle ingère en permanence des données modifiées MongoDB en convertissant des fichiers Parquet en tables Delta et en les gardant synchronisées avec les modifications d’Atlas MongoDB.

  • OneLake est le lac de données unifié et ouvert pour Fabric qui fournit un stockage centralisé pour toutes les charges de travail Fabric. Dans cette architecture, elle fonctionne comme la zone d’atterrissage initiale pour les données modifiées et la couche de stockage partagé auxquelles les services Fabric en aval accèdent.

  • Les lakehouses dans Fabric sont des plateformes de données unifiées qui associent le stockage de lacs de données avec des fonctionnalités d’analyse et d’interrogation SQL sur des tables Delta. Dans cette architecture, un lakehouse expose les tables Delta mises en miroir et permet un accès intégré à T‑SQL pour l'analyse et l'interrogation.

  • Les modèles sémantiques dans Fabric sont des jeux de données Power BI qui définissent des métadonnées et des relations conviviales pour prendre en charge les requêtes analytiques et les rapports. Dans cette architecture, le lakehouse les génère automatiquement pour accélérer la création de rapports et l’analytique Power BI.

  • App Service est une plateforme entièrement managée pour l’hébergement d’applications web et de services en arrière-plan. Dans cette architecture, elle héberge l’application de mise en miroir basée sur Python qui orchestre l’ingestion des modifications dans Fabric.

  • Les flux de modification MongoDB fournissent un mécanisme permettant de capturer les modifications de données en temps réel des collections MongoDB. Dans cette architecture, ils capturent les opérations d’insertion, de mise à jour et de suppression de MongoDB Atlas pour générer une synchronisation continue des données.

  • Terraform est un outil d’infrastructure en tant que code (IaC) utilisé pour approvisionner de manière déclarative des ressources cloud. Dans cette architecture, les modèles automatisent le déploiement des ressources Azure et Fabric requises.

  • Power BI est une plateforme décisionnel (BI) permettant de créer des tableaux de bord et des rapports interactifs. Dans cette architecture, elle visualise les tables Delta mises en miroir à l’aide de Direct Lake pour des analyses en temps quasi réel.

Le diagramme suivant montre l’architecture d’intégration de la mise en miroir.

Diagramme montrant l’architecture d’intégration de mise en miroir.

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

La mise en miroir ouverte permet à votre application d'écrire directement les données de modification MongoDB dans Fabric, de les convertir en format Delta et de les rendre immédiatement disponibles pour un lakehouse, un entrepôt de données, l'analytique en temps réel et Power BI.

Autres solutions

Fabric prend en charge d’autres modèles pour l’intégration à MongoDB Atlas. Ces alternatives peuvent convenir à votre charge de travail en fonction des seuils de latence, des contraintes opérationnelles ou de l’infrastructure existante.

Les sections suivantes décrivent d’autres approches d’ingestion pour différents besoins opérationnels et analytiques.

Intelligence en temps réel avec des flux d’événements et des entrepôts d’événements

Fabric Real-Time Intelligence fournit un chemin natif d’ingestion sans code utilisant le connecteur de capture de données de modification MongoDB (CDC) pour un flux d'événements. Le connecteur diffuse des événements de modification d’Atlas MongoDB directement dans Fabric.

Les flux d’événements routent les événements CDC vers les destinations suivantes :

  • Un eventhouse (base de données KQL) pour l’analytique en temps réel, la détection des anomalies et l’observabilité
  • OneLake pour le traitement en aval du lakehouse ou du Data Warehouse
  • Dossiers Lakehouse pour les charges de travail Apache Spark, SQL Analytics ou Machine Learning

Utilisez cette approche lorsque vous avez besoin des fonctionnalités suivantes :

  • Tableaux de bord en temps réel opérationnels
  • Traitement des logs et des événements à haut débit
  • Surveillance et détections basées sur KQL
  • Scénarios à faible latence sans code personnalisé

Atlas - Déclencheurs, fonctions et OneLake (modèle push)

Cette approche utilise des déclencheurs MongoDB Atlas pour appeler des fonctions de données utilisateur Fabric ou Azure Functions. La fonction écrit le document mis à jour dans OneLake à l’aide d’une API compatible avec Azure Data Lake Storage.

Diagramme d’architecture montrant les déclencheurs et fonctions MongoDB Atlas qui poussent des données vers OneLake.

Flux de données

  1. Le déclencheur Atlas détecte une opération d’insertion, de mise à jour ou de suppression.

  2. Le déclencheur appelle une fonction Atlas.

  3. La fonction Atlas envoie une charge utile vers une fonction de données utilisateur Fabric ou Azure Functions.

  4. La fonction de données utilisateur Fabric ou Azure Functions écrit le document JSON dans OneLake.

  5. Si vous le souhaitez, un pipeline Fabric transforme et charge le document dans un lakehouse ou un entrepôt de données.

Utilisez le modèle push lorsque vous avez besoin d’une ingestion en quasi temps réel, mais que vous ne pouvez pas déployer l’accélérateur de mise en miroir, ou quand vous préférez une intégration serverless basée sur les événements.

Pipelines Fabric et connecteurs MongoDB (modèle de récupération)

Les pipelines de structure incluent un connecteur MongoDB qui prend en charge MongoDB local et MongoDB Atlas.

Vous utilisez généralement des connecteurs pour les tâches suivantes :

  • Chargements de données historiques
  • Synchronisations quotidiennes ou horaires planifiées
  • Ingestion incrémentielle à l’aide de requêtes MongoDB
  • Intégration multicloud ou hybride

Les pipelines peuvent charger des documents dans un lakehouse qui utilise Delta, Parquet, Avro, JSON ou CSV. Ils peuvent également charger des documents dans Data Warehouse.

Nous recommandons ce modèle pour les charges de travail de traitement par lots ou les scénarios qui ne nécessitent pas d’ingestion en temps réel. Par exemple, vous pouvez utiliser un pipeline Fabric pour exécuter une copie nocturne à partir de MongoDB Atlas dans Data Warehouse pour la création de rapports exécutifs. Les données doivent uniquement refléter l’état de fin de jour. Par conséquent, un pipeline planifié par le connecteur MongoDB est suffisant et évite la complexité de l’ingestion continue.

Apache® et Apache Spark™ sont soit des marques déposées, soit des marques commerciales d’Apache Software Foundation aux États-Unis et/ou dans d’autres pays. L’utilisation de ces marques n’implique aucune approbation de l’Apache Software Foundation.

Architecture de connecteur pour l’intégration de MongoDB à des pipelines Fabric.

Vous pouvez également utiliser des dataflows dans Fabric pour l’intégrer à MongoDB Atlas. Le modèle de retrait convient aux scénarios de BI en libre-service ou pilotés par les analystes.

Les dataflows fournissent une option sans code axée sur Power BI pour ingérer des données MongoDB Atlas dans OneLake. Si vous utilisez Power BI comme outil d’analytique principal, vous pouvez utiliser le connecteur Dataflow Gen2 MongoDB pour les tâches suivantes :

  • Ingestion planifiée
  • Récupération des données historiques filtrées
  • Mise en forme et transformation de document sans code
  • Résultats écrits directement dans OneLake via une sortie Dataflows Gen2 standard

Intégration par lots

Vous pouvez utiliser l’intégration par lots ou micro-lots pour déplacer des données historiques ou filtrées de MongoDB Atlas vers OneLake. Les organisations peuvent utiliser des pipelines Fabric et le connecteur Spark MongoDB v10.x, qui prennent en charge les modèles d’ingestion par lots et de diffusion en continu.

  • Utilisez Spark Connector pour l’intégration et la diffusion par lots. Le connecteur MongoDB pour Spark permet une ingestion évolutive et basée sur DataFrame dans le lac de données Fabric. Il prend en charge les fonctionnalités suivantes :

    • Chargements complets de lots historiques
    • Chargements filtrés ou incrémentiels à l’aide de requêtes MongoDB
    • Diffusion en continu ou en micro-lots à l’aide d’un streaming structuré Spark
    • Écriture dans des tables Delta ou Parquet dans OneLake

    Cette approche est optimale pour les équipes qui travaillent principalement avec Spark ou pour les charges de travail qui nécessitent des transformations dans le cadre de l’ingestion.

  • Si vous le souhaitez, utilisez des pipelines Fabric pour l’ingestion par lots. Les pipelines de structure peuvent orchestrer l’ingestion par lots MongoDB via le connecteur MongoDB, mais le connecteur Spark offre plus de flexibilité pour les scénarios de traitement par lots et de diffusion en continu.

Détails du scénario

MongoDB Atlas est un magasin opérationnel commun pour les applications internes, les services clients et les intégrations non-Microsoft. Les entreprises peuvent utiliser Fabric pour unifier les données Atlas avec des sources de données relationnelles, de streaming et non structurées afin d'alimenter l'analytique, la Business Intelligence et le machine learning à grande échelle.

Cas d’usage potentiels

Vente au détail:

  • Optimisation du regroupement et de la promotion des produits
  • Client 360 et hyperpersonnalisation
  • Détection de la demande et prédiction de stockout
  • Recherche intelligente et recommandations

Banque et finance :

  • Détection et prévention des fraudes
  • Produits et offres financiers personnalisés

Télécommunications:

  • Analytique et optimisation de la qualité du réseau
  • Agrégation de télémétrie edge

Automobile:

  • Intelligence des véhicules connectés
  • Détection d’anomalies dans la communication Internet des objets (IoT)

Fabrication:

  • Maintenance prédictive
  • Optimisation de l’inventaire et de l’entrepôt

Exemple : Produits groupés pour la vente au détail

Utilisez des données de modèle de vente pour concevoir des offres groupées qui augmentent la taille et la marge du panier.

Sources de données :

  • Catalogue de produits dans MongoDB Atlas
  • Faits des ventes dans Azure SQL

Flux:

  1. Utilisez un pipeline Fabric pour ingérer des données de produit et de vente dans Data Warehouse ou un lakehouse.

  2. Appliquez des mises à jour par capture des données modifiées (CDC) ou pilotées par les événements pour une synchronisation presque en temps réel, en complément de la charge initiale.

  3. Modèles d'affinité et de copurchase, tels que l'analyse du panier d'achat, et exposition des métriques via Power BI.

Captures d’écran des étapes de pipeline et des graphiques pour le regroupement de produits, y compris les ventes par produit, année, région et affinité.

Recommandations de l’analyse :

  • Regroupez des produits, tels que le stylet et la recharge manuscrite.
  • Promouvoir l’offre groupée dans les régions à affinité élevée.

Exemple : Promouvoir des produits pour la vente au détail

Recommandez des produits complémentaires à l’aide du comportement du client, de la rentabilité et de l’affinité produit.

Approche:

  • Entraîner des modèles d'apprentissage automatique dans des notebooks Fabric Spark ou s’intégrer à Azure Machine Learning.
  • Utilisez OneLake comme magasin de fonctionnalités et servez des prédictions pour les applications Power BI ou en aval.

Capture d’écran du pipeline de données et du flux de travail Machine Learning pour la promotion des produits à l’aide du comportement du client et des fonctionnalités de produit.

Si le modèle obtient une précision élevée, il produit un ensemble hiérarchisé de recommandations de produit alternatives pour chaque client ou segment.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

  • Utilisez HTTPS et les dernières versions tls (Transport Layer Security) pour les fonctions de données utilisateur Fabric et les points de terminaison Azure Functions.
  • Validez les charges utiles entrantes en tant qu’événements de modification MongoDB.
  • Configurez l’authentification Microsoft Entra ID et le contrôle d’accès basé sur les rôles (RBAC) avec privilèges minimaux pour Fabric.
  • Configurez OneLake pour hériter des modèles de sécurité et d’authentification Data Lake Storage.
  • Utilisez MongoDB Atlas pour les contrôles intégrés pour l’accès, l’isolation réseau, le chiffrement et l’audit.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de vérification de conception pour l’optimisation des coûts.

  • Rightsize Fabric capacité et consolidez les charges de travail là où cela est raisonnable.
  • Modifiez les documents par lots pour réduire les appels de fonction et les petits fichiers.
  • Compactez et optimisez les tables de lakehouse tout en planifiant les transformations lourdes pendant les périodes creuses.
  • Utilisez la compression Parquet ou Delta, comme Snappy, pour réduire l’utilisation du stockage et améliorer les performances d’analyse.
  • Dimensionner les clusters Atlas de manière optimale et évaluer les niveaux de partitionnement et de stockage.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

  • Traitement par lots de plusieurs événements de modification pour réduire la surcharge des petits fichiers.
  • Utilisez Delta pour les requêtes Spark, SQL et BI optimisées.
  • Choisissez des stratégies de partitionnement et de distribution adaptées aux grands entrepôts.
  • Paramétrez le parallélisme du pipeline et appliquez des filtres pushdown sur des connecteurs MongoDB.
  • Contrôlez le décalage d’ingestion et implémentez les réessais ainsi que les upserts idempotents.
  • Programmer les opérations de OPTIMIZE et VACUUM pour la maintenance du lakehouse.
  • Utilisez le modèle push pour l’ingestion basée sur les événements en quasi temps réel.
  • Utilisez le modèle pull pour les charges de travail programmées, de lots ou de micro-lots.
  • Utilisez Data Warehouse pour les modèles relationnels régis et la bi d’entreprise.
  • Utilisez des points de terminaison SQL de type lakehouse pour utiliser un SQL léger sur Delta sans provisionnement d'un entrepôt.

Contributeurs

Microsoft maintient cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

Autres contributeurs :

  • Sunil Sabat | Responsable du programme principal - Équipe Azure Data Factory

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes