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

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 😉

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

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.

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

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.