Multi cloud data & apps: snowflake

 Snowflake est une plate-forme data s'adossant sur les trois clouds les plus utilisés: aws, azure et gcp. C'est désormais un produit abouti en termes d'instanciation data du multi-cloud. Il dispose aussi de fonctionnalités data sharing très avancées pour partager la donnée entre différents comptes cloud à travers le monde.

Cette première étape achevée, il se lance désormais dans la construction d'un écosystème équivalent pour les apps en s'appuyant sans surprise sur les container services ou les native apps. Cette deuxième étape si elle réussit sera très fructueuse car le marché des apps offre bien plus d'opportunités que la distribution de la data.

Les container services sont désormais disponibles en public preview.

Pour découvrir Snowflake, une série de liens:

- doc Snowflake

- blog Snowflake

- handlab Snowflake

Observabilité

Un outil intéressant à étudier pour l'observabilité d'un système IT est Prometheus.

Schéma d'archi générale: 

Par l'intermédiaire d'exporters, il permet de regrouper les métriques de plusieurs systèmes ( bases de données, hardware, systèmes de messages, stockage de données, API, ... ) dans une TSDB ( Time Series DataBase ) pour ensuite les diffuser vers des outils d'alertes ou des outils de visualisation, en particulier Grafana, lui-même disposant d'un alert manager pour info.

Comme l'indique cette best practise, éviter d'utiliser le module Pushgateway. En particulier, si l'exporter n'existe pas pour le système à monitorer, soit vous pouvez créer en un, soit vous pouvez utiliser l'option textfile Collector du node exporter.

Elle permet de récupérer les métriques d'un système tiers, ces dernières étant créées par batch. Elles doivent respecter le format d'exposition de Prometheus.

Pour illustrer ce dernier point, voici un exemple de génération de métriques de type CPU:

!/bin/bash

# mpstat 15 >> mpstat.stat

MPSTAT_FILE=./mpstat.stat

DATE_FILE=`date +%F-%T`

METRIC_FILE=./metric.prom.${DATE_FILE}

> ${METRIC_FILE}

# Déclaration des métriques de type cpu

echo '# HELP node_cpu_user node cpu user' >> ${METRIC_FILE}

echo '# TYPE node_cpu_user gauge' >> ${METRIC_FILE}

echo '# HELP node_cpu_sys node cpu user' >> ${METRIC_FILE}

echo '# TYPE node_cpu_sys gauge' >> ${METRIC_FILE}

echo '# HELP node_cpu_idle node cpu user' >> ${METRIC_FILE}

echo '# TYPE node_cpu_idle gauge' >> ${METRIC_FILE}

echo '# HELP node_cpu_wait node cpu user' >> ${METRIC_FILE}

echo '# TYPE node_cpu_wait gauge' >> ${METRIC_FILE}

LAST_LINE=`cat ${MPSTAT_FILE} | tail -n 1 | tr -s ' '`

CPU_USER=`echo ${LAST_LINE} | cut -d ' ' -f 3 | sed 's/,/./'` 

CPU_SYS=`echo ${LAST_LINE} | cut -d ' ' -f 5 | sed 's/,/./'`

CPU_IDLE=`echo ${LAST_LINE} | cut -d ' ' -f 12 | sed 's/,/./'`

CPU_WAIT=`echo ${LAST_LINE} | cut -d ' ' -f 6 | sed 's/,/./' `

 

# Valeur des métriques de type cpu   

echo "node_cpu_user ${CPU_USER}" >> ${METRIC_FILE}

echo "node_cpu_sys ${CPU_SYS}" >> ${METRIC_FILE}

echo "node_cpu_idle ${CPU_IDLE}" >> ${METRIC_FILE} 

echo "node_cpu_wait ${CPU_WAIT}" >> ${METRIC_FILE}

# Copie du fichier des métriques dans le répertoire du node exporter 

PROM_FILE=~/metrics/metric.prom

> ${PROM_FILE}

cp ${METRIC_FILE} ${PROM_FILE}

