Configura un Lakehouse sin bordes para AWS Glue

En este documento, se describe cómo configurar un Lakehouse sin límites para consultar datos de un catálogo de AWS Glue directamente en Google Cloud. Esta capacidad unifica tu análisis de datos integrando tus fuentes de datos externas con tu Google Cloud entorno existente.

Luego, puedes usar Lakehouse para Apache Iceberg para administrar el acceso a tus datos federados.

Antes de comenzar

1. Revisa la descripción general de Lakehouse para comprender cómo Lakehouse administra el acceso a los datos.
2. Lee Acerca de Lakehouse sin bordes para comprender cómo funciona.
3. Revisa los catálogos compatibles para verificar los requisitos de formato de la tabla y las configuraciones admitidas.
4. Asegúrate de que tu administrador de AWS tenga permisos para crear roles de Identity and Access Management (IAM) y configurar políticas de permisos.
5. Opcional: Si planeas enrutar consultas a través de una interconexión privada entre tu VPC de Google Cloud y la VPC de tu proveedor de nube remoto (por ejemplo, AWS), asegúrate de tener una cuenta activa con tu proveedor remoto, aprovisiona una interconexión entre nubes dedicada o una interconexión entre nubes de socio, establece sesiones BGP con tu Cloud Router y verifica que tengas los permisos de 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 API.

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 API

Verify that billing is enabled for your Google Cloud project.

Enable the BigLake API.

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 API

Roles obligatorios

Para obtener los permisos que necesitas para configurar un Lakehouse sin bordes, pídele a tu administrador que te otorgue los siguientes roles de IAM en tu proyecto:

• Administrar catálogos de Lakehouse: Administrador de BigLake (roles/biglake.admin)
• Enrutar el tráfico a través de la interconexión privada (usuario): Administrador de red de Compute (roles/compute.networkAdmin)
• Enruta el tráfico a través de una interconexión privada (cuenta de servicio del catálogo):
  • Visualizador del Directorio de servicios (roles/servicedirectory.viewer)
  • Servicio autorizado por 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 usar Lakehouse sin bordes.

• Proveedores de servicios en la nube admitidos: Se admite el uso de una interconexión privada con tu Lakehouse sin bordes con los siguientes proveedores de servicios en la nube remotos: Amazon Web Services (AWS). Puedes usar una interconexión dedicada de Cross-Cloud Interconnect o una interconexión de socio de Cross-Cloud Interconnect.
• Enrutamiento de red: Si no se configura una interconexión privada (como CCI dedicada o CCI de socio), las búsquedas se enrutan a través de Internet pública. Esto puede generar tarifas de salida más altas de tu proveedor de nube remoto y un rendimiento menos predecible.
• Actualidad de los datos: La marca --refresh-interval del catálogo federado determina la frecuencia con la que se sincronizan los metadatos. Un intervalo más corto proporciona datos más recientes, pero puede generar costos adicionales de la API del proveedor del catálogo remoto.
• Informes de métricas de Iceberg: Los Informes de métricas de Iceberg no están disponibles para los catálogos federados. Establece la propiedad rest-metrics-reporting-enabled en false en tu cliente de Iceberg cuando accedas a un catálogo federado.

Flujo de trabajo general

Para configurar y usar Lakehouse sin límites, sigue estos pasos generales:

• Configura Cross-Cloud Interconnect (opcional): Configura una conexión privada entre tu VPC Google Cloud y tu proveedor de nube remoto.
• Configura la federación: Configura la autenticación creando un rol de IAM con una política de confianza de marcador de posición con tu proveedor remoto. Luego, crea un catálogo federado en Lakehouse y actualiza la política de confianza.
• Verifica la conexión: Asegúrate de que Lakehouse pueda conectarse correctamente a tu catálogo remoto.
• Consulta datos: Ejecuta consultas en tus datos federados con BigQuery o Managed Service para Apache Spark. Para obtener más información, consulta Cómo usar Lakehouse sin bordes.
• Configura los permisos: Usa IAM para administrar quién puede ver y consultar los datos federados.

