Découvrez Trunk Data Platform : La Distribution Big Data Open-Source par TOSIT

Depuis la fusion de Cloudera et Hortonworks, la sélection de distributions Hadoop commerciales on-prem se réduit à CDP Private Cloud. CDP est un mélange de CDH et de HDP conservant les meilleurs fonctionnalités de ces deux distributions. HDP 3.1 n’est plus supporté depuis décembre 2021, cela “oblige” les clients de Cloudera à migrer sur CDP.

Certains de ces clients ne sont pas en mesure d’upgrader régulièrement pour suivre le rythme de fin de support. D’autres ne sont pas intéressés par les features cloud mises en avant par Cloudera et souhaitent juste continuer de faire fonctionner leur existant sur Hadoop. HDP pouvait être téléchargé gratuitement, certaines entreprises sont intéressées par une distribution Big Data sans support pour certains use cases non critiques.

Enfin, certains sont inquiets du déclin de contributions open-source depuis la fusion des deux sociétés.

Trunk Data Platform (TDP) a été développé pour répondre à ces inquiétudes : la gouvernance sur le futur de la distribution est partagée, elle est accessible gratuitement et est 100% open-source.

TOSIT

TOSIT (The Open Source I Trust) est une association française loi 1901 qui vise à promouvoir le développement et l’utilisation de logiciels open-source. Elle a été fondée par des grands groupes, leaders dans leurs industries, comme Carrefour, EDF et Orange mais aussi par des administrations dont la Direction générale des Finances publiques.

Les travaux sur “Trunk Data Platform” (TDP) ont été initiés lors de discussions entre EDF et la DGFiP à propos de leurs plateformes Big Data sous support commercial.

Trunk Data Platform

Composants Apache

Trunk Data Platform (TDP) repose sur une idée claire : disposer d’une base robuste de projets Apache reconnus de l’écosystème Hadoop. Ces projets devaient couvrir la plupart des cas d’usages Big Data : espace de stockage et puissance de calcul distribués et abstractions SQL et NoSQL pour requêter les données.

Le tableau suivant résume les composants de TDP :

Note : Les versions des composants ont été choisies pour assurer une inter-compatibilité. Elles sont plus ou moins basées sur la dernière version de HDP 3.1.5.

Le tableau ci-dessus est extrait du repository TDP.

Nos repositories sont des forks des branches ou tags spécifiques indiquées dans le tableau. Il n’y pas de gros écart de code de la source Apache mais uniquement des changements de noms de versions et l’application de quelques patches supplémentaire. Chaque contribution au code qui bénéficierait à la communauté serait reversée en bonne et due forme au tronc Apache du projet en question.

Un autre pilier de TDP est la maîtrise totale du build au déploiement des composants. Voyons maintenant ce que cela implique.

Build de TDP

Créér un build de TDP revient à builder les projets Apache qui composent TDP à partir de leurs codes sources.

La difficulté principale de cette étape vient de la complexité des projets et des leurs nombreuses interdépendances. Par exemple, Apache Hadoop est un projet de plus de 15 ans avec plus de 200000 lignes de code. Bien que la plupart des composants de TDP soient des projets Java, les codes compilés incluent également les langages C, C++, Scala, Ruby et JavaScript. Pour s’assurer d’une compilation reproductible, nous utlisons une image Docker qui contient tout le nécessaire pour compiler et tester les composants présentés précédemment. Elle est fortement inspirée de celle du repository Apache Hadoop mais nous avons pour objectif d’écrire la notre.

La plupart des composants de TDP ont pour dépendances d’autres composants. Par example, voici un extrait du fichier pom.xml de TDP Hive :

<storage-api.version>2.7.0</storage-api.version>
<tez.version>0.9.1-TDP-0.1.0-SNAPSHOT</tez.version>
<super-csv.version>2.2.0</super-csv.version>
<spark.version>2.3.5-TDP-0.1.0-SNAPSHOT</spark.version>
<scala.binary.version>2.11</scala.binary.version>
<scala.version>2.11.8</scala.version>
<tempus-fugit.version>1.1</tempus-fugit.version>

Dans cet exemple, Hive dépend de Tez et de Spark.

Nous avons créer un répertoire tdp à la racine de chaque repository des composants de TDP (par exemple ici pour Hadoop) dans lequel nous indiquons les commandes utilisées pour compiler, tester (voir section suivante) et packager.

Note : Voir nos précédents articles “Construire votre distribution Big Data open source avec Hadoop, Hive, HBase, Spark et Zeppelin” et “Installation d’Hadoop depuis le code source : build, patch et exécution” si vous voulez en savoir plus sur le processus de compilation des projets Apache interdépendants de l’écosystème Hadoop.

