Configura la conexión entre nubes para Workday Data Lake

Una conexión entre nubes a Workday Data Lake te permite consultar tus datos de Workday directamente en Google Cloud. Luego, puedes usar Lakehouse para administrar el acceso a tus datos federados y analizarlos sin copiarlos ni moverlos.

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 adquisiciones 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 los datos entre nubes 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.
  6. 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.

  7. Verify that billing is enabled for your Google Cloud project.

  8. Enable the BigLake, Secret Manager APIs.

    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

  9. Verify that billing is enabled for your Google Cloud project.

  10. Enable the BigLake, Secret Manager APIs.

    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

    11.

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:

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.

Detalles del catálogo admitidos

En este documento, se proporcionan instrucciones para configurar Lakehouse con Workday Data Lake. Para acceder a otros catálogos, consulta Catálogos admitidos.

Limitaciones y consideraciones

Ten en cuenta lo siguiente cuando accedas a un Workday Data Lake:

  • Solo lectura: Los catálogos federados en Lakehouse son vistas de solo lectura del catálogo remoto. Para crear, actualizar o borrar recursos, debes usar Workday directamente.
  • Enrutamiento de red: Las conexiones y las consultas se enrutan de forma segura a través de Internet pública.
  • Actualidad de los datos: La marca --refresh-interval determina la frecuencia con la que Lakehouse sincroniza los metadatos. El valor debe ser 0s (inhabilitado) o, al menos, 300s (5 minutos). A medida que aumenta la cantidad de espacios de nombres y tablas en un catálogo, las actualizaciones de metadatos en segundo plano tardan más en completarse. Si la actualización anterior supera el intervalo programado, el sistema omite el ciclo actual y se reanuda en el siguiente intervalo programado.
  • Ubicación conjunta: Para evitar problemas de conectividad y minimizar la latencia y los costos de transferencia de datos, crea el catálogo federado y el secreto regional en la región deGoogle Cloud más cercana a la región en la que reside tu instancia de Workday.

Flujo de trabajo general

Para acceder a los datos de varias nubes 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, crea un usuario del sistema de integración (ISU) y un cliente de API para las integraciones.
    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 Workday Data Lake remoto.

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 la siguiente configuración:

    1. Crea un usuario del sistema de integración (ISU): Ejecuta la tarea Create Integration System User para crear una cuenta dedicada que Lakehouse usa para sincronizar recursos.
    2. Habilita el acceso a Workday Data Lake para la ISU: Otorga a la ISU acceso a Workday Data Lake. Comunícate con el equipo de asistencia de Workday para habilitar este acceso. No puedes realizar este paso por tu cuenta. Espera a que Workday configure el acceso en tu arrendatario de Workday antes de continuar.
    3. Register API Client for Integrations: Ejecuta la tarea Register API Client for Integrations.
    4. Guarda el ID y el secreto del cliente: Guarda el ID y el secreto del cliente de OAuth para el siguiente paso.
    5. Genera un token de actualización que no venza: En el cliente de API para integraciones, usa Administrar tokens de actualización para integraciones para generar un token de actualización que no venza para la ISU.
    6. Guarda el token de actualización: Guarda el token de actualización generado para el siguiente paso.

  2. Crea un archivo JSON llamado credentials.json con los datos guardados 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 región de Google Cloud donde 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

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. Para minimizar la latencia y los costos de transferencia de datos, selecciona la región de Google Cloudmás cercana a tu instancia de Workday. Esta región debe ser la misma en la que almacenaste tu secreto.
  • 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 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 otorgar a esta cuenta de servicio el rol de descriptor de acceso a secretos de Secret Manager (roles/secretmanager.secretAccessor) en el secreto que creaste anteriormente. Es posible que las nuevas políticas de IAM tarden unos minutos en aplicarse.

Console

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

    [Ir a Lakehouse][5]

  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?