Modifier

Partager via

Traitement de données lakehouse en quasi-temps réel

Azure AI Search
Azure Cosmos DB
Azure Data Lake
Hubs d'événements Azure
Azure Synapse Analytics

Les entreprises pilotées par les données doivent assurer la synchronisation en quasi-temps réel de leurs systèmes de back-end et d’analytique avec les applications orientées clients. L’impact des transactions, des mises à jour et des modifications doit être reflété avec précision dans les processus de bout en bout, les applications associées et les systèmes OLTP (Online Transaction Processing). La latence tolérable pour refléter les modifications apportées aux applications OLTP dans les systèmes en aval qui utilisent les données peut être de quelques minutes seulement.

Cet article décrit une solution de bout en bout de traitement de données en quasi-temps réel pour synchroniser des données lakehouse. La solution utilise Azure Event Hubs, Azure Synapse Analytics et Azure Data Lake Storage pour le traitement et l’analytique des données.

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

Diagramme montrant le flux de données de la solution de traitement de données de bout en bout.

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

Dataflow

  1. La capture des changements de données est un prérequis pour permettre aux systèmes sources d’être à l’écoute des changements. Les connecteurs Debezium peuvent se connecter à différents systèmes sources et exploiter les changements à mesure qu’ils se produisent. Les connecteurs peuvent capturer les changements et produire des événements à partir de divers systèmes de gestion de bases de données relationnelles (SGBDR). L’installation d’un connecteur Debezium nécessite un système Kafka Connect.

  2. Les connecteurs extraient les données des changements et envoient les événements capturés à Azure Event Hubs. Event Hubs peut recevoir de grandes quantités de données provenant de plusieurs sources.

  3. Event Hubs envoie directement en streaming les données à des pools Spark Azure Synapse Analytics. Il peut également envoyer les données à une zone d’atterrissage Azure Data Lake Storage au format brut.

  4. D’autres sources de données par lots peuvent utiliser des pipelines Azure Synapse pour copier les données dans Data Lake Storage et les rendre accessibles pour traitement. Pour un workflow ETL (extraction, transformation et chargement) de bout en bout, il peut être nécessaire d’enchaîner différentes étapes ou d’ajouter des dépendances entre les étapes. Des pipelines Azure Synapse peuvent orchestrer les dépendances de workflow au sein du framework de traitement global.

  5. Les pools Azure Synapse Spark utilisent des API de streaming structuré Apache Spark entièrement prises en charge pour traiter les données dans le framework de streaming Spark. L’étape de traitement de données incorpore des contrôles de qualité des données et des validations de règles métier d’ordre général.

  6. Data Lake Storage stocke les données validées au format Delta Lake ouvert. Delta Lake fournit une sémantique et des transactions ACID (atomicité, cohérence, isolation et durabilité), une gestion scalable des métadonnées ainsi que des processus unifiés de streaming et de traitement de données par lots pour les lacs de données existants.

    L’utilisation d’index pour l’accélération des requêtes permet d’améliorer les performances de Delta. Les données de la zone validée Data Lake Storage peuvent également servir de source pour des opérations d’analytique et de machine learning plus avancées.

  7. Les données de la zone validée Data Lake Storage, transformées et enrichies avec plus de règles dans leur état final traité, sont chargées dans un pool SQL dédié qui permet d’exécuter des requêtes analytiques à grande échelle.

  8. Power BI utilise les données exposées par le biais du pool SQL dédié pour créer des tableaux de bord et des rapports professionnels.

  9. Vous pouvez également utiliser les données brutes capturées dans la zone d’atterrissage Data Lake Store et les données validées au format Delta pour :

    • Effectuer des analyses ad hoc et exploratoires plus approfondies par le biais de pools Azure Synapse SQL serverless.
    • Effectuer des opération de machine learning avec Azure Machine Learning.

  10. Pour certaines interfaces à faible latence, les données doivent être dénormalisées pour les latences de serveur à un chiffre. Ce scénario d’usage concerne principalement les réponses d’API. Ce scénario interroge des documents dans un magasin de données NoSQL comme Azure Cosmos DB pour obtenir des temps de réponse inférieurs à dix millisecondes.

  11. La stratégie de partitionnement Azure Cosmos DB peut ne pas se prêter à tous les modèles de requête. Si tel est le cas, vous pouvez améliorer la solution en indexant les données auxquelles les API doivent accéder avec Recherche cognitive Azure. Azure Cosmos DB et Recherche cognitive peuvent répondre à la plupart des scénarios nécessitant une faible latence dans les réponses aux requêtes.

Composants