Configura Cross‑Cloud Interconnect (opcional)

De forma predeterminada, las consultas a tu catálogo remoto viajan a través de Internet pública. Para mejorar la seguridad y el cumplimiento, proporcionar un rendimiento predecible y reducir los costos de transferencia de datos, usa una interconexión privada. Esto establece una conexión de red privada y dedicada entre tu Google Cloudnube privada virtual (VPC) y la red de tu proveedor de nube remoto (por ejemplo, AWS).

Puedes aprovisionar y configurar cualquiera de las siguientes opciones de interconexión privada entre tu VPC de Google Cloud y la VPC de tu proveedor de nube remoto (por ejemplo, AWS):

• Cross-Cloud Interconnect dedicado: Es una conexión física dedicada.
• Interconexión de socio de Cross-Cloud Interconnect: Es una conexión a través de un proveedor de servicios admitido.

Establece sesiones de BGP entre tu Cloud Router en Google Cloud y la VPC de tu proveedor de servicios en la nube remoto para garantizar el intercambio de rutas.

Para habilitar las consultas privadas, debes configurar una ruta desde el Lakehouse hasta tu bucket de almacenamiento remoto (por ejemplo, un bucket de Amazon S3 de AWS) a través de tu interconexión privada. Existen dos flujos arquitectónicos que puedes seguir para configurar este enrutamiento:

• Enrutamiento del balanceador de cargas de red del proxy interno regional: Este flujo usa un balanceador de cargas de red del proxy interno regionalGoogle Cloud para distribuir las solicitudes entre los grupos de extremos de red (NEG) de conectividad híbrida que apuntan a varias interfaces de red elásticas (ENI) de AWS. Este flujo es esencial para el balanceo de cargas, la escalabilidad y la alta disponibilidad. Es obligatorio para la CCI de socio y se recomienda para la CCI dedicada para el balanceo de cargas, la escalabilidad y la alta disponibilidad.
• Enrutamiento directo de extremos: Este flujo conecta el Directorio de servicios directamente a una sola dirección IP del extremo de VPC de interfaz de AWS. Este flujo solo funciona para la CCI dedicada y no se admite para la CCI del socio.

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

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

Configura la federación

Para consultar tus datos, configura un catálogo federado de Lakehouse que se conecte a tu catálogo remoto de AWS.

Crea el rol de IAM de AWS con una política de confianza de marcador de posición

Lakehouse aprovisiona un ID de cuenta de servicio de Google después de la creación del catálogo. Crea el rol de IAM de AWS con una política de confianza de marcador de posición.

1. Crea un archivo llamado trust_policy.json:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "accounts.google.com"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "accounts.google.com:aud": [
               "PLACEHOLDER_VALUE"
             ],
             "accounts.google.com:sub": [
               "PLACEHOLDER_VALUE"
             ]
           }
         }
       }
     ]
   }

2. Ejecuta el comando de la CLI de AWS para crear el rol con la política de confianza del marcador de posición. Recomendamos establecer la duración máxima de la sesión en 12 horas (43200 segundos) para evitar que venzan las credenciales durante los trabajos de larga duración:

   aws iam create-role \
     --role-name AWS_ROLE_NAME \
     --assume-role-policy-document file://trust_policy.json \
     --max-session-duration 43200

   Reemplaza lo siguiente:

   • AWS_ROLE_NAME: Es el nombre de tu rol de IAM de AWS. Por ejemplo, lakehouse_glue_federation_role.

Cómo adjuntar una política de permisos

Adjunta una política de permisos a tu rol de IAM que permita que Lakehouse acceda al catálogo de datos de Glue y a los buckets de S3 de la región de AWS. Esta política también otorga acceso a los buckets de tablas de S3 si usas la integración de tablas de S3 de AWS Lake Formation. Si actualizaste los permisos de datos predeterminados de AWS Glue al modelo de AWS Lake Formation, es posible que debas otorgar permisos adicionales en Lake Formation.

