Fermer

septembre 11, 2019

Passer à un «nouveau» paradigme agile pour le Big Data


Il y a quelques années, j'étais en train de rédiger un document architectural conceptuel pour un projet nécessitant des méthodologies très agiles reposant sur des microservices et des équipes interfonctionnelles. L'une des parties clés de l'architecture impliquait Hadoop et Spark pour le stockage et le traitement des données, ainsi que pour la transmission des données à la plate-forme microservices. C’est à ce stade que les principes de microservices ont échoué et j’étais au point d’essayer d’adapter la partie des données à une architecture et à un concept de microservices. À la base, les microservices favorisent les petits services à couplage lâche déployés dans des conteneurs autonomes disposant de tout le nécessaire pour exécuter le service. Cela a permis à chaque groupe de services d'être indépendamment déployé, géré, maintenu et géré par les mêmes équipes fonctionnelles qui ont développé et conçu ces services. Les avantages de microservices et de ses principes sont relativement faciles à quantifier – isolement, résilience, évolutivité, automatisation, agilité, indépendance.

Hadoop était basé sur le cadre MapReduce popularisé par un modèle de programmation écrit par certains Les ingénieurs de Google il y a plus de dix ans. Le modèle était destiné à la programmation et au traitement de grands ensembles de données sur un cluster distribué. Les infrastructures centrales Hadoop et MapReduce associent étroitement le traitement des données à un disque connecté localement, en couplant étroitement les données et le stockage aux ressources de calcul. Les avantages de MapReduce et de Hadoop reposent en grande partie sur l'utilisation d'un disque local connecté pour calculer des ressources afin de traiter des données réparties sur un grand cluster, ce qu'elles ont appelé la localité de données. Actuellement, la plupart des distributions Hadoop ont été étendues pour inclure les ressources, les clusters, la sécurité, la haute disponibilité, de nombreuses bases de données, des outils d'interface graphique utilisateur et une multitude d'autres composants permettant à une variété de services de s'exécuter et de s'exécuter sur la plate-forme.

des évolutions qui ont accéléré le développement des microservices et nous ont en même temps conduits à un nouveau paradigme du Big Data, cela semble être une contradiction des termes ayant à la fois un "micro" service et des "grandes" données. Mais le modèle de microservices élimine l’inflexibilité monolithique et la maladresse avec des unités de service plus petites qui ont de fortes limites modulaires, des déploiements autonomes et une diversité technologique pour opérationnaliser et gérer de très grands systèmes évolutifs de manière agile. Je pense que ce qui suit rompt le modèle monolithique actuel de données volumineuses avec le modèle de microservices.

Stockage et calcul dans le nuage

Lorsque AWS a commencé à offrir ses premiers produits en nuage, le premier service il lancé était son service de stockage simple (S3 ), qui fournissait un service de stockage à faible coût, évolutif et à faible temps de latence avec des garanties de haute disponibilité de 99,99%. Au fil des ans, il s’est avéré être un service extrêmement durable, économique et simple permettant de stocker et d’accéder aux données via des interfaces Web et REST bien connues et omniprésentes. Il reste le service AWS le plus répandu et le plus utilisé. En 2013, il contenait environ 2 000 milliards d'objets, doublant son nombre en seulement un an de 2012 à 2013, si cette augmentation était maintenue ou même si on ne tenait compte que d'une croissance linéaire et non exponentielle, le nombre d'objets serait proche de 10 000 milliards. aujourd'hui. S3 s'appuie sur de nouveaux mécanismes de protection du stockage, tels que les algorithmes de codage d'effacement offrant des taux de durabilité beaucoup plus élevés tout en utilisant moins de stockage que les configurations précédentes telles que RAID10 ou JBOD Hadoop avec des taux de récupération beaucoup plus rapides en cas de perte d'un fragment de fichier. En fait, AWS S3 promet une durabilité de 11 9 (99,99999999999), ce qui correspond à environ un fichier perdu tous les 10 000 ans pour 10 millions de fichiers sur S3!

