Configurar a conexão entre nuvens para o Workday Data Lake

Uma conexão entre nuvens com o Workday Data Lake permite consultar os dados do Workday diretamente no Google Cloud. Esse recurso unifica sua análise de dados ao integrar suas fontes de dados externas ao ambiente doGoogle Cloud .

Depois de configurar a conexão, você pode gerenciar o acesso aos dados federados no Lakehouse sem fronteiras.

Casos de uso

A conexão do Lakehouse ao Workday Data Lake oferece suporte a vários casos de uso importantes:

• Unificar análises: correlacione os dados de RH e remuneração do Workday com os dados doGoogle Cloud , por exemplo, para fornecer contexto para vendas e cotas.
• Aproveite o ecossistema do Google Cloud: por exemplo, use o framework de agentes do Google com o BigQuery ML e os dados de RH do Workday para prever a retenção de funcionários.
• Transmita dados em tempo real sem cópia: analise os dados de compras e contas a pagar do Workday junto com os dados de logística e inventário armazenados noGoogle Cloud repositório de dados para relatar ineficiências na cadeia de suprimentos e otimizar os custos dos fornecedores.

Antes de começar

1. Leia a visão geral do Lakehouse para entender como ele gerencia o acesso aos dados.
2. Leia sobre como acessar dados entre nuvens para entender como isso funciona.
3. Consulte os catálogos compatíveis para verificar a compatibilidade.
4. Entenda como usar secrets regionais do Secret Manager para autenticar com o Workday Data Lake.
5. Entre em contato com os administradores do Workday Data Lake para configurar a autenticação conforme descrito neste documento. Os administradores talvez precisem entrar em contato com o suporte do Workday para ativar o acesso ao Data Lake, o que pode levar algum tempo.
Faça login na sua conta do Google Cloud . Se você começou a usar o Google Cloudagora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US $300 em créditos para executar, testar e implantar cargas de trabalho sem custos financeiros.

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

Funções exigidas

Para receber as permissões necessárias para configurar o acesso entre nuvens, peça ao administrador para conceder a você os seguintes papéis do IAM no projeto:

• Gerenciar catálogos do Lakehouse: Administrador do BigLake (roles/biglake.admin)
• Gerenciar secrets: Administrador do Secret Manager (roles/secretmanager.admin)

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

Atenção : ao usar a autenticação baseada em secret, para seguir o princípio de privilégio mínimo e evitar conceder acesso a todos os secrets no projeto, peça para um administrador do Secret Manager criar o secret para você e conceder permissões para modificar apenas esse secret específico para o Lakehouse.

Limitações e considerações

Nesta seção, listamos as limitações e considerações para acessar dados entre nuvens.

• VPC Service Controls: se o projeto que contém o endpoint do catálogo federado ou o bucket do Cloud Storage estiver dentro de um perímetro de serviço do VPC Service Controls, será necessário configurar regras de saída ou entrada. Para mais informações, consulte Usar o VPC Service Controls com endpoints de catálogo federado.
• Somente leitura: os catálogos federados no Lakehouse são visualizações somente leitura do catálogo remoto. A manipulação de recursos (como criar, atualizar ou excluir recursos) não é compatível e precisa ser realizada diretamente no catálogo remoto.
• Atualização de dados: a flag --refresh-interval de um catálogo federado determina a frequência com que os metadados são sincronizados. O valor precisa ser 0s (desativado) ou pelo menos 300s (5 minutos). A atualização de metadados em segundo plano de um catálogo pode levar mais tempo quanto mais recursos de namespace e tabela houver. Se a atualização anterior for excedida, a atual será ignorada, e a próxima será programada para o intervalo seguinte. As consultas usam os metadados do catálogo sincronizados mais recentemente. Portanto, as alterações feitas no catálogo remoto, como novas tabelas, atualizações de esquema ou dados recém-confirmados, não ficam visíveis no Lakehouse até que a próxima atualização de metadados em segundo plano seja concluída.
• Armazenamento em cache do Lakehouse: o armazenamento em cache entre nuvens está desativado por padrão (--cross-cloud-cache=disabled). É possível ativar ou desativar o armazenamento em cache no nível do catálogo federado ou da conexão. As chaves de criptografia gerenciadas pelo cliente (CMEK) não são compatíveis com o armazenamento em cache. Os arquivos armazenados em cache são criptografados usando Google-owned and Google-managed encryption keys. Se a restrição da política da organização constraints/gcp.restrictNonCmekServices for aplicada a uma tabela na consulta, o armazenamento em cache será desativado automaticamente para essa consulta. Para mais informações, consulte Armazenamento em cache inteligente.
• Residência de dados e compliance: quando você ativa o armazenamento em cache entre nuvens em um catálogo federado ou conexão federada, o Lakehouse armazena temporariamente os arquivos em cache em repouso na Google Cloud região em que a consulta é executada. Se os arquivos de nuvem remotos estiverem em uma jurisdição diferente, verifique se o armazenamento em cache entre regiões atende aos requisitos de residência de dados e compliance da sua organização antes de ativá-lo.

