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 ).
dimanche 27 juin 2021
dimanche 7 février 2021
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.
vendredi 28 août 2020
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 !
vendredi 24 avril 2020
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
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
vendredi 28 février 2020
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
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
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.
Inscription à :
Articles (Atom)
