BigQuery : face à Snowflake, Google Cloud parie sur le « data cloud ouvert »
Lors de Google Cloud Next, le fournisseur cloud a précisé sa feuille de route en matière de gestion de données. Il a aussi révélé les mécaniques sous-jacentes des nouvelles fonctionnalités de BigQuery et de BigLake. L’occasion de souligner de grandes similarités avec les rouages de Snowflake.
En sus du ripolinage de ses offres BI (Looker étant désormais la marque ombrelle des produits analytiques), GCP a présenté des ajouts à ses solutions de gestion de données et d’intelligence artificielle. En commençant par mettre l’accent sur l’analyse des données non structurées dans BigQuery.
Sauf que BigQuery n’est pas nativement compatible avec les données non structurées. D’ailleurs, le support natif des données semi-structurées, via le format JSON, n’est accessible en préversion que depuis janvier 2022.
Traiter les données non structurées depuis l’interface de BigQuery
Or, Google Cloud a présenté en avril et rendu disponible récemment BigLake, une architecture qui unifie ses infrastructures d’entrepôts de données et de lacs de données.
C’est dans ce cadre que le géant du cloud a présenté Object Tables. « Object Tables apporte une interface d’enregistrement structuré pour permettre à BigQuery d’effectuer des analyses sur des données non structurées », présente Gaurav Saxena, Product Manager – BigQuery chez Google Cloud.
Plus spécifiquement, ces tables objets sont stockées sur Google Cloud Storage. Le service de stockage objet accueille les données non structurées. L’interface permet, elle, de cibler ces données.
Cela permettrait d’exécuter des jobs analytiques et de machine learning sur des données textuelles, des images, des vidéos, ou autres directement depuis l’interface de BigQuery.
« Il y a six mois de ça, si vous souhaitiez traiter des images dans BigQuery, vous deviez utiliser votre langage de programmation préféré (Java, Go, Python, etc.) », affirme Steve Walker, Developer Relations Engineer – BigQuery chez Google Cloud. « Vous deviez stocker ces images dans Google Cloud Storage, extraire les vecteurs (embeddings en VO, c’est-à-dire des paramètres lisibles par BigQuery N.D.L.R), puis les charger dans BigQuery. La même chose était vraie si vous vouliez utiliser les services Cloud AI ».
Les rouages des nouveaux services BigQuery et BigLake
Pour Google Cloud, il s’agit d’automatiser ces étapes.
Les Object Tables rendent visibles les métadonnées des données non structurées dans l’interface de BigQuery. Des fonctions distantes permettent d’appeler les tables stockées dans Google Cloud Storage, puis d’appeler les services de traitement d’IA disponibles dans Google Cloud et ensuite de préciser les opérations que l’on souhaite faire. Dans sa démonstration, Steve Walker étiquette des images, y détecte des logos et des objets. Les résultats sont renvoyés sous forme de textes. Le tout en écrivant des requêtes SQL.
Il est également possible de combiner des données structurées et non structurées de la même manière. Pour cela, GCP s’appuie sur les fonctionnalités Remote Functions et Cloud Run. Les Remote Functions ne sont autres que des fonctions définies par l’utilisateur (UDF). Elles permettent d’implémenter des traitements qui ne sont pas écrits en SQL ou en JavaScript, les deux langages natifs de BigQuery. Cloud Run est l’environnement managé qui exécute ces fonctions sur l’architecture de Google Cloud. Il s’agit à proprement parler d’un service FaaS prévu pour lancer des jobs ou déclencher des traitements en fonction de certaines requêtes ou événements.
Dans la même veine, le géant du cloud souhaite simplifier les traitements des données via Apache Spark depuis l’interface de BigQuery.
Disponible en préversion, cette intégration repose sur des procédures stockées. Elles étaient déjà compatibles avec les requêtes SQL. « Une procédure stockée dans BigQuery est une collection d’instructions qui peuvent être appelées à partir d’autres requêtes ou procédures stockées », explique Google Cloud, dans sa documentation. « Une procédure peut accepter des arguments en entrée et renvoyer des valeurs en sortie ».
Les jobs Spark en question doivent être rédigés en Python via PySpark. Ensuite, un usager peut les lancer via une requête SQL « standard », les jobs seront exécutés sur le moteur Spark disponible depuis le service Dataproc. Si la procédure représente plus de 1 Mo, GCP recommande de la stocker dans un bucket Google Cloud Storage. Optionnellement, il est possible de récupérer ou de traiter les métadonnées via une connexion avec Dataproc Metastore. Au maximum, il est possible d’exécuter 180 procédures stockées Spark en parallèle.
En outre, Google Cloud a lancé à la mi-septembre le service Datastream for BigQuery, un service serverless qui permet de répliquer les données en provenance des « bases de données opérationnelles telles que AlloyDB, PostgreSQL, MySQL et Oracle » directement dans BigQuery ou Google Cloud Storage. Datastream sert également à effectuer des synchronisations de données (CDC) entre différents magasins de données.
Une stratégie d’ouverture pour égaler les concurrents
En parallèle, le fournisseur poursuit sa stratégie d’ouverture.
Comme l’avait déjà évoqué Google Cloud, BigLake permettra le support du format de tables Apache Iceberg, à la manière de ses coopétiteurs Cloudera, Snowflake, Starburst et Dremio.
Pour rappel, Apache Iceberg a été conçu pour supporter et favoriser le traitement de large volume de données (à l’échelle du pétaoctet). Il doit assurer la même cohérence qu’un système SQL (support ACID) tout en étant compatible avec les moteurs de traitements tels Flink, Presto, Hive, Impala ou Spark.
Le projet né chez Netflix – qui souhaitait pallier les limites de Hive – a fait des émules chez LinkedIn, Lyft, Wework, Apple ou encore Expedia.
De la même manière, Apache Iceberg sera supporté à travers les tables externes de BigQuery.
Plus tard suivront la prise en charge des formats Delta Lake, (développés par Databricks et confié à la Fondation Linux) et Apache Hudi, une brique pensée par Uber. Au début de l’année, Google pensait d’abord supporter Deta Lake avant Iceberg et Hudi.
« Le fait de laisser nos clients travailler avec tous les types de données, dans les formats de leur choix, est la marque d’un data cloud ouvert », affirme Gerrit Kazmaier, vice-président et directeur général base de données, analytique et Looker chez Google.
« Nous nous engageons à fournir le support et les intégrations dont les clients ont besoin pour supprimer les limites de leurs données et éviter le verrouillage des données entre les clouds. »
Gerrit KazmaierV-P et directeur général base de données, analytique et Looker, Google
Le responsable semble faire référence à Snowflake, qui utilise amplement l’expression Data Cloud pour présenter sa plateforme propriétaire de gestion de données multicloud.
« Nous nous engageons à fournir le support et les intégrations dont les clients ont besoin pour supprimer les limites de leurs données et éviter le verrouillage des données entre les clouds », ajoute-t-il.
À y regarder de plus près, GCP ne fait que prolonger une démarche débutée il y a deux ans avec le support d’Iceberg dans Dataproc. Dataproc est un service managé par GCP permettant d’exécuter Apache Spark, Flink, Presto, Trino, Hive et une trentaine d’autres frameworks open source.
Avec BigLake, le géant du cloud se limite dans un premier temps à Apache Spark, TensorFlow et Presto.
Or, Snowflake supporte également les UDF, les procédures stockées, l’appel à différents moteurs de traitements, se prépare à prendre en charge les données non structurées, Apache Iceberg, et propose, lui aussi, des formes de compatibilité avec les object stores.
Bref, même si Gerrit Kazmeier affirmait au MagIT qu’il existait des différences d’ouverture entre BigLake et Snowflake, les deux solutions offrent – actuellement – peu ou prou les mêmes avantages.