Dans la foulée du lancement de S3, AWS a été lancé. son ​​service EC2 offrant des services de calcul virtualisés avec une large gamme de capacités de machines, de types de systèmes d'exploitation, de vitesses de processeur et de stockage attaché. Cela permettait aux utilisateurs de lancer de manière dynamique des instances avec la puissance de calcul nécessaire pour redimensionner et dimensionner de manière dynamique des tâches plus volumineuses et de mettre fin à ces services lorsqu'ils n'étaient plus nécessaires. Des options telles que la tarification au comptant et à la réserve pour les EC2 offrent également des avantages en termes de coût pour le dimensionnement et la mise à l'échelle dynamiques des ressources de calcul. Alors que la virtualisation des serveurs existait avant les services de calcul AWS, les solutions S3 et EC2 ont apporté, décrétées ou non, le découplage des services de calcul et de stockage.

Les services de calcul pouvaient évoluer de manière élastique et dynamique indépendamment des systèmes de stockage, tandis que les systèmes de stockage est devenu plus durable, évolutif et fiable sans avoir besoin des services de calcul correspondants. Cela offrait beaucoup de flexibilité, d'agilité et une restructuration des coûts de maintenance et de préservation des données. Par exemple, nous pourrions stocker une grande quantité de données sur S3 sans avoir à conserver un ensemble correspondant de ressources de calcul pour lire et écrire à partir des données, ce qui était très différent des serveurs de bases de données et de fichiers où les données étaient étroitement couplées au stockage. [19659002] Même dans ce cas, ce découplage entre calcul et stockage n’avait jusqu’à présent aucune utilisation significative, principalement parce que, même avec l’avènement du Big Data, le traitement des données restait étroitement lié à Hadoop et MapReduce. N'oubliez pas que le concept central de Hadoop / MapReduce est de traiter les données à proximité de l'endroit où les processus de calcul devaient fournir des vitesses d'E / S de données plus rapides. Ce concept de localité de données était essentiel au traitement de grands ensembles de données. Ainsi, même dans le cloud, cela signifiait créer des ressources de calcul avec des disques locaux connectés, comme dans un centre de données pour tirer parti de la localisation des données, des vitesses de traitement et des E / S. La configuration nominale consistait à traiter les données localement dans un cluster Hadoop de EC2, puis à les copier sur S3 en tant que sauvegarde. Même lorsque les données étaient directement écrites et lues à partir de S3, un cluster Hadoop était toujours utilisé pour tirer parti de HDFS pour les données transitoires. Je n’ai toujours pas compris ce concept car tous les avantages de la localité de données sont généralement annulés. Pourquoi s'embêter avec les nœuds de nom, les nœuds principaux, le Zookeeper et la réplication de données HDFS pour les données transitoires?

Lieu de données

Quelle est l'importance d'un lieu de données? L'hypothèse centrale derrière la localisation des données est que les vitesses d'E / S de disque sont nettement plus rapides que les largeurs de bande réseau et que les E / S de disque constituent une partie importante de toute tâche de traitement de données. Il y a études qui réfutent cette hypothèse et postulent que la localisation de disque n'est plus pertinente dans les travaux de traitement de grappes. En fait, dans l’étude référencée ci-dessus, il a été montré que la vitesse de lecture de la localisation locale des données à partir du disque n’est améliorée que de 8% par rapport à la lecture d’un emplacement de stockage distant. Cela est principalement dû aux améliorations apportées aux vitesses du réseau, qui dépassent les vitesses des disques et, plus important encore, la localisation en mémoire des données plutôt que sur les disques, car dans les systèmes de cluster hautes performances actuels, les données sont lues une fois et stockées en mémoire. En s'appuyant sur les clusters Hadoop de Facebook pour fonder leurs études, les auteurs de l'étude ont découvert que l'accès aux disques locaux était peu fréquent et utilisé uniquement pour lire les données lors des chargements initiaux.

Apache Spark

