À propos de l'accès aux données multicloud

La fonctionnalité d'accès aux données cross-cloud vous permet d'interroger les données stockées chez d'autres fournisseurs de services cloud directement depuis Google Cloud sans migrer de fichiers ni créer de pipelines ETL complexes. Les requêtes peuvent être acheminées via l'Internet public ou utiliser interconnexion cross-cloud pour le transport sur un réseau privé.

L'accès aux données cross-cloud dans Lakehouse unifie les charges de travail d'analyse et d'IA sur vos ensembles de données distribués via BigQuery, des environnements Apache Spark autonomes ou Managed Service pour Apache Spark.

En plus d'exécuter des requêtes analytiques, vous pouvez créer des agents d'analyse conversationnelle ancrés dans vos tables distribuées, y compris des sources cross-cloud, pour analyser des données sur plusieurs clouds à partir d'une seule conversation. Vous pouvez également utiliser Knowledge Catalog pour profiler les données et obtenir des insights sur les plates-formes distantes.

Quand utiliser l'accès aux données cross-cloud ?

Voici quelques cas d'utilisation courants :

  • Interroger des tables multicloud sur place : exécutez des analyses BigQuery SQL et Managed Service pour Apache Spark directement sur des tables Apache Iceberg externes dans Amazon Web Services (AWS) et Microsoft Azure sans migrer de fichiers ni gérer de pipelines ETL.
  • Appliquer l'isolation du réseau multicloud privé : acheminez les lectures de données de requête et l'actualisation des métadonnées en arrière-plan via interconnexion cross-cloud pour respecter les règles de sécurité et de conformité qui limitent le trafic Internet public.
  • Réduire les coûts récurrents de transfert de données cross-cloud : combinez des tarifs de sortie d'interconnexion privée prévisibles avec la mise en cache automatique des blocs locaux dansGoogle Cloud pour les tableaux de bord d'informatique décisionnelle et les charges de travail analytiques répétés.
  • Unifiez la gouvernance cross-cloud et les agents d'IA : ancrez les agents d'analyse conversationnelle dans des tables distribuées et appliquez la découverte, le profilage et la traçabilité de Knowledge Catalog sur plusieurs clouds.

Architecture

Le diagramme suivant illustre l'architecture d'accès aux données cross-cloud de Lakehouse :

Architecture de l'accès aux données cross-cloud Lakehouse sur Google Cloud, Amazon Web Services (AWS) et les partenaires SaaS.
L'architecture de Lakehouse connecte Google Cloud les moteurs d'IA et d'analyse aux catalogues cloud externes, au stockage d'objets et aux partenaires SaaS.

Le schéma précédent illustre l'architecture dans Google Cloud et les environnements cloud et SaaS externes :

  • Google Cloud : fournit l'IA, la gouvernance, l'analyse et l'accès aux données cross-cloud sur des ensembles de données distants :
    • Agents et expériences d'IA : crée des agents autonomes dans Conversational Analytics et Gemini Enterprise qui recherchent des données et une signification sémantique dans Knowledge Catalog, et exécutent des requêtes via des moteurs d'analyse et de traitement.
    • Knowledge Catalog : fournit une gouvernance et une traçabilité des données unifiées, ainsi que des insights sur les données, un profilage et des produits de données, en synchronisant les métadonnées et la traçabilité depuis Lakehouse.
    • Moteurs d'analyse et de traitement : exécute les charges de travail BigQuery SQL, BigQuery AI et Looker, ou traite les données distantes avec Managed Service pour Apache Spark et les moteurs ouverts (Apache Spark, Apache Flink et Trino) en résolvant les métadonnées et en lisant les tables via Lakehouse.
    • Accès aux données cross-cloud Lakehouse : interroge les données distantes sur place sans migration de fichiers ni pipelines ETL :
      • Synchronisation des métadonnées : découvre et synchronise les métadonnées des tables sur Apache Iceberg REST et Delta Sharing à l'aide du catalogue d'environnements d'exécution Lakehouse, s'authentifie via OpenID Connect (OIDC) ou Secret Manager, et fournit des identifiants temporaires limités.
      • Fonctionnalités cross-cloud (AWS) : met en cache les blocs de données lus dans Google Cloud à l'aide d'un cache de lecture au niveau du bloc (mise en cache intelligente (cache local)) et achemine le trafic via Dedicated interconnexion cross-cloud (CCI), interconnexion partenaire ou Internet (avec TLS) à l'aide du transport réseau cross-cloud.
  • Sources de données cloud et SaaS externes : hébergent les catalogues distants, les clouds de données SaaS et le stockage d'objets :
    • Catalogues cloud et SaaS externes : synchronise les métadonnées des catalogues de données cloud (AWS Glue Data Catalog sur AWS, et Databricks Unity Catalog et Snowflake Horizon Catalog sur AWS ou Google Cloud) et des clouds de données SaaS (Salesforce Data Cloud, Workday Data Lake sur AWS ouGoogle Cloud, et SAP Business Data Cloud (BDC)) via l'API REST Iceberg et Delta Sharing (pour SAP BDC).
    • Stockage d'objets cloud externe (AWS) : stocke les tables Apache Iceberg (fichiers de données Parquet) et les tables Amazon S3 dans Amazon S3 pour les lectures de blocs directes via CCI ou Internet (avec TLS).

