Hug france - Administration Hadoop et retour d’expérience BI avec Impala, limites et...
-
Upload
hadoop-user-group-france -
Category
Internet
-
view
1.122 -
download
2
description
Transcript of Hug france - Administration Hadoop et retour d’expérience BI avec Impala, limites et...
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 ?