Architectures de Big Data

Une architecture Big Data gère l’ingestion, le traitement et l’analyse des données trop volumineuses ou complexes pour les systèmes de base de données traditionnels. Le seuil d’entrée dans le domaine du Big Data varie selon les organisations, en fonction de leurs outils et fonctionnalités utilisateur. Certaines organisations gèrent des centaines de gigaoctets de données, et d’autres organisations gèrent des centaines de téraoctets. À mesure que les outils permettant d’utiliser des jeux de données volumineux évoluent, la définition de Big Data passe uniquement de la taille des données à la valeur dérivée de l’analytique avancée. Bien que ces types de scénarios aient tendance à avoir de grandes quantités de données.

Au fil des années, le paysage des données a changé. Ce que vous pouvez faire, ou supposer pouvoir faire, avec les données a évolué. Le coût du stockage a diminué considérablement, tandis que les méthodes de collecte de données continuent de s’étendre. Certaines données arrivent à un rythme rapide et nécessitent une collecte et une observation continues. D’autres données arrivent plus lentement, mais en gros segments, et souvent sous la forme de décennies de données historiques. Vous pouvez rencontrer un problème d’analytique avancé ou un problème qui nécessite le Machine Learning pour résoudre. Les architectures Big Data s’efforcent de résoudre ces défis.

Les solutions Big Data impliquent généralement un ou plusieurs des types de charges de travail suivants :

• Traitement par lots des sources Big Data au repos
• Traitement en temps réel du Big Data en mouvement
• Exploration interactive du Big Data
• Analytique prédictive et Machine Learning

Prenez en compte les architectures Big Data lorsque vous devez effectuer les tâches suivantes :

• Stocker et traiter des données dans des volumes trop volumineux pour une base de données traditionnelle
• Transformer des données non structurées pour l’analyse et la création de rapports
• Capturer, traiter et analyser des flux de données non liés en temps réel ou avec une faible latence

Composants d’une architecture Big Data

Le diagramme suivant montre les composants logiques d’une architecture Big Data. Les solutions individuelles peuvent ne pas contenir chaque élément de ce diagramme.

Le processus commence à des sources de données. Les données sont envoyées vers le stockage de données et l’ingestion de messages en temps réel, qui sont interconnectés. Les données du stockage de données sont traitées par lots, puis sont envoyées au magasin de données analytique, puis à l’analytique et à la création de rapports, ou directement à l’analyse et à la création de rapports. Les données issues de l’ingestion de messages en temps réel sont dirigées vers le traitement des flux de données. Il accède ensuite au magasin de données analytique, puis à l’analytique et à la création de rapports, ou directement à l’analytique et à la création de rapports. Le Machine Learning pointe vers le traitement par lots et le traitement de flux.

La plupart des architectures Big Data incluent certains ou tous les composants suivants :

• Sources de données : Toutes les solutions Big Data commencent par une ou plusieurs sources de données. Voici quelques exemples :

  • Magasins de données d’application, tels que les bases de données relationnelles.
  • Fichiers statiques que les applications produisent, tels que les fichiers journaux du serveur web.
  • Sources de données en temps réel, telles que les appareils IoT (Internet des objets).

• Stockage des données : Les données pour les opérations de traitement par lots sont généralement stockées dans un magasin de fichiers distribué qui peut contenir des volumes élevés de fichiers volumineux dans différents formats. Ce type de magasin est souvent appelé data lake. Les options pour l’implémentation de ce stockage incluent des conteneurs Data Lake Store et blob dans le stockage Azure ou OneLake dans Microsoft Fabric.

• Traitement par lots : Les jeux de données sont volumineux. Par conséquent, une solution Big Data traite souvent les fichiers de données à l’aide de travaux de traitement par lots de longue durée pour filtrer, agréger et préparer les données à des fins d’analyse. En règle générale, ces travaux impliquent la lecture de fichiers sources, leur traitement et l’écriture de la sortie dans de nouveaux fichiers. Vous pouvez utiliser les options suivantes :

  • Exécutez des travaux U-SQL dans Azure Data Lake Analytics.

  • Utilisez des travaux Hive, Pig ou MapReduce personnalisés dans un cluster Hadoop Azure HDInsight.

  • Utilisez des programmes Java, Scala ou Python dans un cluster HDInsight Spark.

  • Utilisez le langage Python, Scala ou SQL dans les notebooks Azure Databricks.

  • Utilisez le langage Python, Scala ou SQL dans les notebooks Fabric.

