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

Visualizar

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Observação: para receber suporte durante a prévia, envie um e-mail para [e-mail].

Com uma conexão entre nuvens ao data lake do Workday, você pode consultar os dados do Workday diretamente no Google Cloud. Em seguida, use o Lakehouse para gerenciar o acesso e analisar seus dados federados sem copiar ou mover informações.

Casos de uso

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

• Unificar a análise: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 a estrutura de agente do Google com dados do BigQuery ML e do Workday HR para prever a retenção de funcionários.
• Transmita dados em tempo real sem cópia:analise dados de compras e contas a pagar do Workday, além de dados de logística e inventário armazenados emGoogle Cloud para gerar relatórios sobre 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. Analise 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. Confira com os administradores do data lake do Workday 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 tempo para ser resolvido.
Faça login na sua conta do Google Cloud . Se você começou a usar o Google Cloud, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Verify that billing is enabled for your Google Cloud project.

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

Verify that billing is enabled for your Google Cloud project.

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

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: peça a um administrador do Secret Manager para criar o secret e conceder acesso a ele. Isso segue o princípio do menor privilégio, garantindo que você tenha acesso apenas a esse secret do Lakehouse, em vez de acesso amplo a todos os secrets do projeto.

Detalhes do catálogo compatíveis

Neste documento, você encontra instruções para configurar o Lakehouse com o Workday Data Lake. Para acessar outros catálogos, consulte Catálogos compatíveis.

Limitações e considerações

Ao acessar um Workday Data Lake, tenha em mente o seguinte:

• Somente leitura:os catálogos federados no Lakehouse são visualizações somente leitura do catálogo remoto. Para criar, atualizar ou excluir recursos, use o Workday diretamente.
• Roteamento de rede:as conexões e consultas são roteadas com segurança pela Internet pública.
• Atualização de dados:a flag --refresh-interval determina a frequência com que o lakehouse sincroniza os metadados. O valor precisa ser 0s (desativado) ou pelo menos 300s (5 minutos). À medida que o número de namespaces e tabelas em um catálogo aumenta, as atualizações de metadados em segundo plano levam mais tempo para serem concluídas. Se a atualização anterior exceder o intervalo programado, o sistema vai pular o ciclo atual e retomar no próximo intervalo programado.
• Colocação:para evitar problemas de conectividade e minimizar a latência e os custos de transferência de dados, crie o catálogo federado e o segredo regional naGoogle Cloud região mais próxima de onde sua instância do Workday está localizada.

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 segredos e crie um catálogo federado no Lakehouse.
   1. No Workday, crie um usuário do sistema de integração (ISU) e um cliente de API para integrações.
   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:confira se o Lakehouse consegue se conectar ao catálogo remoto e sincronizar metadados.
3. Consultar dados:execute consultas nos seus dados federados usando o BigQuery ou o Serviço Gerenciado para Apache Spark. 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 data lake remoto do Workday.

Configurar a autenticação

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

1. No Workday, conclua a seguinte configuração:

   1. Crie um usuário do sistema de integração (ISU): execute a tarefa Criar usuário do sistema de integração para criar uma conta dedicada que o Lakehouse usa para sincronizar recursos.
   2. Ative o acesso ao Workday Data Lake para a ISU:conceda à ISU acesso ao Workday Data Lake. Entre em contato com o suporte do Workday para ativar esse acesso. Não é possível realizar essa etapa por conta própria. Aguarde o Workday configurar o acesso no seu locatário do Workday antes de continuar.
   3. Registrar cliente da API para integrações:execute a tarefa Registrar cliente da API para integrações.
   4. Salve o ID do cliente e a chave secreta do cliente:salve o ID e a chave secreta do cliente OAuth para a próxima etapa.
   5. Gerar um token de atualização que não expira:no cliente de API para integrações, use Gerenciar tokens de atualização para integrações para gerar um token de atualização que não expira para o ISU.
   6. Salve o token de atualização:salve o token de atualização gerado para a próxima etapa.

2. Crie um arquivo JSON chamado credentials.json com os dados salvos da etapa anterior:

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

   Substitua:

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

3. Configure o endpoint regional do 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 segredo 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 onde você armazena seu secret do Secret Manager. Por exemplo, us-east4.

4. Faça upload da carga útil 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 de forma segura para evitar 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 Google Cloud em que você cria o secret, por exemplo, us-east4.
   • PROJECT_ID: o ID do projeto do Google Cloud .

Criar um catálogo federado

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

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. Para minimizar a latência e os custos de transferência de dados, selecione a região Google Cloudmais próxima da sua instância do Workday. Essa região precisa ser a mesma em que você armazenou o secret.
• WORKDAY_SECRET_NAME: o nome do secret do Workday no Secret Manager.
• WORKDAY_BASE_URL: o URL 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 com que as informações do catálogo são atualizadas. 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 seu conjunto de dados mais atual. Se omitido, o intervalo de atualizaçã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 a serem federados, por exemplo, finance,hr. Se omitido, o Lakehouse inclui todos os namespaces.

Concluir a configuração da autenticação

Depois de criar 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 Google Cloud , acesse Lakehouse.

   [Acessar o Lakehouse][5]

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

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

   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 alpha 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 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 seu catálogo federado no Lakehouse.

Verifique a conexão

Verifique se a atualização em segundo plano dos metadados foi concluída com sucesso e sincronizou seus namespaces e tabelas.

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

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

2. Confirme se os namespaces estão sincronizados:

   gcloud alpha 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.
• Resolver problemas de acesso aos dados entre nuvens.