Création d'un socle big data ( partie 2 )

Le socle applicatif est écrit sur la base de trois langages ( bash linux, Python, Java ).

Le bash articule le coeur du socle et de nombreuses parties, en particulier la gestion des structures de données, sont développées en shell. Pourquoi ? Il permet d'utiliser les binaires de la stack Cloudera ( beeline, hbase shell, solrctl, hbase-indexer, ... ) et de cette manière, on bénéficie de toutes les fonctionnalités pas toujours disponibles dans des API de plus haut niveau.

Le bash est bien entendu un langage difficile à appréhender, mais on peut désormais l'écrire de manière maintenable et modulable, avec pour notre part l'utilisation de "contextes" qui sont en fait des librairies réutilisables par le socle. De plus, si pour certaines opérations comme par exemple l'analyse de fichiers xml, le bash n'est pas l'outil idoine, loin de là, on fait alors appel à Python, un interpréteur très en voque dans le big data, qui a le mérite d'être plus souple qu'un langage compilé comme Java.

J'apprécie le bash car c'est un outil sans équivalent en terme d'utilitaires. Un exemple: l'utilisation de taskset pour attribuer une tâche à un CPU.

On a ajouté du Python pour des besoins ponctuels, mais aussi car c'est l'outil favori des data scientists, même si avec l'avènement de la plate-forme spark et de scala, il sera intéressant de voir si le machine/deep learning ne migrera pas dans une certaine mesure vers ce type d'infrastructure où tout est optimisé pour la parallélisation des traitements et des données ( rdd ) dans des environnements distribués.

Initialement, on a développé le socle avec des outils tels putty, notepad++, ... bref des outils peu appréciés par certains développeurs peu habitués à linux. C'est pourquoi on propose aussi de développer sur Eclipse et donc de baser le point de départ du mécanisme d'intégration continue sur cet outil. Pour faciliter la tâche des futurs développeurs du socle, on a aussi écrit quelques outils en Python histoire de nous familiariser davantage avec ce langage.

Enfin, on utilise Java car une partie du data loader repose sur un composant Java précédemment écrit chez un autre client. De plus, il faut savoir que Java est un langage incontournable chez les grands comptes français.

En tant qu'ex-consultant Oracle, je suis sensibilisé par la gestion des structures de données et le socle contient donc un outil qui permet d'assurer le déploiement des mêmes structures de données sur tous les environnements de l'infrastructure. Cela paraît anodin comme ça, mais je peux vous assurer que c'est très rare dans les faits ...

De plus, autant à terme dans le big data 2.0, vous aurez des data loader, des outils de streaming, des outils de crunching, ... en mode graphique à l'image des anciens ETL, autant la gestion des structures de données sera probablement comme pour les bases relationnelles la grande oubliée de l'histoire car peu génératrice de business ...

On gère déjà pas mal de fonctionnalités ( droits HDFS, ACL, Sentry, partitionnement, format de fichiers, ... ) et la manière dont a été conçu cet outil permettra d'ajouter d'autres fonctionnalités de manière souple, par exemple des éléments de performance si nécessaire.

Le data loader purement technique est enrichi d'une couche de tables au sens Hive compatible Impala qui permet d'avoir des référentiels de données d'une part et une historisation des données entrantes d'autre part. Il fera à terme, il faut l'espérer, le bonheur des data scientists pour leur exploration des données en mode brut.

Création d'un socle big data ( partie 1 )

Depuis plus d'un an, je pilote un socle applicatif autour de la stack Cloudera afin de la rendre disponible à des usages ( = applicatif métier utilisant les données centralisées dans un data lake ).

La stack Cloudera est un package de multiples services ( hive, impala, solr, spark, ... ) administrable et déployable via un outil de management, cloudera manager, bien utile pour les équipes d'infrastructure, mais en terme applicatif, tout reste à  faire !

