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 :

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 complexes de transfert ou d'ETL des données.

• 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.

  

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

  

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 :

Différences avec BigLake Metastore (version classique)

BigLake Metastore est le metastore recommandé sur Trusted Cloud by S3NS.

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 ressources 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

• Migrer les données Dataproc Metastore vers BigLake Metastore
• Utiliser BigLake Metastore avec Dataproc
• Utiliser BigLake Metastore avec Dataproc sans serveur