Migração de DAGs externos da v4.2 para a v5.0

Este guia descreve as etapas necessárias para realocar tabelas de saída de DAGs (grafos acíclicos dirigidos) externos para os novos locais na arquitetura da Cortex Data Foundation v5.0. Por exemplo, "Clima" e "Tendências". Este guia foi elaborado especificamente para usuários que implementaram DAGs externas em versões anteriores do Cortex Framework Data Foundation (4.2 a 5.0) e 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 anteriores à 4.2 do Cortex Framework Data Foundation 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 pode 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

A Cortex Framework Data Foundation v5.0 apresenta o K9, um novo componente responsável por ingestir, processar e modelar elementos de dados reutilizáveis que são compartilhados em várias fontes de dados. As visualizações de relatórios agora referenciam o 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 da SAP

Os seguintes DAGs dependentes do SAP 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 da fase de captura de dados alterados (CDC).

  • currency_conversion
  • inventory_snapshots
  • prod_hierarchy_texts

Guia de migração

Este guia descreve as etapas para fazer upgrade da base de dados do Cortex Framework para a versão 5.0.

Implantar a Cortex Data Foundation 5.0

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

  1. Use os conjuntos de dados RAW e CDC atuais de implantações de desenvolvimento ou de preparação anteriores como conjuntos de dados RAW e CDC dessa 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 SAP separado do ambiente v4.2 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 para a versão anterior da base de dados do Cortex Framework, 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 a documentação Pausar o DAG.

Seguindo 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

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

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

    pip install jinja-cli
    
  2. Identifique os seguintes parâmetros da versão 4.2 e da nova implantação da versão 5.0:

    Nome Descrição
    project_id_src Source Google Cloud Project: projeto em que o conjunto de dados do CDC do SAP da implantação da versão 4.2 está localizado. O conjunto de dados K9_PROCESSING também é criado neste projeto.
    project_id_tgt Google Cloud de destino, 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.
    dataset_cdc_processed Conjunto de dados do CDC no BigQuery: conjunto de dados do BigQuery em que os dados processados pelo CDC são armazenados nos registros mais recentes disponíveis. Ele pode ser igual ao conjunto de dados de origem.
    dataset_reporting_tgt Conjunto de dados de relatórios do BigQuery de destino: conjunto de dados do BigQuery em que a estrutura de dados predefinida da Data Foundation para SAP é implantada.
    k9_datasets_processing Conjunto de dados do BigQuery K9: conjunto de dados do BigQuery em que o K9 (fontes de dados aumentadas) é implantado.
  3. Crie um arquivo JSON com os dados de entrada necessários. Remova as 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 vai ficar assim:

    {
      "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 (este comando assume que você está 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 seu 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 documentação a seguir:

Validação e limpeza

A migração foi concluída. Agora é possível validar se todas as visualizações de relatórios na nova implantação de relatórios da 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, 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