Interroger des données à distance

Dans un lakehouse sans frontières, une connexion cross-cloud vous permet d'accéder à des données distantes à partir de plates-formes externes sans déplacer de fichiers entre les environnements cloud. Vous pouvez ensuite interroger vos tables fédérées à partir de BigQuery, de Managed Service pour Apache Spark ou d'Apache Spark Open Source.

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 ancrés dans vos sources de données, y compris des tables fédérées, pour analyser des données sur plusieurs clouds à partir d'une seule conversation.
  • Knowledge Catalog : profilez les données et générez des insights sur vos sources de données fédérées.

Pour une analyse plus approfondie, vous pouvez créer des agents d'analyse conversationnelle qui utilisent des projets, des ensembles de données, des tables, des vues, des graphiques et des fonctions définies par l'utilisateur. Ces agents fonctionnent sur les tables BigQuery standards, les tables Apache Iceberg gérées par Lakehouse et les sources Lakehouse telles que Databricks Unity Catalog, AWS Glue, SAP BDC et Salesforce.

Avant de commencer

Avant de pouvoir interroger vos données, vous devez effectuer les opérations suivantes :

  1. Assurez-vous que votre catalogue distant contient des données.
  2. Configurez une connexion cross-cloud pour AWS Glue, Databricks Unity Catalog, Snowflake Horizon Catalog, Workday Data Lake ou SAP Business Data Cloud.

Rôles requis

Pour obtenir les autorisations nécessaires pour interroger des données fédérées, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Interroger les données

Une fois la fédération configurée, vous pouvez interroger vos données distantes à l'aide du SQL standard dans BigQuery ou d'Apache Spark dans Managed Service pour Apache Spark.

Lakehouse gère la traduction des métadonnées et l'accès sécurisé aux données, ce qui vous permet de traiter les tables Apache Iceberg distantes comme si elles étaient locales dans votre environnement Google Cloud .

Requête depuis BigQuery

Pour interroger des tables Apache Iceberg fédérées, utilisez le langage SQL BigQuery standard. Le chemin d'accès à la table suit une structure en quatre parties : project.federated_catalog.namespace.table. La mise en cache, la distribution des identifiants et le routage de transit CCI sont gérés automatiquement.

SELECT
  user_id,
  action,
  COUNT(*) as total_actions
FROM `PROJECT_ID.FEDERATED_CATALOG_NAME.NAMESPACE_NAME.TABLE_NAME`
WHERE event_date >= '2026-04-01'
GROUP BY 1, 2;

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre projet Google Cloud .
  • FEDERATED_CATALOG_NAME : nom du catalogue fédéré.
  • NAMESPACE_NAME : espace de noms dans le catalogue.
  • TABLE_NAME : nom de la table
  • REGION : région Google Cloud . Par exemple, us-east4.

Vous pouvez également exécuter la requête à l'aide de l'outil de ligne de commande bq :

bq --location="REGION" --project_id="PROJECT_ID" query --use_legacy_sql=false \
  "SELECT * FROM \`PROJECT_ID.FEDERATED_CATALOG_NAME.NAMESPACE_NAME.TABLE_NAME\` LIMIT 10"

Requête depuis Managed Service pour Apache Spark

Envoyez une charge de travail par lot PySpark à Managed Service pour Apache Spark avec la distribution d'identifiants activée à l'aide de X-Iceberg-Access-Delegation=vended-credentials. Spark utilisera les identifiants éphémères à champ d'application limité pour se connecter à S3 de manière sécurisée, sans avoir à gérer des identifiants AWS ou des connecteurs S3 distincts.

  1. Activez la connectivité sortante pour Managed Service pour Apache Spark.

    Managed Service pour Apache Spark ne peut pas se connecter à AWS S3 avec sa configuration réseau par défaut. Vous devez provisionner un routeur Cloud Router et Cloud NAT.

    gcloud compute routers create lakehouse-router \
  --network=NETWORK_NAME \
  --region=REGION

