Upload
hadoop-user-group-france
View
1.122
Download
2
Embed Size (px)
DESCRIPTION
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).
Citation preview
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 ?