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

Casos de uso

Conectar Lakehouse a Workday Data Lake admite varios casos de uso clave:

  • Unifica las estadísticas: Correlaciona los datos de RR.HH. y compensación de Workday con los datos de Google 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 copias: Analiza los datos de compras y cuentas por pagar de Workday junto con los datos de logística y de inventario almacenados en Google 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 sobre el acceso a los datos multinube para comprender cómo funciona.
  3. Revisa los catálogos compatibles para verificar la compatibilidad.
  4. Comprende cómo usar los secrets regionales de Secret Manager para autenticarte en Workday Data Lake.
  5. Comunícate con los administradores de Workday Data Lake 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 tardar en resolverse.
  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, 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

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

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

    11.

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:

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.
  • 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 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 Data Lake y Workday.
    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 a la cuenta de servicio del catálogo acceso 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. 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.
  4. Configura 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 de Workday remoto.

Configura la autenticación

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

  1. En Workday, completa lo siguiente:

    1. Configura el data lake.
    2. Registra el cliente de API para Data Lake (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 generado 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 el secreto y el 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 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 el archivo credentials.json de forma segura 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: Es la región de 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 catálogo federado.

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

    1. En la lista Fuente del catálogo federado, 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 está 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. Opcional: En Almacenamiento en caché multinube, selecciona Habilitar el almacenamiento en caché multinube para almacenar en caché los archivos remotos en la región deGoogle 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.
    5. 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, my_company_tenant.
    2. En la sección Método de autenticación, en el campo Secreto de Secret Manager, ingresa el nombre del recurso de tu secreto 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 deben actualizar los metadatos del catálogo (por ejemplo, 300). Para inhabilitar la actualización de metadatos 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 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" \
    --cross-cloud-cache="CROSS_CLOUD_CACHE_MODE"

Reemplaza lo siguiente:

  • FEDERATED_CATALOG_NAME: Es un nombre para tu 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 el Secret. Para minimizar la latencia y los costos de transferencia de datos, haz lo siguiente cuando selecciones una región:
    • Si tu instancia de Workday está en 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 exactamente la misma región.
  • 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 usuario de Workday.
  • REFRESH_INTERVAL: Es opcional y especifica la frecuencia con la que se actualiza 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 más 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 predeterminado es de 5 minutos (300s). Si estableces el valor en 0s, se inhabilita la actualización de metadatos en segundo plano.
  • NAMESPACE_FILTERS: Es opcional y se trata de 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.
  • 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.

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 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, en el banner de alerta, haz clic en Otorgar permisos de secretos.

    Lakehouse otorga el rol roles/secretmanager.secretAccessor en el Secret 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 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 haya sincronizado tus espacios de nombres y tablas.

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

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

  2. Confirma que los espacios de nombres estén sincronizados:

    gcloud 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?