L'idée générale est de créer des patterns ( = services ), des fonctions réutilisables pour l'ensemble des usages leur permettant de pouvoir traiter de la data par de multiples canaux divers et variés.

Bien entendu, ces patterns doivent être déployables sur des infrastructures multi-noeuds, plus précisément un environnement logique composé d'un ensemble de patterns est susceptible d'être installé sur plusieurs environnements multi-noeuds.

Pour ce faire, on a écrit un outil de génération d'environnement en bash s'appuyant sur maven et on utilise un outil d'intégration continu propre au client pour déployer de manière automatique un environnement logique sur toutes les plates-formes disponibles ( qqes centaines de cpu, qqes TB RAM et qqes centaines de TB disque pour vous donner une idée de ce qu'est une infra big data ).

Tout cela pour vous dire que tout est à créer dans le big data 1.0 en mode non cloud !

Bon, revenons à nos patterns. On peut distinguer plusieurs types de patterns, ceux qui permettent de manager le socle ( outil de déploiement, outil de gestion des structures de données, ... ), ceux qui perment d'alimenter le data lake ( loader en mode batch, streaming de flux de données, reprise de données via sqoop ... ), ceux qui permettent d'épurer la donnée loin d'être très propre ( crunching via un outil comme Talend ) et ceux qui offrent  enfin ( ! ) une plus-value pour les usages ( batch de traitement des données en map/reduce, traitement BI via des outils comme Impala et Kudu, V360, data science pour les plus avancés, ... ).

La genèse d'un tel système est tout sauf une sinécure. Après une phase d'architecture pour bien poser l'infrastructure et les besoins des usages, on peut alors d'une part commander l'infrastructure, l'installer et la rendre opérationnelle ( plusieurs mois ) et d'autre part sur des machines mono-noeuds construire les premiers patterns pour alimenter le data lake ( structures de données, chargement des données ).

Une fois l'infra posée, on peut réfléchir à l'outil de construction et de déploiement des patterns tout en commençant à nettoyer et à enrichir les données présentes dans le data lake. A ce moment-là, les usages commencent à avoir accès aux données via JDBC pour effectuer des requêtes en mode SQL ( hive, impala, ... )  et commencer à aller plus loin via des outils de dataviz comme Tableau ou SAS.

Kudu: une base hybride dédiée à l'OLAP mais supportant l'OLTP

Dans le sillage d'Hana, Cloudera propose en mode open source Kudu, une base colonne permettant d'exécuter des requêtes analytiques en mode SQL.

Mais elle permet aussi d'insérer, de modifier et de lire des données en mode random, ce qui évite de multiplier les bases NoSql si vous travaillez sur des données structurées.

Il s'agit d'un système de stockage de données disponible à partir d'API Java  et C++, mais aussi interrogeable à partir d'Impala et de Spark.

La version 1.0 est désormais disponible => ready for production. Cependant, effectuer encore un POC avant de vous lancer.

Pour aller plus loin: Kudu, the white paper

Comme pour Hana, l'objectif final d'une telle  base est d'effectuer de l'analytique temps réel et non plus d'avoir un délai entre l'ingestion des données et la production de reportings.

Data science

Un article qui illustre très bien comment construire un outil de prédiction en utilisant Kafka, Spark ( streaming, mlib ), Kudu et Impala :

Building a prediction engine

Impala

Impala est un outil disponible sur la plate-forme Cloudera; il permet d'exécuter des requêtes analytiques au-dessus d'HDFS avec comme cible une concurrence d'accès de quelques dizaines d'utilisateurs. Vous pouvez envisager quelques centaines d'utilisateurs, mais là, il vous faudra au moins quelques dizaines de noeuds pour bien amortir la charge.

Quelques présentations pour bien appréhender cette nouvelle génération d'optimiseur multi-noeud au-dessus d'un système distribué de fichiers comme HDFS :

- How Impala works.

- How to tune Impala.

- Impala's analysis by G.Rahn.

Spark

