Configura la conexión entre nubes para Workday Data Lake

Vista previa

Esta función está sujeta a las "Condiciones de la oferta previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles “sin modificaciones” y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Nota: Para obtener asistencia durante la vista previa, envía un correo electrónico a [e-mail].

Una conexión multinube a Workday Data Lake te permite consultar tus datos de Workday directamente en Google Cloud. Esta capacidad unifica tu análisis de datos, ya que integra tus fuentes de datos externas con tuGoogle Cloud entorno existente.

Luego, puedes usar el lakehouse sin fronteras para administrar el acceso a tus datos federados.

Casos de uso

La conexión de Lakehouse a Workday Data Lake admite varios casos de uso clave:

• Unifica las estadísticas: Correlaciona los datos de RR.HH. y de compensación de Workday con los datos deGoogle Cloud , por ejemplo, para proporcionar contexto para las ventas y las cuotas.
• Aprovecha el ecosistema de Google Cloud: Por ejemplo, usa el framework de agentes de Google con BigQuery ML y los datos de RR.HH. de Workday para predecir la retención de empleados.
• Transmite datos en tiempo real sin necesidad de copiarlos: Analiza los datos de compras y cuentas por pagar de Workday junto con los datos de logística y de inventario almacenados enGoogle Cloud para informar las ineficiencias de la cadena de suministro y optimizar los costos de los proveedores.

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 del acceso a datos multinube para comprender cómo funciona.
3. Revisa los catálogos compatibles para verificar la compatibilidad.
4. Comprende cómo usar Secrets regionales de Secret Manager para autenticarte en Workday Data Lake.
5. Comunícate con los administradores de tu lago de datos de Workday para configurar la autenticación como se describe en este documento. Es posible que los administradores deban comunicarse con el equipo de asistencia de Workday para habilitar el acceso a Data Lake, lo que puede llevar tiempo.
Accede a tu cuenta de Google Cloud . Si es la primera vez que usas 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

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

Roles obligatorios

Para obtener los permisos que necesitas para configurar el acceso entre nubes, 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)
• Administrar secretos: Administrador de Secret Manager (roles/secretmanager.admin)

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.

Precaución: Cuando uses la autenticación basada en secretos, para seguir el principio de privilegio mínimo y evitar otorgar acceso a todos los secretos del proyecto, pídele a un administrador de Secret Manager que cree el secreto por ti y te otorgue permisos para modificar solo ese secreto específico para Lakehouse.

Limitaciones y consideraciones

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

• 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, actualización o eliminación de recursos), que debe realizarse 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 cuanto más recursos de espacios de nombres y tablas haya. Si la actualización anterior se extiende demasiado, se omitirá la actualización actual, pero la próxima se programará en el siguiente intervalo.
• Almacenamiento en caché de Lakehouse: El almacenamiento en caché de Lakehouse se habilita automáticamente para todas las consultas multinube con el objetivo de ahorrar costos de salida almacenando bloques de datos de forma local en Google Cloud. No se admiten las claves de encriptación administradas por el cliente (CMEK) para el almacenamiento en caché. Los datos almacenados en caché se encriptan con Google-owned and Google-managed encryption keys. Si la restricción de política de la organización constraints/gcp.restrictNonCmekServices se aplica a alguna tabla de la consulta, la caché se inhabilita automáticamente para esa consulta. Para obtener más información, consulta Almacenamiento en caché inteligente.
• Residencia y cumplimiento de datos: Cuando creas un catálogo o una conexión federados en una región de Google Cloud , los datos en reposo almacenados en caché se guardan en esa región de destino. Si tus datos remotos en la nube residen en una jurisdicción diferente, asegúrate de que el almacenamiento en caché entre regiones cumpla con los requisitos de residencia de datos y cumplimiento normativo de tu organización.

Flujo de trabajo general

Para acceder a los datos multinube en Workday Data Lake, sigue estos pasos generales:

1. Configura la federación: Configura la autenticación basada en secretos y crea un catálogo federado en Lakehouse.
   1. En Workday, configura las credenciales de la API de Workday y del lago de datos.
   2. Crea un secreto en Secret Manager con tus credenciales de la API de Workday.
   3. Crea un catálogo federado en Lakehouse y otorga acceso a la cuenta de servicio del catálogo al secreto.
2. Verifica la conexión: Verifica que Lakehouse pueda conectarse a tu catálogo remoto y sincronizar los metadatos.
3. 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 consultar datos remotos.
4. Configura los permisos: Usa Identity and Access Management (IAM) para administrar quién puede ver y consultar los datos federados.