Pour stresser une VM sur différents aspects ( CPU, mémoire, disque, socket, ... ), il existe deux outils stress et stress-ng pour le faire.

Kafka

 Sur le sujet, un livre:

Kafka: The Definitive Guide

Real-Time Data and Stream Processing at Scale

Gwen Shapira, Todd Palino,Rajini Sivaram & Krit Petty

et un site didactique: https://www.conduktor.io/kafka/

Création d'un usage dans le cloud

Je vais tenter d'apporter quelques éléments de réflexion sur le sujet après deux ans d'expérience.

Tout d'abord, le contexte, cet usage est critique car il permet le financement de commerçants à travers l'Europe ce qui leur permet de disposer d'une réserve de trésorerie au quotidien. On n'est plus sur un usage analytique souvent mis en place sur le cloud mais sur une application critique de type batch.

Cet usage s'appuie sur une plate-forme data hébergée par Google ( gcp ). Elle a été construite les précédentes années à partir d'outils comme Terraform et Ansible. 

Elle s'appuie sur un modèle en trois couches:

- une infrastructure commune à tous les usages;

- un socle technique délivrant des composants techniques génériques multi-usages ( ingestion de fichiers ou de messages, transformation et calcul de la donnée, export de données ... )

- une couche usage utilisant les composant techniques pour instancier des usages définis par le métier

Cette séparation entre la couche technique et la couche usage est intéressante car elle permet d'isoler le code métier du code technique et d'enrichir les composants techniques au-fur-et-à-mesure de l'ajout d'usages tout en assurant l'unicité de la couche technique.

De plus, on peut alors distinguer deux types de développeur, les développeurs du socle technique, des profils plus pointus des développeurs de la couche usage, des personnes technico-fonctionnelles pouvant développer des usages dans un canevas préétabli et nécessitant moins de connaissances techniques.

Pour illustrer mes propos, sur le projet où je travaillais, les développeurs du socle technique codent et testent unitairement des composants écrits en Java sur un poste de dev, puis déploient les composants dans des pods kubernetes.

Les développeurs usage codent des dags Airflow qui se résument à des séquences d'appels aux composants du socle technique, il ne reste plus qu'à gérer les paramètres en fonction du contexte métier. Les traitements métiers sont, quant à eux, écrits dans un langage SQL enrichi avec des tags. Les tags permettent d'avoir des traitements métiers multi-usages, par exemple gérer une problématique multi-pays.

Ce type d'architecture permet d'avoir certes un pool restreint de développeurs pointus, mais surtout permet le développement rapide d'usages en se consacrant uniquement aux règles métiers à traduire sans se préoccuper des problématiques techniques sous-jacentes.

On pourrait même envisager d'aller plus loin en proposant une interface de règles métier dans la mesure où les règles métier sont traduites dans un langage déclaratif paramétré. On aurait ainsi un usage qui est capable de se modifier en temps réel ( pas de compilation, pas de déploiement, ... ). Une forme de nocode directement accessible aux équipes métier 😉

Data & Distributed systems

 Best ressources to learn about data and distributed systems

Data & distributed systems

JVM dans container

Une vidéo très détaillée sur le fonctionnement des JVM dans un container avec un focus sur la gestion de la mémoire.

JVM & container 

Apache Beam: traitement unifié de la donnée en mode batch et streaming

 Une présentation claire de Frances Perry sur Apache Beam: Apache Beam: Portable and Parallel Data Processing (Google Cloud Next 17)

L'implémentation Google du modèle Beam toujours présentée par Frances Perry: Dataflow: A Unified Model for Batch and Streaming Data Processing

Fauna DB

Fauna DB est une nouvelle base qui propose un protocole distribué des transactions innovant sans synchronisation d'horloge en s'inspirant du protocole Calvin développé à l'université de Yale ( D.Abadi ).

Un overview de Fauna DB

Le protocole Fauna DB

Snowflake: une base de type datawarehouse en mode cloud

 Au-delà du buzz financier constitué par l'entrée en bourse de Snowflake, cette base "premium" est intéressante à étudier car elle offre une alternative aux bases proposées par les cloudeurs pour ceux qui veulent échapper un peu au vendor lock-in. Snowflake vous permet d'héberger vos données sur AWS, Microsoft et Google et donc vous fournit la possibilité de faire un choix réversible.

