Présentation de BigLake Metastore

Le métastore BigLake est un métastore unifié, géré, sans serveur et évolutif qui connecte les données lakehouse stockées dans Cloud Storage ou BigQuery à plusieurs environnements d'exécution, y compris les environnements d'exécution Open Source (tels qu'Apache Spark et Apache Flink) et BigQuery.

Le métastore BigLake fournit une source unique de vérité pour la gestion des métadonnées provenant de plusieurs moteurs. Il est compatible avec les principaux formats de tables Open Source, tels qu'Apache Iceberg, via les tables BigLake Iceberg et les tables BigQuery standards. De plus, le métastore BigLake est compatible avec les API ouvertes et un catalogue Iceberg REST (preview).

Utilisez le tableau suivant pour déterminer où commencer votre parcours avec le metastore BigLake :

Cas d'utilisation Recommandation
Le moteur Open Source doit accéder aux données dans Cloud Storage. Explorez le catalogue REST Iceberg (aperçu).
Le moteur Open Source doit être interopérable avec BigQuery. Découvrez l'intégration de BigLake Metastore aux moteurs Open Source (comme Spark) à l'aide du plug-in de catalogue Iceberg personnalisé BigQuery.

Avantages

BigLake Metastore offre plusieurs avantages pour la gestion et l'analyse des données :

  • Architecture sans serveur Le métastore BigLake fournit une architecture sans serveur, ce qui élimine le besoin de gestion de serveur ou de cluster. Cela permet de réduire les coûts opérationnels, de simplifier le déploiement et d'adapter automatiquement la capacité en fonction de la demande.
  • Interopérabilité des moteurs : Le métastore BigLake vous permet d'accéder directement aux tables dans les moteurs Open Source (tels que Spark et Flink) et BigQuery. Vous pouvez ainsi interroger les tables au format ouvert sans configuration supplémentaire. Par exemple, vous pouvez créer une table dans Spark, puis l'interroger directement dans BigQuery. Cela permet de simplifier votre workflow d'analyse et de réduire la nécessité de processus ETL ou de transfert de données complexes.
  • Expérience utilisateur unifiée : Le métastore BigLake fournit un workflow unifié pour BigQuery et les moteurs Open Source. Cette expérience unifiée vous permet de configurer un environnement Spark autohébergé ou hébergé par Dataproc via le catalogue REST Iceberg (preview), ou de configurer un environnement Spark dans un notebook BigQuery Studio pour faire la même chose.

    Par exemple, dans BigQuery Studio, vous pouvez créer une table dans Spark avec un notebook BigQuery Studio.

    Créer une table dans BigLake Metastore

    Vous pouvez ensuite interroger la même table Spark dans la consoleGoogle Cloud .

    Interroger une table dans BigLake Metastore

Formats de table dans BigLake Metastore

BigLake est compatible avec plusieurs types de tables. Utilisez le tableau suivant pour choisir le format qui convient le mieux à votre cas d'utilisation :

Tables externes Tables BigLake Iceberg Tables BigLake Iceberg dans BigQuery Tables BigQuery standards
Metastore Métastore externe ou autohébergé BigLake Metastore BigLake Metastore BigLake Metastore
Stockage Cloud Storage / Amazon S3 / Azure Cloud Storage Cloud Storage BigQuery
Gestion Client ou tiers Google Google (expérience hautement gérée) Google (expérience la plus gérée)
Lecture / Écriture Moteurs Open Source (lecture/écriture)

BigQuery (lecture seule)
Moteurs Open Source (lecture/écriture)

BigQuery (lecture seule)
Moteurs Open Source (lecture seule avec les bibliothèques Iceberg, interopérabilité en lecture/écriture avec l'API BigQuery Storage)

BigQuery (lecture/écriture)

Moteurs Open Source (interopérabilité en lecture/écriture avec l'API BigQuery Storage)

BigQuery (lecture/écriture)

Use cases Migrations, tables de préproduction pour les chargements BigQuery, autogestion Lakehouse ouvert Lakehouse ouvert, stockage de niveau entreprise pour l'analyse, le streaming et l'IA Stockage de niveau entreprise pour l'analyse, le streaming et l'IA

Différences avec BigLake Metastore (version classique)

BigLake Metastore est le metastore recommandé sur Google Cloud.

Voici les principales différences entre BigLake Metastore et BigLake Metastore (classique) :

  • BigLake Metastore (classique) est un service de metastore autonome distinct de BigQuery et qui n'est compatible qu'avec les tables Iceberg. Il possède un modèle de ressource en trois parties différent. Les tables du métastore BigLake (classique) ne sont pas automatiquement détectées à partir de BigQuery.
  • Les tables du metastore BigLake sont accessibles à partir de plusieurs moteurs Open Source et de BigQuery. Le metastore BigLake est compatible avec l'intégration directe à Spark, ce qui permet de réduire la redondance lorsque vous stockez des métadonnées et exécutez des jobs. Le métastore BigLake est également compatible avec le catalogue Iceberg REST (preview), qui connecte les données du lakehouse sur plusieurs environnements d'exécution.

Limites

Les limites suivantes s'appliquent aux tables du metastore BigLake :

  • Vous ne pouvez pas créer ni modifier des tables de métastore BigLake avec des instructions LDD ou LMD à l'aide du moteur BigQuery. Vous pouvez modifier les tables du metastore BigLake à l'aide de l'API BigQuery (avec l'outil de ligne de commande bq ou les bibliothèques clientes), mais vous risquez d'apporter des modifications incompatibles avec le moteur externe.
  • Les tables du metastore BigLake ne sont pas compatibles avec les opérations de renommage ni avec les instructions Spark SQL ALTER TABLE ... RENAME TO.
  • Les tables BigLake Metastore sont soumises aux mêmes quotas et limites que les tables standards.
  • Les performances des requêtes portant sur des tables du metastore BigLake à partir du moteur BigQuery peuvent être ralenties par rapport aux requêtes sur des données dans une table BigQuery standard. En général, les performances des requêtes pour une table BigLake Metastore sont équivalentes à celles de la lecture directe de données depuis Cloud Storage.
  • La simulation d'une requête qui utilise une table de métastore BigLake peut indiquer une limite inférieure de 0 octet de données, même si des lignes sont renvoyées. Ce résultat se produit, car il est impossible de déterminer la quantité de données traitées à partir de la table tant que la requête n'est pas terminée. L'exécution de la requête entraîne des frais pour le traitement de ces données.
  • Vous ne pouvez pas référencer de table BigLake Metastore dans une requête de table générique.
  • Vous ne pouvez pas utiliser la méthode tabledata.list pour récupérer des données à partir de tables BigLake Metastore. Vous pouvez plutôt enregistrer les résultats de la requête dans une table de destination, puis utiliser la méthode tabledata.list sur cette table.
  • Les tables BigLake Metastore ne sont pas compatibles avec le clustering.
  • Les tables BigLake Metastore ne sont pas compatibles avec les noms de colonnes flexibles.
  • L'affichage des statistiques de stockage de tables pour les tables BigLake Metastore n'est pas pris en charge.

Étapes suivantes