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).
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).
Hive, Impala, and Spark, Oh My: SQL-on-Hadoop in Cloudera 5.5
Similaire à 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).
[Café techno] Spectrum Project - Affronter et gérer la masse de données hétér...Groupe D.FI
Similaire à 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). (20)
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).
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
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.
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
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)
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
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