• Ingestion de message en temps réel : Si la solution inclut des sources en temps réel, l’architecture doit capturer et stocker des messages en temps réel pour le traitement de flux. Par exemple, vous pouvez avoir un magasin de données simple qui collecte les messages entrants pour le traitement. Toutefois, de nombreuses solutions ont besoin d’un magasin d’ingestion des messages servant de mémoire tampon pour les messages et qui prend en charge un traitement de scale-out, une remise fiable et d’autres sémantiques de files d’attente de messages. Cette partie d’une architecture de diffusion en continu est souvent appelée mise en mémoire tampon de flux. Les options incluent Azure Event Hubs, Azure IoT Hub et Kafka.

• Traitement de flux : Une fois que la solution capture des messages en temps réel, elle doit les traiter en filtrant, en agrégeant et en préparant les données à des fins d’analyse. Les données de flux traitées sont ensuite écrites dans un récepteur de sortie.

  • Azure Stream Analytics est un service de traitement de flux managé qui utilise des requêtes SQL en cours d’exécution continue qui fonctionnent sur des flux non liés.

  • Vous pouvez utiliser des technologies de streaming Apache open source, telles que Spark Streaming, dans un cluster HDInsight ou Azure Databricks.

  • Azure Functions est un service de calcul serverless qui peut exécuter du code piloté par les événements, qui est idéal pour les tâches de traitement de flux légers.

  • Fabric prend en charge le traitement des données en temps réel à l’aide de flux d’événements et du traitement Spark.

• Apprentissage automatique: Pour analyser les données préparées à partir d’un traitement par lots ou de flux, vous pouvez utiliser des algorithmes de Machine Learning pour créer des modèles qui prédisent les résultats ou classifient des données. Ces modèles peuvent être entraînés sur des jeux de données volumineux. Vous pouvez utiliser les modèles résultants pour analyser de nouvelles données et effectuer des prédictions.

  Utilisez Azure Machine Learning pour effectuer ces tâches. Machine Learning fournit des outils pour créer, entraîner et déployer des modèles. Vous pouvez également utiliser des API prédéfinies à partir des services Azure AI pour les tâches de Machine Learning courantes, telles que la vision, la reconnaissance vocale, la langue et les tâches de prise de décision.

• Magasin de données analytiques : De nombreuses solutions Big Data préparent les données pour l’analyse, puis servent les données traitées dans un format structuré que les outils analytiques peuvent interroger. Le magasin de données analytiques qui sert ces requêtes peut être un entrepôt de données relationnelle de type Kimball. La plupart des solutions décisionnels traditionnelles utilisent ce type d’entrepôt de données. Vous pouvez également présenter les données via une technologie NoSQL à faible latence, telle que HBase ou une base de données Hive interactive qui fournit une abstraction des métadonnées sur les fichiers de données dans le magasin de données distribué.

  • Azure Synapse Analytics est un service managé pour l’entreposage de données basé sur le cloud à grande échelle.

  • HDInsight prend en charge Interactive Hive, HBase et Spark SQL. Ces outils peuvent servir des données à des fins d’analyse.

  • Fabric fournit différents magasins de données, notamment des bases de données SQL, des entrepôts de données, des lakehouses et des eventhouses. Ces outils peuvent servir des données à des fins d’analyse.

  • Azure fournit d’autres magasins de données analytiques, tels qu’Azure Databricks, Azure Data Explorer, Azure SQL Database et Azure Cosmos DB.

