Esta página foi traduzida pela API Cloud Translation.

Recomendações de atualizações

Esta página descreve as recomendações para atualizar para novas versões a partir da base de dados do Cortex Framework personalizada. Em cada lançamento, a equipa do Cortex compromete-se a minimizar as interrupções enquanto adiciona novas funcionalidades à estrutura do Cortex. As novas atualizações dão prioridade à compatibilidade com versões anteriores. No entanto, este guia ajuda a minimizar os possíveis problemas.

A base de dados da framework Cortex oferece um conjunto de conteúdo e modelos predefinidos para acelerar o valor dos dados replicados no BigQuery. As organizações adaptam estes modelos, módulos, SQL, scripts Python, pipelines e outro conteúdo fornecido para se adequarem às suas necessidades.

Componentes principais

O conteúdo da base de dados do Cortex Framework foi concebido com base no princípio da abertura. As organizações podem usar as ferramentas que melhor se adequam às suas necessidades quando trabalham com os modelos de dados do BigQuery fornecidos. A única plataforma da qual a base tem uma forte dependência é o BigQuery. Todas as outras ferramentas podem ser trocadas conforme necessário:

Integração de dados: pode tirar partido de qualquer ferramenta de integração que tenha interconectividade com o BigQuery, desde que consiga replicar tabelas e estruturas não processadas. Por exemplo, as tabelas não processadas devem ter um esquema semelhante ao das tabelas criadas no SAP (os mesmos nomes, campos e tipos de dados). Além disso, a ferramenta de integração deve poder fornecer serviços de transformação básicos, como a atualização dos tipos de dados de destino para compatibilidade com o BigQuery, bem como a adição de campos adicionais, como a indicação de tempo ou a flag de operações, para realçar os registos novos e alterados.
Tratamento de dados: os scripts de tratamento de captura de dados de alterações (CDC) funcionam com o Cloud Composer (ou o Apache Airflow) são opcionais. Por outro lado, as declarações SQL são produzidas separadamente dos ficheiros específicos do Airflow, sempre que possível, para que os clientes possam usar os ficheiros SQL separados noutra ferramenta, conforme necessário.
Visualização de dados: embora sejam fornecidos modelos de painéis de controlo do Looker, estes contêm visualizações e lógica mínima. No entanto, a lógica principal permanece disponível na base de dados no BigQuery por predefinição para criar visualizações com a ferramenta de relatórios da sua preferência.

Principais vantagens

A base de dados do Cortex Framework foi concebida para se adaptar a várias necessidades empresariais. Os seus componentes são criados com flexibilidade, o que permite às organizações adaptar a plataforma aos seus requisitos específicos e obter as seguintes vantagens:

Abertura: integra-se perfeitamente com várias ferramentas de integração, processamento e visualização de dados além do BigQuery.
Personalização: as organizações podem modificar e expandir componentes pré-criados, como vistas SQL, para corresponderem aos respetivos modelos de dados e lógica empresarial.
Otimização do desempenho: as técnicas como a partição, as verificações de qualidade dos dados e o agrupamento podem ser ajustadas com base nas cargas de trabalho individuais e nos volumes de dados.
Retrocompatibilidade: o Cortex esforça-se por manter a retrocompatibilidade em lançamentos futuros, minimizando a interrupção das implementações existentes. Para ver informações sobre as alterações de versão, consulte as notas de lançamento.
Contribuição da comunidade: incentiva a partilha de conhecimentos e a colaboração entre os utilizadores.

Processo de atualização

As secções seguintes partilham as instruções de uma forma através da qual os programadores podem manter o respetivo código atualizado com o repositório Data Foundation do Cortex Framework enquanto mantêm as personalizações. Utilização dos scripts de implementação pré-entregues em pipelines de CI/CD. No entanto, as organizações podem usar ferramentas e metodologias alternativas para se adequarem às suas preferências, como o Dataform ou ferramentas de automatização fornecidas pelos diferentes anfitriões do Git, como as ações do GitHub.

Configure o seu repositório

Esta secção descreve uma abordagem para configurar o seu repositório. Antes de seguir estes passos, recomendamos que tenha um conhecimento sólido do Git.