1. Crea un archivo llamado permissions_policy.json con la siguiente configuración de política.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "GlueRead",
         "Effect": "Allow",
         "Action": [
           "glue:GetCatalog",
           "glue:GetDatabase",
           "glue:GetDatabases",
           "glue:GetTable",
           "glue:GetTables"
         ],
         "Resource": "arn:aws:glue:AWS_REGION:AWS_ACCOUNT_ID:*"
       },
       {
         "Sid": "S3Read",
         "Effect": "Allow",
         "Action": [
           "s3:ListBucket",
           "s3:GetObject"
         ],
         "Resource": [
           "arn:aws:s3:::*"
         ]
       },
       {
         "Sid": "S3TablesRead",
         "Effect": "Allow",
         "Action": [
           "s3tables:GetTableBucket",
           "s3tables:ListNamespaces",
           "s3tables:GetNamespace",
           "s3tables:ListTables",
           "s3tables:GetTable",
           "s3tables:GetTableMetadataLocation",
           "s3tables:GetTableData"
         ],
         "Resource": [
           "arn:aws:s3tables:AWS_REGION:AWS_ACCOUNT_ID:*"
         ]
       }
     ]
   }

   Si usas claves administradas por el cliente alojadas en AWS Key Management Service (KMS) para encriptar recursos de AWS Glue, Amazon S3 o tablas de Amazon S3, debes agregar una instrucción que otorgue acceso a la clave de KMS para desencriptar los recursos:

   # ...
   {
     "Sid": "GlueS3S3TablesKmsDecrypt",
     "Effect": "Allow",
     "Action": [
         "kms:Decrypt"
     ],
     "Resource": [
         "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_glue",
         "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3",
         "arn:aws:kms:AWS_REGION:AWS_ACCOUNT_ID:key/key_id_for_s3_tables"
     ]
   }
   # ...

2. Adjunta esta política de permisos a tu rol de IAM:

   aws iam put-role-policy \
     --role-name AWS_ROLE_NAME \
     --policy-name AWS_POLICY_NAME \
     --policy-document file://permissions_policy.json

   Reemplaza lo siguiente:

   • AWS_ROLE_NAME: Es el nombre de tu rol de IAM de AWS. Por ejemplo, lakehouse_glue_federation_role.
   • AWS_POLICY_NAME: Es un nombre para tu política de permisos. Por ejemplo, lakehouse_glue_federation_policy
   • AWS_REGION: Es la región de AWS en la que residen tu catálogo de Glue o tus tablas de S3. Por ejemplo, us-east-1
   • AWS_ACCOUNT_ID: Es tu cadena de ID de cuenta de AWS de 12 dígitos. Por ejemplo, 123456789012

Crea un catálogo federado

Establece el catálogo federado en Google Cloud con la consola de Google Cloud , la CLI de gcloud o la API de REST.

Para evitar fallas prematuras en la actualización de metadatos en segundo plano mientras se propagan las relaciones de confianza de AWS, inicializa el catálogo sin especificar un programa de actualización (que se establece de forma predeterminada en 0s).

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME"

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="glue" \
    --glue-warehouse="GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE" \
    --glue-aws-region="AWS_REGION" \
    --glue-aws-role-arn="arn:aws:iam::AWS_ACCOUNT_ID:role/AWS_ROLE_NAME" \
    --service-directory-name="projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE_NAME"

