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

Com uma conexão entre nuvens ao data lake do Workday, é possível consultar os dados do Workday diretamente no Google Cloud. Essa capacidade unifica a análise de dados ao integrar suas fontes de dados externas ao ambienteGoogle Cloud atual.

Depois, use o Lakehouse sem fronteiras para gerenciar o acesso aos seus dados federados.

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

  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.

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:

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.

Limitações e considerações

Esta seção lista as limitações e considerações para acessar dados entre nuvens.

  • Somente leitura:os catálogos federados no Lakehouse são visualizações somente leitura do catálogo remoto. A manipulação de recursos (como criação, atualização ou exclusão) não é compatível e precisa ser feita diretamente no catálogo remoto.
  • Atualização de dados:a flag --refresh-interval de um catálogo federado determina a frequência de sincronização dos metadados. O valor precisa ser 0s (desativado) ou pelo menos 300s (5 minutos). Uma atualização de metadados em segundo plano de um catálogo pode levar mais tempo quanto mais namespaces e recursos de tabela houver. Se a atualização anterior exceder o tempo, a atual será ignorada, mas a próxima será agendada no intervalo seguinte.
  • Cache do Lakehouse:o cache do Lakehouse é ativado automaticamente para todas as consultas entre nuvens, economizando custos de saída ao armazenar blocos de dados localmente em Google Cloud. As chaves de criptografia gerenciadas pelo cliente (CMEK) não são compatíveis com o armazenamento em cache. Os dados 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 qualquer tabela na consulta, o armazenamento em cache será desativado automaticamente para essa consulta. Para mais informações, consulte Armazenamento em cache inteligente.
  • Residência e compliance de dados:ao criar um catálogo ou uma conexão federada em uma região do Google Cloud , os dados em repouso armazenados em cache ficam nessa região de destino. Se os dados remotos da nuvem estiverem em uma jurisdição diferente, verifique se o armazenamento em cache entre regiões está em conformidade com os requisitos de residência de dados e conformidade regulatória da sua organização.

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

  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