A partir del 20 de abril de 2026, BigLake se llama Lakehouse. El metastore de BigLake ahora se llama catálogo de entorno de ejecución de Lakehouse. Los nombres de IAM, los comandos de la CLI, las bibliotecas cliente y las APIs de Lakehouse no cambian y siguen haciendo referencia a BigLake.

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Configura la conexión entre nubes para el catálogo de Snowflake Horizon

Una conexión multinube a un catálogo de Snowflake Horizon en Amazon Web Services (AWS), Microsoft Azure o Google Cloud te permite consultar datos de ese catálogo directamente en Google Cloud. Esta función unifica tu análisis de datos integrando tus fuentes de datos externas con tu entorno deGoogle Cloud existente.

Después de configurar la conexión, puedes administrar el acceso a tus datos federados en Lakehouse sin límites.

Antes de comenzar

Revisa la descripción general de Lakehouse para comprender cómo Lakehouse administra el acceso a los datos.
Lee Acerca del acceso a los datos multinube para comprender cómo funciona.
Revisa los catálogos compatibles para verificar las configuraciones compatibles.
Comprender cómo usar los secrets regionales de Secret Manager. Esto es obligatorio para configurar Lakehouse con el catálogo de Snowflake Horizon con la autenticación basada en secretos.
Opcional: Si planeas enrutar lecturas de consultas o actualizaciones de metadatos en segundo plano a través de una interconexión privada entre tu red de nube privada virtual (VPC) de Google Cloud y tu red de nube remota (VPC de AWS o VNet de Azure), verifica que tengas una cuenta activa con tu proveedor remoto, aprovisiona una Cross-Cloud Interconnect dedicada o una Cross-Cloud Interconnect para socios, establece sesiones de BGP con tu Cloud Router y verifica que tengas los permisos de Identity and Access Management (IAM) necesarios en ambos entornos de nube.

Accede a tu cuenta de Google Cloud . Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake, Secret Manager APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake, Secret Manager APIs, if any are not already enabled.

Roles required to enable APIs

Enable the APIs

Roles obligatorios

Para obtener los permisos que necesitas para configurar el acceso multinube, pídele a tu administrador que te otorgue los siguientes roles de IAM en tu proyecto:

Administra catálogos de Lakehouse: Administrador de BigLake (roles/biglake.admin)
Administra secretos (si usas la autenticación basada en secretos): Administrador de Secret Manager (roles/secretmanager.admin)
Enruta el tráfico a través de la interconexión privada (usuario): Administrador de redes de Compute (roles/compute.networkAdmin)
Enruta el tráfico a través de la interconexión privada (cuenta de servicio del catálogo):
- Visualizador del Directorio de servicios (roles/servicedirectory.viewer)
- Servicio autorizado de PSC del Directorio de servicios (roles/servicedirectory.pscAuthorizedService)

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios a través de roles personalizados o cualquier otro rol predefinido.

Limitaciones y consideraciones

En esta sección, se enumeran las limitaciones y consideraciones para acceder a los datos multinube.

Controles del servicio de VPC: Si el proyecto que contiene tu extremo de catálogo federado o el bucket de Cloud Storage subyacente está dentro de un perímetro de servicio de los Controles del servicio de VPC, debes configurar reglas de entrada o salida. Para obtener más información, consulta Usa los Controles del servicio de VPC con extremos de catálogo federados.
Proveedores de servicios en la nube compatibles con Cross‑Cloud Interconnect: El uso de una interconexión privada para enrutar el transporte de consultas, la actualización de metadatos en segundo plano o ambos es compatible con AWS y Azure. Puedes usar Cross-Cloud Interconnect dedicado (para AWS o Azure) o Cross-Cloud Interconnect para socios.
Enrutamiento de red: Si no configuras una interconexión privada para el transporte de consultas o la actualización de metadatos en segundo plano, el tráfico correspondiente se enruta a través de la Internet pública con TLS. Enrutar las lecturas de consultas a través de la Internet pública puede generar tarifas de salida más altas de tu proveedor de servicios en la nube remoto y un rendimiento menos predecible.
Tablas compatibles con el catálogo de Snowflake Horizon: Solo las tablas de Apache Iceberg del catálogo de Snowflake Horizon se sincronizan con Lakehouse. Las tablas de Snowflake que no son de Iceberg se ignoran durante la actualización de metadatos en segundo plano.
Política de red y direcciones IP de salida: Cuando la actualización de metadatos en segundo plano se conecta a través de la Internet pública, Lakehouse usa las direcciones IP de salida de la infraestructura global de Google para llegar a tu extremo de Snowflake con acceso a Internet. Si configuras una política de red de Snowflake para el acceso a Internet público, agrega los rangos de direcciones IP de salida de Google de goog.json a la lista de IP permitidas de tu política de red. Cuando configuras la actualización privada de metadatos en segundo plano a través de Cross‑Cloud Interconnect, las solicitudes de metadatos se enrutan de forma privada a través de tu red de VPC hasta tu extremo de PrivateLink de Snowflake.
Solo lectura: Los catálogos federados en Lakehouse son vistas de solo lectura del catálogo remoto. No se admite la manipulación de recursos (como la creación, la actualización o la eliminación de recursos) y se debe realizar directamente en el catálogo remoto.
Actualidad de los datos: La marca --refresh-interval de un catálogo federado determina la frecuencia con la que se sincronizan los metadatos. El valor debe ser 0s (inhabilitado) o, al menos, 300s (5 minutos). La actualización de metadatos en segundo plano de un catálogo puede tardar más tiempo según la cantidad de recursos de espacio de nombres y tablas que haya. Si la actualización anterior se excede, se omite la actualización actual y la siguiente se programa para el intervalo posterior. Las consultas usan los metadatos del catálogo sincronizados más recientemente, por lo que los cambios realizados en el catálogo remoto, como tablas nuevas, actualizaciones de esquemas o datos confirmados recientemente, no son visibles en Lakehouse hasta que se complete la siguiente actualización de metadatos en segundo plano.
Almacenamiento en caché de Lakehouse: El almacenamiento en caché multinube está inhabilitado de forma predeterminada (--cross-cloud-cache=disabled). Puedes habilitar o inhabilitar el almacenamiento en caché a nivel de conexión o de catálogo federado. Las claves de encriptación administradas por el cliente (CMEK) no se admiten para el almacenamiento en caché; los archivos almacenados en caché se encriptan con Google-owned and Google-managed encryption keys. Si la restricción de la política de la organización constraints/gcp.restrictNonCmekServices se aplica a una tabla de la consulta, el almacenamiento en caché se inhabilita automáticamente para esa consulta. Para obtener más información, consulta Almacenamiento en caché inteligente.
Residencia de datos y cumplimiento: Cuando habilitas el almacenamiento en caché multinube en un catálogo o una conexión federados, Lakehouse almacena temporalmente los archivos almacenados en caché en reposo en la región de Google Cloud en la que se ejecuta la consulta. Si tus archivos de nube remotos residen en una jurisdicción diferente, verifica que el almacenamiento en caché entre regiones cumpla con los requisitos de residencia de datos y cumplimiento de tu organización antes de habilitarlo.

