Fonctionnement du lakehouse

L'architecture technique de Lakehouse pour Apache Iceberg est compatible avec l'interopérabilité entre les moteurs en centralisant la gestion des métadonnées et en traitant les requêtes via des chemins spécifiques.

Architecture

La création de Lakehouse de Google Cloud repose sur les composants techniques suivants :

  • Stockage : Cloud Storage et le stockage BigQuery servent de couche de stockage, Apache Iceberg étant le format de table ouvert recommandé pour un stockage hautes performances et interopérable dans Cloud Storage.

  • Catalogue : le catalogue d'environnements d'exécution Lakehouse fournit une source unique de référence pour la gestion des métadonnées. Il centralise la découverte des métadonnées sur plusieurs moteurs à l'aide de diverses options de compatibilité, telles que le point de terminaison du catalogue REST Apache Iceberg. Les enregistrements de tables dans le catalogue enregistrent automatiquement les entrées dans le catalogue de connaissances des métadonnées métier.

  • Moteur de requête : BigQuery et les moteurs Open Source, y compris Apache Spark, Apache Flink et Trino, interagissent de manière transparente en se connectant au catalogue d'environnements d'exécution Lakehouse. Les moteurs de calcul tels que Managed Service pour Apache Spark exploitent Apache Spark Open Source avec des optimisations d'exécution pour garantir la portabilité des charges de travail et éviter l'enfermement propriétaire.

  • Gouvernance : Knowledge Catalog fournit des règles de sécurité, de traçabilité et de gouvernance centralisées dans l'ensemble de votre lakehouse.

  • Outils d'écriture et d'analyse de données : les moteurs et outils intégrés offrent plusieurs chemins pour l'ingestion et l'analyse des données, ce qui garantit un accès cohérent aux données pour les data scientists et les analystes.

Hiérarchie des ressources

Lakehouse de Google Cloud organise les données à l'aide d'une hiérarchie conforme aux normes Apache Iceberg et aux concepts de base de données standards. Cette structure permet au catalogue d'environnements d'exécution Lakehouse de mapper les identités logiques aux chemins de stockage physiques. Pour interagir avec cette hiérarchie de ressources et connecter vos moteurs de requête au catalogue, vous utilisez des points de terminaison spécifiques, comme décrit ci-dessous.

  1. Catalogue d'environnements d'exécution Lakehouse : ressource de service régional de premier niveau dans Google Cloud qui héberge vos métadonnées. Pour connecter des moteurs de requête à ce service et gérer les catalogues sous-jacents, vous configurez des applications clientes à l'aide d'un point de terminaison de catalogue spécifique, tel que le point de terminaison du catalogue REST Apache Iceberg.
  2. Catalogue : conteneur logique dans le service de catalogue d'exécution. Dans la structure de nommage Projet/Catalogue/Espace de noms/Table (P.C.N.T), cela représente l'instance de catalogue spécifique que vous interrogez.
  3. Espace de noms : regroupement logique de tables dans un catalogue. Pour les utilisateurs familiarisés avec BigQuery, un espace de noms est fonctionnellement semblable à un ensemble de données.
  4. Table : entité spécifique pointant vers des données dans Cloud Storage. Les métadonnées de la table contiennent le schéma, les informations de partitionnement et un pointeur vers l'état actuel de la table via un fichier metadata.json Apache Iceberg.

Points de terminaison disponibles

Le catalogue d'environnements d'exécution Lakehouse fournit plusieurs points de terminaison pour connecter vos données dans Cloud Storage et BigQuery.

  • Point de terminaison du catalogue REST Apache Iceberg : fournit une interface REST standard pour une compatibilité étendue avec les moteurs Open Source tels qu'Apache Spark, Apache Flink et Trino. Il s'agit de l'interface recommandée pour les nouvelles charges de travail. Elle offre une interopérabilité complète en lecture et en écriture.

  • Point de terminaison du catalogue Apache Iceberg personnalisé pour BigQuery : permet aux moteurs d'interagir directement avec le catalogue BigQuery. Cette interface est principalement utilisée pour les tables Apache Iceberg gérées par BigQuery et les charges de travail existantes qui passent à l'architecture Lakehouse.

  • Point de terminaison du catalogue Apache Hive : assure la compatibilité avec les charges de travail Open Source qui dépendent de l'interface du metastore Apache Hive (HMS). Cela vous permet d'exécuter des charges de travail Apache Hive ou Spark sur un service de metastore entièrement géré sur Google Cloud.

Catalogue d'environnements d'exécution Lakehouse

Dans la hiérarchie des ressources, le catalogue d'environnements d'exécution Lakehouse sert de service de métadonnées régional de premier niveau dans Google Cloud. Il fait office de conteneur racine qui héberge vos instances de catalogue individuelles, en centralisant la découverte des métadonnées sur différents moteurs de requête.

Pour en savoir plus sur le service de metastore, y compris les fonctionnalités clés, les moteurs compatibles, la configuration des points de terminaison et les limites, consultez À propos du catalogue d'environnements d'exécution Lakehouse.

Catalogue

Un catalogue est un conteneur de metastore logique soutenu par un seul bucket d'entrepôt Cloud Storage. Dans la structure de nommage Project.Catalog.Namespace.Table (P.C.N.T), le catalogue représente l'instance de metastore unique qui connecte les métadonnées de votre table ouverte aux moteurs de requête.

