BigQuery : les efforts de GCP pour ne pas se faire distancer
Alors que Microsoft et AWS ont réussi à faire comprendre au marché qu’ils pouvaient égaler fonctionnellement Snowflake et Databricks, Google Cloud, parti le premier, tente de respecter sa promesse d’unification de ses services analytiques faite il y a trois ans.
Avec plus de 40 fonctionnalités présentées en disponibilité générale et en préversion sur 229 annonces, BigQuery était l’un des produits phares de son événement annuel Next 25. Pourrait-il en être autrement ? C’est un produit d’appel clé pour GCP qui y a apporté plus de 400 modifications et ajouts depuis le début de l’année 2024.
L’infusion de l’IA générative au sein des plateformes analytiques est perçue comme le futur par Google Cloud et les autres fournisseurs. Pour ce qui est du datawarehousing, leur objectif principal n’est autre que de consolider les fonctionnalités de traitement de données à travers une seule plateforme.
Simplifier la transformation et la gestion des pipelines de données
La filiale d’Alphabet a présenté différents efforts en la matière ces dernières années. Cette consolidation avait été présentée sous l’appellation BigLake il y a trois ans. Cependant, force est de constater que Snowflake, Databricks, Microsoft (Fabric) et AWS (SageMaker Unified Studio) la rattrapent.
En ce sens, Google Cloud a présenté la préversion d’un service Apache Spark managé et serverless accessible depuis BigQuery Studio. Une réponse directe à l’offre de Databricks, contributeur principal du framework de calcul distribué. Outre le fait de s’appuyer sur l’IA Code Assist pour concevoir les pipelines PySpark depuis Colab, GCP a annoncé des extensions Jupyter et Visual Studio Code pour exécuter des notebooks Spark et des DataFrames BigQuery. Le service managé Google Cloud For Apache Kafka, reste pour l’instant en dehors de ce giron.
Par ailleurs, BigQuery Continuous Queries entre en disponibilité générale. Ce service permet d’exécuter en mode serverless des instructions SQL en continu, c’est-à-dire au fur et à mesure que les données sont ingérées dans la plateforme analytique. Les données transformées peuvent être injectées dans des tables BigQuery et BigTable ou vers des systèmes Pub/Sub, Vertex AI, Spanner ou des produits tiers. Il s’agit, par exemple, d’alimenter des tableaux de bord ou des applications de détection d’anomalies en presque temps réel.
Dans la même veine, GCP a dévoilé la préversion d’une fonction de prédiction time-series et la disponibilité générale de « contribution analysis », pour détecter les principaux paramètres responsables d’une tendance dans des jeux de données. Il s’agit par exemple d’identifier rapidement les entités responsables de la croissance des ventes dans un rapport financier mensuel.
Une fonctionnalité associée aux pipelines BigQuery est aussi en « GA ». Celle-ci permet de préparer et d’orchestrer des pipelines ETL/ELT à travers BigQuery Studio visuellement ou en utilisant des scripts SQL et Python. Tout comme une version managée d’Apache Airflow pour le lakehouse.
Comme AWS il y a deux ans, BigQuery Studio annonce la préversion de l’analyse des données géospatiales depuis Google Earth Engine et Maps. Mais GCP a surtout mis l’accent sur la prise en charge partielle de « tables multimodales ». Celles-ci s’appuient sur la structure des tables d’objets et introduisent un type de données nommé ObjectRef permettant d’appeler des objets stockés dans Google Cloud Storage. Une forme de fonction de jointure hybride. Et au fournisseur de donner l’exemple d’un cas d’usage lié au support client où l’enregistrement d’un appel, son transcript, l’historique d’achats des clients et leurs ID peuvent être stockés et traités depuis la même table.
La promesse d’une « fédération bidirectionnelle » des métadonnées Iceberg
Les entreprises, elles, attendent davantage les évolutions de la prise en charge d’Apache Iceberg.
Promis depuis deux ans, le format de table ouvert est en bêta depuis le mois d’octobre 2024 sur BigQuery. En sus de Hive et Vertex AI, GCP vient d’annoncer la possibilité de connecter les tables aux moteurs Spark et Apache Flink.
« Dans les prochains mois, nous ajouterons la reprise après désastre, la prise en charge des opérations DML à haut débit, l’injection en temps réel… »
Vinay BalasubramaniamDirecteur produit BigQuery, Google
« Nous avons vu une forte adoption depuis la préversion l’année dernière », assure Vinay Balasubramaniam, directeur produit BigQuery chez Google. « Nous optimisons les tables, nous prenons en charge les métadonnées Iceberg avec Metastore, le partage de données sécurisées, le contrôle d’accès aux colonnes et aux lignes, le time-travel [une fonctionnalité pratique pour le lineage et l’interrogation des historiques, N.D.L.R.], etc. », poursuit-il. « Dans les prochains mois, nous ajouterons la reprise après désastre, la prise en charge des opérations DML à haut débit, l’injection en temps réel… Toutes ces fonctionnalités seront accessibles à travers notre version managée des tables Iceberg ».
À noter que la reprise après désastre automatisée pour BigQuery est entrée en disponibilité générale cette année. Il suffirait de sélectionner une deuxième région cloud pour synchroniser les backups.
Outre BigLake Metastore, GCP offre un moyen de lecture seul pour les catalogues AWS Glue et JSON Iceberg d’Azure. Le fournisseur a prévu de prendre en charge l’API REST Iceberg et les catalogues open source Unity et Polaris.
« Prochainement, nous annoncerons une fédération bidirectionnelle pour Iceberg », promet Vinay Balasubramaniam.
Sur le papier, GCP offre une plus grande ouverture que Snowflake, malgré sa volonté d’une prise en charge « complète » d’Iceberg, et que Databricks, qui privilégie son format de table ouvert Delta. Quant à AWS, il promet une approche entièrement managée, mais propriétaire (S3 Tables, AWS Glue). Dans les faits, si la gestion des métadonnées n’est pas externalisée, ces fournisseurs conservent un contrôle important sur la manière dont les données sont stockées et traitées sur leur plateforme respective.
Gouvernance de données : Dataplex devient Universal Catalog
Justement, avec BigQuery, GCP doit rattraper ses concurrents en matière de gouvernance de données. Jusqu’alors, il avait mis en place différents catalogues suivant la nature des données (structurées, semi-structurées, non structurées). « Nous unifions tout cela avec BigQuery Universal Catalog afin que vous ayez un seul catalogue pour toutes vos métadonnées », vante Vinay Balasubramaniam.
Auparavant nommé Dataplex Catalog, Universal Catalog est avant tout un endroit dans la console BigQuery pour enregistrer et gérer les métadonnées en provenance de différents services GCP. Il ajoute des fonctions de mise en qualité, de traçabilité et de sécurisation des données. Par exemple, certaines opérations peuvent être automatisées avec Terraform.
Par rapport à son autre service de catalogage, le métamodèle d’Universal Catalog serait plus robuste.
Le fournisseur introduit surtout la disponibilité générale d’un outil d’export des métadonnées depuis Cloud Storage et un outil de création de glossaires métier. Il s’agit de favoriser la transition de Data Catalog vers Universal Data Catalog : l’intromission de Dataplex avait généré une certaine confusion chez les clients.
Ces deux acteurs sont plus avancés sur un autre point : la gestion de produits de données. GCP vient justement d’inscrire sur sa feuille de route le développement d’un portail pour retrouver ces jeux de données à forte valeur ajoutée. « La version expérimentale doit permettre de favoriser la coopération entre les équipes », avance Vinay Balasubramaniam.
Au-delà de la gouvernance des données, c’est la gestion des coûts qui intéresse les entreprises. Or les différents services accessibles dans BigQuery sont liés à des contrats ou des SKU différents. Google Cloud promet de simplifier cet aspect avec un système d’engagement contractuel unifié. GCP promet des remises contre des engagements minimaux. Reste à voir si la mesure est plus économique pour les clients. Il y a deux ans, les changements effectués avaient entraîné une hausse des coûts.