Le point clé ici est lieu de mémoire et l’un des facteurs à cet égard a été l’abandon du paradigme MapReduce vers des cadres de traitement utilisant davantage de mémoire. Cela était dû en grande partie à l'introduction de Apache Spark qui fonctionnait avec un modèle de mémoire distribuée pour le traitement de données sur un cluster. Cela était beaucoup plus rapide que le modèle MapReduce qui reposait sur des disques pour stocker les résultats intermédiaires. Les bases de données distribuées résilientes de Spark (RDD) fonctionnaient principalement avec des données en mémoire et fournissaient la partie résiliente en gardant une trace du lignage de traitement des données afin que les résultats intermédiaires puissent être recréés. à partir des données d'origine sur le disque si un noeud échouait. L’autre aspect important de Spark était qu’il pouvait également traiter des données en continu ainsi que des traitements par lots en utilisant le même modèle de mémoire distribuée et les résumer à l’aide d’un langage de traitement SQL. Cependant, la grande majorité des tâches Spark sont exécutées dans un cluster Hadoop / YARN. La motivation habituelle pour exécuter Spark sur Hadoop était encore une fois la localisation des données et l'absence de système de gestion de fichiers dans Spark, même si la majorité du traitement des données était effectué en mémoire et que les pilotes Spark évoluaient pour d'autres systèmes de stockage tels qu'AWS S3 et Azure Object.

Optimisation des données

Il y avait d'autres améliorations qui rendaient la localisation des données moins pertinente. Une partie importante était la compression des données qui accélérait le chargement des données sur la bande passante du réseau, ainsi que les formats de données en colonnes permettant des données plus efficaces. récupération au niveau des blocs vs récupération sur plusieurs blocs. Les formats Columnar tels que Parquet et ORC accéléraient l’interrogation et la recherche dans les fichiers de données et donnaient naissance à des moteurs d’interrogation virtuels distribués, tels que Presto, qui ne nécessitaient pas Hadoop et étaient optimisés pour la lecture des données Parquet compressées à partir d’un système de stockage tel que S3. Netflix a réussi à réussir cette opération avec 10 Po de données de parquet sur S3 exécutant Presto pour interroger et fournir des analyses. Compte tenu du succès de la plate-forme sur S3, AWS a introduit un service Presto sans serveur appelé Athena capable d'interroger efficacement les données sur S3 et permettant aux utilisateurs de vraiment découpler les calculs du stockage. D'autres plates-formes telles que Snowflake et Redshift Spectrum ont également donné naissance à des entrepôts de données virtuels, tous découplés de la couche de stockage sous-jacente.

Culture DevOps

L'un des gros avantages des microservices est la fragmentation de grandes structures monolithiques complexes. en morceaux plus petits et en habilitant les équipes de développement autonomes à construire des déploiements autonomes et modulaires. Celles-ci permettent des déploiements et des modifications très agiles au sein de chaque service modulaire, car les équipes de dépendance ont de grandes architectures monolithiques. Cela permet principalement d'éviter les complexités architecturales que la plupart des organisations ont connues avec les plateformes monolithiques. Je pense que le moteur principal des microservices a toujours été le DevOps et que la capacité à simplifier, rationaliser et automatiser les cycles SDLC, une grande partie de la méthodologie d'application à douze facteurs pour les microservices reposent également sur de solides principes DevOps. La culture DevOps a elle-même brouillé les lignes traditionnelles entre les équipes de développement et les équipes opérationnelles.

Les plateformes complexes telles que Hadoop sont frustrées par le fait qu'il est très difficile de reproduire l'environnement au fil du temps. Étant donné que les composants sont si étroitement liés, il est difficile d’apporter des modifications sans affecter autre chose. En outre, des modifications opérationnelles peuvent être apportées via une multitude de méthodes, d'interface graphique (Hue, Ambari, Sentry, Ranger), de ligne de commande (HDFS, Hive) et de fichiers texte (core-site, mapred). Ces modifications au fil du temps font évoluer l'environnement même grâce aux meilleures intentions de l’équipe des opérations de garder les choses rationalisées. Il est difficile d'être dynamique et agile lorsqu'il est risqué de recréer des environnements car rien ne garantit qu'il en sera de même .

de la plate-forme en tant que service (1945a)