Fluxo de trabalho geral

Para acessar dados entre nuvens no Workday Data Lake, siga estas etapas gerais:

1. Configurar a federação: configure a autenticação baseada em secrets e crie um catálogo federado no Lakehouse.
   1. No Workday, configure o Data Lake e as credenciais da API Workday.
   2. Crie um secret no Secret Manager com suas credenciais da API Workday.
   3. Crie um catálogo federado no Lakehouse e conceda à conta de serviço do catálogo acesso ao secret.
2. Verifique a conexão: verifique se o Lakehouse pode se conectar ao catálogo remoto e sincronizar metadados.
3. Consultar dados: execute consultas nos dados federados usando o BigQuery ou o Serviço Gerenciado para Apache Spark. Se quiser, ative o armazenamento em cache entre nuvens no catálogo federado para reduzir os custos de saída entre nuvens e acelerar as consultas subsequentes. Para mais informações, consulte Consultar dados remotos.
4. Configurar permissões: use o Identity and Access Management (IAM) para gerenciar quem pode visualizar e consultar os dados federados.

Configurar a federação

Para consultar seus dados, configure um catálogo federado do Lakehouse que se conecte ao seu data lake remoto do Workday.

Configurar a autenticação

A federação requer autenticação no Workday Data Lake remoto usando credenciais armazenadas com segurança em secrets regionais do Secret Manager.

1. No Workday, faça o seguinte:

   1. Configurar o data lake.
   2. Registrar o cliente de API para o Data Lake (concessão de token de atualização).
   3. Configurar a segurança e as exportações de tabelas no data lake.

   Para instruções completas sobre como concluir esse processo, consulte Começar a usar o Workday Data Lake.

2. Crie um arquivo JSON chamado credentials.json com as credenciais da etapa anterior:

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

   Substitua:

   • CLIENT_ID: o ID do cliente OAuth do seu cliente de API do Workday para integrações.
   • CLIENT_SECRET: a chave secreta do cliente OAuth do seu cliente da API Workday para integrações.
   • REFRESH_TOKEN: o token de atualização sem validade gerado para o ISU do Workday.

3. Configure o endpoint regional para o Secret Manager:

   Por padrão, o Secret Manager usa um endpoint global. Para evitar problemas de conectividade e minimizar a latência e os custos de transferência de dados, crie o secret e o catálogo na mesma região. Para substituir o endpoint global padrão por um secret regional, execute o seguinte comando:

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

   Substitua:

   • REGION: a região do Google Cloud em que você armazena o secret do Secret Manager. Por exemplo, us-east4.

4. Faça upload do payload para o Secret Manager:

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

5. Exclua o arquivo credentials.json com segurança para evitar o vazamento de credenciais.

   Substitua:

   • WORKDAY_SECRET_NAME: um nome exclusivo para o secret do Workday no Secret Manager, por exemplo, workday-api-credentials ou workday-data-lake-secret.
   • REGION: a região do Google Cloud em que você criará o secret, por exemplo, us-east4.
   • PROJECT_ID: o ID do projeto do Google Cloud .

Criar um catálogo federado

Crie o catálogo federado usando o console do Google Cloud ou a CLI do gcloud:

Console

Para criar um catálogo federado, siga estas etapas:

1. No console do Google Cloud , acesse Lakehouse.

   Acessar o Lakehouse

2. Clique em Criar catálogo e selecione Catálogo federado.

   A página Criar catálogo federado é exibida.

3. Na seção Configuração do catálogo:

   1. Na lista Origem do catálogo federado, selecione Workday (Data Lake).
   2. No campo Nome do catálogo (no Lakehouse), insira um nome para o catálogo.
   3. Na lista Local dos dados, selecione a região em que você quer criar o catálogo federado, por exemplo, us-east4. Ela precisa corresponder à região do secret do Secret Manager. Para minimizar a latência e os custos de transferência de dados, faça o seguinte ao selecionar uma região:
      • Se a instância do Workday estiver na Amazon Web Services (AWS), selecione a Google Cloud região mais próxima da sua região da AWS.
      • Se a instância do Workday estiver em Google Cloud, selecione a mesma região.
   4. Opcional: em Armazenamento em cache entre nuvens, selecione Ativar o armazenamento em cache entre nuvens para armazenar em cache arquivos remotos na região Google Cloud do catálogo e acelerar o desempenho da consulta. Também é possível atualizar essa configuração mais tarde editando os detalhes do catálogo. Para mais informações sobre como o armazenamento em cache funciona, retenção e preços, consulte Armazenamento em cache inteligente.
   5. Clique em Continuar.

