À propos du lakehouse multicloud

Cross-cloud Lakehouse pour Apache Iceberg vous permet d'interroger les données stockées chez d'autres fournisseurs de cloud directement depuis Google Cloud sans avoir à migrer des fichiers ni à créer des pipelines ETL complexes.

Dans Lakehouse, 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.

Cas d'utilisation

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

  • La réduction des transferts 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 cohérentes et une optimisation matérielle sur toutes vos données, où qu'elles se trouvent.
  • L'IA et le ML multicloud vous permettent d'appliquer des modèles d'IA, des agents autonomes et le machine learning directement à vos données à distance, sans avoir à les migrer.

Fonctionnement du lakehouse multicloud

Les requêtes Lakehouse inter-cloud 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. Lakehouse découvre les données sans copier de fichiers. Selon le fournisseur de catalogue à distance, 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, une interconnexion dédiée 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, le 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 de données multicloud.

Catalogues compatibles

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

  • Databricks Unity Catalog : compatible avec Amazon Web Services (AWS) etGoogle Cloud.
  • AWS Glue : compatible avec Amazon Web Services (AWS).

Concepts fondamentaux

Cette section décrit les composants clés essentiels à l'utilisation de Lakehouse cross-cloud.

Catalogues REST Apache Iceberg à distance

Il s'agit de la couche de métadonnées. Vous vous connectez à des catalogues Apache Iceberg REST distants. Le lakehouse découvre les données sans copier de fichiers. Grâce à la fédération de jetons OIDC ou aux identifiants OAuth, Lakehouse s'authentifie de manière sécurisée sans nécessiter de clés d'accès à longue durée de vie.

Couche transport

Il s'agit de la couche de transport. Vous pouvez configurer Lakehouse pour interroger les données stockées chez des fournisseurs de cloud distants via 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 des buckets Amazon S3 Amazon Web Services (AWS) via une connexion réseau privée et dédiée à l'aide de Cross-Cloud Interconnect ou de Partner Interconnect.

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, 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 à la capacité de votre interconnexion privée.
  • Performances cohérentes : latence et bande passante du 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'ILB distribue les requêtes de BigQuery aux points de terminaison privés pour 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 une interconnexion CCI dédiée ou interconnexion partenaire.

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

  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'équilibreur de charge interne 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), offrent un accès privé 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 défaut sur 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 votre fournisseur de cloud à distance (AWS, par exemple), 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 que ceux d'une interconnexion privée dédiée.
  • Configuration simplifiée : ne nécessite aucune infrastructure réseau, aucun appairage de VPC ni aucune configuration d'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 le processus suivant :

  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 valide 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.

Étapes suivantes