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

La fonctionnalité d'accès aux données multicloud vous permet d'interroger les données stockées chez d'autres fournisseurs de services cloud directement depuis Google Cloud , sans avoir à migrer les fichiers ni à créer des pipelines ETL complexes avec interconnexion cross-cloud.

Dans le cadre de Lakehouse sans frontières, cette fonctionnalité vous permet d'effectuer des analyses unifiées et d'appliquer l'IA à vos ensembles de données distribués à l'aide de BigQuery, d'environnements Apache Spark autonomes ou de Managed Service pour Apache Spark.

En plus des requêtes analytiques, vous pouvez utiliser vos données fédérées pour obtenir des insights et une gouvernance basés sur l'IA :

  • Conversational Analytics : créez des agents spécialisés basés sur vos sources de données exactes, y compris des tables multiclouds, pour analyser les données sur plusieurs clouds à partir d'une seule conversation.
  • Knowledge Catalog : utilisez les fonctionnalités de Knowledge Catalog pour le profilage et les insights sur les données avec des sources de données fédérées.

Cas d'utilisation

Lakehouse est compatible avec plusieurs cas d'utilisation clés pour accéder aux données de plusieurs fournisseurs de cloud :

  • La réduction des déplacements de données vous permet d'interroger directement les données stockées dans d'autres environnements cloud, ce qui simplifie l'accès aux données et leur traitement.
  • L'analyse unifiée vous permet d'effectuer des analyses avancées avec des fonctionnalités et une optimisation matérielle cohérentes sur toutes vos données, où qu'elles se trouvent.
  • L'IA et le ML sans frontières vous permettent d'appliquer des modèles d'IA, des agents autonomes et le machine learning directement à vos données à distance, sans les migrer.

Accéder aux données cross-cloud

Les requêtes Lakehouse interrogent les données distantes à l'aide du processus suivant :

  1. Découverte des métadonnées : Google CloudLakehouse se connecte aux catalogues REST Apache Iceberg à distance, tels que Databricks Unity ou AWS Glue. Le lakehouse découvre les données sans copier de fichiers. Selon le fournisseur de catalogue distant, Lakehouse s'authentifie de manière sécurisée via Secret Manager ou la fédération de jetons OpenID Connect avec Google comme fournisseur d'identité (fédération de jetons OIDC).
  2. Transport sécurisé : le choix 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 très prévisible.
  3. Exécution optimisée : lorsque les requêtes lisent des données provenant de clouds distants, Lakehouse met temporairement en cache ces segments de données en local dans Google Cloud sur un espace de stockage spécialisé. Les requêtes suivantes utilisent le cache local, ce qui évite une partie importante des frais de sortie cross-cloud.

Catalogues compatibles

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

Concepts fondamentaux

Cette section décrit les composants clés essentiels à l'utilisation de la fonctionnalité d'accès aux données multicloud.

Couche de métadonnées

La couche de métadonnées se connecte aux points de terminaison du catalogue REST Apache Iceberg à distance pour synchroniser les métadonnées des ressources Iceberg (espace de noms, table) en fonction d'un intervalle d'actualisation. Lakehouse s'authentifie de manière sécurisée avec les identifiants OAuth stockés dans Secret Manager ou la fédération de jetons OIDC.

Couche transport

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

Sélectionnez la méthode de transport qui correspond à vos exigences en termes d'architecture et de sécurité :

Appartenant au client (CCI)

Vous pouvez configurer BigQuery pour interroger les données stockées dans les buckets Amazon S3 d'Amazon Web Services (AWS) via interconnexion cross-cloud privée à l'aide d'une Cross-Cloud Interconnect dédiée ou d'une Cross-Cloud Interconnect partenaire.

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

  • Sécurité renforcée : les données transitent via une connexion réseau privée entre Google Cloud et AWS, ce qui évite l'Internet public.
  • Coûts réduits : les frais de sortie d'AWS peuvent être inférieurs à ceux de la sortie Internet, en particulier lorsqu'ils sont combinés à votre capacité d'interconnexion privée.
  • Performances cohérentes : latence et bande passante réseau plus prévisibles que sur l'Internet public.

Présentation de l'architecture

Pour activer les requêtes privées, vous devez configurer un chemin d'accès de BigQuery à votre bucket AWS Amazon S3 via votre interconnexion privée. Un équilibreur de charge interne (ILB) est un composant clé du cloud privé virtuel (VPC) Google Cloud. L'équilibreur de charge interne distribue les requêtes de BigQuery aux points de terminaison privés d'Amazon S3 dans votre VPC AWS, qui sont provisionnés à l'aide d'AWS PrivateLink.

