Hadoop User Group du lundi 6 oct 2014: Talk #3: Administration Hadoop et retour d’expérience BI avec Impala, limites et recommandations par Abed Ajraou et Cherif Tifrani de Solocal (Pages Jaunes).

1. ADMINISTRATION HADOOP ET
RETOUR D’EXPÉRIENCE BI
HUG FRANCE
CHERIF TIFARANI
06/10/2014

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

3. CONNAISSEZ-VOUS SOLOCAL GROUP
2

4. CONNAISSEZ-VOUS SOLOCAL GROUP
3

5. CONNAISSEZ-VOUS SOLOCAL GROUP
4

6. DIMENSIONNEMENT D’UN CLUSTER
5

7. DIMENSIONNEMENT D’UN CLUSTER
6
Type serveur Capacité de
stockage
Nombre de
coeurs
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 noeuds 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

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

9. DÉPLOIEMENT ET MAINTENANCE
8

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

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

12. SUPERVISION ET STRATÉGIE DE SAUVEGARDE/RESTAURATION
11

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

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

15. RETOUR D’EXPÉRIENCE HADOOP
14

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

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

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

19. 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
TextFile
Parquet
Low-latency queries for a BI user experience

20. INTÉGRATION OUTILS BI/DATAMINING
19

21. INTÉGRATION OUTILS BI/DATAMINING VIA LE CONNECTEUR ODBC
20
¾ Limites Impala:
• Aucune tolérance de pannes,
9 Si un noeud tombe en panne , toutes les requêtes qui s’exécutent sur ce noeud 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),

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

23. 22
QUESTIONS ?