Google Cloud Next 2019 - Day 2

Published in

CodeShake

7 min readApr 11, 2019

Et nous voilà repartis pour la deuxième journée de conférence à Next 2019 avec SFEIR ! Comme hier, nous allons commencer la journée avec la Keynote et ce que l’on peut dire c’est que nous avons été gâté en terme d’annonce et tout particulièrement en ce qui concerne la data.

Voici une liste des annonces qui m’ont particulièrement marquées hier et oui, ce sera ciblé :

Data Fusion : facilite l’intégration de données à travers une interface graphique et assure aussi un meilleur suivi : https://cloud.google.com/data-fusion/;
Data catalog : ils en ont très peu parlé mais je suis vraiment curieux de ce service, sachant que la data gouvernance est une problématique très forte et que pour le moment il existe très peu de solutions vraiment efficaces, pour le moment la beta n’est pas encore disponible, comme il y a une conférence demain, je pourrais faire un retour sur le sujet;
BigQuery BI engine : la promesse, permettre de faire de l’analyse à faible latence avec, dans un premier temps, seul data studio pour l’exploiter : https://cloud.google.com/bi-engine/docs/;
BigQuery ML : importantes évolutions … j’en parle un peu plus bas;
Auto ML Table : facilite et gére le workflow de machine learning sur des données structurées : https://cloud.google.com/automl-tables/;
Document Understanding AI : comprend nos documents : https://cloud.google.com/solutions/document-understanding/.

Et pour être plus complet voici des articles de Google Cloud présentants plus d’informations sur les annonces de ce deuxième jour :

En tout cas, ce fut une Keynote riche en annonces ! Nous avons pu directement enchaîner avec d’autres conférences et j’ai choisi de vous faire un résumé de deux d’entre elles.

BigQuery ML: What’s New, and an Exploration With Booking.com on Using it to Assess Data Quality

BigQuery ML était une des grandes annonces de Next 2018 et le fait de permettre la création de modèles de régression linéaire ou logistique à partir de nos dataset BigQuery et en SQL offre une nouvelle capacité de création de modèles de Machine Learning, que ce soit pour de l’exploration, du testing ou de la mise en place de modèle de production. Pour rappel, cette version en beta permettait de créer et d’entraîner son modèle, de l’évaluer et de l’exploiter sur de nouvelles données dans BigQuery et fournissait un ensemble de métriques intéressantes ainsi que la capacité de paramétrer un certain nombre d’hyperparameters.

Après ce rappel de juillet 2018, Abhishek Kashyap (Product Manager, Google Cloud) et Robert Saxby (Solutions Architect, Google Cloud) nous ont présenté le passage en GA de BQML puis les les dernières évolutions et le moins que l’on puisse dire, c’est que les choses ont beaucoup évolué :

Une nouvelle UI avec la dernière version de BigQuery UI
k-means clustering en beta

CREATE MODEL yourmodel
OPTIONS (model_type = "kmeans", num_clusters=4, standardize_features=true)
AS SELECT ...

Matrix Factorization en Alpha

