Migrazione dei DAG esterni dalla versione 4.2 alla 5.0

Questa guida illustra i passaggi necessari per spostare le tabelle di output dai Directed Acyclic Graph (DAG) esterni alle nuove posizioni all'interno dell'architettura di Cortex Data Foundation v5.0. Ad esempio, Meteo e Tendenze. Questa guida è progettata specificamente per gli utenti che hanno implementato DAG esterni nelle versioni precedenti di Cortex Framework Data Foundation (da 4.2 a 5.0) e che ora stanno eseguendo l'upgrade. Se non hai utilizzato DAG esterni o non hai eseguito il deployment di SAP, questa guida non è applicabile.

Contesto

Le versioni di Cortex Framework Data Foundation precedenti alla 4.2 utilizzavano un flag _GEN_EXT per gestire il deployment delle origini dati esterne, con alcune origini collegate a workload specifici (come la conversione di valuta per SAP). Tuttavia, nella versione 5.0 questo flag è stato rimosso. Ora è disponibile un nuovo modulo dedicato alla gestione dei DAG che possono gestire più workload. Questa guida illustra i passaggi per modificare le pipeline di dati esistenti in modo che funzionino con questa nuova struttura.

DAG riutilizzabili tra i workload

Cortex Framework Data Foundation v5.0 introduce K9, un nuovo componente responsabile dell'importazione, dell'elaborazione e della modellazione di elementi di dati riutilizzabili condivisi tra varie origini dati. Le visualizzazioni di report ora fanno riferimento al set di dati K9_PROCESSING per accedere a questi componenti riutilizzabili, semplificando l'accesso ai dati e riducendo la ridondanza. Le seguenti origini dati esterne vengono ora sottoposte a deployment come parte di K9, nel set di dati K9_PROCESSING:

date_dimension
holiday_calendar
trends
weather

DAG dipendenti da SAP

I seguenti DAG dipendenti da SAP vengono ancora attivati dallo script generate_external_dags.sh, ma ora vengono eseguiti durante il passaggio di creazione dei report e scrivono nel set di dati di reporting SAP anziché nella fase CDC (Change Data Capture).

currency_conversion
inventory_snapshots
prod_hierarchy_texts

Guida alla migrazione

Questa guida illustra i passaggi per eseguire l'upgrade di Cortex Framework Data Foundation alla versione 5.0.

Eseguire il deployment di Cortex Framework Data Foundation 5.0

Innanzitutto, esegui il deployment della versione più recente (v5.0) di Cortex Framework Data Foundation nei tuoi progetti, seguendo queste linee guida:

Utilizza i set di dati RAW e CDC esistenti dei deployment di sviluppo o di gestione temporanea precedenti come set di dati RAW e CDC di questo deployment, poiché non vengono apportate modifiche durante il deployment.
Imposta sia testData sia SAP.deployCDC su False in config/config.json.
Crea un nuovo progetto di reporting SAP separato dall'ambiente v4.2 esistente a scopo di test. In questo modo, puoi valutare in sicurezza il processo di upgrade senza influire sulle operazioni correnti.
(Facoltativo) Se hai DAG Airflow attivi in esecuzione per la versione precedente di Cortex Framework Data Foundation, mettili in pausa prima di procedere con la migrazione. Puoi farlo tramite l'UI di Airflow. Per istruzioni dettagliate, consulta la documentazione Aprire l'UI di Airflow da Composer e Mettere in pausa il DAG.

Seguendo questi passaggi, puoi eseguire la transizione in sicurezza a Cortex Framework Data Foundation versione 5.0 e convalidare le nuove funzionalità.

Eseguire la migrazione delle tabelle esistenti

Per eseguire la migrazione delle tabelle esistenti alla nuova posizione, utilizza jinja-cli per formattare il modello di script di migrazione fornito per completare la migrazione.

Installa jinja-cli con il seguente comando:
```
pip install jinja-cli
```
Identifica i seguenti parametri dalla versione 4.2 esistente e dal nuovo deployment della versione 5.0:
<td"> Nome <td"> Descrizione </td"></td"><td"> project_id_src <td"> Source Google Cloud Project: progetto in cui si trova il set di dati SAP CDC esistente del deployment della versione 4.2. Il dataset K9_PROCESSING viene creato anche in questo progetto. </td"></td"><td"> project_id_tgt <td"> Target Google Cloud where: progetto in cui si trova il set di dati di reporting SAP appena sottoposto a deployment da il nuovo deployment della versione 5.0. Potrebbe essere diverso dal progetto di origine. </td"></td"><td"> dataset_cdc_processed <td"> Set di dati BigQuery CDC: Set di dati BigQuery in cui vengono inseriti i dati elaborati CDC, ovvero gli ultimi record disponibili. Potrebbe essere lo stesso del set di dati di origine. </td"></td"><td"> dataset_reporting_tgt <td"> Set di dati di reporting BigQuery di destinazione: set di dati BigQuery in cui vengono sottoposti a deployment i modelli di dati predefiniti di Data Foundation per SAP. </td"></td"><td"> k9_datasets_processing <td"> Set di dati BigQuery K9: set di dati BigQuery in cui viene sottoposto a deployment K9 (origini dati aumentate). </td"></td">

Crea un file JSON con i dati di input richiesti. Assicurati di rimuovere tutti i DAG di cui non vuoi eseguire la migrazione dalla sezione 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

Ad esempio, se vuoi rimuovere weather e trends, lo script sarà simile al seguente:

{
  "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"
    ]
    }

Crea una cartella di output con il seguente comando:
```
  mkdir output
```
Genera lo script di migrazione analizzato con il seguente comando (questo comando presuppone che tu sia nella directory principale del repository):
```
  jinja -d data.json -o output/migrate_external_dags.sql docs/external_dag_migration/scripts/migrate_external_dags.sql
```
Esamina il file SQL di output ed eseguilo in BigQuery per eseguire la migrazione delle tabelle nella nuova posizione.

Aggiornare e riattivare i DAG Airflow

Esegui il backup dei file DAG correnti nel bucket Airflow. Poi, sostituiscili con i file appena generati dal deployment di Cortex Framework Data Foundation versione 5.0. Per istruzioni dettagliate, consulta la seguente documentazione:

Convalida e pulizia

La migrazione è stata completata. Ora puoi verificare che tutte le visualizzazioni di report nel nuovo deployment di reporting v5.0 funzionino correttamente. Se tutto funziona correttamente, ripeti la procedura, questa volta scegliendo come target il deployment v5.0 del set di reporting di produzione. Dopodiché, puoi rimuovere tutte le tabelle utilizzando il seguente script:

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