Configura la federación

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

Configura la autenticación

La federación requiere la autenticación en el Workday Data Lake remoto con credenciales almacenadas de forma segura en los secretos regionales de Secret Manager.

1. En Workday, completa lo siguiente:

   1. Configura el data lake.
   2. Registra el cliente de API para el lago de datos (concesión de token de actualización).
   3. Configura la seguridad y las exportaciones de tablas en el data lake.

   Para obtener instrucciones completas sobre cómo completar este proceso, consulta Comienza a usar Workday Data Lake.

2. Crea un archivo JSON llamado credentials.json con las credenciales del paso anterior:

   {
     "client_id": "CLIENT_ID",
     "client_secret": "CLIENT_SECRET",
     "refresh_token": "REFRESH_TOKEN"
   }

   Reemplaza lo siguiente:

   • CLIENT_ID: Es el ID de cliente de OAuth de tu cliente de API de Workday para integraciones.
   • CLIENT_SECRET: Es el secreto del cliente de OAuth de tu cliente de la API de Workday para integraciones.
   • REFRESH_TOKEN: Es el token de actualización que no vence y que se generó para tu ISU de Workday.

3. Configura el extremo regional para Secret Manager:

   De forma predeterminada, Secret Manager usa un extremo global. Para evitar problemas de conectividad y minimizar la latencia y los costos de transferencia de datos, crea tu secreto y catálogo en la misma región. Para anular el extremo global predeterminado con un secreto regional, ejecuta el siguiente comando:

   gcloud config set api_endpoint_overrides/secretmanager https://secretmanager.REGION.rep.googleapis.com/

   Reemplaza lo siguiente:

   • REGION: Es la Google Cloud región en la que almacenas tu secreto de Secret Manager. Por ejemplo, us-east4.

4. Sube la carga útil a Secret Manager:

   gcloud secrets create WORKDAY_SECRET_NAME \
     --location="REGION" \
     --project="PROJECT_ID" \
     --data-file=credentials.json

5. Borra de forma segura el archivo credentials.json para evitar la filtración de credenciales.

   Reemplaza lo siguiente:

   • WORKDAY_SECRET_NAME: Es un nombre único para tu secreto de Workday en Secret Manager, por ejemplo, workday-api-credentials o workday-data-lake-secret.
   • REGION: La región Google Cloud en la que creas el secreto, por ejemplo, us-east4.
   • PROJECT_ID: Es el ID del proyecto de Google Cloud .

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, sigue estos pasos:

1. En la consola de Google Cloud , ve a Lakehouse.

   Ir a Lakehouse

2. Haz clic en Crear catálogo y, luego, selecciona Catálogo federado.

   Aparecerá la página Crear un catálogo federado.

3. En la sección Configuración del catálogo, haz lo siguiente:

   1. En la lista Federated catalog source, selecciona Workday (Data Lake).
   2. En el campo Nombre del catálogo (en Lakehouse), ingresa un nombre para el catálogo.
   3. En la lista Ubicación de los datos, selecciona la región en la que deseas crear el catálogo federado, por ejemplo, us-east4. Debe coincidir con la región de tu secreto de Secret Manager. Para minimizar la latencia y los costos de transferencia de datos, haz lo siguiente cuando selecciones una región:
      • Si tu instancia de Workday se encuentra en Amazon Web Services (AWS), selecciona la región deGoogle Cloud más cercana a tu región de AWS.
      • Si tu instancia de Workday está en Google Cloud, selecciona la misma región.
   4. Haz clic en Continuar.

4. En la sección Detalles de la conexión, haz lo siguiente:

   1. En la sección Detalles del catálogo remoto, haz lo siguiente:
      • En el campo URL base de Workday, ingresa la URL base de tu instancia de Workday. Por ejemplo, impl-services1.wd12.myworkday.com o wd501.myworkday.com.
      • En el campo Usuario de Workday, ingresa el nombre de tu usuario de Workday, por ejemplo, google_dp3.
   2. En la sección Método de autenticación, en el campo Secret de Secret Manager, ingresa el nombre del recurso de tu Secret regional. Usa el siguiente formato: projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME.
   3. En la sección Intervalo de actualización, en el campo Intervalo de actualización, ingresa la frecuencia (en segundos) con la que se actualizarán los metadatos del catálogo (por ejemplo, 300). Para inhabilitar la actualización en segundo plano, ingresa 0.

5. Haz clic en Crear.

gcloud CLI

Para crear un catálogo federado con la CLI de gcloud, ejecuta el siguiente comando:

