Depuis Cloudera et Hortonworks fusionnéle choix des distributions Hadoop commerciales pour les charges de travail sur site se résume essentiellement à Cloud privé CDP. Le CDP peut être considéré comme le « meilleur des deux mondes » entre CDH et HDP. Avec la fin du support de HDP 3.1 à venir en décembre 2021, les clients de Cloudera sont « obligés » de migrer vers CDP.
Qu’en est-il des clients qui sont pas capable de mettre à jour régulièrement pour suivre les dates EOS ? Certains autres clients sont pas intéressé par les fonctionnalités du cloud mis en évidence par Cloudera et qui souhaitent simplement continuer à exécuter leurs charges de travail Hadoop « héritées ». Hortonworks’ HDP était téléchargeable gratuitement et certaines entreprises sont toujours intéressées par une distribution Big Data sans support pour charges de travail non critiques pour l’entreprise.
Enfin, certains s’inquiètent du sens diminution des contributions open source depuis la fusion des deux sociétés.
Plate-forme de données de tronc (TDP) a été conçu avec ces problématiques en tête : une gouvernance partagée sur l’avenir de la distribution, accessible gratuitement et 100% open-source.
S’ASSEOIR
S’ASSEOIR (The Open Source I Trust) est une association française à but non lucratif promouvant les logiciels libres. Certains membres fondateurs comprennent des leaders de l’industrie tels que Carrefour (détail), FED (énergie) et Orange (télécommunications) ainsi que Ministère de l’Economie et des Finances.
Les travaux sur la “Trunk Data Platform” (TDP) ont été initiés dans le cadre d’échanges entre EDF et le ministère de l’Economie et des Finances concernant le statut de leurs plateformes Big Data d’entreprise.
Plate-forme de données de tronc
Composants Apache
L’idée centrale de la plate-forme de données de tronc (TDP) est d’avoir un base sécurisée et robuste de projets Apache bien connus de l’écosystème Hadoop. Ces projets devraient couvrir la plupart des cas d’utilisation du Big Data : système de fichiers distribué et ressources informatiques aussi bien que SQL et NoSQL abstractions pour interroger les données.
Le tableau suivant résume les composants de TDP :
Noter: Les versions des composants ont été choisies pour assurer l’intercompatibilité. Ils sont approximativement basés sur la dernière version de HDP 3.1.5.
Le tableau ci-dessus est maintenu dans l’essentiel Référentiel TDP.
Nos référentiels sont principalement des forks de balises ou de branches spécifiques comme mentionné dans le tableau ci-dessus. Il y a aucun écart par rapport à la base de code Apache sauf pour le nom de la version et certains rétroportages de correctifs. Si nous apportons un code significatif à l’un des composants qui profiterait à la communauté, nous suivrons le processus pour soumettre ces contributions à la base de code Apache de chaque projet.
Un autre concept de base de TDP est de tout maîtriser, de la construction au déploiement des composants. Voyons les implications.
Construction du PDT
La construction de TDP revient à construire les projets Apache sous-jacents à partir du code source avec quelques légères modifications.
La difficulté réside dans la complexité des projets et leur de nombreuses interdépendances. Par exemple, Apache Hadoop est un projet de plus de 15 ans avec plus de 200000 lignes de code. Alors que la plupart des composants de TDP sont Projets Javale code que nous compilons inclut également C, C++, Scala, Ruby et JavaScript. Pour assurer des builds reproductibles et fiables, nous utilisons un Image Docker contenant tout le nécessaire pour construire et tester les composants ci-dessus. Cette image a été fortement inspirée par le une présent dans le projet Apache Hadoop mais nous sommes Planification en faisant le nôtre.
La plupart des composants de TDP ont des dépendances sur d’autres composants. Par exemple, voici un extrait de TDP Hive pom.xml dossier:
<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 ce cas, Hive dépend à la fois de Tez et de Spark.
Nous avons créé un tdp répertoire dans chaque référentiel des projets TDP (exemple ici pour Hadoop) dans lequel nous fournissons les commandes utilisées pour construire, tester (couvert dans la section suivante) et forfait.
Noter: Assurez-vous de consulter nos articles précédents “Créer votre distribution Big Data open source avec Hadoop, HBase, Spark, Hive & Zeppelin” et “Installer Hadoop à partir de la source : construire, corriger et exécuter” si vous souhaitez avoir plus de détails sur le processus de construire des projets Apache interdépendants de l’écosystème Hadoop.
Test du TDP
Les tests sont une partie essentielle du processus de publication de TDP. Étant donné que nous emballons nos propres versions pour chaque projet de manière interdépendante, nous devons nous assurer que ces les versions sont compatibles avec l’un l’autre. Ceci peut être réalisé en exécutant des tests unitaires et des tests d’intégration.
Comme la plupart de nos projets sont écrits en Java, nous avons choisi d’utiliser Jenkins pour automatiser la construction et les tests de la distribution TDP. Jenkins’ JUnit plugin est très utile pour un rapport complet des tests que nous exécutons sur chaque projet après avoir compilé le code.
Voici un exemple de sortie pour le rapport de test d’Apache Hadoop :
Tout comme les versions, nous avons également engagé les commandes et les indicateurs de test TDP dans chacun des référentiels. tdp/README.md des dossiers.
Noter: Des informations de haut niveau sur notre environnement de construction/test basé sur Kubernetes sont disponibles ici sur notre référentiel.
Déploiement de TDP
Après la phase de construction que nous venons de décrire, il nous reste .tar.gz fichiers des composants de notre distribution Hadoop. Ces archives regroupent les fichiers binaires, les fichiers JAR compilés et les fichiers de configuration. Où allons-nous à partir d’ici?
Pour rester cohérent avec notre philosophie de garder le contrôle sur l’ensemble de la pile, nous avons décidé d’écrire notre propre Ansible le recueil. Il est livré avec des rôles et des playbooks pour gérer le déploiement et la configuration de la pile TDP.
La tdp-collection est conçu pour déployer tous les composants avec sécurité (authentification Kerberos et TLS) et la haute disponibilité par défaut (si possible).
Voici un extrait du Sous-tâche “hdfs_nn” du rôle Hadoop qui déploie le Namenode Hadoop HDFS :
- 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.serviceBibliothèque TDP
Les playbooks Ansible peuvent être exécutés manuellement ou via le Bibliothèque TDP qui est un CLI Python nous avons développé pour TDP. Son utilisation offre de multiples avantages :
- La bibliothèque utilise un généré DAG sur la base des dépendances entre Composants tout déployer dans le bon ordre ;
- Tout le déploiement les journaux sont enregistrés dans une base de données;
- La lib gère également le gestion des versions de la configuration des composants.
Qu’en est-il d’Apache Ambari ?
Apache Ambari est un Hadoop open source interface utilisateur de gestion de cluster. Il a été entretenu par Hortonworks et a été abandonné en faveur de Cloudera Manager qui n’est pas open-source. Bien qu’il s’agisse d’un projet Apache open source, Ambari était fortement lié au HDP et était uniquement capable de gérer les clusters Hortonworks Data Platform (HDP). HDP a été distribué sous forme de packages RPM et le processus utilisé par Hortonworks pour créer ces RPM (c’est-à-dire : le spécification files) n’a jamais été open-source.
Nous avons évalué que le dette technique de maintien d’Ambari par souci de TDP était trop pour être rentable et a décidé de repartir de zéro et d’automatiser le déploiement de notre distribution Hadoop en utilisant la norme de l’industrie pour l’automatisation informatique : Ansible.
Et après?
TDP est toujours un travaux en cours. Alors que nous avons déjà une base solide de projets orientés Hadoop, nous prévoyons de extension de la liste des composants dans la distribution et l’expérimentation de nouveaux projets Apache Incubator comme Laboratoire de données Apache ou Apache Yunikorn. Nous espérons également pouvoir bientôt contribuer au code du tronc Apache de chaque projet.
La conception de une interface Web est aussi dans les ouvrages. Il devrait pouvoir gérer tout, de la gestion de la configuration à la surveillance des services et aux alertes. Cette interface utilisateur Web sera alimentée par le Bibliothèque TDP.
Nous avons investi beaucoup de temps dans Rôles ansibles et nous prévoyons de les exploiter dans la future interface d’administration.
Être impliqué
Le moyen le plus simple de s’impliquer dans TDP est de passer par le Commencer référentiel dans lequel vous pourrez exécuter une installation TDP entièrement fonctionnelle, sécurisée et hautement disponible dans des machines virtuelles. Vous pouvez également contribuer via demandes d’extraction ou signaler problèmes dans la collection Ansible ou à l’un des TOSIT-IO dépôts.
Si vous avez des questions, n’hésitez pas à nous contacter à [email protected].