Cette solution utilise les services Azure suivants :

  • Event Hubs est un service d’ingestion managé et distribué qui peut être mis à l’échelle pour ingérer de grandes quantités de données. Grâce au mécanisme abonné-éditeur d’Event Hubs, différentes applications peuvent envoyer des messages à des rubriques dans Event Hubs, et les consommateurs en aval peuvent se connecter aux messages et les traiter. La fonctionnalité Capture d’Event Hubs peut écrire des messages dans Data Lake Storage au format AVRO à mesure qu’ils arrivent. Cela facilite le traitement par micro-lots et les scénarios de conservation à long terme. Event Hubs offre également une API compatible Kafka et prend en charge le registre de schémas.

  • Data Lake Storage forme le sous-système de stockage qui stocke toutes les données dans des formats bruts et validés. Data Lake Storage peut gérer des transactions à grande échelle et prendre en charge différents formats et tailles de fichiers. Les espaces de noms hiérarchiques permettent d’organiser les données dans une structure de dossiers familière et prennent en charge les autorisations POSIX (Portable Operating System Interface for UniX). Le pilote ABFS (Azure Blob Filesystem) offre une API compatible Hadoop.

  • Azure Synapse Analytics est un service d’analytique illimité, qui réunit l’intégration de données, l’entreposage de données d’entreprise et des fonctionnalités analytiques pour le Big Data. Cette solution utilise les fonctionnalités suivantes de l’écosystème Azure Synapse Analytics :

    • Les pools Azure Synapse Spark offrent un runtime Spark à la demande qui améliore les performances du système Spark open source. Les clients peuvent configurer des paramètres de mise à l’échelle automatique flexibles, envoyer des travaux à distance par le biais du point de terminaison Apache Livy et utiliser l’interface basée sur les notebooks de Synapse Studio pour bénéficier d’expériences interactives.

    • Les pools Azure Synapse SQL serverless fournissent une interface permettant d’interroger les données lakehouse avec une syntaxe T-SQL familière. Il n’y a aucune infrastructure à configurer, et le déploiement de l’espace de travail Azure Synapse crée automatiquement le point de terminaison. Les pools Azure Synapse SQL serverless permettent la découverte et l’exploration de base des données en place et constituent une bonne option pour l’analyse des requêtes ad hoc des utilisateurs.

    • Les pools SQL dédiés Azure Synapse stockent les données dans des tables relationnelles avec un stockage en colonnes. Les pools SQL dédiés utilisent une architecture « scale-out » pour répartir le traitement des données sur plusieurs nœuds. Les requêtes PolyBase amènent les données dans les tables de pools SQL. Les tables peuvent se connecter à Power BI à des fins d’analyse et de création de rapports.

  • Power BI fournit une interface visuelle pour créer des rapports et des tableaux de bord et y accéder. Power BI Desktop peut se connecter à diverses sources de données, combiner les sources dans un modèle de données et créer des rapports ou des tableaux de bord. Avec Power BI, vous pouvez transformer les données en fonction des besoins métier et partager des visuels et des rapports avec d’autres utilisateurs par le biais du service Power BI.

  • Azure Cosmos DB est une base de données NoSQL multimodale managée qui prend en charge les API ouvertes telles que MongoDB et Cassandra. Cette solution utilise Azure Cosmos DB pour les applications qui nécessitent des temps de réponse inférieurs à dix millisecondes et une haute disponibilité. Azure Cosmos DB offre des écritures multirégions dans toutes les régions Azure. Vous pouvez utiliser Azure Synapse Link pour Azure Cosmos DB pour dériver des insights et effectuer des analyses sur les données en temps réel.

  • La Recherche cognitive Azure est un service de recherche cloud qui peut indexer les données dont vos applications et API ont besoin. La Recherche cognitive propose des fonctionnalités facultatives d’enrichissement par IA qui permettent d’extraire du texte et de déduire du texte à partir de fichiers non textuels. La Recherche cognitive s’intègre à des services comme Azure Data Lake Storage et Azure Cosmos DB pour faciliter l’accès aux données et leur indexation. Vous pouvez interroger les données indexées en utilisant une API REST ou le kit SDK .NET. Pour obtenir les données de deux index distincts, vous pouvez les combiner en un seul index ou utiliser des types de données complexes.

Détails du scénario

Le workflow de bout en bout pour traiter les changements en quasi-temps réel nécessite :

  • Une technologie de capture des changements de données (CDC). Les applications OLTP peuvent avoir différents magasins de données principaux, comme SQL Server, MySQL et Oracle. La première étape consiste à écouter les changements à mesure qu’ils se produisent et à les propager vers l’avant.
  • Une mémoire tampon d’ingestion pour publier les événements de changement à grande échelle. Ce service doit pouvoir gérer de grandes quantités de données à mesure que les messages arrivent. Les abonnés individuels peuvent se connecter à ce système et traiter les données.
  • Un stockage distribué et scalable pour les données telles quelles dans un format brut.
  • Un système de traitement de streams distribué et efficace qui permet aux utilisateurs de redémarrer et de gérer l’état.
  • Un système analytique qui s’exécute à grande échelle pour éclairer les décisions commerciales.
  • Une interface d’analytique en libre-service.
  • Pour les réponses d’API à faible latence, une base de données NoSQL pour stocker la représentation dénormalisée des données.
  • Dans certains cas, un système pour indexer les données, actualiser l’index à intervalles réguliers et rendre les dernières données disponibles en vue d’une consommation en aval.

