Présentation de BigLake Metastore

Le metastore BigLake est un metastore unifié, géré, sans serveur et évolutif. Il connecte les données de lakehouse stockées dans Google Cloud à plusieurs environnements d'exécution, y compris les moteurs Open Source (comme Apache Spark) et BigQuery. Il fournit la base dont vous avez besoin pour créer un lakehouse ouvert, géré et hautes performances avec une gestion des données automatisée et une gouvernance intégrée à l'aide de formats de table Open Source clés, tels qu'Apache Iceberg.

Le metastore BigLake fournit une source unique de vérité pour les métadonnées provenant de plusieurs sources. Il n'est donc plus nécessaire de copier et de synchroniser les données et les métadonnées entre différents systèmes et dépôts analytiques à l'aide d'outils personnalisés. Il est également compatible avec les modèles de délégation d'accès au stockage, tels que la distribution d'identifiants, qui élimine la nécessité pour les utilisateurs du catalogue d'avoir un accès direct aux buckets Cloud Storage.

Pour les workflows qui utilisent des tables BigLake Iceberg dans BigQuery, le métastore BigLake est également compatible avec Dataplex Universal Catalog, qui fournit des contrôles d'accès unifiés et précis sur tous les moteurs compatibles, et permet une gouvernance de bout en bout qui inclut des fonctionnalités complètes de traçabilité, de qualité des données et de détectabilité.

Vous pouvez configurer BigLake Metastore de deux manières : avec le catalogue Iceberg REST ou le catalogue Iceberg personnalisé pour BigQuery. La meilleure option dépend de votre cas d'utilisation, comme indiqué dans le tableau suivant :

Cas d'utilisation Recommandation
Nouveaux utilisateurs de métastores BigLake qui souhaitent que leur moteur Open Source accède aux données dans Cloud Storage et qui ont besoin d'une interopérabilité avec d'autres moteurs, y compris BigQuery et AlloyDB. Utilisez le catalogue REST Iceberg.
Utilisateurs BigLake Metastore existants qui possèdent des tables actuelles avec le catalogue Iceberg personnalisé pour BigQuery. Continuez à utiliser le catalogue Iceberg personnalisé pour BigQuery, mais utilisez le catalogue Iceberg REST pour les nouveaux workflows. Les tables créées avec le catalogue Iceberg personnalisé pour BigQuery sont visibles avec le catalogue Iceberg REST via la fédération.

Capacités clés

BigLake Metastore offre plusieurs avantages majeurs 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 frais généraux opérationnels, de simplifier le déploiement et d'adapter automatiquement la capacité en fonction de la demande.
  • Interopérabilité du moteur avec des API ouvertes. Le métastore BigLake est compatible avec l'interopérabilité avec les moteurs Open Source et tiers. Le metastore 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 étapes de connexion supplémentaires. Cette configuration permet d'optimiser votre workflow d'analyse et de réduire la nécessité de recourir à des processus complexes de transfert ou d'ETL des données.
  • Expérience utilisateur unifiée : Le metastore BigLake fournit un workflow unifié pour les moteurs Open Source et BigQuery. Cette expérience unifiée vous permet, par exemple, de configurer des environnements Spark auto-hébergés, hébergés par Dataproc via le catalogue REST Iceberg ou dans un notebook BigQuery.
  • Analyses, flux de données et IA hautes performances avec BigQuery Le metastore BigLake vous permet de stocker des données Iceberg dans vos propres buckets Cloud Storage et de tirer parti des capacités de gestion des métadonnées en temps réel et hautement évolutives de BigQuery. Cette architecture vous offre l'ouverture et la propriété des données de Cloud Storage, ainsi que les fonctionnalités de streaming, d'analyse et d'IA entièrement gérées de BigQuery.

Différences avec BigLake Metastore (version classique)

BigLake Metastore est le metastore recommandé sur Google Cloud, tandis que BigLake Metastore (ancienne version) est considéré comme une fonctionnalité obsolète.

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

  • Le métastore BigLake est compatible avec une intégration directe aux moteurs Open Source tels que Spark, ce qui permet de réduire la redondance lorsque vous stockez des métadonnées et exécutez des jobs. Les tables du metastore BigLake sont directement accessibles à partir de plusieurs moteurs Open Source et de BigQuery.
  • Le métastore BigLake est compatible avec le catalogue Iceberg REST, contrairement au métastore BigLake (classique).

Limites de BigLake Metastore

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

  • Vous ne pouvez pas créer ni modifier de tables BigLake Iceberg avec des instructions LDD (langage de définition de données) ou LMD (langage de manipulation de données) BigQuery. Vous pouvez modifier les tables BigLake Iceberg à 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 l'instruction Spark SQL ALTER TABLE ... RENAME TO.
  • Les tables du metastore BigLake dans BigQuery sont soumises aux mêmes quotas et limites que les tables standards.
  • Les performances des requêtes portant sur des tables de métastore BigLake à partir du moteur BigQuery peuvent être ralenties par rapport aux requêtes sur des données dans des tables BigQuery standards. En général, la vitesse des requêtes doit être équivalente à celle de la lecture des données depuis Cloud Storage.
  • Une simulation BigQuery d'une requête qui utilise une table BigLake Metastore 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 complète n'est pas exécuté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 enregistrer les résultats de la requête dans une table BigQuery, 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.
  • BigLake Metastore n'est pas compatible avec les vues Iceberg.

Étapes suivantes