Flujo de trabajo general

Para acceder a los datos multinube, sigue estos pasos generales:

Configura Cross-Cloud Interconnect (opcional): Configura una conexión privada entre tu red de VPC de Google Cloud y tu proveedor de servicios en la nube remoto.
Configura la federación: Configura la autenticación y crea un catálogo federado en Lakehouse.
- Autenticación basada en secretos (PAT): Crea un secreto en Secret Manager con tus credenciales de catálogo remoto. Luego, crea un catálogo federado en Lakehouse y otorga a la cuenta de servicio del catálogo acceso al secreto.
- Federación de identidades para cargas de trabajo (WIF): Crea un catálogo federado en Lakehouse especificando el rol de Snowflake requerido. Luego, vincula el ID de la cuenta de servicio del catálogo a un usuario de servicio en Snowflake. El usuario del servicio de Snowflake debe tener permisos de uso en el catálogo remoto de Snowflake Horizon.
Verifica la conexión: Verifica que Lakehouse pueda conectarse a tu catálogo remoto.
Consulta datos: Ejecuta consultas en tus datos federados con BigQuery o Managed Service para Apache Spark. De manera opcional, puedes habilitar el almacenamiento en caché multinube en el catálogo federado para ayudar a reducir los costos de salida multinube y acelerar las consultas posteriores. Para obtener más información, consulta Consulta datos remotos.
Configura los permisos: Usa IAM para administrar quién puede ver y consultar los datos federados.

Configura Cross‑Cloud Interconnect (opcional)

De forma predeterminada, tanto las lecturas de datos de consultas como la actualización de metadatos en segundo plano se realizan a través de la Internet pública con TLS. Para mejorar el aislamiento de la red, proporcionar una latencia predecible y reducir los costos de transferencia de datos, puedes configurar una interconexión privada entre tu red de VPC de Google Cloud y tu red de nube remota (VPC de AWS o red virtual de Azure [VNet]).

Puedes aprovisionar cualquiera de las siguientes opciones de interconexión privada:

Cross-Cloud Interconnect dedicada: Es una conexión física dedicada a AWS o Azure.
Cross-Cloud Interconnect para socios: Es una conexión a AWS a través de un proveedor de servicios compatible.

Establece sesiones de BGP entre tu Cloud Router en Google Cloud y tu red de nube remota para habilitar el intercambio de rutas.

Puedes configurar el enrutamiento privado a través de Cross‑Cloud Interconnect para una o ambas de las siguientes rutas de tráfico, según tus requisitos de seguridad y costo:

Transporte de consultas (--service-directory-name): Enruta las lecturas de consultas desde BigQuery o motores de código abierto a tu almacenamiento de objetos remoto (Amazon S3 o Azure Data Lake Storage Gen2 [ADLS Gen2]) para ayudar a reducir las tarifas de salida multinube y mantener predecible la latencia de las consultas.
Actualización de metadatos en segundo plano (--metadata-service-directory-name): Enruta las solicitudes de autenticación y actualización de metadatos en segundo plano del plano de control desde el catálogo de tiempo de ejecución de Lakehouse hasta tu extremo privado remoto de Snowflake Horizon Catalog, por ejemplo, cuando tu catálogo remoto restringe el acceso público a Internet.

Si enrutas el transporte de consultas y la actualización de metadatos en segundo plano a través de Cross‑Cloud Interconnect, completa los pasos del extremo privado, el enrutamiento y el servicio del Directorio de servicios una vez para el extremo de almacenamiento remoto y otra para el extremo del catálogo remoto. Ambos servicios del Directorio de servicios deben residir en la misma región de Google Cloud que tu catálogo federado y pueden compartir la misma subred de solo proxy y el espacio de nombres del Directorio de servicios.

