Longue vie à TDP !

Nous saluons avec grand plaisir et intérêt la sortie depuis le 14 avril 2022 de la Trunk Data Platform (https://trunkdataplatform.io/) qui constitue “la distribution [Hadoop] co-construite par EDF & La DGFIP (Direction Générale des Finances Publiques), via l'association TOSIT”.

Изображение

C’est une excellente nouvelle à plusieurs titres :

• On se sent moins seuls ! Car depuis près de 3 ans et depuis l’acquisition d’Hortonworks par Cloudera, LINAGORA a développé pour le compte de plusieurs grands clients une pile alternative “LDP pour LINAGORA Data Platform” pour assurer la continuité d’usage et de support des technologies Hadoop dans des environnements critiques ;

• Le travail de LINAGORA est basé sur les codes source des piles HDP et CDP (encore disponibles à date) en version 2.6.x et 3.1.x tout en proposant une assurance logicielle basée sur son offre d’OSSA (https://www.08000linux.com/). Les livrables fournis à nos clients sont des paquets rpm buildés en priorité pour les distributions alternatives à RHEL (CentOS ou encore AlmaLinux) ;

• Nous avions participé aux discussions à l’origine de TDP avec la DGFIP il y a plus d’un an. L’objectif commun et partagé est de permettre l’émergence d’une pile alternative destinée à mutualiser et consolider les efforts d'industrialisation et de maintenance de pile Big Data open source souveraine et sans dépendance à un acteur unique. La première brique est posée... ;

• Nous voyons dans TDP une voie de convergence pour “rebaser” nos travaux sur la version Apache des différents composants tout en observant par ailleurs les travaux réalisés sur d’autres piles : Apache Bigtop (https://bigtop.apache.org), Bigdate for OpenPower (https://github.com/OpenPOWER-BigData) etc...

Nous avons pris le temps de regarder les éléments qui ont été publiés par la communauté TOSIT (https://tosit.fr) . Je vous partage ici les principaux éléments de notre analyse :

• TDP est basée sur les versions Apache des composants mis à disposition par la fondation ;

• Il n’y a aucun correctif/modification/contribution fonctionnelle/correctif de sécurité à ce jour sur le code des composants. C’est du “take it as it is” sur la base des versions communautaires. Ainsi tous les acteurs du marché qui s’intéressent au sujet partent sur la même ligne de départ concernant l’expertise de TDP puisque ce sont les versions Apache qui sont utilisées ;

• Une grande majorité des ajouts/suppressions des lignes dans les commits concernent le renommage des versions et la création des jobs jenkins de construction ;

• un travail a été contribué sur les mécaniques de déploiement (sans packaging RPM à l’heure actuelle) avec la fourniture de livrables exécutables sous forme de tar.gz à déployer ensuite sur la base de playbooks Ansible ;

• Les versions retenues par TDP sont cohérences avec ce que nous produisons pour les builds réalisés pour nos clients ;

   

• Niveau légal/juridique : pas de modification de code et les licences sont conservées donc c’est du Apache v2.

Les points de différences ou ceux qui ont toutefois retenu notre attention :

• A ce jour, seuls 11 composants sont distribués. Nos clients actuels exigent des composants complémentaires qui sont utilisés dans leurs cas d’usage ;

• Nous nous interrogeons sur la forme de packaging retenue (tar.gz déployés avec Ansible) qui selon nous n’est pas optimale dans un contexte de production critique. On reconnaît le fait d’être agnostique de la distribution Linux utilisée, mais la non-gestion des dépendances au moment du déploiement ou la gestion simplifiée des MAJ proposée par un système de packaging industriel comme rpm nous semble être manquants dans TDP.

• La majorité des contributeurs (9 à ce jour sur les repositories principaux) ne proviennent que d'une société. Rappelons qu’un des objectifs visé avec ces piles alternative est de sortir de l’impasse Cloudera et de ne plus être dépendant d'une seule et unique société...

Nous nous sommes d’ores et déjà rapprochés des différents acteurs impliqués dans TDP afin de proposer à très court terme nos premières contributions. Au travers de ces travaux, je souhaite démontrer la capacité de LINAGORA à :

• Participer à cette initiative que nous soutenons et en laquelle nous croyons ;

• Supporter TDP au travers de notre offre d’OSSA : en effet, les prestations attendues par nos clients sont d’assurer le MCO (Maintien en Conditions Opérationnelles) et le MCS (Maintien en Condition de Sécurité) avec des engagements forts de niveaux de service. La seule preuve de cette capacité est d’avoir déjà fait des contributions au projet ;

• Valider le fonctionnement des pull requests, l’accueil de la communauté et de la gouvernance du projet TDP piloté par l’association TOSIT ;

• Et enfin, permettre le fait de valider que l’objectif premier est de ne pas déprendre d’une seule et unique société dans l’apport de code dans les différents composants de TDP (logiciels cœurs et technologie de déploiement).

Ainsi, nous envisageons dans les prochains jours à pousser a minima deux contributions :

• L’ajout d’un composant majeur à TDP comme Sqoop ou Nifi par exemple ;

• La contribution d’un correctif de sécurité sur l’un des composants cœurs.

À plus long temps, les échanges initiés avec la DGFIP et les autres acteurs de TDP doivent selon nous permettre de réponse à questions majeures :

1. Fournir un outil convivial de gestion des déploiements des clusters Hadoop afin aussi d’en simplifier leur monitoring (observabilité) et leur exploitation quotidienne pour remplacer la brique Ambari ;

2. Définir la feuille de route fonctionnelle en termes d’évolution sur les composants cœurs en tirant parti des efforts de la communauté Apache et autres ;

3. Envisager et préparer l’”ère post Hadoop” avec la montée en puissance des principes d’usine de données (en complément des entrepôts de données) et l’avènement des technologies de streaming de données telles que Kafka (https://kafka.apache.org) ou encore Pulsar (https://pulsar.apache.org)

Dans tous les cas, nous nous réjouissons encore une fois de la publication de TDP et nous allons nous attacher à contribuer du code dans les prochains jours au projet.

Longue vie à TDP... en évitant de se prendre les pieds dans la trompe (Trunk) de l’éléphant ;-)