Criar uma ramificação do repositório principal: crie uma ramificação do repositório da base de dados do Cortex Framework. O fork mantém esse repositório a receber atualizações do Google Cloud repositório e um repositório separado para o principal da empresa.
Criar repositório da empresa: estabeleça um novo anfitrião Git para o repositório da sua empresa (por exemplo, Cloud Source). Crie um repositório com os mesmos nomes que o repositório bifurcado no novo anfitrião.
Inicialize o repositório da empresa: copie o código do repositório bifurcado para o repositório da empresa recém-criado. Adicione o repositório original bifurcado como um repositório remoto a montante com o seguinte comando e verifique se o repositório remoto foi adicionado. Isto estabelece uma associação entre o repositório da sua empresa e o repositório original.
```
git remote add google <<remote URL>>
git remote -v
git push --all google
```
Valide a configuração do repositório: certifique-se de que o repositório da sua empresa contém o código e o histórico clonados. Deverá ver os dois repositórios remotos, origin e o que adicionou depois de usar o comando:
```
git remote -v:
```
Agora, tem o repositório, o repositório da empresa, onde os programadores podem enviar as respetivas alterações. Os programadores podem agora clonar e trabalhar em ramificações no novo repositório.

Una as suas alterações com um novo lançamento do Cortex

Esta secção descreve o processo de união das alterações do repositório da empresa e das alterações provenientes do repositório Google Cloud .

Atualize os forks: clique em Sincronizar fork para atualizar os forks do seu repositório com as alterações do repositório Google Cloud . Por exemplo, são feitas as seguintes alterações ao repositório da empresa. Além disso, foram feitas outras alterações no repositório da base de dados pela equipa de engenharia de dados numa nova versão. Google Cloud
- Criou e incorporou a utilização de uma nova vista em SQL
- Vistas existentes modificadas
- Substituímos um script completamente pela nossa própria lógica
A seguinte sequência de comandos adiciona o repositório de ramificação como um repositório remoto a montante para extrair a versão atualizada do GitHub e extrai o respetivo ramo principal como GitHub-main. Em seguida, este exemplo extrai o ramo principal do repositório da empresa no Google Cloud Source e cria um ramo para a união denominado merging_br.
```
git remote add github <<github fork>>
git fetch github main
git checkout -b github-main github/main
git checkout  main
git checkout -b merging_br
```
Existem várias formas de criar este fluxo. O processo de união também pode ocorrer no fork no GitHub, ser substituído por uma nova base em vez de uma união, e o ramo de união também pode ser enviado como um pedido de união. Estas variações do processo dependem das políticas organizacionais atuais, da profundidade das alterações e da conveniência.

Com esta configuração, pode comparar as alterações recebidas com as alterações locais. Recomendamos que use uma ferramenta num IDE gráfico à sua escolha para ver as alterações e escolher o que é unido. Por exemplo, o Visual Studio.

Recomendamos que sinalize as personalizações com comentários que se destaquem visualmente para facilitar o processo de comparação.
Inicie o processo de união: use a ramificação criada (neste exemplo, é a ramificação denominada merging_br) para convergir todas as alterações e rejeitar ficheiros. Quando estiver tudo pronto, pode voltar a unir esta ramificação à ramificação principal ou a outra ramificação do repositório da sua empresa para criar um pedido de união. A partir dessa ramificação de união que foi extraída do repositório principal da sua empresa (git checkout merging_br), una as alterações recebidas da ramificação remota.
```
    ## git branch -a
    ## The command shows github-main which was created from the GitHub fork
    ## You are in merging_br

    git merge github-main

    ## If you don't want a list of the commits coming from GitHub in your history, use `--squash`
```
Este comando gera uma lista de conflitos. Use a comparação gráfica do IDE para compreender as alterações e escolher entre atual, recebido e ambos. É aqui que ter um comentário no código sobre as personalizações se torna útil. Opte por rejeitar todas as alterações, eliminar ficheiros que não quer unir e ignorar alterações a vistas ou scripts que já personalizou.

Unir alterações: depois de decidir as alterações a aplicar, verifique o resumo e confirme-as com o comando:

    git status
    ## If something doesn't look right, you can use git rm or git restore accordingly
    git add --all #Or . or individual files
    git commit -m "Your commit message"

Se não se sentir seguro em relação a algum passo, consulte o artigo Git basic undoing things.

Teste e implemente: até agora, só está a fazer a união numa ramificação "temporária". Neste ponto, recomenda-se a execução de uma implementação de teste a partir dos scripts cloudbuild\*.yaml para garantir que tudo está a ser executado conforme esperado. Os testes automatizados podem ajudar a simplificar este processo. Quando esta ramificação de união estiver do seu agrado, pode consultar a ramificação de destino principal e unir a ramificação merging_br à mesma.