Passo 6: execute a implementação

Esta página descreve o sexto passo para implementar a Data Foundation do Cortex Framework, a base do Cortex Framework. Neste passo, executa a implementação da base de dados do Cortex Framework.

Nota: os passos descritos nesta página foram concebidos especificamente para implementar a base de dados do Cortex Framework a partir do repositório oficial do GitHub.

Processo de compilação

Depois de configurar o ficheiro config.json conforme descrito no Passo 5: configure a implementação, siga estas instruções para criar o seu processo.

1. Execute o seguinte comando para se localizar no repositório clonado:

   cd cortex-data-foundation
   

2. Execute o comando de compilação com o contentor de registos de destino:

    gcloud builds submit \
    --substitutions=_GCS_BUCKET=LOGS_BUCKET,\
    _BUILD_ACCOUNT='projects/SOURCE_PROJECT/serviceAccounts/SERVICE_ACCOUNT@SOURCE_PROJECT.iam.gserviceaccount.com'
   

   Substitua o seguinte:

   • LOGS_BUCKET com o nome do contentor para o armazenamento de registos. A conta de serviço do Cloud Build precisa de acesso para os escrever aqui.
   • SOURCE_PROJECT com o projeto de origem.
   • SERVICE_ACCOUNT com o ID da conta de serviço.

3. Siga o processo de compilação principal consultando os registos no terminal ou na consola do Cloud Build, se tiver autorizações suficientes. Consulte as seguintes imagens para mais referências.

   

   Figura 1. Exemplo de visualização do progresso dos registos no terminal.

   

   Figura 2. Exemplo de visualização do progresso dos registos na consola.

4. Acompanhe os passos de compilação da criança acionados a partir da consola do Cloud Build ou nos registos criados a partir dos passos. Consulte as seguintes imagens para mais referências.

   

   Figura 3. Exemplo de acompanhamento dos passos de compilação da criança na consola.

   

   Figura 4. Exemplo de acompanhamento dos passos de compilação secundários nos registos.

5. Identifique problemas com compilações individuais. Corrija os erros, se existirem. Recomendamos que cole o SQL gerado no BigQuery para identificar e corrigir os erros. A maioria dos erros está relacionada com campos selecionados, mas não presentes na origem replicada. A IU do BigQuery ajuda a identificar e comentar essas linhas.

   

   Figura 5. Exemplo de identificação de problemas através dos registos do Cloud Build.

Mova ficheiros para o contentor DAG do Cloud Composer (Airflow)

Se optou por gerar ficheiros de integração ou CDC e tiver uma instância do Cloud Composer (Airflow), pode movê-los para o respetivo contentor final com o seguinte comando:

  gcloud storage -m cp -r  gs://OUTPUT_BUCKET/dags/ gs://COMPOSER_DAG_BUCKET/
  gcloud storage -m cp -r  gs://OUTPUT_BUCKET/data/ gs://COMPOSER_DAG_BUCKET/

Substitua o seguinte:

• OUTPUT_BUCKET com o contentor de saída.
• COMPOSER_DAG_BUCKET com o contentor DAG do Cloud Composer (Airflow).

Nota: este passo só se aplica se tiver uma instância do Airflow em execução, uma vez que o Airflow é usado frequentemente para gerir e orquestrar pipelines de dados.

Personalize e prepare-se para a atualização

Muitos clientes empresariais têm personalizações específicas dos respetivos sistemas, como documentos adicionais num fluxo ou tipos específicos de um registo. Estes são específicos para cada cliente e configurados por analistas funcionais à medida que surgem as necessidades empresariais.

O Cortex usa etiquetas ## CORTEX-CUSTOMER no código para indicar locais onde é provável que sejam necessárias personalizações deste tipo. Use o comando grep -R CORTEX-CUSTOMER para verificar todos os comentários ## CORTEX-CUSTOMER que deve personalizar.

Além das etiquetas CORTEX-CUSTOMER, pode ter de personalizar ainda mais o seguinte, confirmando todas estas alterações com uma etiqueta clara no código para o seu próprio repositório bifurcado ou clonado:

• Adicionar regras empresariais.
• Adicionar outros conjuntos de dados e juntá-los a vistas ou tabelas existentes
• Reutilizar os modelos fornecidos para chamar APIs adicionais.
• Modificar scripts de implementação.
• Aplicar mais conceitos de malha de dados.
• Adaptar algumas tabelas ou APIs de destino para incluir campos adicionais não incluídos na norma.

Adote um pipeline de CI/CD que funcione para a sua organização para manter estas melhorias testadas e a sua solução geral num estado fiável e robusto. Um pipeline pode reutilizar os scripts para acionar a implementação integral periodicamente ou com base em operações git, consoante o repositório escolhido, automatizando as compilações.cloudbuild.yaml

Use o ficheiroconfig.json para definir diferentes conjuntos de projetos e conjuntos de dados para ambientes de desenvolvimento, teste e produção. Use testes automatizados com os seus próprios dados de amostra para garantir que os modelos produzem sempre o que espera.

Etiquetar as suas próprias alterações de forma visível na ramificação ou no clone de um repositório, juntamente com alguma automatização de implementação e testes, ajuda a fazer atualizações.

Apoio técnico

Se tiver problemas ou pedidos de funcionalidades relacionados com estes modelos ou implementadores, crie um problema no repositório Cortex Framework Data Foundation. Para ajudar a recolher as informações necessárias, execute support.sh a partir do diretório clonado. Este guião fornece-lhe orientações ao longo de uma série de passos para ajudar a resolver problemas.

Para quaisquer pedidos ou problemas relacionados com a Cortex Framework, aceda à secção de apoio técnico na página Vista geral.

Blocos e painéis de controlo do Looker

Tire partido dos blocos e painéis de controlo do Looker disponíveis. Estes são essencialmente modelos de dados reutilizáveis para padrões analíticos comuns e origens de dados para o Cortex Framework. Para mais informações, consulte o artigo Vista geral dos blocos e painéis de controlo do Looker.