gcloud alpha biglake iceberg catalogs create FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID" \
    --primary-location="REGION" \
    --catalog-type="federated" \
    --federated-catalog-type="workday" \
    --secret-name="projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME" \
    --workday-base-url="WORKDAY_BASE_URL" \
    --workday-tenant="WORKDAY_TENANT" \
    --refresh-interval="REFRESH_INTERVAL" \
    --namespace-filters="NAMESPACE_FILTERS"

Reemplaza lo siguiente:

• FEDERATED_CATALOG_NAME: Es el nombre del catálogo federado en Lakehouse.
• PROJECT_ID: Es el ID del proyecto de Google Cloud .
• REGION: Es la región de Lakehouse en la que creas el catálogo federado, por ejemplo, us-east4. Esta región debe ser la misma en la que almacenaste tu secreto. Para minimizar la latencia y los costos de transferencia de datos, haz lo siguiente cuando selecciones una región:
  • Si tu instancia de Workday se encuentra en AWS, selecciona la regiónGoogle Cloud más cercana a tu región de AWS.
  • Si tu instancia de Workday está en Google Cloud, selecciona la misma región exacta.
• WORKDAY_SECRET_NAME: Es el nombre de tu secreto de Workday en Secret Manager.
• WORKDAY_BASE_URL: Es la URL base de tu instancia de Workday. Por ejemplo, impl-services1.wd12.myworkday.com o wd501.myworkday.com.
• WORKDAY_TENANT: Es el nombre del arrendatario de Workday.
• REFRESH_INTERVAL: Opcional: Especifica con qué frecuencia se debe actualizar la información del catálogo. Establece este valor como una duración, por ejemplo, 300s o 5m. Los intervalos más cortos actualizan los datos con mayor frecuencia, pero pueden costar más en llamadas a la API. Los intervalos más largos pueden costar menos, pero es posible que los datos consultados no reflejen tu conjunto de datos más actual. Si se omite, el intervalo de actualización se establece de forma predeterminada en 5 minutos (300s). Si se establece el valor en 0s, se inhabilita la actualización de metadatos en segundo plano.
• NAMESPACE_FILTERS: Opcional: Es una lista separada por comas de los espacios de nombres que se federarán, por ejemplo, finance,hr. Si se omite, Lakehouse incluye todos los espacios de nombres.

Completa la configuración de la autenticación

Después de crear el catálogo, Lakehouse aprovisiona una cuenta de servicio única para él, identificada como biglake-service-account en la descripción del recurso.

Debes otorgarle a esta cuenta de servicio el rol de Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) en el secreto que creaste antes. Es posible que las políticas de IAM nuevas tarden unos minutos en aplicarse.

Console

1. En la consola de Google Cloud , ve a Lakehouse.

   Ir a Lakehouse

2. Haz clic en el nombre del catálogo federado que creaste para Workday.

3. En la página Detalles del catálogo, haz clic en Grant secret permissions en el banner de alerta.

   Lakehouse otorga el rol roles/secretmanager.secretAccessor en el secreto a la cuenta de servicio aprovisionada.

gcloud CLI

1. 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 WORKDAY_SECRET_NAME \
     --project="PROJECT_ID" \
     --location="REGION" \
     --member="serviceAccount:$(gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
         --project="PROJECT_ID" \
         --format='value(biglake-service-account)')" \
         --role="roles/secretmanager.secretAccessor"

2. 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 WORKDAY_SECRET_NAME \
        --project="PROJECT_ID" \
        --location="REGION"

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

Reemplaza lo siguiente:

• REGION: Es la región de Google Cloud en la que almacenas tu secreto de Secret Manager y creaste el catálogo federado, por ejemplo, us-east4.
• WORKDAY_SECRET_NAME: Es el nombre de tu secreto de Workday en Secret Manager.
• PROJECT_ID: Es el ID del proyecto de Google Cloud .
• FEDERATED_CATALOG_NAME: Es el nombre de tu catálogo federado en Lakehouse.

Verifica la conexión

Verifica que la actualización de metadatos en segundo plano se haya completado correctamente y que se hayan sincronizado tus espacios de nombres y tablas.

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 los espacios de nombres estén sincronizados:

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

Reemplaza lo siguiente:

• PROJECT_ID: Es el ID del proyecto de Google Cloud .
• FEDERATED_CATALOG_NAME: Es el nombre de tu catálogo federado en Lakehouse.

¿Qué sigue?

• Consulta datos remotos.
• Soluciona problemas de acceso a los datos multinube.