• Analytique et création de rapports : La plupart des solutions Big Data s’efforcent de fournir des insights sur les données via l’analyse et la création de rapports. Pour permettre aux utilisateurs d’analyser les données, l’architecture peut inclure une couche de modélisation des données, telle qu’un cube de traitement analytique en ligne multidimensionnel ou un modèle de données tabulaire dans Azure Analysis Services. Elle peut également prendre en charge le décisionnel libre-service, en utilisant les technologies de modélisation et de visualisation de Power BI ou Excel.

  Les scientifiques des données ou les analystes de données peuvent également analyser et signaler par le biais d’une exploration interactive des données. Pour ces scénarios, de nombreux services Azure prennent en charge les notebooks analytiques, tels que Jupyter, pour permettre à ces utilisateurs d’utiliser leurs compétences existantes avec Python ou Microsoft R. Pour l’exploration de données à grande échelle, vous pouvez utiliser Microsoft R Server, autonome ou avec Spark. Vous pouvez également utiliser Fabric pour modifier des modèles de données, ce qui offre une flexibilité et une efficacité pour la modélisation et l’analyse des données.

• Orchestration: La plupart des solutions Big Data se composent d’opérations répétées de traitement des données qui sont encapsulées dans les flux de travail. Les opérations effectuent les tâches suivantes :

  • Transformer les données sources
  • Déplacer des données entre plusieurs sources et récepteurs
  • Charger les données traitées dans un magasin de données analytique
  • Envoyer les résultats directement à un rapport ou à un tableau de bord

  Pour automatiser ces flux de travail, utilisez une technologie d’orchestration telle qu’Azure Data Factory, Fabric ou Apache Oozie et Apache Sqoop.

Architecture lambda

Lorsque vous travaillez avec des jeux de données volumineux, il peut prendre beaucoup de temps pour exécuter le type de requêtes dont les clients ont besoin. Ces requêtes ne peuvent pas être effectuées en temps réel. Et ils nécessitent souvent des algorithmes tels que MapReduce qui fonctionnent en parallèle sur l’ensemble du jeu de données. Les résultats de la requête sont stockés séparément des données brutes et utilisés pour effectuer des requêtes supplémentaires.

L’un des inconvénients de cette approche est qu’elle introduit la latence. Si le traitement prend quelques heures, une requête peut retourner des résultats qui sont âgés de plusieurs heures. Dans l’idéal, vous devez obtenir des résultats en temps réel, potentiellement avec une perte de précision et combiner ces résultats avec les résultats de l’analytique par lots.

L’architecture Lambda résout ce problème en créant deux chemins d’accès pour le flux de données. Toutes les données entrantes dans le système passent par les deux chemins suivants :

• Une couche batch (chemin d’accès froid) stocke toutes les données entrantes sous sa forme brute et effectue le traitement par lots sur les données. Le résultat de ce traitement est stocké en tant qu’affichage par lots.

• Une couche vitesse (chemin chaud) analyse les données en temps réel. Cette couche est conçue pour une faible latence, au détriment de la précision.

La couche de traitement par lots alimente une couche service qui indexe la vue de traitement par lots pour améliorer l’interrogation. La couche vitesse met à jour de la couche service avec les mises à jour incrémentielles basées sur les données les plus récentes.

La source de flux de données est un journal unifié des données d’événement. Les données sont envoyées à la couche de traitement en temps réel ou à la couche de traitement par lots. À partir de la couche vitesse, une ligne solide pointe vers le client d’analyse et un trait en pointillé vers la couche service. À partir de la couche batch, les données sont passées à la couche de service, puis au client d’analyse. La couche vitesse est étiquetée comme un chemin chaud. La couche traitement et la couche service sont étiquetées comme un chemin à froid.

Les données qui circulent dans le chemin d’accès chaud doivent être traitées rapidement en raison des exigences de latence imposées par la couche de vitesse. Le traitement rapide garantit que les données sont prêtes à être utilisées immédiatement, mais peuvent introduire une inexactitude. Par exemple, envisagez un scénario IoT dans lequel de nombreux capteurs de température envoient des données de télémétrie. La couche vitesse pourrait traiter les données entrantes dans une fenêtre temporelle coulissante.

Les données qui circulent dans le chemin froid ne sont pas soumises aux mêmes exigences de faible latence. Le chemin froid fournit un calcul de précision élevé sur les jeux de données volumineux, mais peut prendre beaucoup de temps.

