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.
Inscription à :
Articles (Atom)
