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 vérité pour la gestion des métadonnées. Il centralise la détection 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 des tables dans le catalogue 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 transparente 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 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 permet de garantir 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 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 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.

  • 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 (bêta) : assure la compatibilité avec les charges de travail Open Source qui dépendent de l'interface Apache Hive Metastore (HMS). Vous pouvez ainsi 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étection des métadonnées sur différents moteurs de requête.

Il implémente l'API de catalogue REST Apache Iceberg 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 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 basé sur des emplacements 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 : 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 à la région du bucket 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 éphémères à portée réduite au lieu d'accorder aux utilisateurs des autorisations de bucket directes.

Espace de noms

Un espace de noms est un regroupement logique de tables dans un catalogue, qui fonctionne de la même manière qu'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.
  • 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 compatibles.
  • 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 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. Pour s'assurer qu'aucune table n'occupe le même emplacement, les chemins de table personnalisés doivent être imbriqués sous le chemin d'espace de noms parent, et les emplacements de table résultants reçoivent automatiquement un suffixe de chaîne aléatoire pour éviter les conflits.

    Formats de table compatibles

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

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, et 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 une comparaison détaillée de ces options, consultez Comprendre les types et les fonctionnalités des tables.

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 éphémère 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 tâche personnalisés. Cela améliore l'observabilité, ce qui vous permet de filtrer et de suivre les exécutions de tâches dans Cloud Logging et dans 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 faciliter le dépannage et la compatibilité.

Étape suivante