Configura la conexión entre nubes para Workday Data Lake

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 integrando 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 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.

Limitaciones y consideraciones

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

  • 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), por lo que 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 cuanto más recursos de espacio 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 intervalo siguiente.
  • Almacenamiento en caché de Lakehouse: El almacenamiento en caché de Lakehouse se habilita automáticamente para todas las consultas entre nubes 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 la política de 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 de datos y cumplimiento: Cuando creas un catálogo o una conexión federados en una Google Cloud región, los datos almacenados en caché se guardan en reposo en esa región de destino. Si tus datos de la nube remota 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 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

  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?