Puedes usar cualquiera de los dos flujos de arquitectura para enrutar el tráfico desde el Directorio de servicios hasta tus extremos privados remotos:

Enrutamiento del balanceador de cargas de red de proxy regional interno: Usa un balanceador de cargas de red de proxy regional interno de Google Cloudpara distribuir las solicitudes entre los grupos de extremos de red (NEG) de conectividad híbrida que apuntan a tus direcciones IP de extremos privados remotos (interfaces de red elásticas (ENI) de AWS o interfaces de red (NIC) de extremos privados de Azure). Este flujo es obligatorio para Cross‑Cloud Interconnect para socios y se recomienda para Cross‑Cloud Interconnect dedicado para el balanceo de cargas, la escalabilidad y la alta disponibilidad.
Enrutamiento directo de extremos: Conecta el Directorio de servicios directamente a una sola dirección IP de extremo privado remoto. Este flujo solo funciona con Cross‑Cloud Interconnect dedicada y no es compatible con Cross‑Cloud Interconnect para socios.

Selecciona el flujo de configuración que coincida con tus requisitos de arquitectura:

Balanceador de cargas de red del proxy interno regional

Para configurar un balanceador de cargas de red del proxy regional interno que distribuya las solicitudes entre las direcciones IP de tus extremos privados remotos, sigue estos pasos:

Configura extremos privados de nube remota

Crea extremos privados en la red remota y las subredes que se conectan a tu red de VPC de Google Cloud a través de Cross‑Cloud Interconnect y toma nota de las direcciones IP privadas asignadas a cada extremo:

Para el transporte de consultas privadas (almacén de objetos remoto): En AWS, crea un extremo de VPC de interfaz para Amazon S3 (com.amazonaws.AWS_REGION.s3) en tu VPC de AWS y anota las direcciones IP privadas de ENI. En Azure, crea un extremo privado de Azure para Azure Storage que se oriente a tu cuenta de almacenamiento de ADLS Gen2 (dfs o blob) en tu VNet de Azure y anota la dirección IP privada de la NIC.
Para la actualización de metadatos en segundo plano privada (catálogo remoto): En Snowflake, ejecuta SELECT SYSTEM$GET_PRIVATELINK_CONFIG(); para obtener el identificador de servicio de PrivateLink y el identificador de cuenta de .privatelink. En AWS, sigue AWS PrivateLink y Snowflake para crear un extremo de VPC de interfaz en tu VPC de AWS y anota las direcciones IP privadas de ENI. En Azure, sigue Azure Private Link y Snowflake para crear un extremo privado de Azure en tu VNet de Azure y toma nota de la dirección IP privada de la NIC.
Reglas de seguridad de entrada: Verifica que los grupos de seguridad de AWS o los grupos de seguridad de red (NSG) de Azure conectados a tus extremos privados permitan el tráfico de TCP entrante en el puerto 443 (y el puerto 80 si tu configuración de Snowflake usa OCSP) desde tus rangos de CIDR de VPC de Google Cloud . Incluye el rango CIDR de tu subred de solo proxy de Google Cloud para permitir las verificaciones de estado y el tráfico reenviado.

Configura las redes de Google Cloud

Ejecuta los siguientes comandos para configurar el balanceador de cargas interno. Si enrutas el transporte de consultas y la actualización de metadatos en segundo plano a través de Cross‑Cloud Interconnect, configura un servicio de backend, un proxy TCP de destino y una regla de reenvío independientes para tu extremo de almacenamiento y tu extremo de catálogo. Para obtener información sobre las opciones de configuración avanzadas, consulta Configura un balanceador de cargas de red de proxy interno regional para extremos híbridos.

gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK \
    --range=PROXY_SUBNET_RANGE

Reemplaza lo siguiente:

PROXY_SUBNET_NAME: Es un nombre para la subred de solo proxy.
PROXY_SUBNET_RANGE: Es un rango CIDR sin usar dentro de tu red de VPC (por ejemplo, 10.129.0.0/23).

Crea una verificación de estado de TCP regional:
```
gcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --region=REGION \
    --port=443
```
Reemplaza lo siguiente:
- HEALTH_CHECK_NAME: Es un nombre para la verificación de estado.
- REGION: la región de Google Cloud (por ejemplo, us-east4).
Crea grupos de extremos de red (NEG) de conectividad híbrida y agrega extremos:

Crea un NEG híbrido (NON_GCP_PRIVATE_IP_PORT) para cada zona:
```
gcloud compute network-endpoint-groups create NEG_NAME \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=ZONE \
    --network=VPC_NETWORK
```
Agrega la dirección IP privada de la ENI o NIC de tu extremo remoto al NEG híbrido:
```
gcloud compute network-endpoint-groups update NEG_NAME \
    --zone=ZONE \
    --add-endpoint="ip=REMOTE_ENDPOINT_IP,port=443"
```
Reemplaza lo siguiente:
- NEG_NAME: Es un nombre para el NEG híbrido.
- ZONE: Es la zona de Google Cloud (por ejemplo, us-east4-a). Esta zona debe residir dentro de la región de tu adjunto de VLAN de Cross‑Cloud Interconnect.
- VPC_NETWORK: Es el nombre de tu red de VPC.
- REMOTE_ENDPOINT_IP: Es la dirección IP privada del extremo privado de tu almacenamiento remoto o catálogo remoto en esa zona.
Si tu extremo remoto tiene varias direcciones IP privadas distribuidas en las zonas, repite estos comandos para crear NEG híbridos y agregar extremos para cada zona.
Crea y configura el servicio de backend:

Crea un servicio de backend regional con balanceo de cargas administrado interno:
```
gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=TCP \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
Agrega tus NEG híbridos al servicio de backend:
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --region=REGION \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=ZONE \
    --balancing-mode=CONNECTION \
    --max-connections=MAX_CONNECTIONS
```
Reemplaza lo siguiente:
- BACKEND_SERVICE_NAME: un nombre para el servicio de backend.
- NEG_NAME: Es el nombre del NEG híbrido que creaste en el paso anterior.
- ZONE: la zona de Google Cloud (por ejemplo, us-east4-a).
- MAX_CONNECTIONS: Es la cantidad máxima de conexiones simultáneas para el backend (por ejemplo, 100).
Repite el comando add-backend para cada NEG híbrido que hayas creado.

Configura el frontend del balanceador de cargas:

Crea un proxy TCP de destino:

gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \
    --backend-service=BACKEND_SERVICE_NAME \
    --region=REGION

Crea una regla de reenvío para enrutar el tráfico al proxy de destino:

gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=VPC_NETWORK \
    --subnet=VPC_SUBNET \
    --ports=443 \
    --region=REGION \
    --target-tcp-proxy=TARGET_PROXY_NAME \
    --target-tcp-proxy-region=REGION \
    --allow-global-access

Reemplaza lo siguiente:

TARGET_PROXY_NAME: Es un nombre para el proxy de destino.
FORWARDING_RULE_NAME: un nombre para la regla de reenvío.
VPC_SUBNET: Es el nombre de tu subred de VPC.

Después de crear la regla de reenvío para el balanceador de cargas, toma nota de la dirección IP interna que se le asignó. Este es tu ILB_IP_ADDRESS.

Configura el Directorio de servicios

Registra la dirección IP del balanceador de cargas interno en el Directorio de servicios para que Lakehouse pueda descubrirla y enrutarla de forma privada. Si configuraste reglas de reenvío del balanceador de cargas independientes para el transporte de consultas y la actualización de metadatos en segundo plano, crea un servicio y un extremo del Directorio de servicios independientes para cada dirección IP de la regla de reenvío.

Crea un espacio de nombres para tus extremos privados remotos:
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Reemplaza lo siguiente:
- NAMESPACE: Es un identificador único para tu espacio de nombres.
- PROJECT_ID: Es el ID del proyecto de Google Cloud .
- REGION: Es la región de Google Cloud (por ejemplo, us-east4). Debe ser la misma región que la de tu catálogo federado.
Crea un servicio en el espacio de nombres del Directorio de servicios:
```
gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Reemplaza lo siguiente:
- SERVICE_NAME: Es un identificador único para tu servicio (crea un nombre de servicio independiente, como METADATA_SERVICE_NAME, cuando registres un extremo de actualización de metadatos en segundo plano).
Crea un extremo para la regla de reenvío del balanceador de cargas en el servicio:
```
gcloud service-directory endpoints create ENDPOINT_NAME \
    --project=PROJECT_ID \
    --namespace=NAMESPACE \
    --service=SERVICE_NAME \
    --location=REGION \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK \
    --address=ILB_IP_ADDRESS \
    --port=443
```
Reemplaza lo siguiente:
- ENDPOINT_NAME: Es un identificador único para tu extremo.
- PROJECT_NUMBER: Es el número del proyecto de Google Cloud. Usa tu número de proyecto en la marca --network.
- ILB_IP_ADDRESS: Es la dirección IP interna de la regla de reenvío del balanceador de cargas.

Extremo directo

Para configurar el Directorio de servicios de modo que enrute el tráfico directamente a una sola dirección IP de extremo privado remoto a través de Dedicated Cross‑Cloud Interconnect, sigue estos pasos:

Crea el extremo privado en tu red de nube remota:
- Para el transporte de consultas privadas: Crea un extremo de VPC de interfaz para Amazon S3 en tu VPC de AWS o un extremo privado de Azure para Azure Storage (dfs o blob) en tu VNet de Azure.
- Para la actualización privada de metadatos en segundo plano: Ejecuta SELECT SYSTEM$GET_PRIVATELINK_CONFIG(); en Snowflake y crea un extremo de VPC de interfaz siguiendo AWS PrivateLink y Snowflake o un extremo privado de Azure siguiendo Azure Private Link y Snowflake.
Toma nota de la dirección IP privada y el puerto (443) de cada extremo y verifica que tus grupos de seguridad de AWS o NSG de Azure permitan el tráfico TCP entrante en el puerto 443 desde tu red de VPC de Google Cloud .
Crea un espacio de nombres para tus extremos privados remotos:
```
gcloud service-directory namespaces create NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Reemplaza lo siguiente:
- NAMESPACE: Es un identificador único para tu espacio de nombres.
- PROJECT_ID: Es el ID del proyecto de Google Cloud .
- REGION: Es la región de Google Cloud (por ejemplo, us-east4). Debe ser la misma región que la de tu catálogo federado.
Crea un servicio en el espacio de nombres del Directorio de servicios (si enrutas el transporte de consultas y la actualización de metadatos en segundo plano de forma privada, crea un servicio independiente para cada extremo):
```
gcloud service-directory services create SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION
```
Reemplaza lo siguiente:
- SERVICE_NAME: Es un identificador único para tu servicio (crea un nombre de servicio independiente, como METADATA_SERVICE_NAME, cuando registres un extremo de actualización de metadatos en segundo plano).
Crea un extremo en el servicio con la dirección IP privada y el puerto de tu extremo privado remoto:
```
gcloud service-directory endpoints create ENDPOINT_NAME \
    --service=SERVICE_NAME \
    --namespace=NAMESPACE \
    --project=PROJECT_ID \
    --location=REGION \
    --address=REMOTE_ENDPOINT_IP \
    --port=REMOTE_ENDPOINT_PORT \
    --network=projects/PROJECT_NUMBER/global/networks/VPC_NETWORK
```
Reemplaza lo siguiente:
- ENDPOINT_NAME: Es un identificador único para tu extremo.
- REMOTE_ENDPOINT_IP: Es la dirección IP privada de tu extremo privado de almacenamiento remoto o catálogo remoto (por ejemplo, 10.0.1.45).
- REMOTE_ENDPOINT_PORT: Es el número de puerto de tu extremo privado remoto (por ejemplo, 443).
- PROJECT_NUMBER: Es el número del proyecto de Google Cloud. Usa tu número de proyecto en la marca --network.
- VPC_NETWORK: Es el nombre de la red de VPC de Google Cloud asociada con tu interconexión privada.