Fonctionnement de l'accès aux données cross-cloud

Lakehouse interroge les données distantes à l'aide du processus suivant :

  1. Découverte des métadonnées : le catalogue d'environnements d'exécution Lakehouse se connecte aux points de terminaison du catalogue REST Apache Iceberg distant, tels que Databricks Unity Catalog, AWS Glue Data Catalog ou Snowflake Horizon Catalog, pour découvrir les métadonnées de table sans copier de fichiers. Selon le fournisseur de catalogue distant, Lakehouse s'authentifie via Secret Manager ou la fédération de jetons OIDC avec Google comme fournisseur d'identité.
  2. Transport sécurisé : choisir d'acheminer le trafic via une interconnexion privée (par exemple, Dedicated CCI ou interconnexion partenaire) réduit considérablement les coûts de transfert de données par rapport à l'Internet public et rend la latence hautement prévisible.
  3. Exécution optimisée : lorsque vous activez la mise en cache cross-cloud sur votre catalogue fédéré ou votre connexion, Lakehouse met en cache les blocs de fichiers récupérés localement dans la région d'exécution de la requête Google Cloud . Les requêtes ultérieures ciblant les mêmes blocs de fichiers sont lues directement à partir du cache local au lieu de récupérer à nouveau les fichiers depuis le cloud distant, ce qui permet de réduire les coûts de sortie cross-cloud et d'améliorer les performances des requêtes.

Catalogues compatibles

Lakehouse permet d'interroger des données provenant des fournisseurs de catalogues distants suivants :

Concepts fondamentaux

L'accès aux données cross-cloud sépare l'actualisation des métadonnées en arrière-plan du transport des données de requête. Vous pouvez ainsi acheminer l'une ou l'autre de ces couches de trafic, ou les deux, de manière privée, en fonction de vos exigences de sécurité et de coût.

Couche de métadonnées

La couche de métadonnées du catalogue d'environnements d'exécution Lakehouse se connecte aux points de terminaison du catalogue REST Apache Iceberg distant pour synchroniser l'espace de noms et les métadonnées de table Apache Iceberg en fonction d'un intervalle d'actualisation. Lakehouse s'authentifie à l'aide d'identifiants stockés dans Secret Manager ou de la fédération de jetons OIDC.

Par défaut, les requêtes d'authentification et d'actualisation des métadonnées en arrière-plan transitent sur l'Internet public à l'aide de TLS. Lorsque votre catalogue distant limite l'accès au réseau public ou que votre stratégie de sécurité nécessite un trafic de plan de contrôle privé, vous pouvez configurer un service Annuaire des services de métadonnées (--metadata-service-directory-name) pour AWS Glue Data Catalog (sur AWS), Databricks Unity Catalog (sur AWS et Azure) et Snowflake Horizon Catalog (sur AWS et Azure). Cette configuration achemine le trafic de métadonnées et d'authentification de manière privée via Dedicated interconnexion cross-cloud ou Partner interconnexion cross-cloud (pour AWS), indépendamment ou conjointement avec le transport de requêtes privées (--service-directory-name).

Couche transport

La couche transport permet à BigQuery et aux moteurs Open Source d'interroger les fichiers de table distants à l'aide des métadonnées synchronisées de la couche de métadonnées. Pour les catalogues distants compatibles, Lakehouse permet d'interroger des données sur l'Internet public ou via une interconnexion privée dédiée.

Sélectionnez la méthode de transport qui correspond à vos exigences architecturales et de sécurité :

Appartenant au client (CCI)

Vous pouvez configurer BigQuery pour interroger les données stockées dans des buckets Amazon S3 ou des conteneurs Azure Data Lake Storage Gen2 (ADLS Gen2) via interconnexion cross-cloud privée à l'aide de Cross-Cloud Interconnect dédié ou de Cross-Cloud Interconnect partenaire.