Hadoop est la base d'un date lake avec son système de fichier distribué, HDFS. Pour info, il en existe d'autres comme CEPH ( open source ) ou GPFS ( IBM ). Il serait aussi intéressant de voir d'où forke celui de Scality dans la mesure où il est capable de traiter un nombre très considérable de vidéos.

Au dessus de ce shared data storage, d'autres moteurs peuvent être envisagés pour accélérer les traitements sur les données. Parmi ceux-là, j'ai été frappé par l'émergence et l'adoption ultra-rapide de Spark, un moteur parallèle in-memory disposant d'une API intéressante sur les RDD et d'options variées et multiples ( dataframes, streaming, machine learning ). Pour info, IBM est un gros contributeur de Spark.

Pour découvrir ce logiciel, j'ai lu le livre des "guys" de Databricks: Learning Spark.

En attendant l'opportunité de plonger dedans ...

Hadoop: architecture

Depuis sa création, Hadoop repose sur un modèle où chaque noeud du cluster est identique et où la scalabilité qui tend vers la linéarité est assurée par l'ajout de noeuds. Un noeud repose sur le principe de la colocalité des données et des traitements ce qui permet de soulager le réseau, élément primordial à la naissance de cette technologie. Enfin, il est préconisé comme pour les bases NoSQL d'installer le cluster sur du "bare metal", c'est à dire du dédié à l'opposé du virtuel.

Cependant, comme depuis sa naissance, l'IT a énormément évolué depuis plus de 10 ans et en particulier, les réseaux ont effectué un bond technologique ( Ethernet à 40 Gbs et Infiniband à 56 Gbs ). De plus, les grands comptes ont investi considérablement dans la virtualisation de leur infrastructure au détriment du dédié pour rationaliser leur coût et être capable d'offrir un provisioning beaucoup plus souple.

Vu ces évolutions, de nouvelles architectures Hadoop sont en train d'émerger. La première consiste à virtualiser l'architecture Hadoop. Pour les environnements bas ( développement, recette utilisateur, ... ), le pas est déjà franchi depuis quelques années. Reste à faire évoluer les environnements de production. Pour ce faire, les master nodes ( name nodes, admin nodes, appli nodes, edge nodes, ... ) sont complètement virtualisés, accès disque compris ( SAN ). Reste à préserver la colocalité des traitements et des données pour les data nodes, d'où un accès en mode DAS ou équivalent. Dans ce registre, VMware a fait de considérables travaux sur le sujet et propose désormais une alternative crédible au dédié : VMware big data. En particulier, je vous conseille la lecture du REX chez Skyscape.

Sur ce type d'architecture, le revers de la médaille est la perte de la haute disponibilité fournie par VMware au niveau des data nodes, les disques étant locaux. Il reste aux vendeurs de baies de disques de trouver des alternatives crédibles en terme d'HDFS et de sortir de leur modèle actuel privilégiant l'IOPS ( bases SQL en mode transactionnel  ) à la bande passante  ( clusters Hadoop en mode batch brassant de grandes quantités de données ). La solution d'EMC, Isilon, est déjà dans la liste des architectures certifiées par Cloudera et Adobe l'a mise en oeuvre.

Mais allons plus loin et considérant maintenant les progrès de la couche réseau. On peut alors envisager séparer la couche compute ( map-reduce ) de la couche storage ( hdfs ). Cela permettrait d'une part de pouvoir créer des pools de noeuds de type compute ( map-reduce, hive, spark, ... ) avec des configurations adaptées ( introduction possible de la GPU ) et non uniformes et d'autre part, de pouvoir spécialiser les noeuds de type storage en données chaudes/froides et ainsi de provisionner du disque magnétique, du SSD ou encore du disque flash en fonction du degré temporel de la donnée.

Dans ce domaine, HP a effectué un gros travail en laboratoire avec sa solution BDRA. Reste à l'éprouver dans le monde réel ...