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)

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


3


4

5

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


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


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


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


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


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 ?

Internet

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)