CREATE MODEL yourmodel
OPTIONS (model_type = "matrix_factorization"
AS SELECT ...

Deep Neural Network using Tensorflow en Alpha (possibilité d’utiliser toutes les fonctions de régression linéaire et logistique en plus des deux modèles ci dessous )

CREATE MODEL yourmodel
OPTIONS (model_type = "dnn_classifier"
AS SELECT ...CREATE MODEL yourmodel
OPTIONS (model_type = "dnn_regressor"
AS SELECT ...

import tensorflow models for prediction en Alpha

CREATE MODEL yourmodel
OPTIONS (model_type = "tensorflow, model_path=gs://"
AS SELECT ...

Feature pre-processing functions en Alpha, il suffira juste de définir la fonction de préprocessing lors de la création de modèle

CREATE MODEL yourmodel
TRANSFORM(f1 + f2 as c, label)
OPTIONS ...SELECT *
FROM ML.PREDICT(MODEL m, (SELECT f1 + f2 from t1))

Ensuite, Jonathan Poelhuis (Senior Data Scientist, Booking.com) et Timo Kluck (Principal Developer, Booking.com) nous ont fait un retour sur l’utilisation de BQML chez Booking pour le traitement de la qualité des données dans leur datawaherouse.

Les équipements des chambres qu’ils proposent ont 176 possibilités, et ces informations évoluent très régulièrement. Lors de l’utilisation de leur site, si le client fait une recherche et demande par exemple une chambre avec salle de bain et que cette recherche remonte des chambres qui n’en ont pas, l’effet déceptif sera très fort et très rapide, le client ira alors sur un autre site que Booking.com.

Le travail de la qualité des données est donc extrêmement important et ils ont besoin d’identifier efficacement les anomalies potentielles sur les millions de chambres qu’ils proposent. Pour se faire, ils sont partis du principe qu’ils pouvaient identifier les anomalies en regroupant les éléments et en séparant ceux qui seraient aberrants, ainsi qu’en partant sur l’hypothèse que la qualité générale des données est bonne.

C’est dans ce cadre qu’ils ont pu expérimenter les nouvelles fonctionnalités de BigQuery ML et la possibilité de faire du K Mean. Ils ont ensuite fait une démonstration en s’appuyant sur Datastudio pour visualiser les résultats, et nous avons ainsi pu voir leur approche. Ils ont d’abord définit un nombre de centroïde K, 7 dans leur démo, puis en étudiant les résultats ils ont pu comprendre leurs données et définir de nouveaux patterns et réentraîner le modèle en modifiant le nombre de centroïdes, ici jusqu’à 21.

Nous avons donc pu nous rendre compte de la facilité et de la simplicité de ces nouvelles fonctionnalités dans un use case à 176 dimensions.

Pour aller plus loin, voici quelques liens :

Utilisation du k-mean : https://medium.com/@lakshmanok/how-to-use-k-means-clustering-in-bigquery-ml-to-understand-and-describe-your-data-better-c972c6f5733b
Utilisation des modèles de TensorFlow : https://towardsdatascience.com/how-to-do-batch-predictions-of-tensorflow-models-directly-in-bigquery-ffa843ebdba6
Documentation de BigQuery ML : https://cloud.google.com/bigquery/docs/bigqueryml

Best Practices on Migrating to Cloud Spanner

Au cours de cette conférence, Robert Kubis (Cloud Developer Advocate, Google Cloud), nous a exposé comment optimiser, monitorer et bien utiliser Spanner. Dans un premier temps, Pour rappel, Spanner est une base de données scalable horizontalement, globalement consistante sur plusieurs régions, multi-régions et sémantiquement relationnelle (schémas, ACID, transaction et SQL).

Ce petit rappel réalisé, nous allons pouvoir attaquer notre migration. Voici le plan que notre speaker nous a proposé :

étape 1 : planifier notre migration,
étape 2 : migrer les données et l’application,
étape 3 : monitorer et optimiser notre base.

Nous n’avons plus qu’à suivre ce plan.

Planifier la migration

Pour faire simple, cette phase consiste à ne pas prendre à la légère la migration entre, par exemple, une base Oracle et Spanner, et de bien prendre en compte les spécificités de ce service.

Nous allons parcourir ensemble quelques une de ces spécificités :

L’absence de séquence dans Spanner et la nécessité d’avoir une réflexion sur les clés primaires pour avoir une bonne répartition des données. Il est conseillé de proposer une clé UUID / Hash value.
Il n’y a pas de mécanisme de trigger dans Spanner ou de procédure stockée, il faudra donc prendre en compte la nécessité de recréer cette logique si elle est nécessaire.
Il n’y a pas de clé étrangère dans Spanner, mais il est possible de créer une “hiérarchie” dans les données, ce mécanisme Parent / Enfant permet de regrouper les données qui seront requêtées ensemble.
Il est possible de créer des index secondaires.
Le schéma online est modifié tout en conservant l’ancien schéma en mémoire le temps que les modifications s’appliquent avec, bien entendu, une gestion des updates éventuels des données.

Migrer les données.

Pour réaliser la migration, Robert nous propose d’utiliser dataflow. Dans une premier temps nous devons uploader les données dans storage puis appliquer le batch dataflow qui va se charger de la migration dans Spanner. Bien entendu, la stratégie de migration sera plus simple si l’on peut arrêter notre application. Si l’on ne peut se permettre un arrêt de service, il faudra réaliser un double run et utiliser Dataflow pour appliquer les modifications éventuelles lors de cette phase.

Monitorer et optimisation.

Notre speaker s’est appuyé sur un exemple pour nous montrer les possibilité de monitorer et d’optimiser l’application. Pour cela, une migration à l’identique de la structure de la base initial a été effectuée et une requête de l’ancien système sur Spanner a été appliquée. Ce fut la douche froide, 14 secondes pour une simple requête.

Pour comprendre le pourquoi d’un temps si long, nous avons pu utiliser la fonctionnalité d’explication de la requête et nous avons pu voir que notre problématique était liéé aux jointures, comme souvent. Pour remédier à cela, il a ajouté un index sur les clés primaires et le temps de réponse à été réduit à 100 ms !

Une réflexion pourrait par la suite être réalisée pour modifier le schéma d’origine et apporter une construction hiérarchique.

Pour aller plus loin, voici quelques liens :

Best Practice Spanner : https://cloud.google.com/spanner/docs/best-practice-list
Publication de ‘Spanner, TrueTime and the CAP Theorem’ : https://ai.google/research/pubs/pub45855

Voilà, cette deuxième journée bien remplie est maintenant terminée. “Bye and play with data” !

Google Cloud Next 2019 - Day 2

BigQuery ML: What’s New, and an Exploration With Booking.com on Using it to Assess Data Quality

Best Practices on Migrating to Cloud Spanner

Written by Geoffrey Garnotel