Google Cloud Next 2019- Day 1

Il y a déjà 2 jours, nous arrivions à San Francisco avec SFEIR. Lundi démarrait Google Next ’19 avec une journée réservée aux “authorized trainers”, puis hier commençait officiellement la conférence.

Mon programme de la journée : beaucoup de retours d’expérience autour de Bigtable, BigQuery, Dataflow, Tensorflow, Cloud ML, etc. . Mais avant de commencer les conférences, place à la keynote d’ouverture :

Nous avons pu assister à plusieurs annonces au cours de la keynote :

• le lancement de 2 nouvelles régions via des datacenters à Salt Lake City et Séoul;
• la mise en place d’Anthos en GA, la nouvelle plateforme pour manager du multi cloud (https://cloud.google.com/blog/topics/hybrid-cloud/new-platform-for-managing-applications-in-todays-multi-cloud-world);
• la proposition de Cloud Run, à savoir la capacité de déployer et de gérer des conteneurs docker sur une plateforme KNative et ce, soit sur nos propres GKE, soit géré par Google, et ainsi la possibilité de faire du serverless avec nos images docker (https://cloud.google.com/blog/products/serverless/announcing-cloud-run-the-newest-member-of-our-serverless-compute-stack);
• l’évolution de Compute Engine avec l’accès à de nouvelles configurations, notamment avec les compute-optimized VM et les memory-optimized VM (https://cloud.google.com/blog/products/compute/introducing-compute-and-memory-optimized-vms-for-google-compute-engine);
• et la plus grande intégration des technologies open source / tiers (MongoDB / Neo4j / elasticsearch, Redis, Datastax, InfluxData).

Hors Keynote, voici une information qui m’intéresse fortement :

• l’arrivée de Confluent Cloud pour Kafka comme service sur GCP (https://www.confluent.io/blog/announcing-confluent-cloud-for-apache-kafka-native-service-on-google-cloud-platform).

La Keynote s’achevant, les conférences pouvaient démarrer, et voici un résumé de trois conférences auxquelles j’ai pu assister.

Moving from Cassandra to Auto-Scaling Bigtable at Spotify

Animée par Emilio Del Tessandoro (Senior Software Engineer chez Spotify) et Sandhya Ghai (Cloud Bigtable Product Manager chez Google Cloud), ces derniers nous ont présenté la migration du cluster Cassandra de Spotify vers Bigtable avec la gestion de l’auto scaling des noeuds.

Spotify avait et a encore une partie de ses service sur Cassandra et Posgresql, et pour palier à plusieurs limitations rencontrées avec Cassandra, a alors été initiée une migration :

• Storage et Compute étaient couplés,
• nombreux paramètres difficiles à gérer,
• scaling horizontal limité,
• l’export de données était compliqué,
• les changements de design de donnée prenaient énormément de temps.

À cela, il faut ajouter que Spotify avait un fort besoin d’automatisation pour provisionner, configurer et modifier les machines. Pour faire face à cette problématique, entre autres, de nombreux outils tel que cassandra-reaper, cstar et hecuba ont été créés.

La migration sur GCP était donc l’opportunité de gérer moins d’infrastructure, d’avoir facilement accès à de nouvelles technologies et au final de se concentrer sur le coeur de métier. Bigtable a apporté vitesse, scalabilité, services managés et intégration facile par rapport à l’architecture initiale. À cela, Dataflow a été ajouté pour résoudre le problème de data export.

Enfin, a été présenté l’autoscaler de Bigtable. L’auto scaling des nodes dans Bigtable n’étant pas géré automatiquement, il est alors tout à fait possible de le gérer programmatiquement et c’est justement ce que Spotify a fait en créant un module d’auto scaling. L’un des use cases auxquels ils voulaient répondre était la capacité de scaler dans les cas de pic de chargement, par exemple lors de lancement de batch.

L’auto scaler de Spotify se base sur le monitoring des services de Bigtable et va adapter les noeuds selon différents critères, le nombre minimal et maximal de noeuds, l’utilisation CPU moyenne et les noeuds à ajouter quand un cluster à un taux d’utilisation CPU trop élevé.

Pour aller plus loin, voici quelques liens :

• Programmer l’auto scaling : https://cloud.google.com/bigtable/docs/scaling
• Article sur le Bigtable Autoscaler de Spotify : https://labs.spotify.com/2018/12/18/bigtable-autoscaler-saving-money-and-time-using-managed-storage/
• Repo Github : https://github.com/spotify/bigtable-autoscaler

Plaid’s Journey to Global Large-Scale Real-Time Analytics With Google BigQuery

Ensuite, j’ai eu la possibilité d’assister à une superbe session autour de BigQuery. Elle a commencé par le retour d’expérience de Yuki Makino (CTO, Plaid). Plaid est une une startup japonaise qui fournit un outil SaaS d’analyse en temps réel et le challenge de départ était la gestion de 40.000 events/seconde, plusieurs Tera de données par jour et l’obtention d’un service d’analytique en temps réel.

Yuki nous a tout d’abord présenté l’architecture mise en place, basée sur BigQuery mais s’appuyant aussi sur Bigtable, Spanner et Redis pour résoudre les challenges. Yuki a ensuite présenté les 5 patterns utilisés pour construire la plateforme de Plaid :

• Complex Query & Cache Pattern : la construction d’un cache en front de BigQuery avec un refresh régulier;
• ELT & Simple Query Pattern : l’utilisation de BigQuery comme ELT, avec un chargement des logs dans BigQuery sans transformation puis un travail des logs à l’aide de requêtes SQL scheduler;
• Frequent update Large Row Pattern : le stockage de l’ensemble de la ligne à chaque modification mais avec une query uniquement de la dernière ligne ou d’une ligne bien précise. La solution offre la possibilité de mettre un Buffer (dans leur cas, avec Redis) pour limiter le stockage. Le choix se fera selon la volonté de privilégier le coût ou la fraîcheur des données;
• Optimize for Low-Latency Serving Pattern : l’export de data avec Dataflow dans des databases GCP, offrant une meilleur latence : Spanner, Bigtable, Redis (cela pourrait aussi être Cloud SQL voire GCS);
• Direct Join Pattern : le partage du dataset du client ou sa copie dans une région déterminée pour permettre l’exploitation des données en temps réel.

Ensuite ce fût le tour des Googlers de prendre la parole avec Tino Tereshko (Product Manager, BigQuery, Google Cloud) et Seth Hollyman, (Developer Programs Engineer, Google Cloud). Ils ont annoncé la mise à disposition d’une nouvelle fonctionnalité dans BigQuery : la BQ Storage API, à savoir la capacité d’exploiter les données du service de storage de BigQuery. Il s’agit là d’une grande évolution dans la construction d’une architecture Data. Avant, pour exploiter les données dans BigQuery, il fallait soit utiliser les fonctionnalités de BigQuery, soit exporter les données pour les utiliser avec d’autres technologies (Dataflow, Dataproc ou autre). À présent, avec cette fonctionnalité, plus besoin d’exporter les données, il est possible d’exploiter directement les données stockées dans BigQuery. Les principales features de BQ Storage API qui nous ont été présentées sont :

• Multiple Stream : la possibilité d’utiliser plusieurs stream au sein d’une session,
• Dynamic Sharding,
• Projection and Filtering : la capacité de sélectionner des colonnes et de filtrer les données,
• et Table Snapshot Control.

À absolument tester à mon retour en France !

Pour aller plus loin, voici quelques liens :

• BigQuery Storage API : https://cloud.google.com/bigquery/docs/reference/storage/
• Insert on Streaming https://cloud.google.com/blog/products/gcp/life-of-a-bigquery-streaming-insert

Serverless and Open-Source Machine Learning at Sling Media

Dernière conférence de la journée pour moi avec le retour d’expérience de Sling Media sur la construction de sa plateforme data et la prise en main par ses équipes de data engineers et data scientists. Pour cela, Austin Bennett (Senior Data Engineer, Sling Media) et Salma Riazi (Data Scientist,Sling Media) nous ont partagé les best practices qu’ils ont mis en place et les leçons qu’ils ont appris autour de l’évolution de leur plateforme :

1. L’utilisation du deep learning pour assurer une meilleure prédiction,
2. Le développement d’un pipeline “traditionnel” pour déployer le modèle,
3. L’amélioration du pipeline pour le rendre serverless et scalable en utilisant des technologies open source et les services GCP.

Sling Media propose Sling tv online, un service de chaîne de TV et d’émission à la carte, et a besoin d’analyser le comportement de ses utilisateurs afin de proposer des services qui correspondent le mieux aux attentes des clients. Pour cela, ils ont mis en place du deep learning pour répondre à leurs problématiques.

Austian et Salma nous ont ainsi présenté l’évolution de leur plateforme pour partie gérant le machine learning, avec la capacité de stocker l’information, de la pré-processer et de l’explorer, de tester le modèles et les hyperparameters et, enfin, d’exposer le modèle et de fournir des résultats.

Au final Sling Media a mis en place :

• BigQuery : pour stocker l’information et l’explorer, puis pour stocker les résultats;
• Dataflow : pour pré-processer les données pour l’entraînement et le serving avec tf.transform;
• Storage ;
• Cloud ML : pour entraîner le modèle et assurer le serving;
• Airflow : pour piloter et automatiser l’ensemble des traitements.

Cette dernière session s’est avérée particulièrement intéressante avec beaucoup de codes affiché à l’écran, qu’il sera intéressant de regarder ultérieurement.

Pour aller plus loin, voici quelques liens :

• Article sur tf.transform : https://gweb-cloudblog-publish.appspot.com/products/ai-machine-learning/pre-processing-tensorflow-pipelines-tftransform-google-cloud/amp/
• Train and serve with Tensorflow : https://cloud.google.com/blog/products/ai-machine-learning/cloud-ai-helps-you-train-and-serve-tensorflow-tfx-pipelines-seamlessly-and-at-scale

Voila, cette première journée a déjà touché à sa fin. “Bye and play with data”.

Articles liés :

• Google Cloud Next’19 Day 2: https://medium.com/codeshake/google-cloud-next-2019-day-2-4120eff7d5f8
• Google Cloud Next’19 Day 3: https://medium.com/@geoffreygarnotel/google-cloud-next-2019-day-3-da6d69e6d48