Configura la federación

Para consultar tus datos, debes configurar un catálogo federado de Lakehouse que se conecte a tu catálogo remoto de Snowflake Horizon.

Configura la autenticación

La federación requiere credenciales o configuración de roles para acceder al catálogo remoto de Snowflake Horizon. Elige uno de los siguientes métodos.

Basada en secretos (PAT)

Esta opción usa un token de acceso programático (PAT) almacenado de forma segura con secrets regionales de Secret Manager.

Genera un token de acceso programático (PAT) que tenga acceso de lectura al catálogo de destino.
Crea un archivo JSON llamado credentials.json con tu carga útil:
```
{
  "client_secret": "SNOWFLAKE_PAT_TOKEN",
  "scope": "session:role:SNOWFLAKE_ROLE"
}
```
Importante: Almacena esta estructura JSON en el Secret, no en la cadena sin procesar del token de acceso personal (PAT). Si almacenas el token sin procesar sin el wrapper JSON, la actualización de metadatos en segundo plano fallará con el código 16.

Reemplaza lo siguiente:
- SNOWFLAKE_PAT_TOKEN: Es tu token de acceso programático (PAT) de Snowflake.
- SNOWFLAKE_ROLE: Es el rol específico de Snowflake necesario para la sesión. Por ejemplo, ICEBERG_VIEW
Nota: El parámetro client_id no es obligatorio para las configuraciones del catálogo de Snowflake Horizon, ya que la autenticación se controla con el PAT y el permiso.
Configura el extremo regional para Secret Manager:

De forma predeterminada, Secret Manager usa un extremo global. Sin embargo, Lakehouse requiere que tus secretos se almacenen en la misma región que tu catálogo de Lakehouse. Para interactuar con secretos regionales con Google Cloud CLI, debes anular el extremo de API predeterminado para tu sesión o perfil actual.
```
gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
```
Reemplaza lo siguiente:
- REGION: Es la región de Google Cloud en la que se almacena tu secreto de Secret Manager. Por ejemplo, us-east4. Para evitar problemas de conectividad, el secreto y el catálogo deben crearse en la misma región.
Sube la carga útil a Secret Manager:
```
gcloud secrets create SNOWFLAKE_SECRET_NAME \
  --location="REGION" \
  --project="PROJECT_ID" \
  --data-file=credentials.json
```
Reemplaza lo siguiente:
- SNOWFLAKE_SECRET_NAME: Es un nombre para tu secreto de Snowflake.
- PROJECT_ID: Es el ID del proyecto de Google Cloud .

Federación de identidades para cargas de trabajo

La federación de identidades para cargas de trabajo (WIF) evita el uso de secretos de larga duración, ya que vincula una cuenta de servicio del catálogo de Lakehouse directamente a un usuario del servicio de Snowflake. No hay una configuración de requisitos previos. Continúa con la creación del catálogo federado.

Crea un catálogo federado

Crea el catálogo federado con la consola de Google Cloud o la CLI de gcloud.

Console

Para crear un catálogo federado, haz lo siguiente:

En la consola de Google Cloud , ve a Lakehouse.

Ir a Lakehouse
Haz clic en Crear catálogo.
Haz clic en Catálogo federado.

