Google Cloud Next 2019 — Day 3

Nous voilà maintenant rentrés à Paris, et je vous propose de vous faire un retour sur le dernier jour de Google Next ’19 et notamment deux conférences auxquelles j’ai pu assister.

Data Catalog — Data discovery in Google Cloud

Data Catalog a été annoncé lors des keynotes mais n’a pas été détaillé et nous avons eu très peu d’informations sur le sujet. Cette conférence était l’occasion d’en savoir davantage.

Avant toute chose, resituons le contexte : dans les plateformes data, le suivi et la gestion des données, ainsi que la connaissance des informations contenues, d’une manière plus générale, la data gouvernance, sont des problématiques importantes. Malheureusement, celles-ci sont très peu souvent prises en compte ou mal réalisées, souvent en raison d’un manque d’outillage ou de prise de conscience de la problématique. Et pourtant la data gouvernance devrait piloter notre plateforme data.

Une mauvaise data gouvernance de vos plateformes aura des conséquences qui peuvent être importantes :

• Duplication de traitement sur les données (non connaissance des traitements),
• Duplication de données (non connaissance des données),
• Mauvaise gestion des droits d’accès (owner de la données non connu ou mal défini),
• Utilisation de la donnée pour des cas normalement interdits (mauvaise classification de la donnée),
• Non réalisation de use case en raison de la méconnaissance de l’information et de la façon de la partager (non connaissance des données),
• Maintenabilité défaillante (process et cycle de vie des données mal définis),
• Obligation réglementaire non respectée.

Cette liste est bien entendu non exhaustive … .

Dans le domaine du suivi des données, GCP ne proposait pas, jusque là, de produit ou de démarche pouvant nous aider à résoudre ces problématiques. Nous avions à notre disposition la possibilité de tagger les éléments contenant notre information et les services qui l’exploitent, ainsi qu’une gestion des logs afin de pouvoir faire un suivi de nos données.

Après cette introduction, voyons ensemble ce qu’est Data Catalog. Shekhar Bapat (Product Manager, Google Cloud) en a fait la présentation lors de cette session. Data Catalog est un service managé et scalable pour la découverte de la donnée et la gestion des metadata. Il s’agit de la première pierre de la construction de la gouvernance de la donnée dans GCP.

Data Catalog va donc nous permettre de connaître la constitution de nos données sur plusieurs projets à travers les services suivants :

• BigQuery : Dataset, table et vue
• Storage : Bucket
• PubSub : Topic

Cette recherche va pouvoir se faire sur le type de contenu que l’on souhaite, sur les particularités de ce contenu (par exemple, les colonnes d’une table ou d’une vue dans BigQuery) et sur les metadata. Nous pourrons par ailleurs appliquer des facets lors de nos recherches.

Les metadata pourront être aussi bien techniques que fonctionnelles, de simples textes ou des structures complexes. Elles pourront être appliquées automatiquement ou manuellement à nos contenus. Par exemple, si l’on utilise le service DLP (Data Loss Prevention) pour scanner nos données, des tags s’appliqueront directement dans Data Catalog. Voici une liste des metadata possibles :

• Metadata techniques : nom de tables, de colonnes, du topic, date de création etc. … . Ces metadata seront ingérées automatiquement;
• Metadata fonctionnelles : propriétaire de la donnée, niveau de criticité, information de DLP, logique métier, qui a construit la donnée et comment, … . Ces informations pourront être ajoutées manuellement ou inférées.

Dans le schéma suivant, nous voyons un exemple de gestion de metadata.

Enfin, nous pourrons gérer via IAM les droits d’accès à Data Catalog et définir des droits sur ce que les utilisateurs auront le droit de voir ou non. Si nous prenons l’exemple de données dans BigQuery, les utilisateurs pourront avoir le droit d’accéder aux données, uniquement aux metadata ou n’avoir accès que partiellement aux metadata si l’on ne veut pas, par exemple, donner accès aux informations de sécurité.

Ce service sera disponible dans le courant du 2e trimestre de 2019.

Pour aller plus loin, voici quelques liens :

• Documentation Data Catalog : https://cloud.google.com/data-catalog/
• Video de la conférence : https://www.youtube.com/watch?v=Qq76r-z_50c

Dataflow / PubSub / BigQuery — Advances in Stream Analytics

Au cours de cette conférence, Sergei Sokolenko (Product Manager, Google Cloud) nous a tout d’abord présenté l’architecture type pour le stream Analytics dans GCP et il insiste bien sur le fait de parler de processus continu et non de micro batch.

