ADMINISTRATION HADOOP ET RETOUR  D’EXPÉRIENCE  BI

HUG FRANCE CHERIF TIFARANI

06/10/2014

SOMMAIRE

1

1. CONNAISSEZ-VOUS SOLOCAL GROUP

2. DIMENSIONNEMENT  D’UN  CLUSTER

3. DÉPLOIEMENT ET MAINTENANCE

4. SUPERVISION ET STRATÉGIE DE SAUVEGARDE /RESTAURATION

5. RETOUR  D’EXPÉRIENCE  HADOOP

1. Chargement de données/migration 2. Intégration outils BI/datamining via le connecteur ODBC

6. CONCLUSION

CONNAISSEZ-VOUS SOLOCAL GROUP

2

CONNAISSEZ-VOUS SOLOCAL GROUP

3

CONNAISSEZ-VOUS SOLOCAL GROUP

4

5

DIMENSIONNEMENT  D’UN  CLUSTER

DIMENSIONNEMENT  D’UN  CLUSTER

6

Type serveur Capacité de stockage

Nombre de cœurs

Capacité Mémoire

Réseau

Equilibré 8-10 x 1 TB

2 x 6 Coeurs 4 GB / Coeur 2 x 10 GB

Intensif I/O 12-15 x 1 TB 2 x 6 Coeurs

4 GB / Coeur

2 x 10 GB

Intensif CPU 8-10 x 2 TB

2 x 8 Coeurs

4 GB / Coeur

2 x 10 GB

¾ Pourquoi les machines virtuelles sont déconseillées • Hadoop  a  besoin  d’I/O  performantes • Un cluster Hadoop a besoin de connaître sa topologie pour optimiser le placement des données

¾ Certains composants Hadoop peuvent être utilisés dans des machines virtuelles • Les  nœuds  front  end  et  masters  qui  n’ont  pas  de  contrainte  forte  d’I/O • Cependant,  il  faut  prévoir  d’une  bande  passante  et  d’une  mémoire  suffisante

DIMENSIONNEMENT  D’UN  CLUSTER

7

¾Remplir 2 baies en parallèle

¾Les deux baies dans le même data center. ¾Répartir les services sur les baies

• Un Serveur master NN dans chaque baie • Assurer au moins un service ZK et JN sur chaque baie

¾Vlan  dédié  afin  d’assurer  une  communication fluide entre les serveurs.

8

DÉPLOIEMENT ET MAINTENANCE

DÉPLOIEMENT ET MAINTENANCE

9

¾Sécuriser les accès • Authentification forte via Kerberos, Habilitation par  permissions  Unix:  propriétaire,  groupe,  … • Isolation des utilisateurs forte: portée par les permissions HDFS

¾Sécuriser les données • Isolation des données dans un projet, un cluster  contient  l’ensemble  des  données.  L’isolation  repose  sur  les  permissions  HDFS • Isolation des données entre les projets. L’isolation  est  portée  par  la  gestion  des  groupes  Unix

Knox : passerelle  d’accès  sécurisée  et  distribuée  aux  services  d’un  cluster  hadoop

Sentry : contrôle  d’accès  fin  à  hive,  impala

Falcon : gestion du cycle de vie des données stockées dans hadoop

DÉPLOIEMENT ET MAINTENANCE

10

¾Ne pas oublier de mettre en place et maintenir à jour: • Un miroir local : OS, distribution hadoop, outils connexes • Serveur support dédié kerberos

¾Utiliser plusieurs baies et nommer les serveurs en fonction de cela

¾Favoriser les outils du monde DevOps (chef, puppet) • Restreindre les accès directs aux machines.

¾Penser HA par défaut

• Répliquer le serveur front end

¾ D’une  manière  générale,  il  est  essentiel  d’industrialiser la mise en production et de limiter au maximum la masse de code à maintenir en interne

SUPERVISION ET STRATÉGIE DE SAUVEGARDE/RESTAURATION

11

SUPERVISION ET STRATÉGIE DE SAUVEGARDE/RESTAURATION

12

¾ Ganglia:

• Collecte des métriques système et applicative dans une base RRD • Mise  à  disposition  à  l’exploitant   • Agrégation des métriques de plusieurs clusters

« Ganglia est le standard commun aux solutions sur hadoop pour la Remontée de métrique » ¾ Nagios:

• Alerting sur la base des métriques collectées par ganglia

« Nagios peut  être  remplacé  par  votre  outil  d’alerting interne » La  bonne  pratique  est  de  s’interfacer  avec,  pas  de  le  remplacer  

