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
vendredi 28 février 2020
mercredi 7 août 2019
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.
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.
dimanche 21 juillet 2019
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.
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 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.
Inscription à :
Articles (Atom)