Aparecerá la sección Configuración del catálogo.
En Fuente de catálogo federado, selecciona Snowflake (Horizon).
En Ubicación de los datos, selecciona la región de Lakehouse en la que deseas crear el catálogo federado. Por ejemplo, us-east4 Para minimizar la latencia (incluso en la Internet pública), haz lo siguiente cuando selecciones una región:
- Si tu catálogo de Snowflake Horizon está en AWS, selecciona la región deGoogle Cloud más cercana a tu región de AWS.
- Si tu catálogo de Snowflake Horizon está en Azure, selecciona la región deGoogle Cloud más cercana a tu región de Azure.
- Si tu catálogo de Snowflake Horizon está en Google Cloud, selecciona la misma región.
Opcional: En Almacenamiento en caché multinube, selecciona Habilitar el almacenamiento en caché multinube para almacenar en caché los archivos remotos en la región de Google Cloud del catálogo y acelerar el rendimiento de las consultas. También puedes actualizar este parámetro de configuración más adelante editando los detalles del catálogo. Para obtener más información sobre cómo funciona el almacenamiento en caché, la retención y los precios, consulta Almacenamiento en caché inteligente.
Haz clic en Continuar.

Aparecerá la sección Detalles de la conexión.
En la sección Detalles del catálogo remoto, en el campo Identificador de cuenta de Snowflake, ingresa el identificador de tu cuenta de Snowflake (por ejemplo, myorg-myaccount). Si enrutas la actualización de metadatos en segundo plano de forma privada a través de AWS PrivateLink o Azure Private Link, ingresa el identificador de tu cuenta de .privatelink (por ejemplo, myorg-myaccount.privatelink).
En el campo Snowflake warehouse, ingresa el nombre de tu almacén de Snowflake. También se conoce como el nombre de la base de datos en el catálogo de Snowflake Horizon.
Selecciona una opción para Método de autenticación:
- En Secreto, ingresa el nombre de tu secreto para Basado en secretos (PAT). Usa el siguiente formato: projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME.
- En OIDC, ingresa tu rol de Snowflake para la federación de identidades para cargas de trabajo. Por ejemplo: ICEBERG_VIEW.
En Capa de transporte, selecciona Internet pública o Interconexión privada dedicada. Si seleccionas Interconexión privada dedicada, configura los siguientes campos:
- En el campo Nombre del directorio de servicios, ingresa la ruta de acceso a tu servicio de Directorio de servicios de transporte en el formato projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME.
- Opcional: Para sincronizar los metadatos del catálogo de forma privada a través de Cross‑Cloud Interconnect, en el campo Nombre del directorio de servicios de metadatos, ingresa la ruta de acceso al servicio del Directorio de servicios de metadatos en el formato projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME.
Haz clic en Crear.

gcloud

Basada en secretos (PAT)

Si usas la autenticación basada en secretos, debes especificar --secret-name.

Internet público (sin CCI)

Si no configuras Cross‑Cloud Interconnect, las conexiones se realizan a través de la Internet pública con TLS.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE"

Propiedad del cliente (CCI)

Si configuraste una interconexión privada (Cross‑Cloud Interconnect dedicada o de socio), proporciona la referencia del servicio de Directorio de servicios para el transporte de consultas privadas (--service-directory-name), la actualización de metadatos en segundo plano privada (--metadata-service-directory-name) o ambas. También puedes agregar o actualizar cualquiera de las marcas en un catálogo existente ejecutando gcloud biglake iceberg catalogs update.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/SNOWFLAKE_SECRET_NAME" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME" \
    --metadata-service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME"

Reemplaza lo siguiente:

FEDERATED_CATALOG_NAME: Es un nombre para tu catálogo federado.
PROJECT_ID: Es el ID del proyecto de Google Cloud .
REGION: Es la región de Lakehouse en la que se crea el catálogo federado. Debe ser la misma región que el espacio de nombres del Directorio de servicios y el Secret regional. Para minimizar la latencia, haz lo siguiente:
- Si tu catálogo de Snowflake Horizon está en AWS, selecciona la región deGoogle Cloud más cercana a tu región de AWS.
- Si tu catálogo de Snowflake Horizon está en Azure, selecciona la región deGoogle Cloud más cercana a tu región de Azure.
- Si tu catálogo de Snowflake Horizon está en Google Cloud, selecciona la misma región.
SNOWFLAKE_SECRET_NAME: Es el nombre de tu secreto de Snowflake.
SNOWFLAKE_ACCOUNT_IDENTIFIER: Es el identificador de tu cuenta de Snowflake (por ejemplo, myorg-myaccount). Si especificas --metadata-service-directory-name para sincronizar metadatos a través de PrivateLink o Private Link, usa el identificador de tu cuenta de .privatelink (por ejemplo, myorg-myaccount.privatelink).
SNOWFLAKE_WAREHOUSE: Es el almacén de Snowflake con el que deseas federar. También se conoce como el nombre de la base de datos en el catálogo de Snowflake Horizon.
REFRESH_INTERVAL: Es opcional. Especifica la frecuencia con la que se ejecuta la actualización de metadatos en segundo plano. Establece este valor como una duración, por ejemplo, 330s o 5m30s.
NAMESPACE_FILTERS: Es opcional y se trata de una lista separada por comas de los espacios de nombres que se federarán. Por ejemplo, ns1,ns2 Si se omite, Lakehouse incluye todos los espacios de nombres.
CROSS_CLOUD_CACHE_MODE: Opcional. Indica si se debe habilitar el almacenamiento en caché multinube en el catálogo federado (enabled o disabled). El valor predeterminado es disabled. Cuando se establece en enabled, Lakehouse almacena en caché los archivos remotos en la región Google Cloud del catálogo. Para obtener más información, consulta Almacenamiento en caché inteligente.
Si usas una interconexión privada (Cross‑Cloud Interconnect), especifica una o ambas referencias del Directorio de servicios que se indican a continuación (omite cualquiera de las marcas si no enrutas esa capa de tráfico a través de Cross‑Cloud Interconnect):
- SERVICE_DIRECTORY_NAMESPACE y SERVICE_NAME: el espacio de nombres y el nombre del servicio del Directorio de servicios que creaste para el transporte de consultas privadas al almacén de objetos remoto.
- METADATA_SERVICE_DIRECTORY_NAMESPACE y METADATA_SERVICE_NAME: el espacio de nombres y el nombre del servicio del Directorio de servicios que creaste para la actualización privada de metadatos en segundo plano.