Pour finir, le chemin relatif et le chemin à froid convergent au niveau de l’application cliente analytique. Si le client a besoin d’afficher en temps opportun des données potentiellement moins précises en temps réel, il obtiendra ses résultats via le chemin chaud. Dans le cas contraire, le client sélectionne les résultats à partir du chemin froid pour afficher des données moins rapides mais plus précises. En d’autres termes, le chemin réactif offre des données dans une fenêtre temporelle relativement restreinte, après laquelle les résultats peuvent être mis à jour avec des données plus précises grâce au chemin à froid.

Les données brutes stockées au niveau de la couche batch sont immuables. Les données entrantes sont ajoutées aux données existantes et les données précédentes ne sont pas remplacées. Les modifications apportées à la valeur d’une référence particulière sont stockées sous la forme d’un nouvel enregistrement d’événement horodaté. Les enregistrements d’événements horodatés autorisent la recomputation à tout moment dans l’historique des données collectées. La possibilité de recompiler la vue par lots à partir des données brutes d’origine est importante, car elle permet la création de vues à mesure que le système évolue.

Architecture kappa

Un inconvénient de l’architecture Lambda est sa complexité. La logique de traitement apparaît à deux endroits différents, les chemins froids et chauds, via différents frameworks. Ce processus conduit à dupliquer la logique de calcul et la gestion complexe de l’architecture pour les deux chemins.

L’architecture Kappa est une alternative à l’architecture Lambda. Il a les mêmes objectifs de base que l’architecture Lambda, mais toutes les données transitent par un chemin unique via un système de traitement de flux.

La source de flux de données est un journal unifié des données d’événement. Les données sont envoyées à la couche de vitesse ou au stockage à long terme. La ligne des données sources vers le stockage à long terme indique « Événements miroir vers un stockage à long terme ». Le stockage à long terme pointe vers la couche vitesse. Cette ligne lit « recalculer les événements de log depuis le stockage si nécessaire ». La couche de vitesse réfère au client d'analytique et est soulignée en vert.

Comme pour la couche batch de l’architecture Lambda, les données d’événement sont immuables et toutes sont collectées, au lieu d’un sous-ensemble de données. Les données sont ingérées en tant que flux d’événements dans un journal unifié distribué et tolérant aux pannes. Ces événements sont classés, et l’état actuel d’un événement change uniquement lorsqu’un nouvel événement est ajouté. Comme pour la couche de vitesse de l’architecture Lambda, tous les traitements d’événements sont effectués sur le flux d’entrée et conservés en tant qu’affichage en temps réel.

Si vous devez recompiler l’ensemble du jeu de données (équivalent à ce que fait la couche batch dans l’architecture Lambda), vous pouvez relire le flux. Ce processus utilise généralement le parallélisme pour effectuer le calcul en temps voulu.

Architecture de Lakehouse

Un lac de données est un référentiel de données centralisé qui stocke des données structurées (tables de base de données), des données semi-structurées (fichiers XML) et des données non structurées (images et fichiers audio). Ces données sont au format brut, d’origine et ne nécessitent pas de schéma prédéfini. Un lac de données peut gérer de grands volumes de données. Il convient donc au traitement et à l’analytique big data. Les lacs de données utilisent des solutions de stockage à faible coût, qui offrent un moyen économique de stocker de grandes quantités de données.

Un entrepôt de données est un référentiel centralisé qui stocke des données structurées et semi-structurées à des fins de création de rapports, d’analyse et de décisionnel. Les entrepôts de données peuvent vous aider à prendre des décisions éclairées en fournissant une vue cohérente et complète de vos données.

L’architecture Lakehouse combine les meilleurs éléments des lacs de données et des entrepôts de données. Le modèle vise à fournir une plateforme unifiée qui prend en charge les données structurées et non structurées, ce qui permet une gestion et une analytique efficaces des données. Ces systèmes utilisent généralement un stockage cloud à faible coût sous formats ouverts, tels que Parquet ou Optimized Row Columnar (ORC), pour stocker aussi bien les données brutes que les données traitées.

Les cas d’usage courants d’une architecture lakehouse sont les suivants :

• Analytique unifiée : Idéal pour les organisations qui ont besoin d’une plateforme unique pour l’analyse des données historiques et en temps réel