Comme vous pouvez le voir sur le schéma, nous avons la possibilité d’ingérer le flux de données via pubsub ou kafka. Les étapes de transformation sont réalisées en temps réel via Dataflow / Beam ou d’autres solutions telles que Flink ou encore Spark. Les structured streamings le sont potentiellement avec dataproc. Les flux de données sont enregistrés pour analyse dans différentes solutions comme BigQuery / BigTable, sur lesquels il est aussi possible de lancer des tâches de prédictions via l’AI platform. Sergei ne l’a pas encore précisé mais, bien entendu, une partie des analyses peuvent être réalisées avec Dataflow.

Au coeur de cette architecture se trouve l’étape de transformation / processing avec Dataflow / Beam. Apache Beam est un projet open source (à la base un projet Google) qui se décompose en deux grandes parties :

• SDK : ensemble de composants permettant de processer des flux continus de données ou des ensembles limités de données, en d’autres termes de traiter du streaming et du Batch. Lorsque l’on construit un job, nous pouvons associer différentes fonctionnalités pour réaliser un DAG d’exécution;
• Runner : les runners sont les composants qui vont exécuter le DAG sur l’infrastructure souhaité. Il existe des Runners pour des exécutions sur des clusters Beam, Spark, Flink, Hadoop, Apex, Gearpump, IBM Stream, Samza, Nemo et sur GCP avec Dataflow. Chacun de ces runners ont leurs particularités.

Sergei a ensuite évoqué les évolutions importantes concernant Dataflow :

• Streaming engine et Streaming auto scaling en GA : amélioration des performances et des capacité de streaming de Dataflow;
• Nouvelle interface pour la création de job Dataflow pour les templates, que ce soit pour les templates custom ou pour les templates “Google” avec, entre autres, le graphe du pipeline;
• Monitoring amélioré avec des informations complémentaires sur les retards des messages et, associé à cela, la capacité de créer des alertes directement au niveau du pipeline. Ces nouvelles informations (Lag et Data Freshness) sont pratiques pour déterminer les problématiques de performance, d’ingestion ou de propagation dans notre pipeline, les alertes nous permettant d’intervenir rapidement;
• Possibilité de faire des pipelines composés de transform provenant de langages différents (SQL, python, java, go). Par exemple, il est possible de construire un pipeline avec du Beam SQL et Tensorflow Extended.
• Créer des pipelines de Streaming à partir de l’interface de BigQuery.

Streaming avec Dataflow, PubSub, BigQuery et … Datacatalog

Je vais revenir sur la création de flux d’analyse de données en streaming à partir de BigQuery plus en détails grâce à la démonstration de Sergei. Cette évolution est très intéressante car elle offre de nouvelles possibilités à la plateforme et, en plus, montre le fonctionnement des différents services entre eux.

Voyons les différentes étapes :

1. Dans un premier temps, nous allons enregistrer le schéma des events qui nous devrons envoyer à PubSub dans Datacatalog. Ce schéma doit permettre par la suite à Dataflow de pouvoir manipuler les events avec du Beam SQL;
2. À partir du moment où nous avons associé nos messages en stream avec un schéma, nous allons pouvoir réaliser une requête SQL utilisant ce flux de données et potentiellement le joindre à d’autres tables dans BigQuery;
3. Nous prévoyons la table de destination pour les résultats;
4. Cette requête conçue, il ne nous reste plus qu’à exécuter notre job Dataflow via l’interface de BigQuery.

Concrètement, cela veut dire que nous allons pouvoir traiter les flux directement avec du SQL, les associer facilement à d’autres tables de références et enregistrer nos résultats en NRT (Near Real Time) dans BigQuery pour ensuite y associer un dashboard.

Beaucoup de possibilités en perspective, l’alpha étant prévue pour mai 2019.

Pour aller plus loin, voici quelques liens :

• Documentation Apache Beam : https://beam.apache.org/documentation/
• Article sur Beam SQL : https://medium.com/weareservian/exploring-beam-sql-on-google-cloud-platform-b6c77f9b4af4
• Video de la conférence : https://www.youtube.com/watch?v=YW2yK5V5L5k, je vous conseille aussi la deuxième partie de la vidéo avec Thomas Weise (Software Engineer, Streaming Platform, Lyft) sur son retour d’expérience avec BEAM sur la portabilité du framework, sur les évolutions de ce dernier et du Runner Flink

Voilà Google Next’19 est fini. Il y a eu beaucoup d’annonces coté Data, que nous allons pouvoir tester et mettre en pratique. “Bye and play with data” !

Articles liés :

• Google Cloud Next’19 Day 1 : https://medium.com/codeshake/google-next-2019-day-1-8916c7bf9aac
• Google Cloud Next’19 Day 2: https://medium.com/codeshake/google-cloud-next-2019-day-2-4120eff7d5f8