gcloud compute routers nats create lakehouse-nat \
  --router=lakehouse-router \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges \
  --region=REGION

    Remplacez les éléments suivants :

    • NETWORK_NAME : réseau de la charge de travail par lot Managed Service pour Apache Spark (par exemple, default).
    • REGION : région de la charge de travail par lot Managed Service pour Apache Spark.

  2. Créer un fichier d'application PySpark et exécuter le job PySpark

    from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("CATALOG_NAME").getOrCreate()

df = spark.table("CATALOG_NAME.NAMESPACE_NAME.TABLE_NAME")
df.show(10, truncate=False)

    Importez-le dans Cloud Storage à l'emplacement PYSPARK_FILE.

    gcloud dataproc batches submit pyspark PYSPARK_FILE \
    --project=PROJECT_ID \
    --region=REGION \
    --version=RUNTIME_VERSION \
    --properties="\
    spark.sql.defaultCatalog=CATALOG_NAME,\
    spark.sql.catalog.CATALOG_NAME=org.apache.iceberg.spark.SparkCatalog,\
    spark.sql.catalog.CATALOG_NAME.type=rest,\
    spark.sql.catalog.CATALOG_NAME.uri=https://biglake.googleapis.com/iceberg/v1/restcatalog,\
    spark.sql.catalog.CATALOG_NAME.warehouse=bl://projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME,\
    spark.sql.catalog.CATALOG_NAME.header.x-goog-user-project=PROJECT_ID,\
    spark.sql.catalog.CATALOG_NAME.rest.auth.type=org.apache.iceberg.gcp.auth.GoogleAuthManager,\
    spark.sql.catalog.CATALOG_NAME.io-impl=IO_IMPL,\
    spark.sql.catalog.CATALOG_NAME.header.X-Iceberg-Access-Delegation=vended-credentials,\
    spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"

    Remplacez les éléments suivants :

    • NAMESPACE_NAME : espace de noms dans le catalogue fédéré.
    • TABLE_NAME : nom de la table dans le catalogue fédéré.
    • CATALOG_NAME : nom du catalogue Spark local (par exemple, my_catalog).
    • PYSPARK_FILE : chemin d'accès Cloud Storage gs:// vers le fichier de votre application PySpark.
    • REGION : région de la charge de travail par lot Managed Service pour Apache Spark.
    • RUNTIME_VERSION : version d'exécution de Managed Service pour Apache Spark, par exemple 2.3.
    • PROJECT_ID : projet facturé pour l'utilisation du point de terminaison du catalogue REST Apache Iceberg.
    • FEDERATED_CATALOG_NAME : nom du catalogue fédéré.
    • IO_IMPL : implémentation FileIO correspondant à votre stockage sous-jacent.

    Paramètres de configuration Spark

    Le tableau suivant liste les paramètres courants requis pour toutes les connexions :

    Paramètre Description
    spark.sql.defaultCatalog Nom du catalogue par défaut (par exemple, CATALOG_NAME).
    spark.sql.catalog.CATALOG_NAME Classe d'implémentation du catalogue. Variable définie sur org.apache.iceberg.spark.SparkCatalog.
    spark.sql.catalog.CATALOG_NAME.type Type de backend du catalogue. Définissez cette option sur rest pour le catalogue REST Iceberg.
    spark.sql.catalog.CATALOG_NAME.uri URI du point de terminaison du catalogue REST. Variable définie sur https://biglake.googleapis.com/iceberg/v1/restcatalog.
    spark.sql.catalog.CATALOG_NAME.warehouse Chemin d'accès à l'emplacement de l'entrepôt pour le catalogue fédéré. Variable définie sur bl://projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME.
    spark.sql.catalog.CATALOG_NAME.header.x-goog-user-project ID du projet Google Cloud utilisé pour l'attribution de la facturation et des quotas. Variable définie sur PROJECT_ID.
    spark.sql.extensions Extensions de session Spark pour la syntaxe et les fonctionnalités Iceberg SQL. Variable définie sur org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions.

    Le tableau suivant liste les paramètres d'authentification :

    Paramètre Description
    spark.sql.catalog.CATALOG_NAME.rest.auth.type Classe du gestionnaire d'authentification personnalisée. Définissez cette option sur org.apache.iceberg.gcp.auth.GoogleAuthManager pour l'authentification du flux OAuth.
    spark.sql.catalog.CATALOG_NAME.oauth2-server-uri URI du point de terminaison du serveur de jetons OAuth2. Définissez cette option sur https://oauth2.googleapis.com/token pour l'authentification par jeton d'accès personnel (PAT).
    spark.sql.catalog.CATALOG_NAME.token Jeton de support ou jeton d'accès personnel (PAT). Généralement défini sur $(gcloud auth application-default print-access-token) pour l'authentification PAT.

    Le tableau suivant liste les paramètres uniques en fonction de votre fournisseur de stockage (IO_IMPL) :

    Stockage spark.sql.catalog.CATALOG_NAME.io-impl Remarques
    Amazon S3 org.apache.iceberg.aws.s3.S3FileIO Nécessite la distribution d'identifiants (X-Iceberg-Access-Delegation=vended-credentials) si elle est activée.
    Paramètre supplémentaire : spark.sql.catalog.CATALOG_NAME.s3.region (pour obtenir la liste des régions, consultez Points de terminaison et quotas Amazon S3).
    Google Cloud Storage org.apache.iceberg.gcp.gcs.GCSFileIO Paramètre supplémentaire : spark.sql.catalog.CATALOG_NAME.gcs.oauth2.refresh-credentials-endpoint=https://oauth2.googleapis.com/token.
    Azure Blob Storage org.apache.iceberg.azure.adlsv2.ADLSFileIO Aucun paramètre de stockage supplémentaire n'est requis.

    Pour Snowflake, vous pouvez rencontrer des problèmes lors de l'interrogation des colonnes STRING, car elles sont automatiquement optimisées pour le stockage. Vous pouvez résoudre ce problème de deux manières :

    • Option 1 : Désactiver la vectorisation dans Spark : ajoutez les propriétés de configuration Spark suivantes à l'option --properties :
    • spark.sql.iceberg.vectorization.enabled=false

    • spark.sql.catalog.CATALOG_NAME.table-override.read.parquet.vectorization.enabled=false

    • Option 2 : Modifier la règle de sérialisation dans Snowflake : remplacez la règle de sérialisation du stockage par COMPATIBLE pour la table dans Snowflake.

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

La mise en cache Lakehouse est activée automatiquement pour toutes les requêtes cross-cloud. Lorsqu'une requête est exécutée, Lakehouse met automatiquement en cache les blocs de données localement dans le stockage Google Cloud . Les requêtes ultérieures ciblant les mêmes blocs de données sont lues directement à partir du cache local au lieu de récupérer à nouveau les données à partir du cloud distant.

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 récupérez les statistiques du job de requête (JobStatistics2) à l'aide de l'API BigQuery ou de la CLI bq :

bq show --format=prettyjson --j JOB_ID

Dans la sortie JSON sous statistics.query.objectStorageStats (ou object_storage_stats dans l'API proto), les statistiques du job renvoient une liste avec une entrée pour chaque fournisseur de services cloud auquel il a été accédé pendant l'exécution. Chaque entrée contient les champs suivants :

  • cloudProvider (cloud_provider) : fournisseur de services cloud distant hébergeant 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 de l'espace de stockage d'objets distant.
  • objectStorageBytesRead (object_storage_bytes_read) : nombre total d'octets lus directement à partir du store d'objets du fournisseur de services cloud distant.

Pour en savoir plus sur les concepts de mise en cache et les considérations liées à la résidence des données, consultez Mise en cache intelligente.

Étapes suivantes