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.
dimanche 21 juillet 2019
dimanche 24 février 2019
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.
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.
dimanche 9 septembre 2018
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
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
lundi 5 mars 2018
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.
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.
mardi 7 novembre 2017
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 :
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:
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 ) :
Puis, on crée l'indexation :
La réplication dispose d'un mode debug fort utile lors du développement, le mode par défaut étant peu disert.
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");
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
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
$ 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.
lundi 31 juillet 2017
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.
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.
Inscription à :
Articles (Atom)