Tester TDP

Tester TDP est une phase critique du processus de fabrication de TDP. Comme nos projets sont packagés et buildés de manière interdépendante, il faut nous assurer que ces releases sont compatibles entre elles. Pour cela nous déroulons les tests unitaires et les tests d’intégration.

La plupart des projets étant écrits en Java, nous avons choisi d’utiliser Jenkins pour automatiser les builds et tests de la distribution TDP. Le plugin JUnit est également très utile. Il permet d’obtenir un rapport complet des tests qui ont été exécutés après la compilation du code.

Voici un exemple de rapport de test pour Apache Hadoop :

Comme pour les commandes de builds, les commandes de tests et leurs options sont détaillées dans les fichiers tdp/README.md de chaque repository.

Note : Notre infrastructure de build/test basée sur Kubernetes est détaillée ici.

Déployer TDP

Une fois la phase de compilation terminée, nous nous retrouvons avec des fichiers .tar.gz qui correspondent aux releases de chaque composant de notre distribution Hadoop. Ces archives contiennent des binaires, des JARs compilés et des fichiers de configuration.

Pour rester en phase avec notre idée de contrôler toute la stack technique, nous avons décidé d’écrire une collection Ansible. Celle-ci embarque des rôles et playbooks qui permettent de gérer le déploiement et la configuration de TDP.

La tdp-collection est conçue pour déployer les composants de manière sécurisée (authentification Kerberos et TLS) et en haute disponibilité par défaut (si possible).

Ci-dessous un extrait de la tâche “hdfs_nn” du rôle Hadoop qui est chargée de déployer le HDFS NameNode :

- name: Create HDFS Namenode directory
  file:
    path: "{{ hdfs_site['dfs.namenode.name.dir'] }}"
    state: directory
    group: '{{ hadoop_group }}'
    owner: '{{ hdfs_user }}'

- name: Create HDFS Namenode configuration directory
  file:
    path: '{{ hadoop_nn_conf_dir }}'
    state: directory
    group: '{{ hadoop_group }}'
    owner: '{{ hdfs_user }}'

- name: Template HDFS Namenode service file
  template:
    src: hadoop-hdfs-namenode.service.j2
    dest: /usr/lib/systemd/system/hadoop-hdfs-namenode.service

TDP Lib

Les playbooks Ansible peuvent être lancés manuellement ou avec la TDP Lib. Il s’agit d’une CLI Python que nous avons conçu pour TDP. En l’utilisant, nous pouvons :

• Générer un DAG à partir des dépendances entre les composants pour tout déployer dans le bon ordre.
• Sauvegarder l’état et les logs des déploiements dans une base de donnée.
• Gérer le versionning des configurations des composants.

Quid d’Apache Ambari ?

Apache Ambari est une UI de management de cluster Hadoop open-source. Le projet était maintenu par Hortonworks et est maintenant déprécié en faveur de Cloudera Manager qui n’est pas open-source. Bien que les sources soient accessibles, Ambari est fortement dépendant à HDP et peut seulement déployer des clusters Hortonworks Data Platform (HDP). HDP était distribué sous la forme de paquets RPM dont les spec files permettant de les construire n’a jamais été open-source

Ces éléments nous ont permis d’établir que la dette technique du maintien d’Ambari pour TDP était trop importante. C’est pourquoi nous avons décidé de partir d’une feuille blanche et d’automatiser le déploiement de notre distribution Hadoop avec la solution la plus populaire : Ansible.

Prochaines étapes

TDP reste un projet en cours de conception. Bien que nous disposions déjà d’une base robuste de projets de l’écosystème Hadoop, nous souhaitons étendre la liste des composants de la distribution tout en essayant des nouveaux projets issus de l’incubation Apache comme Apache Datalab ou Apache Yunikorn. Nous espérons également être en mesure de pouvoir contribuer du code à certains des projets côté Apache.

La conception d’une Web UI est également prévue. Elle devra être capable de gérer la configuration des services, leur déploiement et leur alerting. Cette Web UI utilisera la TDP lib.

Rejoignez-nous !

La manière la plus simple de se lancer sur TDP est de parcourir le repository “Getting started” dans lequel vous trouverez des instructions pour déployer un cluster TDP sécurisé, fonctionnels et en haute disponibilité sur des machines virtuelles. Vous pouvez également soumettre des pull requests ou rapporter des issues dans la collection Ansible ou n’importe quel autre repository de TOSIT-IO.

Si vous avez des questions, n’hésitez pas à nous contacter via david@adaltas.com.