Toutes les technologies précédentes doivent utiliser des constructions de sécurité pertinentes pour la sécurité de périmètre, l’authentification, l’autorisation et le chiffrement des données.

Cas d’usage potentiels

Cette solution est bien adaptée aux cas suivants :

  • Industries devant propager les changements de l’OLTP vers le traitement analytique en ligne (OLAP).
  • Applications nécessitant une transformation ou un enrichissement des données.

Le scénario de traitement de données en temps réel est particulièrement important dans le secteur des services financiers. Par exemple, si le titulaire d’une assurance, d’une carte de crédit ou d’un compte bancaire effectue un paiement, puis contacte aussitôt le service client, l’agent du support client doit disposer des dernières informations.

Des scénarios similaires s’appliquent aux secteurs de la vente au détail, du commerce et de la santé. La prise en charge de ces scénarios simplifie les opérations, ce qui entraîne une augmentation de la productivité organisationnelle et de la satisfaction des clients.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

  • Event Hubs conserve les données pendant 90 jours dans le cadre des niveaux premium et dédié. Pour les scénarios de basculement, vous pouvez configurer un espace de noms secondaire dans la région jumelée et l’activer pendant le basculement.

  • Les travaux du pool Azure Synapse Spark sont recyclés tous les sept jours à mesure que les nœuds sont mis hors service pour maintenance. Tenez compte de cette activité quand vous travaillez sur les contrats de niveau de service (SLA) liés au système. Cette limitation n’est pas un problème pour de nombreux scénarios où l’objectif de temps de récupération (RTO) est d’environ 15 minutes.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

  • Vous avez le choix entre différents niveaux Event Hubs en fonction des caractéristiques de la charge de travail. Event Hubs facture le stockage Capture séparément, en fonction de la quantité de données stockées sur Data Lake Storage.

  • Envisagez de gérer le cycle de vie des objets avec des niveaux sur Azure Data Lake Storage. À mesure que les données vieillissent, vous pouvez déplacer les données d’un niveau de stockage chaud, où vous devez accéder aux données récentes pour l’analytique, vers un niveau de stockage froid dont le prix est nettement inférieur. Le niveau de stockage froid est une option rentable pour la conservation à long terme.

  • Vous pouvez suspendre le pool SQL dédié quand vous ne vous en servez pas dans vos environnements de développement ou de test. Vous pouvez planifier un script pour suspendre le pool en fonction des besoins, ou vous pouvez suspendre manuellement le pool par le biais du portail.

  • Azure Cosmos DB propose différents modèles de provisionnement : débit provisionné manuel, serverless, mise à l’échelle automatique, etc. Envisagez d’utiliser le provisionnement serverless pour vos charges de travail de développement et de test. Vous pouvez également utiliser la mise à l’échelle automatique, où vous pouvez définir le nombre maximal de requête par seconde (RU/s) sur le conteneur. Le débit sur le conteneur est automatiquement mis à l’échelle entre 10 % du nombre maximal de RU/s (seuil inférieur) et le nombre maximal de RU/s configuré.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

  • Vous pouvez utiliser le partitionnement pour mettre à l’échelle Event Hubs. Envisagez de partitionner vos données pour conserver l’ordre des événements au moyen d’un journal de validation. Le partitionnement vous permet de créer plusieurs journaux parallèles en maximisant la capacité de débit disponible.

  • Vous pouvez configurer des pools Azure Synapse Spark avec des références SKU de machine virtuelle de petite, moyenne ou grande taille en fonction de la charge de travail. Vous pouvez également configurer la mise à l’échelle automatique sur les pools Azure Synapse Spark pour tenir compte des charges de travail imprévisibles. Si vous avez besoin de ressources de calcul supplémentaires, les clusters effectuent automatiquement un scale-up pour répondre à la demande, puis un scale-down une fois le traitement terminé.

  • Utilisez les bonnes pratiques pour concevoir des tables dans le pool SQL dédié. Les limites de performances et de scalabilité associées s’appliquent en fonction du niveau sur lequel le pool SQL s’exécute.

  • Azure Cosmos DB utilise des partitions pour mettre à l’échelle les conteneurs en fonction d’une clé de partition. Toutes les données basées sur une clé de partition forment une partition logique. Veillez à choisir la bonne stratégie de partitionnement en fonction des exigences de la charge de travail. Vous pouvez également utiliser des index pour accélérer l’extraction de données.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Autre contributeur :

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

Étapes suivantes