Esta página foi traduzida pela API Cloud Translation.

Recomendações de upgrade

Esta página descreve recomendações para fazer upgrade para novas versões de uma base de dados do Cortex Framework personalizada. Em cada lançamento, a equipe do Cortex se compromete a minimizar as interrupções enquanto adiciona novos recursos ao Cortex Framework. As novas atualizações priorizam a compatibilidade com versões anteriores. No entanto, este guia ajuda a minimizar os possíveis problemas.

A base de dados do Cortex Framework oferece um conjunto de modelos e conteúdo predefinidos para acelerar o valor dos dados replicados no BigQuery. As organizações adaptam esses modelos, módulos, SQL, scripts Python, pipelines e outros conteúdos fornecidos para atender às necessidades delas.

Principais componentes

O conteúdo da base de dados do Cortex Framework foi criado com o princípio da abertura em mente. As organizações podem usar as ferramentas que funcionam melhor para elas ao trabalhar com os modelos de dados do BigQuery fornecidos. A única plataforma em que a fundação tem uma dependência estreita é o BigQuery. Todas as outras ferramentas podem ser trocadas conforme necessário:

Integração de dados:qualquer ferramenta de integração que tenha interconectividade com o BigQuery pode ser aproveitada, desde que possa replicar tabelas e estruturas brutas. Por exemplo, as tabelas brutas precisam ter o mesmo esquema que foram criadas no SAP (mesmos nomes, campos e tipos de dados). Além disso, a ferramenta de integração precisa fornecer serviços básicos de transformação, como atualizar tipos de dados de destino para compatibilidade com o BigQuery, além de adicionar outros campos, como carimbo de data/hora ou sinalização de operações, para destacar registros novos e alterados.
Processamento de dados:os scripts de processamento de captura de dados alterados (CDC, na sigla em inglês) trabalham com o Cloud Composer (ou o Apache Airflow) são opcionais. Por outro lado, as instruções SQL são produzidas separadamente dos arquivos específicos do Airflow sempre que possível, para que os clientes possam usar os arquivos SQL separados em outra ferramenta, conforme necessário.
Visualização de dados:embora os modelos de painel do Looker sejam fornecidos e contenham visualizações e lógica mínima, a lógica principal permanece disponível na base de dados do BigQuery por design para criar visualizações com a ferramenta de relatórios escolhida.

Principais vantagens

A base de dados do Cortex Framework foi projetada para ser adaptável a várias necessidades de negócios. Os componentes são criados com flexibilidade, permitindo que as organizações adaptem a plataforma aos requisitos específicos e recebam os seguintes benefícios:

Abertura: integração perfeita 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 visualizações SQL, para corresponder aos modelos de dados e à lógica de negócios.
Otimização de desempenho:técnicas como particionamento, verificações de qualidade de dados e agrupamento podem ser ajustadas com base em cargas de trabalho e volumes de dados individuais.
Compatibilidade com versões anteriores:o Cortex se esforça para manter a compatibilidade com versões anteriores em versões futuras, minimizando a interrupção das implementações atuais. Para informações sobre mudanças de versão, consulte as notas da versão.
Contribuição da comunidade:incentiva o compartilhamento de conhecimento e a colaboração entre os usuários.

Atualizar processo

As seções a seguir compartilham as instruções de uma maneira em que os desenvolvedores podem manter o código atualizado com o repositório de dados do Cortex Framework, mantendo as personalizações. Uso dos scripts de implantação pré-entregues em pipelines de CI/CD. No entanto, as organizações podem usar ferramentas e metodologias alternativas para atender às preferências, como o Dataform ou ferramentas de automação fornecidas pelos diferentes hosts do Git, como as ações do GitHub.

Configurar seu repositório

Esta seção descreve uma abordagem para configurar seu repositório. Antes de seguir essas etapas, é recomendável ter um bom entendimento do Git.