Snowflake est une base de type colonne dans la lignée d'Hana mais hébergée dans le cloud et peut être comparée à Google Big Query et Amazon Redshift. Si vous souhaitez avoir une vue générale sur le produit, consulter l'introduction générale.

C'est donc une base pour faire de l'analytique, mais comme Hana, elle peut supporter du transactionnel dans une certaine mesure. Pour en savoir plus, consulter la documentation sur le transactionnel. En comparaison, Google Biq Query ne supporte que l'auto-commit.

En terme d'architecture, elle s'appuie sur trois couches:

- une couche storage qui repose sur le système objet des cloudeurs ce qui lui permet de faire du time travel;

- une couche compute, nommée virtual warehouse, complètement configurable, l'équivalent des slots chez Google Biq Query;

- une couche cloud services qui regroupe les fonctionnalités essentielles d'une base ( gestion de l'infrastructure, catalogue des metadata, sécurité au sens large ... et un optimiseur ).

Comme les bases cloud, tout est géré automatiquement, de la gestion de la base à l'optimisation des requêtes. Cela permet aux DBA de se concentrer sur l'architecture et la conception et moins sur les tâches usuelles habituelles ( backup, patching, montée de version, ... ). Reste quand même à gérer les bugs inévitables avec le support et quelques optimisations ici et là ... 

Elle propose des fonctions de data sharing qui peuvent être étendues à plusieurs régions et à plusieurs cloudeurs via une fonction de réplication.

La réplication lui permet aussi d'offrir une fonctionnalité de disaster recovery.

Les autres principales fonctionnalités sont décrites ici.

Si vous souhaitez aller plus loin, une série de vidéos est disponible pour compléter votre analyse.

Pour ma part, j'ai testé environ un mois Snowflake et Google Big Query, les deux bases sont des choix possibles, mais Snowflake propose plus de fonctionnalités et le GUI est plus riche. Reste bien entendu à voir ces deux bases en action en production sur de grands volumes de données, au moins qqes dizaines de TB, mais ici, l'objectif est d'atteindre le PB et dans un cadre analytique pour se faire une idée plus claire sur leur potentiel.

Hana étant réservé au monde SAP, il est intéressant de voir une offre datawarehouse s'étoffer er prendre de l'ampleur pour la rendre accessible au plus grand nombre.

Kubernetes

Ces derniers mois, j'ai étudié Kubernetes pour voir s'il pouvait dépasser le domaine des micro-services utilisés ces dernières années ce qui a permis son essor.

A 5 ans d'âge, sur le point de devenir un standard dans le cloud, les trois leaders ( Google, AWS, Microsoft ) en déclinant une version "prête" à l'usage, mais aussi déployable en on-premise, il est temps de se poser la question du passage du stateless au stateful et de quitter le monde des containers appelant des services cloud en mode API.

J'ai donc exploré le monde Kubernetes du stateful et j'ai été agréablement surpris par le foisonnement autour de ce sujet qui va bien au-delà des PV ( physical volume ) et des PVC ( physical volume claim ). Le nombre de startups qui se développe autour du concept de cloud native storage en symbolise l'attrait et préfigure une montée en puissance d'applications plus conséquentes dans ce cluster d'applications qu'est Kubernetes.

Pour ma part, j'ai étudié la solution développée par Portworx et dans une optique d'un regroupement de clusters data dans un cluster Kubernetes, l'idée de séparation de la couche traitement et de la couche storage est séduisante. Ils ont plusieurs projets en production ou pas loin et leur site contient de nombreux exemples d'implémentation pour découvrir le produit.

Pour vous faire une idée de la richesse de l'écosystème Kubernetes, je vous invite à explorer cette map.

D'autre part, si on envisage un produit comme Anthos ou équivalent, on dispose alors d'une première approche pour pouvoir piloter des applications en on-premise ou sur le cloud avec peut-être la perspective d'éviter le fameux vendor lock-in de l'IT. L'histoire est longue dans ce sens, IBM, Oracle, cloudeurs et j'en oublie quelques-uns ...

