Migração de DAGs externos da versão 4.2 para a 5.0

Este guia descreve as etapas necessárias para realocar tabelas de saída de DAGs (gráficos acíclicos direcionados) externos para os novos locais na arquitetura do Cortex Data Foundation v5.0. Por exemplo, clima e tendências. Este guia foi criado especificamente para usuários que implementaram DAGs externos em versões anteriores do Cortex Framework Data Foundation (4.2 a 5.0) e agora estão fazendo upgrade. Se você não usou DAGs externos ou não implantou o SAP, este guia não é aplicável.

Contexto

As versões do Cortex Framework Data Foundation anteriores à 4.2 usavam uma flag _GEN_EXT para gerenciar a implantação de fontes de dados externas, com algumas fontes vinculadas a cargas de trabalho específicas (como conversão de moeda para SAP). No entanto, com a versão 5.0, essa flag foi removida. Agora, há um novo módulo dedicado ao gerenciamento de DAGs que podem atender a várias cargas de trabalho. Este guia descreve as etapas para ajustar seus pipelines de dados atuais para trabalhar com essa nova estrutura.

DAGs reutilizáveis entre cargas de trabalho

O Cortex Framework Data Foundation v5.0 apresenta o K9, um novo componente responsável por ingerir, processar e modelar elementos de dados reutilizáveis compartilhados entre várias fontes de dados. As visualizações de relatórios agora fazem referência ao conjunto de dados K9_PROCESSING para acessar esses componentes reutilizáveis, simplificando o acesso aos dados e reduzindo a redundância. As seguintes fontes de dados externas agora são implantadas como parte do K9, no conjunto de dados K9_PROCESSING:

  • date_dimension
  • holiday_calendar
  • trends
  • weather

DAGs dependentes do SAP

Os DAGs dependentes do SAP a seguir ainda são acionados pelo script generate_external_dags.sh, mas agora são executados durante a etapa de criação de relatórios e gravam no conjunto de dados de relatórios do SAP em vez do estágio de CDC (captura de dados alterados).

  • currency_conversion
  • inventory_snapshots
  • prod_hierarchy_texts

Guia de migração

Este guia descreve as etapas para fazer upgrade do Cortex Framework Data Foundation para a versão 5.0.

Implantar o Cortex Framework Data Foundation 5.0

Primeiro, implante a versão mais recente (v5.0) do Cortex Framework Data Foundation nos seus projetos, seguindo estas diretrizes:

  1. Use seus conjuntos de dados RAW e CDC existentes de implantações de desenvolvimento ou de preparação anteriores como seus conjuntos de dados RAW e CDC desta implantação, já que nenhuma modificação é feita neles durante a implantação.
  2. Defina testData e SAP.deployCDC como False em config/config.json.
  3. Crie um novo projeto de relatórios do SAP separado do ambiente v4.2 atual para fins de teste. Isso avalia com segurança o processo de upgrade sem afetar suas operações atuais.
  4. Opcional. Se você tiver DAGs do Airflow ativos em execução para a versão anterior do Cortex Framework Data Foundation, pause-os antes de continuar com a migração. Isso pode ser feito pela interface do Airflow. Para instruções detalhadas, consulte Abrir a interface do Airflow no Composer e Pausar o DAG documentação.

Ao seguir estas etapas, você pode fazer a transição com segurança para a versão 5.0 do Cortex Framework Data Foundation e validar os novos recursos e funcionalidades.

Migrar tabelas atuais

Para migrar as tabelas atuais para o novo local, use jinja-cli para formatar o modelo de script de migração fornecido para concluir a migração.

  1. Instale o jinja-cli com o seguinte comando:

    pip install jinja-cli

  2. Identifique os seguintes parâmetros da implantação da versão 4.2 atual e da nova versão 5.0:

    <td"> Nome <td"> Descrição </td"></td"><td"> project_id_src <td"> Source Google Cloud Project: projeto em que o conjunto de dados CDC do SAP existente da implantação da versão 4.2 está localizado. O conjunto de dados K9_PROCESSING também é criado nesse projeto. </td"></td"><td"> project_id_tgt <td"> Target Google Cloud onde o conjunto de dados de relatórios do SAP recém-implantado da nova versão 5.0 está localizado. Isso pode ser diferente do projeto de origem. </td"></td"><td"> dataset_cdc_processed <td"> Conjunto de dados CDC do BigQuery: conjunto de dados do BigQuery em que os dados processados do CDC chegam aos registros mais recentes disponíveis. Isso pode ser igual ao conjunto de dados de origem. </td"></td"><td"> dataset_reporting_tgt <td"> Conjunto de dados de relatórios do BigQuery de destino: conjunto de dados do BigQuery em que os modelos de dados predefinidos do Data Foundation para SAP são implantados. </td"></td"><td"> k9_datasets_processing <td"> Conjunto de dados K9 do BigQuery: conjunto de dados do BigQuery em que o K9 (fontes de dados aumentadas) é implantado. </td"></td">

  3. Crie um arquivo JSON com os dados de entrada necessários. Remova todos os DAGs que você não quer migrar da seção migrate_list:

    {
  "project_id_src": "your-source-project",
  "project_id_tgt": "your-target-project",
  "dataset_cdc_processed": "your-cdc-processed-dataset",
  "dataset_reporting_tgt": "your-reporting-target-dataset-OR-SAP_REPORTING",
  "k9_datasets_processing": "your-k9-processing-dataset-OR-K9_REPORTING",
  "migrate_list":
    [
        "holiday_calendar",
        "trends",
        "weather",
        "currency_conversion",
        "inventory_snapshots",
        "prod_hierarchy_texts"
    ]
}
EOF

    Por exemplo, se você quiser remover weather e trends, o script será semelhante ao seguinte:

    {
  "project_id_src": "kittycorn-demo",
  "project_id_tgt": "kittycorn-demo",
  "dataset_cdc_processed": "CDC_PROCESSED",
  "dataset_reporting_tgt": "SAP_REPORTING",
  "k9_datasets_processing": "K9_PROCESSING",
  "migrate_list":
    [
        "holiday_calendar",
        "currency_conversion",
        "inventory_snapshots",
        "prod_hierarchy_texts"
    ]
    }

  4. Crie uma pasta de saída com o seguinte comando:

      mkdir output

  5. Gere o script de migração analisado com o seguinte comando (esse comando pressupõe que você esteja na raiz do repositório):

      jinja -d data.json -o output/migrate_external_dags.sql docs/external_dag_migration/scripts/migrate_external_dags.sql

  6. Examine o arquivo SQL de saída e execute no BigQuery para migrar as tabelas para o novo local.

Atualizar e retomar os DAGs do Airflow

Faça backup dos arquivos DAG atuais no bucket do Airflow. Em seguida, substitua-os pelos arquivos recém-gerados da implantação da versão 5.0 do Cortex Framework Data Foundation. Para instruções detalhadas, consulte a seguinte documentação:

Validação e limpeza

A migração foi concluída. Agora você pode validar se todas as visualizações de relatórios na nova implantação de relatórios v5.0 estão funcionando corretamente. Se tudo funcionar corretamente, repita o processo, desta vez direcionando a implantação da v5.0 para o conjunto de relatórios de produção. Depois disso, remova todas as tabelas usando o seguinte script:

    jinja -d data.json -o output/delete_old_dag_tables.sql docs/external_dag_migration/scripts/delete_old_dag_tables.sql