CV/Mission d'Administrateur Hadoop freelance

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

• POSTE : Data Ops (Administrateur/intégrateur Hadoop)

  BoursoBank (ex-Boursoama Banque
  Jan 2023 - aujourd'hui

  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...

• POSTE : Ingénieur DevOps Big Data – Administrateur/intégrateur Hadoop

  CNAM– Angers
  Jan 2021 - Jan 2023

  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)
  
  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’...

  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 …