curl -s -X POST \
  -H "x-goog-user-project: PROJECT_ID" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs?iceberg_catalog_id=FEDERATED_CATALOG_NAME&primary_location=REGION" \
  -d '{
    "catalog_type": "CATALOG_TYPE_FEDERATED",
    "storage_regions": ["'"REGION"'"],
    "federated_catalog_options": {
      "glue_catalog_info": {
        "warehouse": "'"GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE"'",
        "aws_region": "'"AWS_REGION"'",
        "aws_role_arn": "arn:aws:iam::'"AWS_ACCOUNT_ID"':role/'"AWS_ROLE_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 del Lakehouse en la que se crea el catálogo federado. Por ejemplo, us-east4
• GLUE_OR_S3_TABLE_BUCKET_WAREHOUSE: Es el identificador del catálogo del almacén de destino. Para el Data Catalog de Glue de una región de AWS, ingresa tu cadena de ID de cuenta de AWS de 12 dígitos. Por ejemplo, 123456789012. Para usar un bucket de tabla de S3 en la región, ingresa AWS_ACCOUNT_ID:s3tablescatalog/S3_TABLE_BUCKET. Por ejemplo, 123456789012:s3tablescatalog/my-table-bucket.
• AWS_ACCOUNT_ID: Es tu cadena de ID de cuenta de AWS de 12 dígitos. Por ejemplo, 123456789012
• AWS_REGION: Es la región de AWS en la que reside tu catálogo de Glue o bucket de tabla de S3. Por ejemplo, us-east-1
• AWS_ROLE_NAME: Es el nombre de tu rol de IAM de AWS. Por ejemplo, lakehouse_glue_federation_role
• NAMESPACE: (Opcional) Es el espacio de nombres del Directorio de servicios que creaste durante la configuración de la interconexión privada.
• SERVICE_NAME: (Opcional) Es el nombre del servicio del Directorio de servicios que creaste durante la configuración de la interconexión privada.

Actualiza la política de confianza

Cuando se crea el catálogo, Lakehouse aprovisiona una cuenta de servicio única para él, que se devuelve como el campo biglake-service-account-id en la respuesta de creación del catálogo. Usarás esta cuenta de servicio para establecer la relación de confianza.

1. Ejecuta el siguiente comando para extraer el valor de biglake-service-account-id en una variable bash activa:

   LAKEHOUSE_SA_ID=$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
     --project="PROJECT_ID" \
     --format="value(biglake-service-account-id)")

2. Actualiza la política de confianza de tu rol de IAM de AWS para reemplazar el marcador de posición por tu ID verificado del agente de servicio de Google. El bloque de condición valida la coincidencia de sub y aud. Escribe la política en un archivo llamado trust_policy_comprehensive.json:

   cat > trust_policy_comprehensive.json << EOF
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "accounts.google.com"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "accounts.google.com:aud": [
               "$LAKEHOUSE_SA_ID"
             ],
             "accounts.google.com:sub": [
               "$LAKEHOUSE_SA_ID"
             ]
           }
         }
       }
     ]
   }
   EOF

3. Aplica la política finalizada a tu rol de AWS:

   aws iam update-assume-role-policy \
     --role-name AWS_ROLE_NAME \
     --policy-document file://trust_policy_comprehensive.json

Habilita la actualización de metadatos en segundo plano

Ahora que se establecieron correctamente las relaciones de confianza seguras en ambas plataformas, actualiza tu catálogo para activar la actualización de metadatos en segundo plano (cada 5 minutos o 300s, o más).

gcloud alpha biglake iceberg catalogs update FEDERATED_CATALOG_NAME \
  --project="PROJECT_ID" \
  --refresh-interval="300s"

curl -s -X PATCH \
-H "x-goog-user-project: PROJECT_ID" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://biglake.googleapis.com/iceberg/v1/restcatalog/extensions/projects/PROJECT_ID/catalogs/FEDERATED_CATALOG_NAME?updateMask=federated_catalog_options.refresh_options.refresh_schedule" \
-d '{
  "federated_catalog_options": {
    "refresh_options": {
      "refresh_schedule": {
        "refresh_interval": "300s"
      }
    }
  }
}'

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

Si enrutas el tráfico a través de una interconexión privada (CCI 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 de Directorio de servicios.

# Grant Service Directory Viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:$(gcloud alpha 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 alpha 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 estén sincronizados.

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

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

2. Confirma que las bases de datos remotas aparezcan como espacios de nombres sincronizados:

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

¿Qué sigue?

• Usa Lakehouse sin fronteras y consulta tablas.
• Soluciona problemas relacionados con Lakehouse sin bordes.