Recomendações de upgrade

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

A base de dados do Cortex Framework oferece um conjunto de conteúdo e modelos 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 projetado com um princípio de abertura. 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 base tem uma dependência forte é 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 ser capaz de 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 flag de operações, para destacar registros novos e alterados.
Processamento de dados: Os scripts de processamento de captura de dados alterados (CDC) fornecem trabalho com o Serviço Gerenciado para Apache Airflow (ou Apache Airflow) e 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 no BigQuery por design para criar visualizações com a ferramenta de relatórios de escolha.

Principais benefícios

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

Abertura: integra-se perfeitamente a 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 clustering 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 lançamentos futuros, minimizando a interrupção das implementações atuais. Para mais informações sobre mudanças de versão, consulte as notas de lançamento.
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 da base 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 delas, 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 estas etapas, é recomendável ter um bom entendimento do Git.

Criar um fork do repositório principal: crie um fork do repositório da base de dados do Cortex Framework. O fork mantém esse repositório recebendo atualizações do Google Cloud repositório e um repositório separado para a empresa principal.
Criar o repositório da empresa: estabeleça um novo host do Git para o repositório da sua 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 bifurcado original 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 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ê 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 as mudanças com uma nova versão do Cortex

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

Atualizar forks: clique em Sincronizar fork para atualizar os forks do repositório com as mudanças do repositório. Google Cloud Por exemplo, as seguintes mudanças no repositório da empresa são feitas. E houve algumas outras mudanças no repositório da base de dados por Google Cloud em uma nova versão.
- Criou e incorporou o uso de uma nova visualização em SQL
- Visualizações modificadas
- Substituiu um script completamente pela nossa própria lógica
A sequência de comandos a seguir adiciona o repositório de ramificação como um repositório remoto upstream para extrair a versão atualizada de GitHub e faz o check-out da ramificação principal como GitHub-main. Em seguida, este exemplo faz o check-out da 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 ocorrer no fork no GitHub, ser substituído por um 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 mudanças locais. É recomendável usar uma ferramenta em um IDE gráfico de 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 diff.
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 da principal do repositório da 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 (IDE) para entender as mudanças e escolher entre atual, recebida e ambas. É aqui que ter um comentário no código sobre personalizações se torna útil. Escolha descartar as mudanças completamente, excluir arquivos que você não quer mesclar e ignorar mudanças em visualizações ou scripts que já foram personalizados.

Mesclar mudanças: depois de decidir as mudanças a serem aplicadas, confira 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 você se sentir inseguro em relação a alguma etapa, consulte Desfazer coisas básicas do Git.

Testar e implantar: até agora, você só está mesclando em uma ramificação "temporária". É recomendável executar uma implantação de teste dos 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 boa, você poderá fazer o check-out da ramificação de destino principal e mesclar a ramificação merging_br nela.