Federación de identidades para cargas de trabajo

Si usas la federación de identidades para cargas de trabajo, debes especificar --snowflake-role.

Internet público (sin CCI)

Si no configuras Cross‑Cloud Interconnect, las conexiones se realizan a través de la Internet pública con TLS.

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE"

Propiedad del cliente (CCI)

gcloud biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="snowflake" \
    --snowflake-account-identifier="SNOWFLAKE_ACCOUNT_IDENTIFIER" \
    --snowflake-warehouse="SNOWFLAKE_WAREHOUSE" \
    --snowflake-role="SNOWFLAKE_ROLE" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/SERVICE_DIRECTORY_NAMESPACE/services/SERVICE_NAME" \
    --metadata-service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/METADATA_SERVICE_DIRECTORY_NAMESPACE/services/METADATA_SERVICE_NAME"

Reemplaza lo siguiente:

FEDERATED_CATALOG_NAME: Es un nombre para tu catálogo federado.
PROJECT_ID: Es el ID del proyecto de Google Cloud .
REGION: Es la región de Lakehouse en la que se crea el catálogo federado. Debe ser la misma región que el espacio de nombres del Directorio de servicios y el Secret regional. Para minimizar la latencia, haz lo siguiente:
- Si tu catálogo de Snowflake Horizon está en AWS, selecciona la región deGoogle Cloud más cercana a tu región de AWS.
- Si tu catálogo de Snowflake Horizon está en Azure, selecciona la región deGoogle Cloud más cercana a tu región de Azure.
- Si tu catálogo de Snowflake Horizon está en Google Cloud, selecciona la misma región.
SNOWFLAKE_ACCOUNT_IDENTIFIER: Es el identificador de tu cuenta de Snowflake (por ejemplo, myorg-myaccount). Si especificas --metadata-service-directory-name para sincronizar metadatos a través de PrivateLink o Private Link, usa el identificador de tu cuenta de .privatelink (por ejemplo, myorg-myaccount.privatelink).
SNOWFLAKE_WAREHOUSE: Es el almacén de Snowflake con el que deseas federar. También se conoce como el nombre de la base de datos en el catálogo de Snowflake Horizon.
SNOWFLAKE_ROLE: el rol de Snowflake específico que se requiere para la sesión. Por ejemplo, ICEBERG_VIEW
REFRESH_INTERVAL: Especifica la frecuencia con la que se ejecuta la actualización de metadatos en segundo plano. Establece este valor como una duración, por ejemplo, 330s o 5m30s.
NAMESPACE_FILTERS: Es opcional y se trata de una lista separada por comas de los espacios de nombres que se federarán. Por ejemplo, ns1,ns2 Si se omite, Lakehouse incluye todos los espacios de nombres.
CROSS_CLOUD_CACHE_MODE: Opcional. Indica si se debe habilitar el almacenamiento en caché multinube en el catálogo federado (enabled o disabled). El valor predeterminado es disabled. Cuando se establece en enabled, Lakehouse almacena en caché los archivos remotos en la región Google Cloud del catálogo. Para obtener más información, consulta Almacenamiento en caché inteligente.
Si usas una interconexión privada (Cross‑Cloud Interconnect), especifica una o ambas referencias del Directorio de servicios que se indican a continuación (omite cualquiera de las marcas si no enrutas esa capa de tráfico a través de Cross‑Cloud Interconnect):
- SERVICE_DIRECTORY_NAMESPACE y SERVICE_NAME: el espacio de nombres y el nombre del servicio del Directorio de servicios que creaste para el transporte de consultas privadas al almacén de objetos remoto.
- METADATA_SERVICE_DIRECTORY_NAMESPACE y METADATA_SERVICE_NAME: el espacio de nombres y el nombre del servicio del Directorio de servicios que creaste para la actualización privada de metadatos en segundo plano.

Completa la configuración de la autenticación

Completa el proceso de autenticación con el tipo de autenticación que elegiste.

Basada en secretos (PAT)

Cuando se crea el catálogo, Lakehouse aprovisiona una cuenta de servicio única para él (se devuelve como biglake-service-account en la descripción del recurso).

Debes otorgar permiso a esta cuenta de servicio para acceder al secreto que creaste antes. Ten en cuenta que la propagación de las políticas de IAM puede tardar unos minutos.

Otorga permiso a la cuenta de servicio del catálogo para acceder al secreto:

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets add-iam-policy-binding SNOWFLAKE_SECRET_NAME \
  --project="PROJECT_ID" \
  --location="REGION" \
  --member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
      --project="PROJECT_ID" \
      --format='value(biglake-service-account)')" \
  --role="roles/secretmanager.secretAccessor"