. Une des idées fausses sur les microservices est que la simplicité de la construction de services à responsabilité unique engendre également une simplicité opérationnelle. L'objectif macro de microservices est de créer un système holistique intégré, automatisé, évolutif, à partir du tissage et de l'intégration de services isolés. Les modèles Platform as a Service, tels que Heroku et Cloud Foundry, permettent de déployer, d'orchestrer, de mettre à l'échelle et de surveiller des microservices dans des environnements cloud et sur site. Des objets tels que des conteneurs, des bus d'événements, la découverte de services, des tuyaux idiots, des disjoncteurs sont fournis par ces plateformes, ce qui permet aux équipes de développement de se concentrer sur le code d'application, la logique métier, les configurations et les processus de livraison pour le développement, les tests et la livraison des systèmes. En fait, il serait difficile de trouver des projets de microservices naissants fonctionnant dans un environnement IaaS plutôt que dans un PaaS, la complexité requise pour mettre en place l'orchestration, l'évolutivité et certains modèles de services internes est assez élaborée. ] Infrastructure centrée sur les applications

Le passage à un modèle de microservices et de conteneurisation ainsi qu’à la culture DevOps est également un changement important vers un modèle centré sur les applications plutôt que sur une machine. Les conteneurs contiennent généralement toutes les exigences d'environnement requises par une application pour s'exécuter, isolant ainsi l'environnement de l'application. L’évolution des conteneurs de Google de leur système interne de conteneurs appelé Borg à Kubernetes résume leurs opérations de centre de données à un modèle de gestion centré sur les applications. La sous-utilisation des machines dans les centres de données ainsi que les inefficacités de «garder les lumières allumées» sont réduites de manière significative avec la conteneurisation. Les plates-formes PaaS telles que Heroku et Cloud Foundry exploitent toutes les fonctionnalités des conteneurs pour faciliter le déploiement d'applications. La différence fondamentale entre une plate-forme PaaS telle que Cloud Foundry et Kubernetes réside dans le fait que, dans Kubernetes, le conteneur lui-même est l'application, tandis que dans la PaaS traditionnelle, la plate-forme éloigne le conteneur de l'application au moyen d'éléments de build. Cela permet une plus grande flexibilité vis-à-vis des applications qui ne correspondent généralement pas au modèle de microservices. applications avec état, par exemple, nécessitant le maintien de l'ordre et de la persistance, ou données persistantes. Pour la plupart des microservices, l'apatridie est un principe clé car la plate-forme est capable d'évoluer de manière dynamique sans se préoccuper de la perte de données ou d'état. Cela exclut les grandes infrastructures de traitement de données telles que les bases de données et les outils tels que Spark, qui posent des problèmes plus complexes dans un environnement avec état distribué. Les motifs d’opérateur de Kubernetes StatefulSets et permettent la gestion de toute application dans un service de plate-forme conteneur gérée via un ensemble commun d’API et d’objets. L’évolution de ce processus est un modèle de plate-forme ouverte qui permet l’extensibilité, la cohérence, l’auto-guérison et l’abstraction des opérations, et non une orchestration de services, mais plutôt une chorégraphie qui permet à l’environnement de croître et d’évoluer. 19659002] Architectures natives en nuage

Nous nous orientons ensuite vers un système orienté applications et micro-services à couplage lâche, qui synthétise l'infrastructure sous-jacente permettant aux organisations de se déployer n'importe où, optimisant efficacement les coûts des ressources et permettant l'application Les développeurs / opérateurs doivent se concentrer sur la logique et le code d’entreprise plutôt que sur les environnements et les ressources et la configuration ou l’administration. C’est une exigence réelle, en particulier dans le domaine de la science des données, où selon Gartner, moins de la moitié des projets ML sont déployés même au sein d’une organisation appliquant des pratiques éprouvées en matière de science des données. Des outils de pipeline de science des données tels que MLFlow Seldon Core et KubeFlow exploitent à la fois les microservices et la culture DevOps pour automatiser et orchestrer des modèles ML en production. Regardez cette présentation pour un véritable pipeline ML utilisant Kubernetes dans une grande organisation!

Ce mouvement vers une architecture Cloud Native est réel et ne peut être ignoré. Il repose sur des microservices mais englobe non seulement les services sans état et les applications front-end, mais aussi les données et les données distribuées et le traitement des données distribuées. Il est agnostique dans le cloud, hybride et multi-cloud pour utiliser tous les mots à la mode de mon dictionnaire. Il est basé de facto sur Kubernetes et basé sur les conteneurs. Il fournit résilience, élasticité, agilité et automatisation via DevOps. Le nombre de mises en œuvre de Kubernetes augmente pour les données; Étincelle Flink Kafka MongoDB Nifi de MongoDB




Source link