Ce document définit les termes et concepts clés de Google Cloud Lakehouse.
Cette page ne constitue pas une liste exhaustive des fonctionnalités, mais plutôt une référence générale des termes et concepts utilisés dans la documentation Google Cloud Lakehouse.
Concepts fondamentaux
Les concepts suivants constituent la base de l'architecture Google Cloud Lakehouse.
Data Lakehouse Google Cloud
Un data lakehouse combine les économies et la flexibilité d'un lac de données avec la gestion des données et les performances d'un entrepôt de données. Il vous permet de stocker des données dans des formats ouverts sur Cloud Storage et d'utiliser les fonctionnalités de BigQuery, telles que des contrôles de sécurité précis et des requêtes rapides.
Interopérabilité ouverte
L'interopérabilité ouverte permet à plusieurs systèmes analytiques et transactionnels (tels que BigQuery, Apache Spark et Apache Flink) de fonctionner sur une seule copie de données dans des formats ouverts tels qu'Apache Iceberg. Cela évite la duplication des données et garantit une vue cohérente des données dans différents outils.
Catalogue d'exécution Lakehouse
Le catalogue d'exécution Lakehouse est un service de métadonnées centralisé et sans serveur qui sert de source unique de vérité pour Google Cloud Lakehouse. Il permet à plusieurs moteurs, tels qu'Apache Spark, Apache Flink et BigQuery, de découvrir et d'interroger les mêmes tables simultanément.
Types de catalogues
Le catalogue d'exécution Lakehouse propose différents types de catalogues pour gérer vos métadonnées.
Point de terminaison du catalogue REST Apache Iceberg
Il s'agit d'un catalogue basé sur le point de terminaison du catalogue REST Apache Iceberg. 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.
Catalogue Apache Iceberg personnalisé pour BigQuery
Il s'agit d'une intégration qui utilise directement le catalogue BigQuery comme service de métadonnées sous-jacent pour les tables Apache Iceberg gérées.
Formats de tableau
Google Cloud Lakehouse est compatible avec plusieurs formats de tables, selon le moteur utilisé pour gérer les données.
Tables du catalogue REST Iceberg Lakehouse
Il s'agit de tables Apache Iceberg créées à partir de moteurs Open Source et stockées dans Cloud Storage. Le catalogue d'exécution Lakehouse sert de catalogue central. Seul le moteur Open Source qui a créé la table peut y écrire.
les tables BigQuery
Ces tables sont gérées avec BigQuery.
Tables Apache Iceberg
Il s'agit de tables Apache 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.
Tables natives
Ces tables sont gérées par BigQuery et stockent les données dans l'espace de stockage BigQuery. Vous pouvez associer ces tables au catalogue du runtime Lakehouse.
Tables externes
Les tables externes résident en dehors du catalogue d'exécution Lakehouse. Les données et les métadonnées sont autogérées dans un catalogue tiers (tel que Cloud Storage, S3 ou Azure Blob Storage). BigQuery ne peut lire que les données de ces tables.
Fonctionnalités des tableaux
Évolution des tableaux
Google Cloud Lakehouse est compatible avec l'évolution des tables Apache 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.
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.
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. 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 depuis Cloud Storage lors de l'exécution des requêtes.
Gestion des tables Google Cloud Lakehouse
La gestion des tables Lakehouse Google Cloud simplifie la maintenance des lakehouses en automatisant des tâches telles que le compactage et le nettoyage des tables gérées. Cela garantit des performances de requête et une efficacité de stockage optimales.
Concepts d'interopérabilité
Fédération du catalogue d'exécution Lakehouse
La fédération de catalogues est une fonctionnalité qui permet au catalogue du runtime Lakehouse de gérer et d'interroger des tables provenant de catalogues externes (tels qu'AWS Glue ou Unity Catalog) visibles par 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 du catalogue d'exécution Lakehouse à 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 du runtime Lakehouse.
- Espace de noms : regroupement logique des tables (semblable à un ensemble de données).
- Table : nom de la table de données.
Concepts de sécurité
Connexions
Une connexion est une ressource BigQuery qui stocke les identifiants permettant d'accéder aux données externes. Dans Google Cloud Lakehouse, 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.
Distribution d'identifiants
La distribution d'identifiants est un mécanisme de sécurité qui permet de renforcer le contrôle des accès lors de l'utilisation du catalogue Lakehouse Runtime. Lorsqu'il est activé, le service génère des identifiants à durée de vie limitée et à portée réduite, conçus pour n'accorder l'accès qu'aux chemins d'accès aux fichiers spécifiques requis pour une requête.
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.
Concepts de fiabilité
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.
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.