• Apprentissage automatique: Prend en charge les charges de travail d’analytique et d’apprentissage automatique avancées en intégrant des fonctionnalités de gestion des données

• Gouvernance des données : Garantit la conformité et la qualité des données dans les jeux de données volumineux

IdO

L’IoT représente tout appareil qui se connecte à Internet et envoie ou reçoit des données. Les appareils IoT incluent des PC, des téléphones mobiles, des montres intelligentes, des thermostats intelligents, des réfrigérateurs intelligents, des automobiles connectées et des implants de surveillance cardiaque.

Le nombre d’appareils connectés augmente chaque jour, et ainsi de suite la quantité de données qu’ils génèrent. Ces données sont souvent collectées dans des environnements qui ont des contraintes importantes et parfois une latence élevée. Dans d’autres cas, des milliers ou millions d’appareils envoient des données à partir d’environnements à faible latence, ce qui nécessite une ingestion et un traitement rapides. Vous devez planifier correctement la gestion de ces contraintes et des exigences uniques.

Les architectures basées sur les événements sont des éléments essentiels dans les solutions IoT. Le diagramme suivant montre une architecture logique pour IoT. Le diagramme met en évidence les composants de streaming d’événements de l’architecture.

Le flux de données commence par les appareils sur la gauche, connectés à une passerelle de champ, qui se connecte ensuite à une passerelle cloud. La passerelle cloud se connecte à différentes tâches via le traitement de flux. Les tâches incluent le stockage à froid, l’analytique des chemins d’accès chaud, les notifications et le Machine Learning. Batch Analytics pointe vers le stockage à froid. Le traitement de flux pointe vers le serveur principal de l’application, qui pointe vers la commande et le contrôle, l’API d’approvisionnement et le Registre des appareils. L’API d’approvisionnement pointe vers le registre d’appareils. Commande et contrôle pointe vers la passerelle locale d’origine ainsi qu’à d’autres appareils, mais pas aux appareils d’origine du flux de données.

La passerelle cloud ingère les événements d’appareils à la limite du cloud via un système de messagerie fiable et à faible latence.

Les appareils peuvent envoyer des événements directement à la passerelle cloud ou via une passerelle de champ. Une passerelle de champ est un appareil ou un logiciel spécialisé, généralement colocalisée avec les appareils, qui reçoit les événements et les transfère à la passerelle cloud. La passerelle de champ peut également prétraiter les événements d’appareil bruts, notamment l’exécution de fonctions de filtrage, d’agrégation ou de transformation de protocole.

Après l’ingestion, les événements passent par un ou plusieurs processeurs de flux qui peuvent acheminer les données vers des destinations, telles que le stockage, ou effectuer des analyses et d’autres traitements.

Les types courants de traitement sont les suivants :

• Écriture de données d’événement dans un stockage froid pour archivage ou analyse en mode batch.

• Analyse des chemins chauds. Analysez le flux d’événements en temps quasi réel pour détecter les anomalies, reconnaître les modèles au fil des fenêtres de temps propagées ou déclencher des alertes lorsqu’une condition spécifique se produit dans le flux.

• Gestion de types de messages d’appareils non liés à la télémétrie, tels que les notifications et les alarmes.

• Apprentissage automatique.

Dans le diagramme précédent, les zones grises sont des composants d’un système IoT qui ne sont pas directement liés à la diffusion en continu d’événements. Ils sont inclus dans le diagramme pour obtenir l’exhaustivité.

• Le registre d’appareils est une base de données des appareils approvisionnés, y compris les ID d’appareil et généralement les métadonnées de l’appareil, telles que l’emplacement.

• L’API d’approvisionnement est une interface externe commune pour l’approvisionnement et l’inscription de nouveaux appareils.

• Certaines solutions IoT permettent d’envoyer des messages de commande et de contrôle aux appareils.

Étapes suivantes

• IoT Hub
• Hubs d’événements
• Stream Analytics
• Explorateur de données Azure
• Tissu
• Azure Databricks

Ressources associées

• Architectures IoT
• Style d’architecture Big Data
• Architecture d’analytique moderne avec Azure Databricks
• Architectures Big Data avec Fabric