CV/Mission d'Administrateur Hadoop freelance

Exemple de missions de Yas,
Administrateur Hadoop habitant Paris (75)

Expérience professionnelle

EXPERIENCES PROFESSIONNELLES
Mai 2023 à Aujourd’hui BoursoBank (ex-Boursoama Banque
POSTE : Data Ops (Administrateur/intégrateur Hadoop)
Contexte :
Implication sur les périmètres Data, Datalake, automatisation des workflows
récurrents, audits et traitement de l’obsolescence des systèmes et services, ainsi que
conception de stratégies de backup et restore...Support N3, participation à la
sécurité et application des normes de sécurité établies par la société Générale,
Dora...
Réalisations :
- Automatiser la répliquer mensuellement des fichiers de la gateway vers HDFS
UAT, ou de UAT vers PROD, en utilisant des scripts Shell ou des DAGs Airflow.
- Traiter l’obsolescence de Hue : mise à jour de la version 4.2.0 vers 4.11.0 en
utilisant une nouvelle image Docker et intégration de Keycloak pour la gestion
des accès.
- Traiter l’obsolescence de Knox : générer une image Docker Knox, mettre à jour
vers la version 2.0.0 et exposer les UIs : resource manger, hdfs et webhdfs
- Traiter l’obsolescence de Nifi en passant de 1.9.2 à 1.23.0 en créant deux
nouveaux clusters
- Traiter l’obsolescence de Zookeeper en passant de 3.4.14 à 3.8.4 et déploiement
en conteneur Docker
- Backuper le cluster de Nifi Streaming via Dirvish, et tester la restauration
- Traiter l’obsolescence système : migration de Debian Jessie à Debian Buster puis
vers Ubuntu sur des différentes Clusters Nifi, hadoop, Hive, Hue, knox...
- Patcher les failles identifiées par Cyberwatch
- Créer des playbooks ansible pour la gestion des clusters Nifi..
- Générer des pistes d’audit hive, yarn et hdfs en local et les après envoyer aux
plateforme d’audit en utilisant Fluentb, passant par kafka, logstash, elasticsearch
et puis kibana...
- Remonter les pistes d’audit Hue vers la plateforme d’audit pour assurer la
traçabilité
- Upgrader la version système des clusters Hadoop (dev, préprod, prod) et Hive en
traitant toutes les dépendances nécessaires
- Générer des certificat, enregistrer les DNS et urbaniser...
- Configurer les HAProxy pour plusieurs services tels que NiFi, Zeppelin, Hive, sur
des load balancers dédiés, avec une VIP dédiée pointant vers le backend et le
frontend souhaité.
- Créer des URLs Consul renvoyant l’adresse IP du serveur actif pour la
configuration de services ne supportant pas le HA.
Optimiser les ressources pour plusieurs jobs Yarn
- Exporter les métriques de NiFi vers Prometheus et Grafana en reconstruisant une
nouvelle image Docker prenant en charge ce processus.
- Configurer Hive et créer un service Consul dédié pour exporter ses métriques vers
Prometheus et Grafana
- Exporter les logs Spark vers la plateforme de log dans le cadre de l’observabilité
des applications Data.
- Exporter des logs Hdfs, Yarn vers la plateforme de log...
- Effectuer le backup HDFS vers S3 (buckets ceph) en se basant sur des dags airflow
dans le cadre du projet complétude des sauvegardes DORA.
- Backuper les metadata HDFS via dirvish sur des machines des backups dédiés
- Dans le cadre du traitement de l’obsolescence Hadoop (passage de la version 3.1.1
à 3.4.1) : mise en place d’un environnement complet avec tous les autres services
associés, (prestodb, ranger, knox, hue, haproxy...) et traitement de l’obsolescence
système avec migration vers Ubuntu.
- Améliorer la configuration Hiera utilisée par Puppet pour déployer les services
Hadoop
- Gérer des Users/Groupes (système/technique) au niveau de système, Ldap et
Ranger, selon le besoin...
- Configurer les services SSSD et HDFS pour passer de LDAP à LDAPS, en créant de
nouveaux comptes techniques pour HDFS.
- Créer des VM avec Terraform et taguer/flagger les sous-réseaux pour une bonne
intégration avec Shorewall, la sécurisation des machines et gréer l’ouverture des
flux...
- Renforcer les clusters Hadoop par l’ajout de disques et de DataNodes, ainsi que par
la gestion de l’équilibrage des données, etc.
- Améliorer le playbook Ansible utilisé pour normaliser les données HDFS
- Mise en place de PostgreSQL pour Jfrog avec contrôle de la replication, du
switchover et du failover par Patroni+Consul, ainsi que la sauvegarde avec Barman et
archivage sur S3.
- Installer des nouveaux nœuds Cassandra
- Ajouter des nouveaux Node Manager
- Upgrader Traefik de la version 1.7 à 2.0 et mettre à jour toute la configuration afin
de gérer le trafic et remonter les métriques des workers Presto..
- Désactiver l’authentification Kerberos interne entre les workers et les coordinators
Presto
- Intégrer l’interpréteur Presto dans Hue, après l’échec de son intégration dans
Zeppelin suite à une mise à jour.
- Assurer le support N3...
- Déménager des DataNodes vers de nouveaux racks
- Mettre en place le spark History dans le cadre de l’amélioration, suivi et monitoring
des application avec l’arrivée du streaming on yarn
- Dévirtualiser les datanodes (En cours)
- Rédiger la documentation Confluence
Environnement technique:
Bitbucket, Bamboo, Jira, Confluence, Ubuntu, Terraform, Terragrunt, Puppet, Ansible,
Metabase, Mysql, Postgres, Cassandra, Prestodb, Hue, Zepplin, knox, Ranger, Nexus,
Jfrog, kerberos, Docker, Nifi, Hadoop (3.1.1, 3.4.1), Nfs, Spark, Hive, Airflow, kafka,
Fluentb, Elasticsearch, Jenkins, Prometheus, Consul, Kibana, Graphana, icenga,
Cyberwatch, Vsphere, Device42, Ipam, Ceph, Rclone, Shell, Python, Keycloak, Sssd,
Pki, Shorewall, Haproxy, Keepalived, Traefik...

Décembre 2021 à Avril 2023 CNAM– Angers
POSTE : Ingénieur DevOps Big Data – Administrateur/intégrateur Hadoop

I/Projet Réversibilité
Contexte :
Construire deux plateformes BigData (en association avec Linagora ): HDP(3.1.5):
Hortonworks Data Plateforme et HDF(3.1.5): Hortonworks Data Flow 100%
opensource dans le but de se détacher de Cloudera.
Parmi les difficultés à gérer dans la construction des piles, c’est l’absence de la
méthode de fabrication des binaires à partir des sources, difficulté d’avoir une
visibilité de la complexité des composants, sources Cloudera opaques, multiplicité
des repos, complexité et richesse d’écosystème BigData et la Complexité des
dépendances inter-composantes logicielles…
Artefacts interdépendants entre eux, ce qui implique un ordre de build particulier
pour permettre des dépendances externes : artefacts java ou paquets RPMs.
Les sources sont principalement en Java. La compilation java avec Maven est utilisé
dans ces projets.
Dans le cadre du build de la pile HDF, les versions des composants utilisés et les
niveaux de patchs de certains composants diffèrent de celles utilisées dans le cadre
du build de la pile HDP. C’est en particulier le cas de Ranger, Zookeeper, Hadoop.
Réalisations :
- Définir les règles d’exploitation des binaires HDP et HDF dans l’environnent de la
CNAM
- Récupération des sources sur le GitHub Hortonworks de chaque composant :
plusieurs versions taguées : 3.1.5 et 3.1.4 dans le code Tag HDP ajouté après la
version standard Apache.
- Création des environnements avec Docker pour avoir les bons outils dont a besoin
chaque composant.
- Modification du code source en code intermédiaire afin de permettre son
optimisation
- Optimisation du code source intermédiaire
- Configuration Maven (configuration de déploiement)
- Lancement des tests unitaires, deux grand plugins les plus utilisés : SUREFIRE et
JUINIT
- Analyse des risques
- Application des patchs
Continuer à recompiler les sources Cloudera et maintenance correctif et évolutif des
fichiers de configuration
- Construction des RPMs pour chaque composant
- Gestion et résolution des erreurs tout au long des compilations Apache et RPMs
- Gestion des dépendances pour chaque composant
- Support technique à distance sur l’utilisation et la maintenance corrective de la pile
Big Data CNAM
- Reprendre la méthodologie Hortonworks pour le fonctionnement des paquets.
- Vérification de la livraison des paquets
- Applications des patchs et CVE
- Utilisation de la procédure de pack management pour intégrer les versions
Apaches ( Ambari pack management)
-Préparation des MEPS (mise en production)
Environnement technique:
Centos7, Docker, RPMs, Maven, Ant, Bower, R, Java, Yum , Dnf, Hive, Hbase, Ambari,
Atlaas, Phœnix, Kafka, Zookeeper, Spark, Nifi, Knox, Ranger, Hadoop …

II/Projet TDP (Trunk Data Platform)
Contexte :
Trunk Data Platform est une distribution Hadoop, Open Source, totalement libre de
droits.
La distribution TDP est basée sur les versions open source de composants Apache de
l’écosystème big data. Dans le cadre du projet TDP, ces composants sont compilés,
testés et déployés de manière automatique.
Par soucis de continuation de services, les première versions mise à disposition sont
alignées sur celles des distributions HDP 2.6.5 et HDP 3.1.5. La liste des composants
supportés inclue : Hadoop (HDFS, YARN, MapReduce), Hive, Tez, Spark, Ranger,
Ranger-KMS, HBase, Phoenix, Knox, Oozie, NiFi, Kafka, et ZooKeeper.
Réalisations :
- Réalisation supplémentaire d’un projet pour compiler des sources RPMs Centos7
(système CNAM) à partir des sources Ubuntu afin de les utiliser pour le projet TDP.
- Implémentation de la procédure de désinstallation d’un cluster TDP
- Développement de script de désinstallation de cluster TDP
- Participation à la construction du dossier d’architecture TDP
- Correction des erreurs liées à la stack sur l’aspect système ou sur les configurations
des services
- Implémentations des playbooks pour le déploiement et l’installation des certificat
SSL valide sur le réseau de la CNAM
- Implémentations des patchs pour la correction automatique des erreurs
- Cryptage de tous les passwords utilisés dans le projet avec ansible Vault
- Etude sur l’aspect sécurité du cluster notamment la faille log4
- Réalisation des tests techniques et fonctionnels sur les clusters (DEV, PROD)
- Rédaction des tests d'acceptance déploiement TDP
- Industrialisation des tests d’...