4. Na seção Detalhes da conexão:

   1. Na seção Detalhes do catálogo remoto:
      • No campo URL de base do Workday, insira o URL de base da sua instância do Workday. Por exemplo, impl-services1.wd12.myworkday.com ou wd501.myworkday.com.
      • No campo Locatário do Workday, insira o nome do locatário do Workday, por exemplo, my_company_tenant.
   2. Na seção Método de autenticação, no campo Secret do Secret Manager, insira o nome do recurso do secret regional. Use o seguinte formato: projects/PROJECT_ID/locations/REGION/secrets/WORKDAY_SECRET_NAME.
   3. Na seção Intervalo de atualização, no campo Intervalo de atualização, insira a frequência (em segundos) de atualização dos metadados do catálogo (por exemplo, 300). Para desativar a atualização de metadados em segundo plano, insira 0.

5. Clique em Criar.

CLI da gcloud

Para criar um catálogo federado usando a CLI gcloud, execute o seguinte 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"

Substitua:

• FEDERATED_CATALOG_NAME: um nome para o catálogo federado no Lakehouse.
• PROJECT_ID: o ID do projeto do Google Cloud .
• REGION: a região do Lakehouse em que você cria o catálogo federado, por exemplo, us-east4. Essa região precisa ser a mesma em que você armazenou o secret. Para minimizar a latência e os custos de transferência de dados, faça o seguinte ao selecionar uma região:
  • Se a instância do Workday estiver na AWS, selecione a região doGoogle Cloud mais próxima da sua região da AWS.
  • Se a instância do Workday estiver em Google Cloud, selecione exatamente a mesma região.
• WORKDAY_SECRET_NAME: o nome do secret do Workday no Secret Manager.
• WORKDAY_BASE_URL: o URL de base da sua instância do Workday. Por exemplo, impl-services1.wd12.myworkday.com ou wd501.myworkday.com.
• WORKDAY_TENANT: o nome do locatário do Workday.
• REFRESH_INTERVAL: opcional. Especifica a frequência de atualização das informações do catálogo. Defina esse valor como uma duração, por exemplo, 300s ou 5m. Intervalos mais curtos atualizam os dados com mais frequência, mas podem custar mais em chamadas de API. Intervalos mais longos podem custar menos, mas os dados consultados podem não refletir o conjunto de dados mais atual. Se omitido, o intervalo de atualização padrão será de 5 minutos (300s). Definir o valor como 0s desativa a atualização de metadados em segundo plano.
• NAMESPACE_FILTERS (opcional): uma lista separada por vírgulas de namespaces para federar, por exemplo, finance,hr. Se omitido, o Lakehouse inclui todos os namespaces.
• CROSS_CLOUD_CACHE_MODE: opcional: se o armazenamento em cache entre nuvens deve ser ativado no catálogo federado (enabled ou disabled). O padrão é disabled. Quando definido como enabled, o Lakehouse armazena em cache os arquivos remotos na região Google Cloud do catálogo. Para mais informações, consulte Armazenamento em cache inteligente.

Concluir a configuração da autenticação

Depois que você cria o catálogo, o Lakehouse provisiona uma conta de serviço exclusiva para ele, identificada como biglake-service-account na descrição do recurso.

É necessário conceder a essa conta de serviço o papel de acessador de secrets do Secret Manager (roles/secretmanager.secretAccessor) no secret que você criou anteriormente. Pode levar alguns minutos para que as novas políticas do IAM entrem em vigor.

Console

1. No console do Google Cloud , acesse Lakehouse.

   Acessar o Lakehouse

2. Clique no nome do catálogo federado que você criou para o Workday.

3. Na página Detalhes do catálogo, no banner de alerta, clique em Conceder permissões de secret.

   O Lakehouse concede o papel roles/secretmanager.secretAccessor no secret à conta de serviço provisionada.

CLI da gcloud

1. Conceda à conta de serviço do catálogo permissão para acessar o secret:

   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 se a conta de serviço do catálogo federado tem acesso ao secret, execute o seguinte 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"

   Na saída, verifique se a conta de serviço biglake-service-account tem o papel roles/secretmanager.secretAccessor.

Substitua:

• REGION: a região do Google Cloud em que você armazena o secret do Secret Manager e criou o catálogo federado, por exemplo, us-east4.
• WORKDAY_SECRET_NAME: o nome do secret do Workday no Secret Manager.
• PROJECT_ID: o ID do projeto do Google Cloud .
• FEDERATED_CATALOG_NAME: o nome do catálogo federado no Lakehouse.

Verifique a conexão

Verifique se a atualização de metadados em segundo plano foi concluída e se os namespaces e as tabelas foram sincronizados.

1. Verifique se o status de atualização indica sucesso:

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

2. Confirme se os namespaces estão sincronizados:

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

Substitua:

• PROJECT_ID: o ID do projeto do Google Cloud .
• FEDERATED_CATALOG_NAME: o nome do catálogo federado no Lakehouse.

A seguir

• Consultar dados remotos.
• Usar o VPC Service Controls com endpoints de catálogo federado.
• Resolver problemas de acesso a dados entre nuvens.