L'utilisation d'une interconnexion privée présente les avantages suivants :

  • Sécurité renforcée : les données transitent par une connexion réseau privée entre Google Cloud et AWS ou Azure, sans passer par l'Internet public.
  • Réduction des coûts : réduction potentielle des frais de sortie d'AWS ou d'Azure par rapport à la sortie Internet, en particulier lorsqu'elle est combinée à votre capacité d'interconnexion privée.
  • Performances constantes : latence et bande passante réseau plus prévisibles par rapport à l'Internet public.

Présentation de l'architecture

Pour activer l'interrogation privée, vous devez configurer un chemin d'accès de BigQuery vers votre bucket Amazon S3 ou votre conteneur ADLS Gen2 via votre interconnexion privée. Un composant clé du cloud privé virtuel (VPC)Google Cloud est un équilibreur de charge interne (ILB). L'ILB distribue les requêtes de BigQuery aux points de terminaison privés pour Amazon S3 dans votre VPC AWS (provisionné à l'aide d'AWS PrivateLink) ou pour ADLS Gen2 dans votre réseau virtuel Azure (VNet), provisionné à l'aide d'Azure Private Link.

L'utilisation d'un équilibreur de charge interne avec plusieurs interfaces réseau élastiques (ENI) ou cartes d'interface réseau (NIC) en tant que backends est essentielle pour l'équilibrage de charge, l'évolutivité et la haute disponibilité. Cela s'applique que vous utilisiez Dedicated CCI ou interconnexion partenaire.

Le workflow de requête privée suit ce processus :

  1. BigQuery utilise une connexion configurée avec un service de l'Annuaire des services.
  2. L'Annuaire des services résout le nom du service en adresse IP interne de l'ILB Google Cloud .
  3. L'ILB reçoit les requêtes de BigQuery et les distribue aux backends configurés.
  4. Les backends de l'ILB sont des groupes de points de terminaison du réseau (NEG) de connectivité hybride, chacun pointant vers l'adresse IP privée d'une ENI dans votre VPC AWS ou d'une carte d'interface réseau dans votre VNet Azure.
  5. Le trafic circule de l'ILB, via les NEG, via l'interconnexion privée, vers les ENI AWS ou les cartes d'interface réseau Azure.
  6. Les ENI AWS, qui font partie d'un point de terminaison d'interface VPC Amazon S3 (AWS PrivateLink), ou les cartes d'interface réseau Azure, qui font partie d'un point de terminaison privé ADLS Gen2 (Azure Private Link), fournissent un accès privé au service Amazon S3 ou ADLS Gen2.

Internet public (pas de CCI)

Si vous ne configurez pas d'interconnexion privée, les requêtes adressées à votre catalogue distant transitent par défaut via l'Internet public.

Lorsque vous interrogez des données sur l'Internet public, tenez compte des implications suivantes :

  • Chiffrement standard : les demandes d'accès aux données et les transferts de données sont chiffrés en transit à l'aide des protocoles TLS standards sur l'Internet public.
  • Coûts de sortie : le transfert de données entraîne des frais de sortie Internet standards de la part de votre fournisseur cloud distant (par exemple, AWS ou Azure), qui sont généralement plus élevés que les tarifs de sortie d'interconnexion privée.
  • Latence variable : les performances, la bande passante et la latence du réseau dépendent du routage et de la congestion de l'Internet public, ce qui se traduit par des temps d'exécution des requêtes moins prévisibles par rapport à une interconnexion privée dédiée.
  • Configuration simplifiée : ne nécessite aucune infrastructure réseau supplémentaire, d'appairage de VPC ou de configuration de l'Annuaire des services dans Google Cloud ou votre fournisseur de services cloud distant.

Présentation de l'architecture

Lorsque vous interrogez des données sur l'Internet public, Lakehouse se connecte directement à vos points de terminaison de catalogue et de store d'objets distants, sans nécessiter d'infrastructure réseau cloud privée Google Cloud ou distante.

Le workflow de requête sur l'Internet public suit ce processus :

  1. BigQuery lance une requête sur une table distante définie dans votre catalogue Lakehouse.
  2. Lakehouse s'authentifie de manière sécurisée auprès de votre catalogue Apache Iceberg distant à l'aide d'identifiants stockés dans Secret Manager ou de la fédération de jetons OIDC.
  3. Lakehouse récupère les métadonnées de la table et les fichiers manifestes sur l'Internet public pour identifier les fichiers de données sous-jacents pertinents (par exemple, dans Amazon S3 ou ADLS Gen2).
  4. Les requêtes d'accès aux données pour les objets sous-jacents sont envoyées directement depuisGoogle Cloud sur l'Internet public à l'aide du chiffrement TLS standard.
  5. Le service de stockage distant vérifie la requête à l'aide d'identifiants temporaires et limités fournis par Lakehouse, puis renvoie les blocs de fichiers demandés à Google Cloudvia l'Internet public.

Mise en cache intelligente

