Intégration moderne des données nécessite à la fois des calculs fiables en mode batch et en mode streaming pour prendre en charge les processus métier essentiels. Traditionnellement, dans l'espace des logiciels d'entreprise, l'ETL (Extract Transform and Load) par lots et le CEP (Complex Event Processing) en flux continu étaient deux produits complètement différents, avec des moyens différents de formuler les calculs. Jusqu'à récemment, dans l'espace des logiciels open source pour le big data, le batch et le streaming étaient traités séparément, comme MapReduce pour le batch et Storm pour les streams. Aujourd'hui, nous voyons de plus en plus de moteurs de traitement de données qui tentent de fournir des modèles à la fois pour le batch et le streaming, comme Apache Spark et Apache Flink. Dans une série de billets, j'expliquerai la nécessité d'un modèle de programmation unifié et d'une architecture de traitement des données hybride sous-jacente qui s'adapte à la fois au traitement par lots et au traitement en continu. le calcul en continu pour l'intégration des données. Toutefois, pour l'intégration des données, ce modèle doit se situer à un niveau qui fait abstraction des moteurs de traitement des données spécifiques.
Chez SnapLogic, nous avons développé un modèle de programmation visuelle hybride et un moteur d'exécution plateforme. Nous avons mis en œuvre notre propre moteur d'exécution hybride qui peut exécuter des calculs par lots et en continu. En outre, nous pouvons transformer les pipelines de flux de données SnapLogic en calculs MapReduce et Spark. Notre modèle isole les utilisateurs de la complexité des moteurs de traitement de données sous-jacents. Cette isolation permet aux pipelines SnapLogic de s'exécuter sur la cible la plus appropriée. Elle masque également les changements de cibles et permet une migration aisée d'une cible à l'autre. Cette approche permet également aux utilisateurs de tirer parti de nouveaux moteurs de traitement des données sans avoir à porter les pipelines de données.
Comprendre le calcul par lots
Un calcul d'intégration par lots implique généralement l'accès à un ensemble de données complet, tel qu'une table ou une collection, afin de transformer les données ou d'effectuer une requête analytique. En d'autres termes, les données utilisées pour le calcul par lots sont entièrement disponibles dans une base de données ou sur un autre site de stockage plateforme , tel que HDFS. Les transformations de données comprennent le filtrage des données, l'exécution d'opérations de qualité des données, ou l'augmentation et l'enrichissement des données avec des données externes supplémentaires. Il est important de comprendre que certains calculs par lots peuvent être effectués sur chaque élément de données (ligne ou document) indépendamment de tous les autres éléments de données. C'est le cas du filtrage et des transformations simples. Cependant, certains calculs ont des dépendances entre les éléments de données. C'est le cas des requêtes analytiques qui impliquent l'agrégation, le tri ou la jonction d'ensembles de données. Enfin, certains calculs par lots nécessitent plusieurs itérations sur un ensemble de données. C'est le cas des algorithmes d'apprentissage automatique et de certains types de calculs graphiques (par exemple, l'algorithme PageRank).
Un élément clé des moteurs de traitement de données modernes est la capacité à tolérer les pannes au cours d'un calcul potentiellement long. Cela est particulièrement vrai lorsque le calcul s'effectue sur des centaines, voire des milliers de nœuds de calcul. Google MapReduce a été le premier moteur de traitement de données à grande échelle à fournir un modèle de programmation qui permet au programmeur de se concentrer sur le calcul et de masquer la complexité de la gestion de la tolérance aux pannes. Le moteur d'exécution MapReduce garantit qu'un calcul MapReduce s'achèvera finalement en présence de défaillances du réseau et des nœuds. La tolérance aux pannes de MapReduce est obtenue par la réexécution des tâches Map ou Reduce. L'implémentation de MapReduce travaille en étroite collaboration avec le système de fichiers distribués fiable sous-jacent, GFS dans le cas de Google, afin de fournir des informations pour la réexécution des tâches. Hadoop MapReduce repose sur HDFS et fonctionne de la même manière que Google MapReduce. Les outils destinés aux utilisateurs, tels que Pig et Hive, exécutent en fin de compte des calculs sous la forme de tâches MapReduce.
Comme MapReduce, Spark fournit un modèle de programmation et un moteur d'exécution qui garantissent que les calculs Spark se dérouleront correctement en cas de défaillance d'un cluster. Le modèle et la mise en œuvre de Spark, basés sur des ensembles de données distribués résilients (RDD), offrent une manière différente de formuler les calculs distribués et peuvent permettre une exécution beaucoup plus rapide dans de nombreux cas. Spark fournit une API de plus haut niveau que MapReduce et les opérations individuelles sont suivies. Cette capacité à suivre l'évolution des opérations permet de réexécuter et de recréer des RDD en cas de défaillance d'un nœud. Contrairement à MapReduce, Core Spark estompe la frontière entre les requêtes par lots et les requêtes interactives. Une fois que les données ont été chargées dans un ou plusieurs RDD Spark dans un cluster, ces données peuvent être interrogées rapidement pour découvrir différents résultats. Cela évite de recharger les mêmes données en mémoire pour des requêtes indépendantes. Cela dit, comme MapReduce, Spark est souvent utilisé comme un moteur de traitement de données par lots plus rapide. Comme MapReduce, Spark s'appuie sur un système de fichiers distribué fiable, tel que HDFS, ou sur un magasin de données distribué fiable, tel que Cassandra.
Les calculs par lots purs sont au cœur de la prise en charge des principaux secteurs d'activité, des rapports, des prévisions et des calculs scientifiques. En tant que tel, le calcul distribué par lots continuera à être un composant technologique essentiel dans la plupart des organisations.
Mon prochain billet dans cette série portera sur Comprendre le calcul en continu et je conclurai par les avantages d'une intégration des données en mode batch et en mode streaming plateforme.