Repositório principal Fork: crie um fork do repositório da base de dados do Cortex Framework. O fork continua fazendo com que esse repositório receba atualizações do repositório Google Cloud e um repositório separado para o repositório principal da empresa.
Criar repositório da empresa: estabeleça um novo host do Git para o repositório da empresa (por exemplo, o Cloud Source). Crie um repositório com os mesmos nomes do repositório bifurcado no novo host.
Inicializar 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 upstream com o comando a seguir e verifique se o controle remoto foi adicionado. Isso estabelece uma conexã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
```
Verificar a configuração do repositório: verifique se o repositório da empresa contém o código e o histórico clonados. Você vai ver os dois controles remotos, a origem e o que você adicionou depois de usar o comando:
```
git remote -v:
```
Agora você tem o repositório, o repositório da empresa, em que os desenvolvedores podem enviar as mudanças. Os desenvolvedores agora podem clonar e trabalhar em ramificações no novo repositório.

Mesclar suas alterações com uma nova versão do Cortex

Esta seção descreve o processo de mesclagem de mudanças do repositório da empresa e de mudanças do repositório Google Cloud .

Atualizar bifurcações: clique em Sincronizar bifurcação para atualizar as bifurcações do repositório com as mudanças do repositório Google Cloud . Por exemplo, as seguintes mudanças no repositório da empresa foram feitas. E houve algumas outras mudanças no repositório do Data Foundation por Google Cloud em uma nova versão.
- Criou e incorporou o uso de uma nova visualização no SQL
- Visualizações modificadas
- Substituímos um script totalmente pela nossa própria lógica
A sequência de comandos a seguir adiciona o repositório de bifurcação como um repositório remoto upstream para extrair a versão atualizada do GitHub e verifica a ramificação principal como GitHub-main. Em seguida, este exemplo verifica a ramificação principal do repositório da empresa em Google Cloud Source e cria uma ramificação para mesclagem chamada 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
```
Há várias maneiras de criar esse fluxo. O processo de mesclagem também pode acontecer no fork no GitHub, ser substituído por uma rebase em vez de uma mesclagem, e a ramificação de mesclagem também pode ser enviada como uma solicitação de mesclagem. Essas variações do processo dependem das políticas organizacionais atuais, da profundidade das mudanças e da conveniência.

Com essa configuração, você pode comparar as mudanças recebidas com as locais. É recomendável usar uma ferramenta em um ambiente de desenvolvimento integrado gráfico de sua escolha para conferir as mudanças e escolher o que será mesclado. Por exemplo, o Visual Studio.

É recomendável sinalizar personalizações usando comentários que se destacam visualmente para facilitar o processo de comparação.
Iniciar o processo de mesclagem: use a ramificação criada (neste exemplo, é a ramificação chamada merging_br) para convergir todas as mudanças e descartar arquivos. Quando estiver tudo pronto, você poderá mesclar essa ramificação de volta à principal ou a outra ramificação do repositório da empresa para criar uma solicitação de mesclagem. Na ramificação de mesclagem que foi extraída do repositório principal da sua empresa (git checkout merging_br), mescle as mudanças recebidas do fork remoto.
```
    ## 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`
```
Esse comando gera uma lista de conflitos. Use a comparação gráfica do ambiente de desenvolvimento integrado para entender as mudanças e escolher entre atual, entrada e ambos. É aí que um comentário no código sobre as personalizações é útil. Descartar as mudanças, excluir arquivos que você não quer mesclar e ignorar mudanças em visualizações ou scripts que você já personalizou.

Mesclar mudanças: depois de decidir quais mudanças serão aplicadas, verifique o resumo e as confirme 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 você não tiver certeza sobre alguma etapa, consulte Como desfazer ações básicas no Git.

Testar e implantar: até agora, você está mesclando apenas em uma ramificação "temporária". Recomendamos executar uma implantação de teste nos scripts cloudbuild\*.yaml neste momento para garantir que tudo esteja sendo executado conforme o esperado. Os testes automatizados podem ajudar a simplificar esse processo. Quando essa ramificação de mesclagem estiver correta, faça o checkout da ramificação de destino principal e mescle a ramificação merging_br nela.