Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Migrazione dei DAG esterni dalla versione 4.2 alla versione 5.0
Questa guida illustra i passaggi necessari per spostare le tabelle di output dai grafici acicli diretti (DAG) esterni alle nuove posizioni all'interno dell'architettura di Cortex Data Foundation 5.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 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 di origini dati esterne, con alcune origini legate a workload specifici (come la conversione di valute per SAP). Tuttavia, con la versione 5.0, questo
indicatore è stato rimosso. Ora è disponibile un nuovo modulo dedicato alla gestione delle DAG che può gestire più workload. Questa guida illustra i passaggi per modificare le tue pipeline di dati esistenti in modo che funzionino con questa nuova struttura.
DAG riutilizzabili tra carichi di lavoro
La versione 5.0 di Cortex Framework Data Foundation 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 dei 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 sono ora messe in produzione 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 scriptgenerate_external_dags.sh, ma ora vengono eseguiti durante il passaggio di compilazione dei report e ora scrivono nel set di dati dei report 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 Data Foundation di Cortex Framework alla versione 5.0.
Esegui 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 le seguenti linee guida:
Utilizza i set di dati RAW e CDC esistenti di implementazioni di sviluppo o di staging precedenti come set di dati RAW e CDC di questa implementazione, poiché non vengono apportate modifiche durante l'implementazione.
Imposta sia testData che SAP.deployCDC su False in config/config.json.
Crea un nuovo progetto SAP Reporting separato dall'ambiente v4.2 esistente per scopi di test. In questo modo puoi valutare in sicurezza la procedura di upgrade
senza influire sulle tue operazioni attuali.
Facoltativo. Se hai DAG Airflow attivi per la versione precedente di Cortex Framework Data Foundation, mettili in pausa prima di procedere con la migrazione.
Questa operazione può essere eseguita tramite l'interfaccia utente di Airflow. Per istruzioni dettagliate, consulta la documentazione su come aprire la UI di Airflow da Composer e su come mettere in pausa il DAG.
Se segui questi passaggi, puoi eseguire la transizione a Cortex Framework Data Foundation
nella versione 5.0 e convalidare le nuove funzionalità.
Esegui la migrazione delle tabelle esistenti
Per eseguire la migrazione delle tabelle esistenti nella 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:
pipinstalljinja-cli
Identifica i seguenti parametri dalla versione 4.2 esistente e dal nuovo deployment della versione 5.0:
Nome
Descrizione
project_id_src
Progetto Google Cloud di origine: il progetto in cui si trova il set di dati CDC SAP esistente
dal deployment della versione 4.2. Anche il set di dati K9_PROCESSING viene creato in questo progetto.
project_id_tgt
Destinazione Google Cloud dove si trova il set di dati SAP Reporting appena disegnato dal deployment della nuova versione 5.0. Potrebbe essere diverso dal progetto di origine.
dataset_cdc_processed
Set di dati BigQuery del CDC:
set di dati BigQuery in cui vengono caricati i dati elaborati dal CDC
gli ultimi record disponibili. Potrebbe essere lo stesso del set di dati di origine.
dataset_reporting_tgt
Set di dati dei report BigQuery di destinazione: set di dati BigQuery
in cui viene eseguito il deployment dei modelli di dati predefiniti di Data Foundation for SAP.
k9_datasets_processing
Set di dati BigQuery K9:
set di dati BigQuery in cui è implementato K9 (origini dati aumentate).
Crea un file JSON con i dati di input richiesti. Assicurati di rimuovere eventuali DAG di cui non vuoi eseguire la migrazione dalla sezione migrate_list:
Esamina il file SQL di output ed eseguilo in BigQuery per eseguire la migrazione delle tabelle nella nuova posizione.
Aggiorna e riattiva i DAG di 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:
La migrazione è stata completata. Ora puoi verificare che tutte le visualizzazioni dei report
nel nuovo deployment dei report della versione 5.0 funzionino correttamente. Se tutto funziona correttamente, ripeti la procedura, questa volta scegliendo come target il deployment della versione 5.0 nel set di report di produzione. Successivamente, puoi rimuovere tutte le tabelle utilizzando lo script seguente:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[[["\u003cp\u003eThis guide details the migration process for external Directed Acyclic Graphs (DAGs) when upgrading from Google Cloud Cortex Framework versions 4.2 to 5.0, which involves relocating output tables to the new Cortex Data Foundation v5.0 architecture.\u003c/p\u003e\n"],["\u003cp\u003eCortex Framework Data Foundation v5.0 introduces a new K9 module for managing cross-workload reusable data elements like \u003ccode\u003edate_dimension\u003c/code\u003e, \u003ccode\u003eholiday_calendar\u003c/code\u003e, \u003ccode\u003etrends\u003c/code\u003e, and \u003ccode\u003eweather\u003c/code\u003e in the \u003ccode\u003eK9_PROCESSING\u003c/code\u003e dataset, which replaces the \u003ccode\u003e_GEN_EXT\u003c/code\u003e flag used in prior versions.\u003c/p\u003e\n"],["\u003cp\u003eSAP-dependent DAGs, including \u003ccode\u003ecurrency_conversion\u003c/code\u003e, \u003ccode\u003einventory_snapshots\u003c/code\u003e, and \u003ccode\u003eprod_hierarchy_texts\u003c/code\u003e, are now triggered during the reporting build step and write to the SAP reporting dataset instead of the CDC stage.\u003c/p\u003e\n"],["\u003cp\u003eThe migration process requires deploying Cortex Framework Data Foundation 5.0, using existing RAW and CDC datasets, and creating a new SAP Reporting project, before migrating existing tables using \u003ccode\u003ejinja-cli\u003c/code\u003e and an outputted SQL file.\u003c/p\u003e\n"],["\u003cp\u003eAfter migration, users must update and unpause Airflow DAGs, validate the new v5.0 reporting deployment, and then optionally delete old DAG tables using a provided \u003ccode\u003ejinja\u003c/code\u003e command, ensuring backups are taken beforehand as this step is irreversible.\u003c/p\u003e\n"]]],[],null,["# External DAGs migration from v4.2 to v5.0\n=========================================\n\n| **Warning:** This page contains specific information to update only Google Cloud Cortex Framework versions 4.2 to 5.0. The content might not apply to other versions.\n\nThis guide outlines the steps necessary to relocate output tables from external\nDirected Acyclic Graphs (DAGs) to their new locations within the Cortex Data\nFoundation v5.0 architecture. For example, Weather and Trends. This guide is\nspecifically designed for users who have implemented External DAGs in previous\nCortex Framework Data Foundation versions (4.2 to 5.0) and are now upgrading. If\nyou haven't used External DAGs or haven't deployed SAP, this guide is not\napplicable.\n\nContext\n-------\n\nCortex Framework Data Foundation versions prior to 4.2 used a `_GEN_EXT` flag to manage\nthe deployment of external data sources, with some sources tied to specific\nworkloads (like currency conversion for SAP). However, with version 5.0, this\nflag has been removed. Now, there's a new module dedicated to managing DAGs\nthat can serve multiple workloads. This guide outlines steps to adjust your\nexisting data pipelines to work with this new structure.\n\n### Cross-workload reusable DAGs\n\nCortex Framework Data Foundation v5.0 introduces K9, a new component responsible for\ningesting, processing, and modeling reusable data elements that are shared\nacross various data sources. Reporting views are now reference the\n`K9_PROCESSING` dataset to access these reusable components, streamlining data\naccess and reducing redundancy. The following external data sources are now\ndeployed as a part of K9, into the `K9_PROCESSING` dataset:\n\n- `date_dimension`\n- `holiday_calendar`\n- `trends`\n- `weather`\n\n### SAP-dependent DAGs\n\nThe following SAP-dependent DAGs are still triggered by\n`generate_external_dags.sh` script, but now executes during the reporting build\nstep, and now write into the SAP reporting dataset instead of the CDC\n(Change Data Capture) stage.\n\n- `currency_conversion`\n- `inventory_snapshots`\n- `prod_hierarchy_texts`\n\nMigration Guide\n---------------\n\nThis guide outlines the steps to upgrade your Cortex Framework Data Foundation to version 5.0.\n\n### Deploy Cortex Framework Data Foundation 5.0\n\nFirst, deploy the newest version (v5.0) of Cortex Framework Data Foundation to your\nprojects, with the following guidelines:\n\n1. Use your existing RAW and CDC datasets from prior development or staging deployments as your RAW and CDC datasets of this deployment, as no modification is made to them during deployment.\n2. Set both `testData` and `SAP.deployCDC` to `False` in `config/config.json`.\n3. Create a new SAP Reporting project separate from your existing v4.2 environment for testing purposes. This safely evaluate the upgrade process without impacting your current operations.\n4. Optional. If you have active Airflow DAGs running for your previous Cortex Framework Data Foundation version, pause them before proceeding with the migration. This can be done through the Airflow UI. For detailed instructions see [Open Airflow UI from Composer](/composer/docs/how-to/accessing/airflow-web-interface) and [Pause the DAG](https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html#dag-pausing-deactivation-and-deletion) documentation.\n\nBy following these steps, you can safely transition to Cortex Framework Data Foundation\nversion 5.0 and validate the new features and functionalities.\n\n### Migrate existing tables\n\nTo migrate your existing tables to their new location, use `jinja-cli` to\nformat the provided migration script template to complete the migration.\n\n1. Install jinja-cli with the following command:\n\n pip install jinja-cli\n\n2. Identify the following parameters from your existing version 4.2 and new\n version 5.0 deployment:\n\n3. Create a JSON file with the required input data. Make sure to remove any\n DAGs you don't want to migrate from the `migrate_list` section:\n\n {\n \"project_id_src\": \"your-source-project\",\n \"project_id_tgt\": \"your-target-project\",\n \"dataset_cdc_processed\": \"your-cdc-processed-dataset\",\n \"dataset_reporting_tgt\": \"your-reporting-target-dataset-OR-SAP_REPORTING\",\n \"k9_datasets_processing\": \"your-k9-processing-dataset-OR-K9_REPORTING\",\n \"migrate_list\":\n [\n \"holiday_calendar\",\n \"trends\",\n \"weather\",\n \"currency_conversion\",\n \"inventory_snapshots\",\n \"prod_hierarchy_texts\"\n ]\n }\n EOF\n\n For example, if you want to remove `weather` and `trends`, the script would\n look like the following: \n\n {\n \"project_id_src\": \"kittycorn-demo\",\n \"project_id_tgt\": \"kittycorn-demo\",\n \"dataset_cdc_processed\": \"CDC_PROCESSED\",\n \"dataset_reporting_tgt\": \"SAP_REPORTING\",\n \"k9_datasets_processing\": \"K9_PROCESSING\",\n \"migrate_list\":\n [\n \"holiday_calendar\",\n \"currency_conversion\",\n \"inventory_snapshots\",\n \"prod_hierarchy_texts\"\n ]\n }\n\n4. Create an output folder with the following command:\n\n mkdir output\n\n5. Generate the parsed migration script with the following command (this command\n assumes you are at the root of the repository):\n\n jinja -d data.json -o output/migrate_external_dags.sql docs/external_dag_migration/scripts/migrate_external_dags.sql\n\n6. Examine the output SQL file and execute in BigQuery to migrate your tables to the new location.\n\n### Update and unpause the Airflow DAGs\n\nBack up the current DAG Files in your Airflow bucket. Then, replace them with\nthe newly generated files from your Cortex Framework Data Foundation version 5.0\ndeployment. For detail instructions, see the following documentation:\n\n- [Open Airflow UI from Composer](/composer/docs/how-to/accessing/airflow-web-interface)\n- [Unpause the DAG](https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html#dag-pausing-deactivation-and-deletion)\n\n### Validation and cleanup\n\nThe migration is now complete. You can now validate that all reporting views\nin the new v5.0 reporting deployment is working correctly. If everything works\nproperly, go through the process again, this time targeting the v5.0 deployment\nto your production Reporting set. Afterwards, feel free to remove all tables\nusing the following script:\n**Warning:** This step permanently removes your old DAG tables and can't be undone after is applied. Only execute this step after all validation is complete. Consider taking backups of these tables. \n\n jinja -d data.json -o output/delete_old_dag_tables.sql docs/external_dag_migration/scripts/delete_old_dag_tables.sql"]]
