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. SUPERVIS...
CONNAISSEZ-VOUS SOLOCAL GROUP 
2
CONNAISSEZ-VOUS SOLOCAL GROUP 
3
CONNAISSEZ-VOUS SOLOCAL GROUP 
4
DIMENSIONNEMENT D’UN CLUSTER 
5
DIMENSIONNEMENT D’UN CLUSTER 
6 
Type serveur Capacité de 
stockage 
Nombre de 
coeurs 
Capacité 
Mémoire 
Réseau 
Equilib...
DIMENSIONNEMENT D’UN CLUSTER 
7 
¾Remplir 2 baies en parallèle 
¾Les deux baies dans le même 
data center. 
¾Répartir les ...
DÉPLOIEMENT ET MAINTENANCE 
8
DÉPLOIEMENT ET MAINTENANCE 
9 
¾Sécuriser les accès 
• Authentification forte via Kerberos, Habilitation 
par permissions ...
DÉPLOIEMENT ET MAINTENANCE 
10 
¾Ne pas oublier de mettre en place et maintenir à jour: 
• Un miroir local : OS, distribut...
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 ...
SUPERVISION ET STRATÉGIE DE SAUVEGARDE/RESTAURATION 
13 
¾ Chaque composant d’hadoop fourni 
• Une interface basique en HT...
RETOUR D’EXPÉRIENCE HADOOP 
14
15 
RETOUR D’EXPÉRIENCE MIGRATION HADOOP 
CONTEXTE Points clés 
• La plateforme de stockage et d’analyse 
des données mobi...
INTÉGRER HADOOP DANS LE DATA CENTER 
16 
¾ Différentes sources de 
données et différents 
types de données 
¾ Une platefor...
CHARGEMENT DE DONNÉES/MIGRATION 
17 
¾ 183 tables 
¾ 18 mois d’historiques 
¾ 22 TO de données brutes collectées 
¾ 66 TO ...
INTÉGRATION OUTILS BI/DATAMINING 
18 
¾ Impala :Un moteur de requêtage SQL en temps réel sur hadoop (MPP) 
• Utilisant la ...
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 noe...
CONCLUSION 
¾Ne pas confondre Hadoop avec un outil de BI temps réel 
• A besoin d’être complété surtout sur le plan DataVi...
22 
QUESTIONS ?
Prochain SlideShare
Chargement dans…5
×

Hug france - Administration Hadoop et retour d’expérience BI avec Impala, limites et recommandations par Abed Ajraou et Cherif Tifrani de Solocal (Pages Jaunes).

1 977 vues

Publié le

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

Publié dans : Internet
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 977
Sur SlideShare
0
Issues des intégrations
0
Intégrations
100
Actions
Partages
0
Téléchargements
49
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Hug france - Administration Hadoop et retour d’expérience BI avec Impala, limites et recommandations par Abed Ajraou et Cherif Tifrani de Solocal (Pages Jaunes).

  1. 1. ADMINISTRATION HADOOP ET RETOUR D’EXPÉRIENCE BI HUG FRANCE CHERIF TIFARANI 06/10/2014
  2. 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. 3. CONNAISSEZ-VOUS SOLOCAL GROUP 2
  4. 4. CONNAISSEZ-VOUS SOLOCAL GROUP 3
  5. 5. CONNAISSEZ-VOUS SOLOCAL GROUP 4
  6. 6. DIMENSIONNEMENT D’UN CLUSTER 5
  7. 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. 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. 9. DÉPLOIEMENT ET MAINTENANCE 8
  10. 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. 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. 12. SUPERVISION ET STRATÉGIE DE SAUVEGARDE/RESTAURATION 11
  13. 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. 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. 15. RETOUR D’EXPÉRIENCE HADOOP 14
  16. 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. 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. 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. 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. 20. INTÉGRATION OUTILS BI/DATAMINING 19
  21. 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. 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. 23. 22 QUESTIONS ?

×