Pour apprendre Kubernetes, j'ai suivi les deux modules de Cloud Academy, Introduction to Kubernetes et Building, Deploying and Running Containers in Production, ils sont très bien conçus pour appréhender les concepts Kubernetes et réaliser quelques TP d'apprentissage. En mode gratuit, n'hésitez pas à explorer You Tube, on y trouve de très bonnes présentations pour s'initier.

Ma playlist Kubernetes.

Pour pratiquer, vous pouvez installer MiniKube sur une VM et si vous pouvez disposer d'un portable avec 32 GB de RAM, vous pouvez créer un véritable cluster sur un hyperviseur. Pour ma part, j'apprécie l'hyperviseur de Vmware et j'ai donc monté un cluster à 3 noeuds ( un master, deux workers ) en m'appuyant sur le mode d'emploi fourni par Nakivo, excellent !

Ce tutoriel m'a permis de monter un cluster Cassandra et un cluster Elasticsearch ainsi que d'autres bricoles et de vérifier la solidité de la dernière version de Kubernetes, les noeuds étant des VM Ubuntu 20.04.

Durant cette étude, j'ai aussi découvert une startup qui propose des outils pour faciliter la prise en main de Kubernetes , d2iq. Auparavant, elle opérait sur Mesos, d'où un vrai savoir-faire dans le domaine des clusters d'applications.

Et pour les geeks, tentez de développer un opérateur en go !

Présentation de Spanner

Une étude sur Google Spanner

