Ce document définit les termes et concepts clés de BigLake.
Concepts fondamentaux
Les concepts suivants constituent la base de l'architecture BigLake.
Data lakehouse
Un data lakehouse est une architecture de données qui combine la rentabilité et la flexibilité d'un lac de données avec les structures de gestion et de performances des données d'un entrepôt de données. BigLake permet une architecture de lakehouse en vous permettant de conserver les données dans des formats ouverts sur Cloud Storage tout en utilisant les fonctionnalités BigQuery telles que la sécurité précise et les requêtes hautes performances. Pour en savoir plus, consultez Fonctionnement de BigLake.
Interopérabilité ouverte
L'interopérabilité ouverte permet à plusieurs systèmes analytiques et transactionnels (tels que BigQuery, Spark et Flink) de fonctionner sur une seule copie de données dans des formats ouverts tels qu'Apache Iceberg. Cela évite de dupliquer les données et garantit une vue cohérente des données dans différents outils. Pour en savoir plus, consultez Fonctionnement de BigLake.
BigLake Metastore
BigLake Metastore est un service de métadonnées centralisé et sans serveur qui sert de source unique de référence pour votre lakehouse. Il permet à plusieurs moteurs, tels que Spark, Flink et BigQuery, de découvrir et d'interroger les mêmes tables simultanément. Pour en savoir plus, consultez À propos de BigLake Metastore.
Types de catalogues
Le metastore BigLake propose deux types de catalogues différents pour gérer vos métadonnées. Le choix du catalogue est une décision fondamentale qui affecte la façon dont vous interagissez avec vos données.
Catalogue REST Iceberg
Il s'agit d'un catalogue basé sur la spécification du catalogue Apache Iceberg REST. Il assure l'interopérabilité entre les moteurs Open Source et BigQuery, et est compatible avec des fonctionnalités telles que la distribution d'identifiants et la reprise après sinistre. Pour en savoir plus, consultez Concepts du catalogue Apache Iceberg REST.
Catalogue Iceberg personnalisé pour BigQuery
Il s'agit d'une intégration qui utilise BigQuery directement comme metastore de sauvegarde. Pour en savoir plus, consultez Fédération de catalogues avec BigQuery.
Formats de tableau
BigLake est compatible avec plusieurs formats de table, en fonction du moteur utilisé pour gérer les données.
Tables BigLake Iceberg
Il s'agit de tables Iceberg créées à partir de moteurs Open Source et stockées dans Cloud Storage. Le metastore BigLake sert de catalogue central. Seul le moteur Open Source qui a créé la table peut y écrire. Pour en savoir plus, consultez Présentation des tables BigLake Iceberg pour Apache Iceberg.
Tables BigLake Iceberg dans BigQuery
Il s'agit de tables Iceberg que vous créez à partir de BigQuery et que vous stockez dans Cloud Storage. BigQuery gère la mise en page et l'optimisation des données. Bien que ces tables puissent être lues par plusieurs moteurs, BigQuery est le seul moteur capable d'y écrire directement. Pour en savoir plus, consultez Gérer les tables BigLake Iceberg dans BigQuery.
Tables BigQuery standards
Ces tables sont gérées par BigQuery et stockent les données dans l'espace de stockage BigQuery. Vous pouvez connecter ces tables au metastore BigLake. Pour en savoir plus, consultez Présentation des tables BigLake.
Tables externes
Les tables externes résident en dehors du metastore BigLake. Les données et les métadonnées sont autogérées dans un catalogue tiers. BigQuery ne peut lire que ces tables. Pour en savoir plus, consultez Présentation des tables BigLake.
Fonctionnalités des tableaux
BigLake fournit plusieurs fonctionnalités qui simplifient la gestion des données et améliorent les performances des requêtes pour les tables Iceberg.
Évolution des tableaux
BigLake est compatible avec l'évolution des tables Iceberg, ce qui vous permet de modifier le schéma ou la spécification de partition d'une table au fil du temps sans réécrire les données de la table ni la recréer. Pour en savoir plus, consultez Fonctionnalités supplémentaires de BigLake Metastore.
Fonctionnalité temporelle
La fonctionnalité temporelle vous permet d'interroger les données d'une table telles qu'elles existaient à un moment précis ou à un ID d'instantané spécifique. Cela est utile pour l'audit, la reproduction d'expériences ou la restauration de données après une suppression accidentelle. Pour en savoir plus, consultez Fonctionnalités supplémentaires de BigLake Metastore.
Mise en cache de métadonnées
La mise en cache des métadonnées est une fonctionnalité qui accélère les performances des requêtes pour les tables externes BigLake. Il stocke une copie des métadonnées de la table dans le stockage BigQuery, ce qui réduit la nécessité de lire les fichiers de métadonnées à partir de Cloud Storage lors de l'exécution des requêtes. Pour en savoir plus, consultez Présentation des tables BigLake.
Maintenance automatique des tables
La maintenance automatique des tables simplifie la gestion du lakehouse en automatisant des tâches telles que la compaction et la récupération de mémoire pour les tables gérées. Cela garantit des performances de requête et une efficacité de stockage optimales sans intervention manuelle. Pour en savoir plus, consultez Fonctionnalités supplémentaires de BigLake Metastore.
Concepts d'interopérabilité
L'interopérabilité permet d'accéder aux données dans les systèmes Google Cloud et open source.
Fédération de catalogues
La fédération de catalogues est une fonctionnalité du catalogue REST Iceberg qui lui permet de gérer et d'interroger les tables visibles par BigQuery, y compris celles créées avec le catalogue Iceberg personnalisé. Pour en savoir plus, consultez Fédération de catalogues avec BigQuery.
Structure de dénomination des P.C.N.T
La structure de dénomination P.C.N.T est une convention en quatre parties utilisée pour identifier et interroger de manière unique les tables dans BigLake Metastore à partir de BigQuery. Il s'agit de l'abréviation de Project.Catalog.Namespace.Table :
- Project : ID du projet Google Cloud
- Catalogue : nom du catalogue BigLake Metastore
- Espace de noms : regroupement logique des tables (semblable à un ensemble de données)
- Table : nom de la table de données
Pour en savoir plus, consultez Interroger des catalogues.
Concepts de sécurité
Les fonctionnalités de sécurité fournissent des mécanismes de gestion des accès et de protection des données.
Connexions
Une connexion est une ressource BigQuery qui stocke les identifiants permettant d'accéder aux données externes. Dans BigLake, les connexions délèguent l'accès à Cloud Storage en permettant au compte de service de la connexion d'accéder au bucket de stockage en votre nom. Pour en savoir plus, consultez S'authentifier auprès de BigQuery.
Distribution d'identifiants
La distribution d'identifiants est un mécanisme de sécurité qui permet de renforcer le contrôle des accès lorsque vous utilisez le catalogue REST Iceberg. Lorsqu'il est activé, BigLake génère des identifiants à courte durée de vie et à portée limitée, conçus pour n'accorder l'accès qu'aux chemins d'accès aux fichiers spécifiques requis pour une requête, plutôt que de transmettre un accès générique au bucket à Compute Engine. Cela permet d'empêcher les utilisateurs de contourner les règles de sécurité au niveau des tables pour lire directement les fichiers bruts. Pour en savoir plus, consultez À propos de la distribution d'identifiants.
Gouvernance unifiée
La gouvernance unifiée vous permet de définir et d'appliquer des règles de sécurité et de gestion des données de manière centralisée grâce à l'intégration à Knowledge Catalog. Pour en savoir plus, consultez IAM et contrôle des accès.
Concepts de fiabilité
Les fonctionnalités de fiabilité assurent la résilience des données et la disponibilité du catalogue.
Réplication interrégionale
La réplication interrégionale réplique les métadonnées dans plusieurs régions pour garantir la disponibilité du catalogue en cas de panne régionale. Pour en savoir plus, consultez À propos de la reprise après sinistre gérée.
Basculement
Le basculement est le processus qui consiste à passer d'une région principale à une région secondaire en cas d'indisponibilité régionale pour maintenir les opérations du catalogue. Pour en savoir plus, consultez À propos de la reprise après sinistre gérée.