Une traduction de l'article a été préparée spécialement pour les étudiants du cours Data Engineer .
Après que Cloudera et MapR aient annoncé il y a quelques semaines que leur entreprise traversait une période difficile, j'ai vu un flux de publications sur les réseaux sociaux sur le thème «Hadoop est mort». Ces postes ne sont pas nouveaux, mais dans un secteur où les experts techniques produisent rarement du matériel de haute qualité pour les réseaux sociaux, ces exclamations deviennent de plus en plus fortes. Je voudrais examiner certains des arguments concernant l'état de Hadoop.
Compétition avec gratuit
Cloudera a des suggestions qui aident Hadoop à être une solution plus complète. Ces outils sont apparus avant que les devops ne se généralisent et le déploiement automatisé était rare.
Leurs outils offrent des offres exceptionnelles à plus de 2 600 clients, mais la plupart des logiciels qu'ils proposent sont open source et gratuits. Cloudera est finalement en concurrence avec les logiciels libres. Pour couronner le tout, de nombreux développeurs d'écosystème Hadoop ont travaillé à un moment ou à un autre chez Cloudera, c'est-à-dire en fin de compte, ils ont en quelque sorte subventionné les offres gratuites avec lesquelles ils sont en concurrence.
Comme ils rivalisent avec gratuit, Cloudera ne servira jamais 100% de la base d'utilisateurs Hadoop. Je n'oserais pas les utiliser comme indicateur de la santé de Hadoop pour cette raison même.
D'autres sociétés proposant des solutions clé en main Spark et Presto tentent de se distancier de la marque Hadoop. Leurs offres peuvent inclure des centaines de fichiers .jar de divers projets Hadoop, mais néanmoins, ces entreprises veulent tout faire pour éviter la concurrence avec les offres gratuites, tout en réduisant leurs coûts de développement en utilisant des logiciels open source. Les ventes ne sont pas si faciles lorsque votre client peut légalement télécharger 80% de votre offre sans le payer.
Concurrence avec AWS
En 2012, j'ai travaillé sur la mise en œuvre de Hadoop avec 25 autres entrepreneurs. Certains de mes collègues venaient de Google, d'autres ont continué à travailler pour Cloudera. Un budget important a été impliqué, l'équipe a produit de nombreuses heures rémunérées, mais une très petite partie de l'écosystème Hadoop était prête.
En quelques années, AWS EMR est apparu et a commencé à absorber sa part de marché. EMR vous permet d'exécuter des clusters Hadoop avec une grande variété de logiciels installés en quelques clics. Il peut fonctionner en copies ponctuelles, ce qui réduit les coûts d'équipement d'environ 80%, et peut stocker des données sur S3, qui était et reste bon marché et fiable à 99,9999999999%.
Du coup, le besoin de 25 entrepreneurs sur le projet a disparu. Sur certains projets, seuls moi, un travailleur à temps plein et plusieurs autres à temps partiel, préparant l'infrastructure en plus de nos autres responsabilités, pouvaient être impliqués. Il existe toujours un besoin de consultants de projet utilisant AWS EMR, mais le potentiel global de facturation pour ce type de travail est beaucoup moins élevé qu'il y a quelques années.
Quelle part de l'activité potentielle de Cloudera a été perdue au profit de l'EMR? Cloudera a fait un bon travail de mise en place et de gestion de clusters bare metal, mais aujourd'hui la plupart du monde des données est dans le cloud. Il convient de considérer à quel point Hadoop est attrayant pour votre entreprise, ne serait-ce que parce qu'AWS dispose d'une offre gérée avec des copies ponctuelles.
Qu'est-ce que Hadoop?
Si vous me demandiez la définition de Hadoop, je dirais que c'est une grande collection de logiciels open source qui s'intègre dans une certaine mesure et possède plusieurs bibliothèques communes. Je vois Hadoop comme une base de données partitionnée, presque comme une distribution de système d'exploitation pour les données.
Tous les projets logiciels sponsorisés par Hadoop ne sont pas des projets Apache. Presto fait partie de ces exceptions. D'autres, comme ClickHouse, avec la prise en charge prochaine de HDFS et Parquet, ne seront pas perçus par beaucoup comme un projet Hadoop, bien qu'ils cocheront bientôt le graphique de compatibilité.
Jusqu'en 2012, il n'y avait pas de fichiers ORC ni de parquet. Ces formats ont contribué à la mise en œuvre d'une analyse rapide dans Hadoop. Avant ces formats, les charges de travail étaient principalement orientées ligne. Si vous avez besoin de convertir des téraoctets de données et que vous pouvez le faire en parallèle, Hadoop fera parfaitement le travail. MapReduce était un cadre souvent utilisé à cette fin.
Le stockage sur colonne était proposé pour une analyse des téraoctets de données en quelques secondes. Ce qui s'est avéré être une offre plus valable pour un plus grand nombre d'entreprises. Les scientifiques des données peuvent n'avoir besoin que d'une petite quantité de données pour se faire une idée, mais ils devront d'abord examiner des pétaoctets potentiellement de données pour choisir les bons. L'analyse des colonnes est cruciale pour eux dans leur maîtrise du traitement des données nécessaires pour comprendre ce qui doit être sélectionné.
MapReduce possède deux opérateurs de traitement de données fonctionnels, mappant et réduisant, et traitant les données comme des chaînes. Spark le suit immédiatement et possède des opérateurs plus fonctionnels, tels que le filtre et l'union, et perçoit les données structurées dans un graphique acyclique dirigé (Direct Acyclic Graph - DAG). Ces éléments ont permis à Spark d'exécuter des charges de travail plus complexes telles que l'apprentissage automatique et l'analyse graphique. Spark peut toujours utiliser YARN en tant que planificateur de capacité, tout comme les tâches dans MapReduce. Mais l'équipe Spark a également commencé à créer son propre planificateur et a ensuite ajouté le support pour Kubernetes.
À un moment donné, la communauté Spark a tenté de se distancier de l'écosystème Hadoop. Ils ne voulaient pas être considérés comme un module complémentaire au-dessus du logiciel hérité ou comme une sorte de "module complémentaire" pour Hadoop. Étant donné le niveau d'intégration de Spark avec le reste de l'écosystème Hadoop, et compte tenu des centaines de bibliothèques d'autres projets Hadoop utilisées par Spark, je ne suis pas d'accord avec l'idée que Spark est un produit autonome.
MapReduce n'est peut-être pas le premier choix pour la plupart des charges de travail de nos jours, mais c'est toujours l'environnement de base lors de l'utilisation de hadoop distcp - un package logiciel qui peut transférer des données entre AWS S3 et HDFS
plus rapidement que toute autre offre I testé.
Tous les outils Hadoop sont-ils efficaces?
Non, certains projets ont déjà éclipsé les nouveaux articles.
Par exemple, de nombreuses charges de travail qui étaient auparavant automatisées avec Oozie sont désormais automatisées avec Airflow. Robert Kanter, le principal développeur d'Oozie, a fourni une partie importante de la base de code qui existe aujourd'hui. Malheureusement, Robert n'a plus pris une part aussi active au projet depuis son départ de Cloudera en 2018. Pendant ce temps, Airflow compte plus de 800 participants, dont le nombre a presque doublé au cours de la dernière année. Presque tous les clients avec qui j'ai travaillé depuis 2015 ont utilisé Airflow dans au moins un département de leur organisation.
Hadoop fournit les différents éléments constitutifs et éléments qui composent la plate-forme de données. Souvent, plusieurs projets se disputent la fourniture de la même fonctionnalité. Au final, certains de ces projets s'estompent tandis que d'autres prennent les devants.
En 2010, plusieurs projets ont été positionnés comme le premier choix pour diverses charges de travail, dans lesquelles il n'y avait que quelques participants ou, dans certains cas, plusieurs déploiements importants. Le fait que ces projets vont et viennent a été utilisé comme preuve que l'écosystème Hadoop entier est en train de mourir, mais je n'en tire pas de telles conclusions.
Je vois cette faible association de projets comme un moyen de développer de nombreuses fonctionnalités puissantes qui peuvent être utilisées sans frais de licence utilisateur final importants. C'est le principe de survie des plus aptes, et cela prouve que pour chaque problème plus d'une approche a été envisagée.
MISE À JOUR: J'ai initialement déclaré que Oozie avait 17 membres sur la base de ce qui est rapporté sur GitHub. En fait, Oozie avait à la fois des validations directes et des correctifs soumis par 152 développeurs, et pas seulement 17 qui apparaissent dans le calcul de GitHub. Robert Kanter m'a contacté après la publication initiale de cet article avec la preuve de ces 135 auteurs supplémentaires, et je le remercie pour cette clarification.
Le trafic de recherche ne fonctionne pas
L'un des arguments en faveur de la "mort" de Hadoop est que le trafic de recherche Google sur diverses technologies Hadoop ne fonctionne pas. Cloudera et un certain nombre d'autres consultants ont fait un bon travail de collecte de fonds ces dernières années et ont fait des efforts importants pour faire avancer leurs propositions. Ceci, à son tour, a suscité un grand intérêt, et à un moment donné, une vague de personnes étudiant ces technologies est apparue dans la communauté technique. Cette communauté est diversifiée et, à un moment donné, la plupart des gens, comme toujours, sont passés à autre chose.
Dans toute l'histoire de Hadoop, il n'y avait pas une variété de fonctionnalités aussi riche qu'aujourd'hui, et elle n'a jamais été aussi stable et testée au combat auparavant.
Les projets Hadoop se composent de millions de lignes de code écrites par des milliers d'auteurs. Chaque semaine, des centaines de développeurs travaillent sur différents projets. La plupart des offres de bases de données commerciales ont de la chance si au moins une poignée d'ingénieurs apportent des améliorations significatives à leurs bases de données de code chaque semaine.
Pourquoi Hadoop est-il spécial?
Tout d'abord, il existe des clusters HDFS d'une capacité de plus de 600 PB. La nature des métadonnées HDFS dans la RAM signifie que vous pouvez facilement traiter 60 000 opérations par seconde.
AWS S3 a cassé beaucoup de ce qui peut être trouvé sur les systèmes de fichiers POSIX pour atteindre l'évolutivité. Les modifications rapides de fichiers, telles que celles requises lors de la conversion de fichiers CSV en fichiers Parquet, ne sont pas possibles dans S3 et nécessitent quelque chose comme HDFS si vous souhaitez répartir la charge de travail. Si le logiciel de conversion a été modifié pour rendre la charge de travail S3 susmentionnée uniquement, les compromis avec la localisation des données sont susceptibles d'être importants.
Deuxièmement, le projet Hadoop Ozone vise à créer un système compatible avec l'API S3 qui peut stocker des milliards d'objets dans un cluster sans avoir besoin d'utiliser son propre service cloud. Le projet vise à avoir un support intégré pour Spark et Hive, ce qui lui donne une bonne intégration avec le reste de l'écosystème Hadoop. Une fois sorti, ce logiciel sera l'une des premières offres open source à pouvoir stocker autant de fichiers dans un cluster.
Troisièmement, même si vous ne travaillez pas avec des pétaoctets de données, les API disponibles dans l'écosystème Hadoop fournissent une interface cohérente pour le traitement de gigaoctets de données. Spark est la solution ultime pour l'apprentissage automatique distribué. Dès que vous vous familiarisez avec l'API, peu importe si votre charge de travail est mesurée en Go ou en PB, le code que vous créez n'a pas besoin d'être réécrit, vous avez juste besoin de plus de machines pour l'exécuter. J'enseignerais d'abord à quelqu'un comment écrire du code SQL et PySpark, puis je lui enseignerais comment distribuer des commandes AWK sur plusieurs machines.
Quatrièmement, de nombreuses fonctionnalités de l'écosystème Hadoop sont des leaders pour les fournisseurs commerciaux. Chaque tentative de marketing infructueuse pour une base de données propriétaire conduit le service commercial à découvrir le nombre de fonctionnalités, de compromis et de goulots d'étranglement manquants dans leur offre. Chaque échec de POC amène l'équipe commerciale à découvrir la fiabilité de leurs tests logiciels internes.
Ceci conclut la première partie de la traduction. La suite peut être
lue ici . Et maintenant, nous attendons vos commentaires et invitons tout le monde à un webinaire gratuit sur le thème:
"Principes de construction de systèmes d'analyse en streaming" .