Para verificar que la cuenta de servicio del catálogo federado tenga acceso al secreto, ejecuta el siguiente comando:

gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/
gcloud secrets get-iam-policy SNOWFLAKE_SECRET_NAME \
    --project="PROJECT_ID" \
    --location="REGION"

En el resultado, verifica que la cuenta de servicio biglake-service-account tenga asignado el rol roles/secretmanager.secretAccessor.

Federación de identidades para cargas de trabajo

Después de crear el catálogo, debes vincular su identidad de cuenta de servicio a un usuario de servicio en Snowflake.

Extrae el ID de la cuenta de servicio de Lakehouse (asunto) de los detalles del catálogo.

Puedes obtenerlo de la respuesta JSON del comando de creación (campo biglake-service-account-id).

Como alternativa, puedes ejecutar el comando describe en el catálogo para obtener el valor:
```
gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID"
```
Busca biglake-service-account-id en el resultado.
Accede a tu instancia de administración de Snowflake y ejecuta la siguiente secuencia de comandos para establecer la relación de confianza con la identidad del servicio de Lakehouse:
```
USE ROLE ACCOUNTADMIN;

CREATE USER SNOWFLAKE_SERVICE_USER
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE = GCP
    SUBJECT = 'LAKEHOUSE_SERVICE_ACCOUNT_ID'
  )
  DEFAULT_ROLE = SNOWFLAKE_ROLE
  COMMENT = 'Service user for Lakehouse federation over WIF';

-- Also explicitly GRANT permissions to the role
GRANT ROLE SNOWFLAKE_ROLE TO USER SNOWFLAKE_SERVICE_USER;
```
Reemplaza lo siguiente:
- SNOWFLAKE_SERVICE_USER: Es un nombre para el usuario de servicio nuevo en Snowflake.
- LAKEHOUSE_SERVICE_ACCOUNT_ID: Es el ID de cuenta de servicio que se extrajo en el paso anterior.
- SNOWFLAKE_ROLE: Es el rol de Snowflake (debe coincidir con el rol especificado durante la creación del catálogo).

Completa la configuración de la interconexión privada (solo Cross‑Cloud Interconnect)

Si enrutas el transporte de consultas, la actualización de metadatos en segundo plano o ambos a través de una interconexión privada (Cross‑Cloud Interconnect dedicada o de socio), debes otorgar permisos a la cuenta de servicio del catálogo de Lakehouse para descubrir y autorizar conexiones a través del Directorio de servicios. Si tu servicio de Directorio de servicios de transporte y el servicio de Directorio de servicios de metadatos se alojan en proyectos de Google Cloud diferentes, otorga estos roles en cada proyecto que aloje un servicio de Directorio de servicios.

Console

En la consola de Google Cloud , dirígete a la página IAM.

Ir a IAM
Haz clic en Otorgar acceso (o Agregar).
En el campo Principales nuevas, ingresa la dirección de correo electrónico de la cuenta de servicio del catálogo de Lakehouse. Puedes recuperar esta dirección de correo electrónico describiendo el catálogo (consulta la pestaña gcloud).
En el menú Rol, selecciona Visualizador del Directorio de servicios (roles/servicedirectory.viewer).
Haz clic en Agregar otro rol y, luego, selecciona Servicio autorizado de PSC del Directorio de servicios (roles/servicedirectory.pscAuthorizedService).
Haz clic en Guardar.

gcloud

Otorga los roles necesarios a la cuenta de servicio del catálogo en el proyecto que aloja tus servicios del Directorio de servicios:

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.viewer"

# Grant Service Directory PSC Authorized Service
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --format='value(biglake-service-account)')" \
--role="roles/servicedirectory.pscAuthorizedService"

Verifica la conexión

Verifica que el ciclo de actualización de metadatos en segundo plano del catálogo se haya completado correctamente y que los espacios de nombres y las tablas estén sincronizados.

Verifica que el estado de actualización indique que se realizó correctamente:

gcloud biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID"

Confirma que los espacios de nombres estén sincronizados:

gcloud biglake iceberg namespaces list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME"

Confirma que las tablas de un espacio de nombres estén sincronizadas:

gcloud biglake iceberg tables list \
  --project="PROJECT_ID" \
  --catalog="FEDERATED_CATALOG_NAME" \
  --namespace="NAMESPACE_ID"

Configura la conexión entre nubes para el catálogo de Snowflake Horizon Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Antes de comenzar

Roles obligatorios

Limitaciones y consideraciones

Flujo de trabajo general

Configura Cross‑Cloud Interconnect (opcional)

Balanceador de cargas de red del proxy interno regional

Extremo directo

Configura la federación

Configura la autenticación

Basada en secretos (PAT)

Federación de identidades para cargas de trabajo

Crea un catálogo federado

Console

gcloud

Basada en secretos (PAT)

Internet público (sin CCI)

Propiedad del cliente (CCI)

Federación de identidades para cargas de trabajo

Internet público (sin CCI)

Propiedad del cliente (CCI)

Completa la configuración de la autenticación

Basada en secretos (PAT)

Federación de identidades para cargas de trabajo

Completa la configuración de la interconexión privada (solo Cross‑Cloud Interconnect)

Console

gcloud

Verifica la conexión

¿Qué sigue?

Configura la conexión entre nubes para el catálogo de Snowflake Horizon