Pour réduire les coûts de sortie cross-cloud et accélérer les requêtes qui lisent les mêmes blocs de fichiers, vous pouvez activer la mise en cache cross-cloud sur vos catalogues fédérés Lakehouse et vos connexions cross-cloud BigQuery sans frais supplémentaires.

Lorsque vous activez la mise en cache cross-cloud, Lakehouse met en cache les blocs de fichiers récupérés depuis Amazon S3 ou Azure Blob Storage localement dans la région d'exécution de la requête Google Cloud . Les requêtes ultérieures, y compris les requêtes différentes ciblant les mêmes blocs de fichiers, sont lues directement à partir du cache local au lieu de récupérer à nouveau les fichiers à partir du cloud distant.

Google gère automatiquement la capacité, la conservation et l'éviction du cache. Les économies réelles sur les coûts de sortie dépendent de vos schémas de requête, de la fréquence de modification de vos fichiers sources et de la conservation du cache dans la région Google Cloudcible. Avant de diffuser des données mises en cache, chaque requête vérifie les métadonnées et les autorisations d'accès auprès de la source de stockage distante afin de ne pas lire de données obsolètes ni de contourner les autorisations révoquées.

La mise en cache cross-cloud est désactivée par défaut. Vous pouvez activer ou désactiver la mise en cache lorsque vous créez ou mettez à jour un catalogue fédéré Lakehouse ou une connexion cross-cloud BigQuery. Pour obtenir des instructions de configuration, consultez le guide de configuration de votre fournisseur de catalogue compatible ou Créer des connexions cross-cloud.

Vérifier l'utilisation du cache et les économies sur les coûts de sortie

Pour vérifier les taux de succès de cache (hit) et mesurer vos économies sur les coûts de sortie, inspectez les détails du job dans la console BigQuery ou vérifiez le champ objectStorageStats (object_storage_stats) dans les statistiques du job de requête JobStatistics2 de BigQuery :

  • cloudProvider (cloud_provider) : fournisseur de services cloud qui héberge le store d'objets (par exemple, AWS ou AZURE).
  • cacheBytesRead (cache_bytes_read) : nombre total d'octets lus à partir du cache Google Cloud local, ce qui évite une lecture du store d'objets distant.
  • objectStorageBytesRead (object_storage_bytes_read) : nombre total d'octets lus directement à partir du store d'objets du fournisseur de services cloud.

Pour savoir comment récupérer ces métriques à l'aide de l'outil de ligne de commande bq, consultez Surveiller l'utilisation du cache et les économies sur les coûts de sortie.

Points à prendre en compte concernant la résidence des données et la juridiction

Lorsque vous activez la mise en cache cross-cloud, Lakehouse stocke temporairement des copies mises en cache de vos fichiers distants au repos dans la région Google Cloud où la requête est exécutée. Avant d'activer la mise en cache pour les fichiers situés dans une autre région géographique ou juridiction (par exemple, Amazon S3 ou Azure Blob Storage dans l'Union européenne interrogés depuis us-east4), vérifiez que le stockage de copies temporaires mises en cache dans la régionGoogle Cloud cible répond aux exigences de résidence des données et de conformité de votre organisation.

Chiffrement et compatibilité avec les clés CMEK

Les données mises en cache sont chiffrées au repos à l'aide de clésGoogle-owned and Google-managed encryption keyspar défaut. Les clés de chiffrement gérées par le client (CMEK) ne sont pas compatibles avec la mise en cache cross-cloud.

Si votre organisation applique la contrainte de règle d'administration Limiter les services non-CMEK (constraints/gcp.restrictNonCmekServices), Lakehouse désactive automatiquement la mise en cache pour les requêtes qui accèdent aux tables limitées. Vos requêtes continuent de s'exécuter, mais elles lisent directement à partir du stockage distant sans mettre en cache les blocs de fichiers.

Mode d'identité

Lakehouse accepte deux modes d'identité pour l'accès aux données cross-cloud :

  • Identité du service (par défaut) : l'actualisation des métadonnées en arrière-plan et les requêtes s'exécutent à l'aide du compte de service du catalogue, qui peut être configuré avec l'authentification OIDC (recommandée) ou basée sur un secret.

  • Fédération d'identité des utilisateurs : l'actualisation des métadonnées en arrière-plan s'exécute à l'aide du compte de service du catalogue, mais les requêtes s'exécutent à l'aide de l'identité de l'utilisateur final et sont propagées au catalogue distant. Cela permet au catalogue distant d'attribuer les requêtes de Google Cloud aux utilisateurs finaux, ce qui permet d'appliquer les autorisations et de générer des journaux d'audit. La fédération d'identité doit être configurée dans le catalogue distant.

Étapes suivantes