{"id":33630,"date":"2019-10-31T21:53:49","date_gmt":"2019-10-31T18:53:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit\/"},"modified":"2019-10-31T21:53:49","modified_gmt":"2019-10-31T18:53:49","slug":"chto-osobennogo-v-cloudera-i-kak-ee-gotovit","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit","title":{"rendered":"Qu'est-ce qui rend Cloudera sp\u00e9cial et comment l'utiliser","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Le march\u00e9 de l'informatique r\u00e9partie et des donn\u00e9es volumineuses, si l'on en croit les statistiques<\/a><\/noindex>, cro\u00eet de 18 \u00e0 19 % par an. Cela signifie que la question du choix des logiciels pour ces objectifs reste d'actualit\u00e9. Dans cet article, nous commencerons par expliquer pourquoi l'informatique r\u00e9partie est n\u00e9cessaire, nous examinerons plus en d\u00e9tail le choix des logiciels, nous parlerons de l'utilisation de Hadoop avec Cloudera et, enfin, nous aborderons le choix du mat\u00e9riel et la mani\u00e8re dont il influence la performance de diff\u00e9rentes mani\u00e8res.<\/p>\n

\"Qu'est-ce<\/a><\/noindex>
\nPourquoi l'informatique r\u00e9partie est-elle n\u00e9cessaire dans les entreprises ordinaires ? C'est \u00e0 la fois simple et complexe. Simple \u2014 car dans la plupart des cas, nous r\u00e9alisons des calculs relativement simples par unit\u00e9 d'information. Complexe \u2014 parce que cette information est abondante. Tr\u00e8s abondante. En cons\u00e9quence, nous devons traiter des t\u00e9raoctets de donn\u00e9es en 1000 flux<\/a><\/noindex>. Ainsi, les sc\u00e9narios d'utilisation sont plut\u00f4t universels : les calculs peuvent \u00eatre appliqu\u00e9s partout o\u00f9 il est n\u00e9cessaire de prendre en compte un grand nombre de m\u00e9triques sur des ensembles de donn\u00e9es encore plus vastes.<\/p>\n

Un des exemples r\u00e9cents : la cha\u00eene de pizzerias Dodo Pizza a d\u00e9termin\u00e9<\/a><\/noindex> sur la base de l'analyse de la base de donn\u00e9es des commandes des clients, que lors du choix d'une pizza \u00e0 garniture al\u00e9atoire, les utilisateurs se basent g\u00e9n\u00e9ralement sur six ensembles d'ingr\u00e9dients de base, plus quelques al\u00e9atoires. En cons\u00e9quence, la pizzeria a ajust\u00e9 ses achats. De plus, cela lui a permis de mieux recommander des produits suppl\u00e9mentaires lors de la commande, ce qui a permis d'augmenter les profits.<\/p>\n

Un autre exemple : l'analyse<\/a><\/noindex> des articles a permis au magasin H&M de r\u00e9duire son assortiment dans certains magasins de 40 %, tout en maintenant son niveau de ventes. Cela a \u00e9t\u00e9 possible en excluant les articles peu vendus, en tenant compte de la saisonnalit\u00e9.<\/p>\n

Choix de l'outil<\/h2>\n

\nLa norme industrielle pour ce type de calcul est Hadoop. Pourquoi ? Parce que Hadoop est un excellent framework bien document\u00e9 (m\u00eame Habr publie de nombreux articles d\u00e9taill\u00e9s \u00e0 ce sujet), qui est accompagn\u00e9 d'un ensemble d'outils et de biblioth\u00e8ques. Vous pouvez lui soumettre d'\u00e9normes ensembles de donn\u00e9es \u00e0 la fois structur\u00e9es et non structur\u00e9es, et le syst\u00e8me s'occupera de les r\u00e9partir entre les ressources de calcul. De plus, ces ressources peuvent \u00eatre accrus ou diminu\u00e9s \u00e0 tout moment \u2014 c'est la scalabilit\u00e9 horizontale en action. <\/p>\n

En 2017, la soci\u00e9t\u00e9 de conseil influente Gartner a conclu<\/a><\/noindex>, que Hadoop serait bient\u00f4t obsol\u00e8te. La raison est assez banale : les analystes estiment que les entreprises commenceront \u00e0 migrer massivement vers le cloud, car elles pourront payer en fonction de leur utilisation des ressources de calcul. Un deuxi\u00e8me facteur important qui pourrait pr\u00e9tendument \u00ab enterrer \u00bb Hadoop est la vitesse de fonctionnement. En effet, des options comme Apache Spark ou Google Cloud DataFlow fonctionnent plus rapidement que MapReduce, qui est \u00e0 la base de Hadoop.<\/p>\n

Hadoop repose sur plusieurs piliers, les plus notables \u00e9tant les technologies MapReduce (un syst\u00e8me de r\u00e9partition des donn\u00e9es pour des calculs entre serveurs) et le syst\u00e8me de fichiers HDFS. Ce dernier est sp\u00e9cifiquement con\u00e7u pour stocker des informations r\u00e9parties entre les n\u0153uds d'un cluster : chaque bloc de taille fixe peut \u00eatre plac\u00e9 sur plusieurs n\u0153uds, et gr\u00e2ce \u00e0 la r\u00e9plication, la r\u00e9silience du syst\u00e8me face aux pannes de certains n\u0153uds est garantie. Au lieu d'un tableau de fichiers, un serveur sp\u00e9cial appel\u00e9 NameNode est utilis\u00e9.<\/p>\n

L'illustration ci-dessous montre le sch\u00e9ma de fonctionnement de MapReduce. Au premier stade, les donn\u00e9es sont divis\u00e9es selon un crit\u00e8re d\u00e9fini, au second, elles sont r\u00e9parties sur les ressources de calcul, et au troisi\u00e8me, le calcul intervient. <\/p>\n

\"Qu'est-ce
\nInitialement, MapReduce a \u00e9t\u00e9 cr\u00e9\u00e9 par Google pour ses besoins en recherche. Ensuite, MapReduce est devenu open source, et le projet a \u00e9t\u00e9 pris en charge par Apache. Quant \u00e0 Google, il a progressivement migr\u00e9 vers d'autres solutions. Un point int\u00e9ressant : actuellement, Google a un projet appel\u00e9 Google Cloud Dataflow, pr\u00e9sent\u00e9 comme la prochaine \u00e9tape apr\u00e8s Hadoop, comme une substitution rapide.<\/p>\n

\u00c0 un examen d\u00e9taill\u00e9, on constate que Google Cloud Dataflow est bas\u00e9 sur une variante d'Apache Beam, qui inclut le framework bien document\u00e9 Apache Spark, ce qui permet d'affirmer que la vitesse d'ex\u00e9cution des solutions est pratiquement \u00e9quivalente. De plus, Apache Spark fonctionne parfaitement sur le syst\u00e8me de fichiers HDFS, ce qui permet de le d\u00e9ployer sur des serveurs Hadoop.<\/p>\n

Ajoutons \u00e0 cela le volume de documentation et de solutions pr\u00eates concernant Hadoop et Spark par rapport \u00e0 Google Cloud Dataflow, et le choix de l'outil devient \u00e9vident. De plus, les ing\u00e9nieurs peuvent d\u00e9cider eux-m\u00eames quel code ex\u00e9cuter \u2014 pour Hadoop ou Spark \u2014 en fonction de la t\u00e2che, de leur exp\u00e9rience et de leur qualification.<\/p>\n

Cloud ou serveur local<\/h2>\n

\nLa tendance \u00e0 la migration vers le cloud a m\u00eame engendr\u00e9 un terme int\u00e9ressant comme Hadoop-as-a-service. Dans ce sc\u00e9nario, l'administration des serveurs connect\u00e9s est devenue tr\u00e8s importante. Car, malheureusement, malgr\u00e9 sa popularit\u00e9, Hadoop pur reste un outil assez complexe \u00e0 configurer, car beaucoup de choses doivent \u00eatre faites manuellement. Par exemple, configurer individuellement les serveurs, surveiller leurs indicateurs, et ajuster soigneusement de nombreux param\u00e8tres. En gros, c'est un travail pour les amateurs et il y a un grand risque de faire des erreurs ou de laisser passer quelque chose.<\/p>\n

C'est pourquoi divers distributions sont devenues tr\u00e8s populaires, car elles sont initialement \u00e9quip\u00e9es d'outils de d\u00e9ploiement et d'administration pratiques. L'une des distributions les plus populaires qui supportent Spark et simplifient tout est Cloudera. Elle a des versions payantes et gratuites \u2014 et dans la derni\u00e8re, toutes les fonctionnalit\u00e9s principales sont disponibles, sans limitation du nombre de n\u0153uds. <\/p>\n

\"Qu'est-ce
\n
\nLors de la configuration, Cloudera Manager se connectera \u00e0 vos serveurs via SSH. Un point int\u00e9ressant : lors de l'installation, il est pr\u00e9f\u00e9rable d'indiquer que cela se fasse avec des packages<\/i>: des paquets sp\u00e9ciaux, chacun contenant tous les composants n\u00e9cessaires, configur\u00e9s pour fonctionner ensemble. En gros, c'est une version am\u00e9lior\u00e9e du gestionnaire de paquets.<\/p>\n

Apr\u00e8s l'installation, nous obtenons un tableau de bord de gestion du cluster, o\u00f9 l'on peut voir la t\u00e9l\u00e9m\u00e9trie des clusters, les services install\u00e9s, et vous pourrez ajouter\/supprimer des ressources et modifier la configuration du cluster. <\/p>\n

\"Qu'est-ce
\n
\nVous avez devant vous la d\u00e9coupe de la fus\u00e9e qui vous emm\u00e8nera vers un avenir radieux avec BigData. Mais avant de dire \u00ab c'est parti \u00bb, jetons un \u0153il sous le capot.<\/p>\n

Exigences mat\u00e9rielles<\/h2>\n

\nSur son site, Cloudera mentionne diff\u00e9rentes configurations possibles. Les principes g\u00e9n\u00e9raux sur lesquels elles sont bas\u00e9es sont pr\u00e9sent\u00e9s dans l'illustration :<\/p>\n

\"Qu'est-ce
\nCette image optimiste peut \u00eatre assombrie par MapReduce. En regardant \u00e0 nouveau le sch\u00e9ma du chapitre pr\u00e9c\u00e9dent, il devient \u00e9vident que presque dans tous les cas, une t\u00e2che MapReduce peut rencontrer un \u00ab goulot d'\u00e9tranglement \u00bb lors de la lecture des donn\u00e9es depuis un disque ou un r\u00e9seau. Cela est \u00e9galement not\u00e9 dans le blog de Cloudera. Par cons\u00e9quent, pour des calculs rapides, y compris ceux via Spark, qui est souvent utilis\u00e9 pour des calculs en temps r\u00e9el, la vitesse d'entr\u00e9e\/sortie est primordiale. C'est pourquoi, lors de l'utilisation de Hadoop, il est essentiel que le cluster soit compos\u00e9 de machines \u00e9quilibr\u00e9es et rapides, ce qui, pour dire les choses simplement, n'est pas toujours garanti dans une infrastructure cloud.<\/p>\n

L'\u00e9quilibrage de la charge est atteint gr\u00e2ce \u00e0 l'utilisation de la virtualisation Openstack sur des serveurs avec des processeurs multi-c\u0153urs puissants. Les n\u0153uds de donn\u00e9es se voient attribuer leurs propres ressources processeur et disques sp\u00e9cifiques. Dans notre solution Atos Codex Data Lake Engine<\/i> une large virtualisation est r\u00e9alis\u00e9e, ce qui nous permet de b\u00e9n\u00e9ficier \u00e0 la fois de performances accrues (impact minimal de l'infrastructure r\u00e9seau) et de co\u00fbts totaux de possession r\u00e9duits (suppression des serveurs physiques superflus).<\/p>\n

\"Qu'est-ce
\nEn utilisant des serveurs BullSequana S200, nous obtenons une charge de travail tr\u00e8s uniforme, d\u00e9pourvue de certains goulots d'\u00e9tranglement. La configuration minimale comprend 3 serveurs BullSequana S200, chacun avec deux JBOD, plus des S200 suppl\u00e9mentaires pouvant \u00eatre connect\u00e9s, contenant quatre n\u0153uds de donn\u00e9es chacun. Voici un exemple de la charge dans le test TeraGen :<\/p>\n

\"Qu'est-ce
\n
\nDes tests avec diff\u00e9rents volumes de donn\u00e9es et valeurs de r\u00e9plication montrent des r\u00e9sultats identiques en termes de r\u00e9partition de la charge entre les n\u0153uds du cluster. Ci-dessous se trouve un graphique de la r\u00e9partition de l'acc\u00e8s au disque lors des tests de performance.<\/p>\n

\"Qu'est-ce
\n
\nLes calculs ont \u00e9t\u00e9 r\u00e9alis\u00e9s sur la base d'une configuration minimale compos\u00e9e de 3 serveurs BullSequana S200. Cela inclut 9 n\u0153uds de donn\u00e9es et 3 n\u0153uds principaux, ainsi que des machines virtuelles r\u00e9serv\u00e9es au cas o\u00f9 la protection serait d\u00e9ploy\u00e9e sur la base de l'OpenStack Virtualization. Le r\u00e9sultat du test TeraSort : taille de bloc de 512 Mo avec un facteur de r\u00e9plication de trois, avec chiffrement, est de 23,1 minutes.<\/p>\n

Comment peut-on \u00e9tendre le syst\u00e8me ? Divers types d'extensions sont disponibles pour Data Lake Engine :<\/p>\n