Fonctionnement du Lakehouse sans frontières

L'architecture technique de Lakehouse sans frontières 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 du Lakehouse Google Cloud se compose des composants techniques suivants :

  • Stockage : le stockage Cloud Storage et BigQuery sert de couche de stockage, avec Apache Iceberg comme format de table ouvert recommandé pour un stockage hautes performances et interopérable dans Cloud Storage. Avec le lakehouse sans frontières, vos données n'ont pas besoin de résider dans Google Cloud. En configurant des connexions multicloud (preview) vers des catalogues distants compatibles, vous pouvez conserver vos données dans d'autres systèmes de stockage cloud, tels qu'Amazon S3, et les interroger sans migrer de fichiers ni créer de pipelines ETL.

  • Catalogue : le catalogue d'environnements d'exécution Lakehouse fournit une source unique de vérité 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. L'enregistrement de tables dans le Knowledge Catalog enregistre 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 fluide en se connectant au catalogue d'environnements d'exécution Lakehouse. Les moteurs de calcul tels que Managed Service pour Apache Spark utilisent Apache Spark Open Source avec des optimisations d'exécution pour assurer la portabilité des charges de travail et éviter le verrouillage du fournisseur.

  • Gouvernance : Knowledge Catalog fournit des règles de sécurité, de traçabilité et de gouvernance centralisées pour 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 permet d'assurer un accès cohérent aux données pour les data scientists et les analystes.

Hiérarchie des ressources

Le 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 devez utiliser des points de terminaison spécifiques, comme décrit dans la liste suivante.

  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 Apache Iceberg REST.
  2. Catalogue : conteneur logique au sein du service de catalogue d'environnements d'exécution. Dans la structure de dénomination 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.

  • Catalogue Apache Iceberg personnalisé pour le point de terminaison 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 (preview) : assure la compatibilité avec les charges de travail Open Source qui dépendent de l'interface Apache Hive Metastore (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 sert de conteneur racine pour héberger vos instances de catalogue individuelles, ce qui centralise la découverte des métadonnées sur différents moteurs de requête.

Il implémente l'API Apache Iceberg REST Catalog Open Source pour gérer les espaces de noms et les tables, et fournit des extensions spécifiquement pour la gestion des catalogues.

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

Catalogue

Un catalogue est un conteneur de métastore logique soutenu par des emplacements d'entrepôt Cloud Storage. Dans la structure de dénomination Project.Catalog.Namespace.Table (P.C.N.T), le catalogue représente l'instance 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 : la relation entre un catalogue et son stockage sous-jacent dépend du type de catalogue que vous configurez.
  • Réplication régionale : la région d'un catalogue correspond automatiquement à celle du bucket sous-jacent.
  • Délégation d'accès : les administrateurs peuvent activer la distribution d'identifiants dans le catalogue pour déléguer l'accès. Cela permet de générer automatiquement des identifiants à durée de vie limitée et à portée réduite au lieu d'accorder aux utilisateurs des autorisations d'accès direct aux buckets.

Espace de noms

Un espace de noms est un regroupement logique de tables dans un catalogue. Il fonctionne de la même manière qu'une base de données, un schéma ou un ensemble de données BigQuery. Elle 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.
  • Flexibilité de l'emplacement : les options permettant de spécifier des emplacements d'espace de noms personnalisés sont déterminées par le type d'entrepôt du catalogue.
  • Limites d'imbrication : les espaces de noms imbriqués (sous-espaces de noms) ne sont pas acceptés.
  • Limites de sécurité : vous pouvez accorder 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 le Lakehouse 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. Ils offrent une compatibilité et une gestion ouvertes via le point de terminaison REST du catalogue d'environnements d'exécution Lakehouse. Pour s'assurer qu'aucune table n'occupe le même emplacement, les chemins d'accès personnalisés aux tables doivent être imbriqués sous le chemin d'accès à l'espace de noms parent. Les emplacements de table obtenus reçoivent automatiquement un suffixe de chaîne aléatoire pour éviter les conflits.

    Formats de tableau acceptés

    Les tables Apache Iceberg V2 (disponibilité générale) et V3 (preview) sont compatibles. Les tables Iceberg V1 ne sont pas acceptées. Avant d'utiliser des tables V1 existantes avec Lakehouse, vous devez les mettre à niveau vers une version compatible. Pour en savoir plus, consultez Mettre à niveau les tables Iceberg V1 vers V2.

Pris en charge par 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 vous permettre d'interagir avec des 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 obtenir une comparaison détaillée de ces options, consultez Comprendre les types de tableaux et leurs fonctionnalités.

Séquence de traitement des requêtes

Lorsque vous envoyez une requête à une table Apache Iceberg gérée par Lakehouse, 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. Demande 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 l'emplacement de ses métadonnées.
  3. Autorisation : si le point de terminaison que vous utilisez est compatible, le catalogue valide la requête par rapport aux stratégies IAM (Identity and Access Management) et de sécurité affinée.
  4. Réponse des 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 depuis 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 Gold 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'exploration analytique et la création de notebooks, utilisez des modèles de session afin de standardiser les configurations d'environnement dans les équipes de développement et de réduire les configurations répétitives.
  • 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 vous aide à filtrer et à suivre les exécutions de jobs dans Cloud Logging et la console Google Cloud .
  • Activez la journalisation des diagnostics : pour les pipelines d'ingénierie des 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 faciliter le dépannage et la compatibilité.

Étapes suivantes