Voici les principales caractéristiques des catalogues :

  • Association de stockage : vous ne pouvez associer qu'un seul catalogue à un seul bucket Cloud Storage.
  • Réplication régionale : la région d'un catalogue correspond automatiquement à la région du bucket Cloud Storage sous-jacent.
  • Délégation d'accès : les administrateurs peuvent activer la distribution d'identifiants sur le catalogue pour déléguer l'accès, ce qui permet de générer automatiquement des identifiants à courte durée et à portée limitée au lieu d'accorder aux utilisateurs des autorisations directes sur le bucket.

Espace de noms

Un espace de noms est un regroupement logique de tables dans un catalogue, qui fonctionne de manière semblable à une base de données, à un schéma ou à un ensemble de données BigQuery. Il fournit une structure permettant d'organiser et de gérer les contrôles d'accès aux tables.

Voici les principales caractéristiques des espaces de noms :

  • Régionalité : lorsque vous créez un espace de noms, il utilise automatiquement la même région que son catalogue parent.
  • Limites d'imbrication : les espaces de noms imbriqués (sous-espaces de noms) ne sont pas compatibles.
  • Limites de sécurité : vous pouvez attribuer des rôles IAM au niveau de l'espace de noms pour gérer l'accès à toutes les tables qu'il contient.

Tables

Lorsque vous créez des tables avec Lakehouse de Google Cloud, vous pouvez choisir parmi les types de tables suivants :

Compatible avec le catalogue d'environnements d'exécution Lakehouse

Recommandé

  • Tables Apache Iceberg : tables Apache Iceberg créées à partir de moteurs Open Source et stockées dans Cloud Storage. Elles offrent une compatibilité et une gestion ouvertes via le point de terminaison REST du catalogue d'environnements d'exécution Lakehouse.

Compatible avec BigQuery

  • Tables Apache Iceberg : tables Apache Iceberg créées et gérées par BigQuery. Les métadonnées de ces tables sont stockées dans le catalogue BigQuery, tandis que les données de table et les métadonnées physiques sont stockées dans Cloud Storage.
  • Tables natives : tables entièrement gérées par BigQuery qui peuvent être connectées au catalogue d'environnements d'exécution Lakehouse pour permettre l'interopérabilité avec les moteurs Open Source.
  • Tables externes : tables en dehors du catalogue d'environnements d'exécution Lakehouse où les données et les métadonnées sont autogérées. Elles sont compatibles avec l'accès délégué via des connexions pour les données stockées dans Cloud Storage, Amazon S3 ou Azure Blob Storage.

Pour une comparaison détaillée de ces options, consultez Présentation des tables.

Formats de table compatibles

Seules les tables Apache Iceberg V2 sont compatibles. Les tables Iceberg V1 ne le sont pas. Si vous disposez de tables Iceberg V1 existantes, vous devez les mettre à niveau vers la version V2 (par exemple, en exécutant ALTER TABLE catalog.schema.table SET TBLPROPERTIES ('format-version'='2'); ou en utilisant des opérations de moteur similaires) avant de les utiliser avec Lakehouse pour Apache Iceberg.

Séquence de traitement des requêtes

Lorsque vous envoyez une requête à la table Lakehouse de Google Cloud, la requête suit un chemin spécifique pour appliquer les règles et récupérer les métadonnées avant le traitement des données.

  1. Envoi : vous envoyez une requête SQL à un moteur compatible tel qu'Apache Spark, Trino ou BigQuery.
  2. Requête de métadonnées : le moteur demande les métadonnées de la table au catalogue d'environnements d'exécution Lakehouse pour identifier la table et son emplacement de métadonnées.
  3. Autorisation : si le point de terminaison que vous utilisez est compatible, le catalogue valide la requête par rapport à Identity and Access Management (IAM) et aux règles de sécurité précises.
  4. Réponse de métadonnées : le catalogue renvoie les métadonnées. Si la distribution d'identifiants est activée, il fournit également un jeton de courte durée pour faciliter l'accès sécurisé au stockage.
  5. Récupération des données : le moteur utilise les métadonnées et le jeton facultatif pour lire les fichiers de données directement à partir de Cloud Storage.
  6. Exécution : le moteur traite les données et renvoie les résultats.

Bonnes pratiques

Lorsque vous concevez et exploitez un data lakehouse sur Google Cloud, tenez compte des bonnes pratiques suivantes :

  • Adoptez une architecture en médaillon : structurez votre entrepôt de données en couches logiques progressives (bronze pour l'ingestion brute, argent pour les données nettoyées et conformes, et or pour les agrégations organisées au niveau de l'entreprise). Utilisez BigQuery pour la couche de consommation or afin de maximiser les performances et la simultanéité des requêtes.
  • Utilisez des modèles de session pour les charges de travail interactives : pour l'analyse exploratoire et la création de notebooks, utilisez des modèles de session afin de standardiser les configurations d'environnement entre les équipes de développement et de réduire la configuration répétitive.
  • Attribuez des identifiants de lot personnalisés : lorsque vous envoyez des charges de travail par lot Apache Spark sans serveur non interactives, attribuez des noms de lot et de job personnalisés. Cela améliore l'observabilité, ce qui facilite le filtrage et le suivi des exécutions de jobs dans Cloud Logging et la Google Cloud console.
  • Activez la journalisation des diagnostics : pour les pipelines d'ingénierie de données complexes, activez les bundles de diagnostic et assurez-vous que les journaux du pilote et de l'exécuteur sont conservés pour simplifier le dépannage et la compatibilité.

Étape suivante