SUPERVISION ET STRATÉGIE DE SAUVEGARDE/RESTAURATION

13

¾ Chaque  composant  d’hadoop  fourni  

• Une interface basique en HTML (*.Http.Address dans les configurations) - Namenode : http://$hostname:50070/ - Resource manager: http://$hostname:8088/

• Une API REST

¾ Des interfaces graphiques fournissant une vue agrégée existent

• Cloudera manager : interface de gestion de cloudera

¾HDFS fournit un mécanisme de snapshot en temps constant

¾Distcp :  permet  de  faire  une  copie  distribuée  d’un  cluster  A  vers  un  Cluster B • À ordonnancer dans une crontab, controlM,  …

¾Sauvegarde des méta informations du namenode • fsimage et le WAL (fichier edits)

14

RETOUR  D’EXPÉRIENCE  HADOOP

15

RETOUR  D’EXPÉRIENCE  MIGRATION  HADOOP

CONTEXTE Points clés

• La  plateforme  de  stockage  et  d’analyse  des données mobile Pages Jaunes connait une croissance forte et rapide en volumes de données.

• Le coût du stockage de la solution existante  basés  sur  Netezza  n’est  plus  tenable à court terme

• Hadoop a été identifié comme une solution de  déchargement  d’entrepôt  permettant  d’atteindre  l’objectif  de  réduction  des  coûts  et optimisation des performances d’analyses

• Cadrage  d’un  projet  de  migration  et  d’une  plateforme  Hadoop

• Réalisation technique et fonctionnelle  d’interfaçage  entre  Hadoop et Netezza

• Intégration de la plateforme Hadoop avec les outils décisionnels existants

INTÉGRER HADOOP DANS LE DATA CENTER

16

¾ Différentes sources de données et différents types de données

¾ Une plateforme distribuée

¾ Différents  types  d’accès

CHARGEMENT DE DONNÉES/MIGRATION

17

¾ 183 tables ¾ 18  mois  d’historiques ¾ 22 TO de données brutes collectées ¾ 66 TO de données répliquées ¾ 80 TO de capacité de stockage brut (réplication incluse) ¾ Transfèrt des données avec Sqoop (en utilisant Cloudera Connector for Netezza et sqoop1) ¾ Compression des tables en mode parquet avec Impala

INTÉGRATION OUTILS BI/DATAMINING

18

¾ Impala :Un moteur de requêtage SQL en temps réel sur hadoop (MPP)

• Utilisant la même base de données de métadonnées que hive • Bypass MapReduce(lecture directe des données) • Prise en charge des formats de fichiers HDFS (text files, sequence files compressé, avro data files, treveni) • Optimisé pour les requêtes d'entrepôt de données (en particulier, parquet)

¾ Hive vs Impala TextFile vs Parquet

Low-latency queries for a BI user experience

TextFile

Parquet

INTÉGRATION OUTILS BI/DATAMINING

19

INTÉGRATION OUTILS BI/DATAMINING VIA LE CONNECTEUR ODBC

20

¾ Limites Impala:

• Aucune tolérance de pannes, 9 Si  un  nœud  tombe  en  panne  ,  toutes  les  requêtes  qui  s’exécutent  sur  ce  nœud  tombent  en  panne

• Impala ne prend pas en charge certaines opérations HiveQL 9 DESCRIBE DATABASE/COLUMN 9 SHOW PARTITION/COLUMNS/INDEXES) 9 Beaucoup d'entre elles sont envisagées pour les futures versions

• Impala ne couvre pas les processus de traitement de type ETL qui sont offerts par Hive

• Ne gère pas les type de données complexes (Array, MAP, STRUCT)

• Très consommateur en mémoire (prévoir 128go),

CONCLUSION ¾Ne pas confondre Hadoop avec un outil de BI temps réel

• A  besoin  d’être  complété  surtout  sur  le  plan  DataViz

¾ Big Data ne veut pas dire Open data • Penser aux enjeux sécurité en amont • Confidentialité

¾Faire monter en compétences les équipes sur le volet infra et applicatif

• Une formation est nécessaire mais pas suffisante • Donner un maximum de pouvoir aux utilisateurs

¾Ne pas négliger les coûts cachés

• Le  coût  de  migration  d’un  existant    (Netezza  vers  Hadoop)

¾Adopter une approche DEVOPS et utiliser des outils comme PUPPET, CHEF,

¾Être  en  capacité  d’absorber  les  nouvelles  versions  et  technologies

21

22

QUESTIONS ?