À propos de Lakehouse sans bordure

Borderless Lakehouse vous permet d'interroger des données stockées chez d'autres fournisseurs cloud directement depuissans avoir à migrer des fichiers ni à créer des pipelines ETL complexes. Google Cloud

Dans le cadre de Lakehouse pour Apache Iceberg, 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 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 multicloud, pour analyser les données dans les clouds à partir d'une seule conversation.
  • Knowledge Catalog : utilisez les fonctionnalités de Knowledge Catalog pour le profilage et les insights des données avec des sources de données fédérées.

Cas d'utilisation

Borderless Lakehouse prend en charge plusieurs cas d'utilisation clés pour accéder aux données de plusieurs fournisseurs cloud :

  • La réduction du déplacement des 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, quel que soit leur emplacement.
  • 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 distantes sans les migrer.

Fonctionnement de Borderless Lakehouse

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

  1. Découverte des métadonnées Google Cloud's Lakehouse se connecte à des catalogues REST Apache Iceberg distants, tels que Databricks Unity ou AWS Glue. 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, une interconnexion CCI dédiée ou une 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 localement dans Google Cloud sur un stockage spécialisé. Les requêtes suivantes utilisent le cache local, ce qui évite une partie importante des frais de sortie multicloud.

Catalogues compatibles

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

  • Databricks Unity Catalog : compatible avec Amazon Web Services (AWS) et Google Cloud.
  • AWS Glue : compatible avec Amazon Web Services (AWS).
  • Snowflake : compatible avec Amazon Web Services (AWS) et Google Cloud.
  • SAP Business Data Cloud (BDC) : compatible avec le connecteur SAP BDC.

Concepts fondamentaux

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

Catalogues REST Apache Iceberg distants

Il s'agit de la couche de métadonnées. Vous vous connectez à des catalogues REST Apache Iceberg distants. 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.

Les catalogues fédérés de Borderless Lakehouse synchronisent les métadonnées des catalogues REST Apache Iceberg distants en fonction d'un intervalle d'actualisation. L'actualisation des métadonnées en arrière-plan d'un catalogue peut prendre plus de temps en fonction du nombre de ressources d'espace de noms et de tables. Si l'actualisation précédente dépasse le délai imparti, l'actualisation en cours est ignorée, mais la prochaine actualisation est programmée à l'intervalle suivant.

Couche transport

Il s'agit de la couche de transport. Vous pouvez configurer Lakehouse pour interroger les données stockées chez des fournisseurs cloud distants via l'Internet public ou une interconnexion privée dédiée. Cette section ne s'applique pas aux connexions SAP Business Data Cloud (BDC).

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 les buckets Amazon S3 d'Amazon Web Services (AWS) via une interconnexion privée Cross-Cloud Interconnect à 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 : frais de sortie potentiellement inférieurs depuis AWS par rapport à 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 par rapport à l'Internet public.

Présentation de l'architecture

Pour activer les requêtes privées, configurez un chemin d'accès de BigQuery à votre bucket AWS Amazon S3 via votre interconnexion privée. Un composant clé du Google Cloud cloud privé virtuel (VPC) est un équilibreur de charge interne (ILB). L'ILB 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 ILB avec plusieurs interfaces réseau Elastic (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 le processus suivant :

  1. BigQuery utilise une connexion configurée avec un service Annuaire des services.
  2. Annuaire des services résout le nom de service en adresse IP interne de l' Google Cloud ILB.
  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 de connectivité hybride (NEG), chacun pointant vers l'adresse IP privée d'une ENI dans votre VPC AWS.
  5. Le trafic transite de l'ILB, via les NEG, via l'interconnexion privée, vers les ENI AWS.
  6. Les ENI AWS, qui font partie d'un point de terminaison d'interface VPC Amazon S3 (AWS PrivateLink), fournissent un accès privé au service Amazon S3.

Internet public (sans 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 requêtes d'accès aux données et les transferts de données sont chiffrés en transit à l'aide de 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 cloud distant (par exemple, AWS), qui sont généralement plus élevés que les tarifs de sortie d'interconnexion privée.
  • Latence variable : les performances du réseau, la bande passante et la latence dépendent du routage et de la congestion de l'Internet public, ce qui entraîne des temps d'exécution des requêtes moins prévisibles que ceux d'une interconnexion privée dédiée.
  • Configuration simplifiée : ne nécessite aucune infrastructure réseau supplémentaire, aucun appairage de VPC ni aucune configuration de l'Annuaire des services dans Google Cloud ou votre fournisseur cloud distant.

Présentation de l'architecture

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

Le workflow de requête 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 de la table et les fichiers manifestes sur l'Internet public pour identifier les fichiers de données sous-jacents pertinents (par exemple, dans AWS Amazon S3).
  4. Les requêtes d'accès aux données pour les objets sous-jacents sont envoyées directement depuissur l'Internet public à l'aide du chiffrement TLS standard.Google Cloud
  5. Le service de stockage distant 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.

Étape suivante