L'utilisation d'un équilibreur de charge interne avec plusieurs interfaces réseau élastiques (ENI) comme 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 des requêtes privées est le suivant :

  1. BigQuery utilise une connexion configurée avec un service 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'équilibreur de charge interne reçoit les requêtes de BigQuery et les distribue aux backends configurés.
  4. Les backends de l'équilibreur de charge interne 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.
  5. Le trafic transite de l'équilibreur de charge interne vers les ENI AWS, en passant par les NEG et l'interconnexion privée.
  6. Les ENI AWS, qui font partie d'un point de terminaison d'interface VPC Amazon S3 (AWS PrivateLink), permettent d'accéder de manière privée au service Amazon S3.

Internet public (sans CCI)

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

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 votre fournisseur de cloud à distance (par exemple, AWS), qui sont généralement plus élevés que les tarifs de sortie des interconnexions privées.
  • 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. Les temps d'exécution des requêtes sont donc moins prévisibles qu'avec une interconnexion privée dédiée.
  • Configuration simplifiée : ne nécessite aucune infrastructure réseau, ni aucun peering VPC ni aucune configuration de l'annuaire des services supplémentaires dans Google Cloud ou votre fournisseur de services cloud à distance.

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 stockage 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 fédérée 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 et les fichiers manifestes des tables sur l'Internet public pour identifier les fichiers de données sous-jacents pertinents (par exemple, dans AWS Amazon S3).
  4. Les demandes 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 à distance vérifie la requête à l'aide d'identifiants temporaires et limités fournis par Lakehouse, puis renvoie les blocs de données demandés sur l'Internet public à Google Cloud.

Mise en cache intelligente

Lorsque vous interrogez des données cloud à distance, Lakehouse met automatiquement en cache les blocs de données récupérés localement dans Google Cloud. La mise en cache est automatiquement activée pour toutes les requêtes multicloud afin de réduire les frais de sortie des fournisseurs de cloud à distance. Les requêtes suivantes ciblant les données mises en cache sont lues directement à partir du stockage Google Cloud local au lieu de récupérer les données dans les clouds.

Économies sur les coûts de sortie

Lors de l'exécution initiale de la requête, Lakehouse récupère les blocs de données requis auprès du fournisseur de cloud à distance et remplit le cache local. Les requêtes suivantes ciblant les mêmes blocs de données sont lues directement à partir du cacheGoogle Cloud local au lieu de récupérer à nouveau les données dans les différents clouds.

Pour les charges de travail avec des modèles de requêtes répétés sur le même ensemble de données, la mise en cache réduit les frais de sortie cross-cloud en traitant les demandes de données à partir du stockage local. Les économies réelles sur les coûts de sortie dépendent de facteurs tels que les modèles d'accès aux requêtes, les taux de modification des données et la durée de conservation du cache dans la région Google Cloudcible.

Vérifier l'utilisation du cache et les économies de coûts de sortie dans les statistiques des jobs

Pour vérifier les taux de succès de cache (hit) et les économies de coûts de sortie pour une requête, inspectez les statistiques de la requête dans la console ou l'API BigQuery (JobStatistics2). Étant donné qu'une requête peut référencer des données provenant de plusieurs fournisseurs de services cloud, les statistiques du job fournissent un champ object_storage_stats (objectStorageStats) répété avec une entrée pour chaque fournisseur de services cloud consulté lors de l'exécution.

Chaque entrée object_storage_stats indique les métriques suivantes :

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

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

Lorsque vous créez un catalogue ou une connexion fédérés dans une région Google Cloud , les données mises en cache au repos sont stockées localement dans cette région cible.

Si vos données cloud à distance résident dans une région géographique ou une juridiction différente (par exemple, AWS Amazon S3 dans l'Union européenne associé au calcul BigQuery dans us-east4), l'interrogation multicloud stocke des copies mises en cache des données à distance au repos dans la régionGoogle Cloud cible. L'utilisateur ou l'administrateur qui crée la connexion ou le catalogue doit s'assurer que la mise en cache transjuridictionnelle est conforme aux exigences de son organisation en matière de résidence des données, de souveraineté et de conformité.

Chiffrement et compatibilité avec les CMEK

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

Si votre organisation applique la contrainte de règle d'administration Restreindre les services non-CMEK (constraints/gcp.restrictNonCmekServices), Lakehouse désactive automatiquement la mise en cache des requêtes qui accèdent à des tables restreintes. Les requêtes s'exécutent toujours correctement, mais elles ne mettent pas en cache les blocs de données ni ne bénéficient d'économies sur le trafic sortant liées au cache.

Étapes suivantes