Les sujets abordés:
- Architecture
- ACID
- Conception de BDD
- Bonnes pratiques SQL
- Demo ( chargement par dataflow, LMD non partitionné ou non, plan d'exécution, ... )
- Limites de Spanner

Une infrastructure de clusters elk

Ces derniers mois, j'ai mis en oeuvre une infrastructure de clusters elk ( Elasticsearch, Logstash, Kibana ) sur gcp ( Google Cloud Platform ) en mode IAAS.

Pour ce faire, j'ai utilisé le shell, gcloud, ansible et terraform. Le pilotage de l'infrastructure peut se faire en mode manuel via une VM distante ou de manière automatisée sur Jenkins en mode conteneur ou sur Airflow. un ordonnanceur ( basique ).

En terme d'architecture, elle est virtualisée via des VM et repose sur des groupes d'instance pour la résilience et l'auto-scalabilité. Entre chaque groupe d'instance, des LB de niveau 4 permettent de gérer l'élasticité de l'infrastructure.

Elle est en mode streaming et non en mode batch, elle s'appuie sur un groupe d'instances logstash, chaque filtre de chaque instance effectuant des pull sur une queue pubsub en amont où les logs arrivent, l'objectif  de cette architecture étant de mettre en place un puit de logs à moyen terme.

Le coeur de l'architecture multi-environnment est un cluster elasticsearch, un groupe d'instance pour les master nodes et un groupe d'instance pour les data nodes. Par précaution, les data nodes ne sont pas auto-scalables, l'ajout ou la suppression des noeuds automatisés nécessitant une décision préliminaire. Contrairement à la partie cliente scalable classiquement sur la CPU ( logstash, kibana ), la partie data est délicate à scaler ( métrique, performance disque et réseau, gestion de la taille des data pour la suppression, ... ).

Les groupes d'instances sont régionaux. Ainsi, pour le groupe d'instances des data nodes, ils sont répartis au mieux sur trois zones ( = datacenters ) dans un périmètre acceptable pour la latence réseau, pour ma part, vu le client, on a opté pour la Belgique. Cette configuration permet d'assurer une HA de qualité.

En terme de disponibilité, si vous avez une VM qui plante suite par exemple à un problème kernel, oui, cela peut arriver, elle est immédiatement relancée.

Les datas sont visualisables via une ferme de VM Kibana. Elles sont disponibles au réseau extérieur de Google via un reverse proxy.

Par rapport à l'on-premise, on change de monde. Plus de machines à acheter et à attendre, plus de compétences réparties sur n équipes fonctionnant en mode silo, plus besoin de tailler les infras sur des pics, plus besoin de régler les pbs en envoyant un ticket d'incident à n équipes ... et je ne vous parle pas de la mise en production !

Reste la problématique du prix. Sur ce plan, on joue sur la taille des clusters. En dev, on a des clusters minimaux et non pas des mono-noeuds ( groupe d'instance à une VM et à deux pour les master nodes ) ce qui permet d'avoir de l'élasticité en fonction des besoins. On a aussi des environnements éphémères, merci au cloud car désormais, supprimer et recréer un cluster est automatisable ( pour ma part, c'est fait à 90%, mais on pourrait aller plus loin ).

Et puis, avis personnel, si on comptait enfin tous les coûts cachés d'une infra on-premise ... Suivant les usages, les contraintes, la confidentialité des données, ... cela prendra du temps mais on va droit vers un environnement hybride. La voie est tracée !

Pour être complet, un plugin gcp permet de gérer les snapshots sur un bucket, un agent stackdriver permet de monitorer les VM et il est possible de le compléter avec un agent applicatif pour le suivi du cluster elasticsearch. La brique Stackdriver permet aussi de créer des dashboards, un système d'alerte ...

Pour ceux qui souhaitent approfondir le sujet, voilà un bon point d'entrée: construction d'une infra elk via Terraform

Conversion des DDL

Lorsque vous initiez un projet Hadoop, un sujet à traiter consiste à initialiser les structures de données sous Hive. Vous pouvez créer un script qui va lire un fichier XML ou JSON décrivant les structures à importer, mais ce dernier doit être initialisé d'une façon ou d'une autre. Et si vous devez traiter des milliers de table, l'exercice devient vite long et ingrat.

L'autre solution consiste à écrire un script ou un programme qui va convertir une table relationnelle provenant souvent d'une base Oracle en une table Hive. Vous pouvez aussi chercher un outil de conversion déjà écrit, mais je n'en ai pas trouvé un suffisamment complet pour réaliser mon cahier des charges, ni sur github, encore moins chez un éditeur, ce sujet ayant toujours été le parent pauvre des outils de base de données.

En source, vous pouvez avoir plusieurs générateurs de bases de données ( outil de conception comme Power AMC,  binaires exportant une base de données, ... ). La première étape consiste à s'assurer que les options de ces différents outils soient identiques à chaque génération de scripts DDL, le but n'étant pas d'écrire un compilateur, mais simplement d'être capable d'extraire les données utiles de la source.

On peut décomposer le programme en deux principales parties, une première partie consiste à récupérer les informations utiles ( nom de  la table, noms et types des colonnes, partitionnement, commentaires, ... ), la seconde génère la structure Hive à introduire dans le catalogue de données.

Pour la première partie, le point à retenir est de rechercher les informations utiles dans le fichier d'export initial et non pas de chercher à supprimer toutes les informations inutiles. Vous verrez rapidement, avec cette stratégie, vous obtiendrez un code plus simple et surtout vous n'aurez pas à le modifier systématiquement à chaque nouvelle base traitée. Si les outils de génération se multiplient, n'hésitez pas à traiter les fichiers par type de famille afin de conserver un code maintenable même si vous éclatez votre code.

Pour la seconde partie, la conversion, il est intéressant au préalable de créer une structure intermédiaire qui catégorise les informations utiles récupérées durant la première phase ( objets de type table, de type colonne, de type commentaire, ... ). De cette manière, la génération d'une table Hive se base sur cette structure et donc votre code de génération Hive sera indépendant des différentes sources d'export, il ne sera modifié que si de nouveaux objets sont à traiter dans le mécanisme de conversion.

Pour ma part, j'ai écrit l'utilitaire en bash, car souvent en début de projet, on ne dispose pas d'environnements de développement style Eclipse, mais il peut être écrit dans n'importe quel langage et cet exercice vaut vraiment le coup si vous voulez créer un vrai data lake sous Hadoop, l'écriture initiale vous prendra environ 2 à 3 semaines suivant la complexité de la conversion. Mais après, moyennant quelques mises à jour au fil de l'eau, vous pourrez créer des milliers de tables en quelques minutes.

Découverte du cloud

Depuis quelques mois, j'étudie les fondamentaux sur les trois principaux cloud ( aws, azure et gcp ). Pour ce faire, je me suis appuyé sur les cours de Cloud Academy.

Les cours sont intéressants, ils permettent d'acquérir une vision générale sur les principaux composants d'un cloud ( réseau, vm, bases de données, sécurité, ... ) . L'émergence de Kubernetes n'est pas ignorée. La partie managée ( ha, auto-scaling, patching, ... ) qui consiste à gérer de manière automatique l'infrastructure est traitée, tout comme les services prêts à l'emploi du style App Engine qui se généraliseront probablement à l'avenir si l'usage cible reste relativement peu complexe.

Les TPs mériteraient d'être plus consistants pour certains, mais ils deviennent plus intéressants quand vous passez au mode intermédiaire sur un cloud. Pour aws et azure, les ressources sont nombreuses et variées, pour gcp, le cataloque est en cours de fabrication, google s'étant mis à vendre son cloud sur le tard.

Quelques examens permettent de vérifier ses connaissances, il y a même des cours qui préparent à certaines certifications pour les amateurs.

LLAP

LLAP est dans les grandes lignes l'équivalent d'Impala.

Contrairement à Impala, la documentation est bien moins fournie ( outil moins utilisé ? ). Pour ma part, je vais le découvrir dans les prochaines mois ... en attendant la fusion Hortonworks-Cloudera et son futur produit, un temps appelé Unity.

Un bon point lié à cette fusion: on va effectuer une montée de version ( 2.6 -> 3.x ) d'HDP pour être par la suite candidat à une migration vers la nouvelle stack du nouvel ensemble.

Cela nous permettra d'utiliser les nouvelles fonctionnalités d'Hive 3.0 ( le mode "transactionnel" apparu avant mais qui se généralise, les vues matérialisées, les contraintes d'intégrité, ... ).

Deux bons pointeurs sur LLAP:
- Home page;
- Configuration.

Chiffrement des données sous HDFS

Une présentation écrite pour un client : 

https://docs.google.com/presentation/d/1SVsnvyJ0ZU5eddqz8gn8wQnmpAsqv9NZLNJV_hj07FI/edit?usp=sharing

PerfUG #55 : Comment gérer un cluster Hadoop de 2800 noeuds et 150 M de conteneurs ?

Une présentation de qualité sur un cluster Hadoop ( Cloudera ) de grande taille maintenu par les ingénieurs de Criteo :

https://tv.octo.com/videos/perfug-55-comment-gerer-un-cluster-hadoop-de-2800-noeuds-et-150m-de-conteneurs/#share

https://drive.google.com/open?id=150VHcxYNa6CmI-CsZzcak6lgwepSlApz

Socle big data: vers le fil de l'eau

Jusqu'à maintenant, je vous ai parlé du socle construit pour un client et des fonctionnalités développées dans ce cadre.

Le chargement des données se fait en mode batch via un pattern, le data loader, qui charge les données dans un référentiel de données brutes accessible aux personnes habilités pour vérifier les données issues d'un silo qui sont par la suite transforméees en donnée d'entreprise via une phase de crunching, l'objectif étant de proposer aux usages une donnée transversale.

L'étape suivante est d'alimenter le data lake au fil de l'eau. On pourrait envisager la création d'un nouveau pattern reposant sur Kafka, un système de topics ( = queues ) très populaire au sein de la communauté big data. Si vous êtes intéressé pour explorer cette voie, je vous conseille d'étudier le travail de Gwen Shapira ( Confluent ).

Pour notre part, vu le besoin, nous nous sommes orientés vers un outil de réplication car nos sources de données sont essentiellement des bases de données ( DB2 & Oracle ). On aurait pu se diriger vers Oracle GoldenGate, mais le client souhaite se désengager d'Oracle pour des raisons tarifaires principalement.

On s'est donc tourné vers une autre alternative, Attunity Replicate. Si vous souhaitez avoir un apercu du produit, je vous conseille de lire l'article de Franck Pachot.

L'outil est en cours de test. Cependant, on peut déjà en dégager les grandes caractéristiques :
- Il est agentless: nul besoin d'installer un client sur les sources de données ( Oracle, DB2 ) et la cible ( Hadoop ). Ceux qui ont déployé des produits sur un parc étendu verront tout de suite l'utilité en terme d'administration ...
- Il dispose d'une console d'administration web centralisée où toutes les réplications peuvent être définies. Pour ceux qui veulent gérer plusieurs environnements, l'option AEM ( Attunity Entreprise Manager ) permet de gérer l'ensemble de ses clusters et les couloirs associés.
- Il est doté d'un module Compose qui au-delà du CDC ( Change Data Capture ), va constituer un référentiel des données chargées ( historique des mises à jour, données rafraichies au fil de l'eau et exploitables par un ETL par la suite, ... ).
- Il peut être appelé via une API REST pour être intégré dans un ordonnanceur style Control-M.
- Il dispose d'un dashboard pour monitorer l'ensemble des flux. Pour la consolidation, l'option AEM est recommendée.
- La reprise sur erreur est automatisée.

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

Pour cette dernière partie, je vais vous parler de la v360, pas au niveau de l'interface, là, vous trouverez toute la littérature utile sur la toile, mais d'une implémentation possible pour gérer les données.

Elle s'appuie sur une stack Hadoop ( Cloudera ) et elle repose sur les services Hive, HBase, Lily Indexer et Solr. L'objectif est de proposer une exposition simultanée des données en mode transactionnel ( Hbase ) et en mode recherche ( Solr ).

Pour ce faire, les données de la table Hbase sont mises à jour en mode map-reduce à partir des données raffinées du data lake. Puis, Lily Indexer s'occupe de la réplication des données entre la table Hbase et la collection Solr correspondante.

Maintenant, rentrons un peu dans la technique. Le table HBase est définie de cette manière :

CREATE TABLE IF NOT EXISTS table_name(row_key type, col1 type1, …, coln typen)
STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
WITH SERDEPROPERTIES ("hbase.columns.mapping" = ":key,cf1:col1,…,cf1:coln")
TBLPROPERTIES ("hbase.table.name" = "namespace_name:table_name");

Cette définition permet à Hive d'utiliser la table, cette dernière étant déclarée dans le métastore Hive.

Dans le socle, il existe toute une gestion du cycle de vie de la table Hbase ( création, remplacement, suppression ... et même un undo du remplacement ! ). De plus, cette table peut être indexée, c'est à dire on peut lui associer une collection Solr.

Cette dernière peut être définie ainsi:

solrctl instancedir --generate /root_socle/environnement/socle/solr/collection_name
cp directory_conf_usage/collection_name_schema.xml  /root_socle/environnement/socle/solr/collection_name
solrctl instancedir --create collection_name /root_socle/environnement/socle/solr/collection_name
solrctl collection --create collection_name -s num_shard -r num_replica

La partie la plus délicate consiste à configurer le service Lily indexer. Le point de départ est ce lien très général, mais je vous conseille de vous faire aider par le support Cloudera pour cette partie si possible. Sinon, vous pouvez vous appuyer sur ce tutoriel très complet et vous y réussirez petit à petit en mode essai/erreur ...

Pour information, nous avons implémenté Kerberos et Sentry et cela marche correctement sur nos clusters de dev. Reste à le valider en pré-production, puis en production.

Une fois cette étape franchie, il vous reste à définir la configuration de la réplication ( deux fichiers ) et sa déclaration ( commande hbase_indexer ). Le mode d'emploi se trouve ici.

Une illustration du fichier morphline pour le type double ( ajout de code Java ) :

DDL:

CREATE TABLE IF NOT EXISTS tab_double(id string, col1 double)

STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'

WITH SERDEPROPERTIES ("hbase.columns.mapping" = ":key,cf1:col1")

TBLPROPERTIES ("hbase.table.name" = ":tab_double"); 

Morphline :

{

extractHBaseCells {

mappings : [

{

inputColumn : "cf1:id"

outputField : "id"

type : "string"

source : value

}

{

inputColumn : "cf1:col1"

outputField : "col1"

type : "string"

source : value

}

]

}

}

{

java {

imports : "import java.util.*;"

code: """

String stringAmount = (String) record.getFirstValue("col1");

logger.info("stringAmount:" + stringAmount);

Double dbl = Double.parseDouble(stringAmount);

record.replaceValues("col1",dbl);

return child.process(record);

"""

}

}

Schema.xml :

fields
   field name="id" type="string" indexed="true" stored="true" 
                   required="true" multiValued="false"
   field name="col1" type="double" indexed="true" stored="true"
   field name="_version_" type="long" indexed="true" stored="true"
fields

Puis, on crée l'indexation :

$ hbase-indexer add-indexer \
--name table_name_indexer \
--indexer-conf root_socle/socle/solr/collection_name/
               morphline-collection_name-mapper.xml \
--connection-param solr.zk=zkhost1:2181,zkhost2:2181,
               zkhost3:2181/solr \
--connection-param solr.collection=collection_name \
--zookeeper zkhost1:2181,zkhost2:2181,zkhost3:2181

La réplication dispose d'un mode debug fort utile lors du développement, le mode par défaut étant peu disert.

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

Après avoir présenté le socle en terme d'architecture technique, détaillons un premier usage, qui ne sera pas une v360, premier usage habituel pour un data lake ( au prochain épisode ! ), mais un outil BI couplé à Hadoop.

L'idée est ambitieuse, elle consiste à vouloir remplacer progressivement un infocentre ( Oracle, puis DB2 ) par une solution Hadoop pour effectuer des requêtes analytiques plus rapidement et même de pouvoir exécuter de nouvelles requêtes qui ne se terminent pas habituellement.

Pour ce faire, le choix s'est porté sur Impala, les données étant stockées sous HDFS soit en format texte, soit en format Parquet pour optimiser le stockage et les performances. On n'a pas introduit Kudu pour de multiples raisons: manque de maturité, Kerberos à l'époque pas implémenté, PRA non disponible, ...

Impala est un service dédié à l'analytique, de nombreuses présentations sont disponibles sur slideshare pour bien cerner la technologie, par exemple : Impala internals.

La recette étant bien avancée, l'objectif est en passe d'être atteint, il reste encore sur le premier lot à réécrire quelques requêtes adaptées à l'optimiseur Oracle, mais pas à l'optimiseur Impala. Mais le nombre est restreint comparé au nombre de requêtes migrées.

Une première remarque, n'oubliez pas de calculer les statistiques sur les tables suite à une mise à jour importante, il n'existe pas encore une fonctionnalité permettant le recalcul automatique des statistiques si nécessaire.

Impala est un système effectuant des scans en parallèle sur plusieurs noeuds, la scalabilité étant assurée par l'ajout de noeuds si les performances se dégradent. De plus, il nécessite une quantité de RAM non négligeable ( 256 GB RAM par noeud ).

Par conséquent, le tuner ne dispose pas d'index pour optimiser ses requêtes. Il doit donc porter une attention toute particulière au choix de ses jointures. Heureusement, Cloudera dispose d'une grammaire riche dans ce domaine et vous vous apercevrez vite que parfois, il faudra changer le type de jointure pour éviter des temps de réponse trop élevés.

Pour des tables de grande volumétrie, il vous faudra aussi penser à partitionner vos tables pour éviter des jointures trop importantes.

Il n'existe pas encore de livres sur le tuning Impala de la qualité de ceux disponibles sur Oracle ( J.Lewis, Antognini, ... ). La seule documentation est celle offerte par Cloudera, heureusement de qualité. Le point de départ est ici.

Pour finir, un dernier tip: il existe bien des hints pour Impala et le hint STRAIGHT_JOIN vous permettra de reprendre la main sur les jointures.