Le marché de l'informatique distribuée et du big data, selon , croît de 18 à 19 % par an. Cela signifie que la question du choix des logiciels à ces fins reste pertinente. Dans cet article, nous commencerons par expliquer pourquoi nous avons besoin de l'informatique distribuée, nous nous attarderons plus en détail sur le choix du logiciel, nous parlerons de l'utilisation de Hadoop avec Cloudera, et enfin nous parlerons du choix du matériel et de son impact sur les performances en différentes manières.
Pourquoi avons-nous besoin de l'informatique distribuée dans les affaires ordinaires ? Tout est simple et compliqué à la fois. Simple - parce que dans la plupart des cas, nous effectuons des calculs relativement simples par unité d'information. Difficile - car il y a beaucoup d'informations de ce type. Tant. En conséquence, il faut . Ainsi, les cas d'utilisation sont assez universels : les calculs peuvent être appliqués partout où il est nécessaire de prendre en compte un grand nombre de métriques sur un tableau de données encore plus grand.
Un exemple récent : Dodo Pizza sur la base d'une analyse de la base de commandes des clients, que lors du choix d'une pizza avec des garnitures arbitraires, les utilisateurs opèrent généralement avec seulement six ensembles d'ingrédients de base plus quelques ingrédients aléatoires. En conséquence, la pizzeria a ajusté ses achats. De plus, il a été en mesure de mieux recommander aux utilisateurs des produits supplémentaires proposés au stade de la commande, ce qui a augmenté les bénéfices.
Un autre exemple: marchandises ont permis à H&M de réduire l'assortiment dans les magasins individuels de 40 %, tout en maintenant le niveau des ventes. Ceci a été réalisé en excluant les positions peu vendeuses et la saisonnalité a été prise en compte dans les calculs.
Sélection d'outils
La norme de l'industrie pour ce type d'informatique est Hadoop. Pourquoi? Parce que Hadoop est un excellent framework bien documenté (le même Habr donne de nombreux articles détaillés sur ce sujet), qui s'accompagne de tout un ensemble d'utilitaires et de bibliothèques. Vous pouvez soumettre d'énormes ensembles de données structurées et non structurées en entrée, et le système lui-même les répartira entre la puissance de calcul. De plus, ces mêmes capacités peuvent être augmentées ou désactivées à tout moment - cette même évolutivité horizontale en action.
En 2017, l'influent cabinet de conseil Gartner que Hadoop deviendra bientôt obsolète. La raison est plutôt banale : les analystes estiment que les entreprises vont massivement migrer vers le cloud, puisqu'elles pourront y payer en fonction de l'utilisation de la puissance de calcul. Le deuxième facteur important supposément capable "d'enterrer" Hadoop est la rapidité de travail. Parce que des options comme Apache Spark ou Google Cloud DataFlow sont plus rapides que le Hadoop sous-jacent de MapReduce.
Hadoop repose sur plusieurs piliers dont les plus notables sont les technologies MapReduce (système de répartition des données pour les calculs entre serveurs) et le système de fichiers HDFS. Ce dernier est spécifiquement conçu pour stocker des informations réparties entre les nœuds du cluster : chaque bloc d'une taille fixe peut être placé sur plusieurs nœuds, et grâce à la réplication, le système est résistant aux défaillances des nœuds individuels. Au lieu d'une table de fichiers, un serveur spécial appelé NameNode est utilisé.
L'illustration ci-dessous montre comment fonctionne MapReduce. À la première étape, les données sont divisées selon un certain attribut, à la deuxième étape, elles sont distribuées par puissance de calcul, à la troisième étape, le calcul a lieu.
MapReduce a été initialement créé par Google pour les besoins de sa recherche. Ensuite, MapReduce est passé au code libre et Apache a repris le projet. Eh bien, Google a progressivement migré vers d'autres solutions. Une nuance intéressante : pour le moment, Google a un projet appelé Google Cloud Dataflow, positionné comme la prochaine étape après Hadoop, comme son remplacement rapide.
Un examen plus approfondi montre que Google Cloud Dataflow est basé sur une variante d'Apache Beam, tandis qu'Apache Beam inclut le framework Apache Spark bien documenté, ce qui nous permet de parler à peu près de la même vitesse d'exécution de la solution. Eh bien, Apache Spark fonctionne bien sur le système de fichiers HDFS, ce qui vous permet de le déployer sur des serveurs Hadoop.
Ajoutez ici le volume de documentation et de solutions toutes faites pour Hadoop et Spark contre Google Cloud Dataflow, et le choix de l'outil devient évident. De plus, les ingénieurs peuvent décider eux-mêmes quel code - sous Hadoop ou Spark - ils exécuteront, en se concentrant sur la tâche, l'expérience et les qualifications.
Cloud ou serveur local
La tendance à la transition générale vers le cloud a même donné naissance à un terme aussi intéressant que Hadoop-as-a-service. Dans un tel scénario, l'administration des serveurs connectés est devenue très importante. Car, hélas, malgré sa popularité, Hadoop pur est un outil plutôt difficile à configurer, puisqu'il faut faire beaucoup à la main. Par exemple, vous pouvez configurer les serveurs individuellement, surveiller leurs performances et ajuster de nombreux paramètres. En général, travaillez pour un amateur et il y a de fortes chances de se tromper quelque part ou de rater quelque chose.
Par conséquent, diverses distributions sont devenues très populaires, qui sont initialement équipées d'outils de déploiement et d'administration pratiques. L'une des distributions les plus populaires qui prend en charge Spark et facilite les choses est Cloudera. Il a des versions payantes et gratuites - et dans cette dernière, toutes les fonctionnalités principales sont disponibles, et sans limiter le nombre de nœuds.
Lors de l'installation, Cloudera Manager se connectera via SSH à vos serveurs. Un point intéressant : lors de l'installation, mieux vaut préciser qu'elle soit réalisée par le soi-disant colis: packages spéciaux, chacun contenant tous les composants nécessaires configurés pour fonctionner les uns avec les autres. En fait, il s'agit d'une version tellement améliorée du gestionnaire de paquets.
Après l'installation, nous obtenons une console de gestion de cluster, où vous pouvez voir la télémétrie pour les clusters, les services installés, ainsi que vous pouvez ajouter/supprimer des ressources et modifier la configuration du cluster.
En conséquence, la découpe de cette fusée apparaît devant vous, ce qui vous emmènera vers le brillant avenir du BigData. Mais avant de dire "allons-y", avançons rapidement sous le capot.
Exigences matérielles
Sur leur site, Cloudera mentionne différentes configurations possibles. Les principes généraux selon lesquels ils sont construits sont indiqués dans l'illustration :
MapReduce peut brouiller cette image optimiste. En regardant à nouveau le diagramme de la section précédente, il devient clair que dans presque tous les cas, une tâche MapReduce peut rencontrer un goulot d'étranglement lors de la lecture de données à partir d'un disque ou d'un réseau. Ceci est également noté sur le blog Cloudera. Par conséquent, pour tout calcul rapide, y compris via Spark, qui est souvent utilisé pour les calculs en temps réel, la vitesse d'E / S est très importante. Par conséquent, lors de l'utilisation de Hadoop, il est très important que des machines équilibrées et rapides entrent dans le cluster, ce qui, pour le moins, n'est pas toujours fourni dans l'infrastructure cloud.
L'équilibre dans la répartition de la charge est obtenu grâce à l'utilisation de la virtualisation Openstack sur des serveurs dotés de puissants processeurs multicœurs. Les nœuds de données se voient allouer leurs propres ressources de processeur et certains disques. Dans notre décision Moteur de lac de données Atos Codex une large virtualisation est obtenue, c'est pourquoi nous gagnons à la fois en termes de performances (l'impact de l'infrastructure réseau est minimisé) et de TCO (les serveurs physiques supplémentaires sont éliminés).
Dans le cas de l'utilisation de serveurs BullSequana S200, nous obtenons une charge très uniforme, dépourvue de certains goulots d'étranglement. La configuration minimale comprend 3 serveurs BullSequana S200, chacun avec deux JBOD, plus des S200 supplémentaires contenant quatre nœuds de données éventuellement connectés. Voici un exemple de chargement dans un test TeraGen :
Les tests avec différents volumes de données et valeurs de réplication montrent les mêmes résultats en termes de répartition de la charge sur les nœuds du cluster. Vous trouverez ci-dessous un graphique de la distribution des accès au disque par les tests de performances.
Les calculs sont basés sur une configuration minimale de 3 serveurs BullSequana S200. Il comprend 9 nœuds de données et 3 nœuds maîtres, ainsi que des machines virtuelles réservées en cas de déploiement d'une protection basée sur la virtualisation OpenStack. Résultat du test TeraSort : taille de bloc de 512 Mo d'un facteur de réplication de trois avec chiffrement de 23,1 minutes.
Comment le système peut-il être étendu ? Différents types d'extensions sont disponibles pour le Data Lake Engine :
- Nœuds de données : pour chaque tranche de 40 To d'espace utilisable
- Nœuds analytiques avec la possibilité d'installer un GPU
- Autres options en fonction des besoins de l'entreprise (par exemple, si vous avez besoin de Kafka, etc.)
Le complexe Atos Codex Data Lake Engine comprend à la fois les serveurs eux-mêmes et des logiciels préinstallés, dont le kit Cloudera avec une licence ; Hadoop lui-même, OpenStack avec des machines virtuelles basées sur le noyau RedHat Enterprise Linux, des systèmes de réplication et de sauvegarde des données (y compris l'utilisation d'un nœud de sauvegarde et Cloudera BDR - Backup and Disaster Recovery). Atos Codex Data Lake Engine est la première solution de virtualisation à être certifiée .
Si les détails vous intéressent, nous nous ferons un plaisir de répondre à nos questions dans les commentaires.
Source: habr.com