Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Migración de DAGs externos de la versión 4.2 a la 5.0
En esta guía, se describen los pasos necesarios para reubicar las tablas de salida de los gráficos acíclicos dirigidos (DAG) externos a sus nuevas ubicaciones dentro de la arquitectura de Cortex Data Foundation v5.0. Por ejemplo, Clima y Tendencias. Esta guía está diseñada específicamente para los usuarios que implementaron DAG externos en versiones anteriores de Data Foundation de Framework de Cortex (de 4.2 a 5.0) y ahora realizan la actualización. Si
no usaste DAG externos ni implementaste SAP, esta guía no
es aplicable.
Contexto
Las versiones anteriores a la 4.2 de Cortex Framework Data Foundation usaban una marca _GEN_EXT para administrar la implementación de fuentes de datos externas, con algunas fuentes vinculadas a cargas de trabajo específicas (como la conversión de moneda para SAP). Sin embargo, con la versión 5.0, se quitó esta marca. Ahora, hay un nuevo módulo dedicado a administrar DAGs
que pueden entregar varias cargas de trabajo. En esta guía, se describen los pasos para ajustar tus
canalizaciones de datos existentes para que funcionen con esta nueva estructura.
DAG reutilizables entre cargas de trabajo
La versión 5.0 de la base de datos de Cortex Framework presenta K9, un nuevo componente responsable de la transferencia, el procesamiento y el modelado de elementos de datos reutilizables que se comparten en varias fuentes de datos. Las vistas de informes ahora hacen referencia al conjunto de datos K9_PROCESSING para acceder a estos componentes reutilizables, lo que optimiza el acceso a los datos y reduce la redundancia. Las siguientes fuentes de datos externas ahora se implementan como parte de K9 en el conjunto de datos K9_PROCESSING:
date_dimension
holiday_calendar
trends
weather
DAGs dependientes de SAP
La siguiente secuencia de comandos de generate_external_dags.sh sigue activando los DAGs dependientes de SAP, pero ahora se ejecuta durante el paso de compilación de informes y escribe en el conjunto de datos de informes de SAP en lugar de la etapa de CDC (captura de datos modificados).
currency_conversion
inventory_snapshots
prod_hierarchy_texts
Guía de migración
En esta guía, se describen los pasos para actualizar tu base de datos de Cortex Framework a la versión 5.0.
Implementa Cortex Framework Data Foundation 5.0
Primero, implementa la versión más reciente (v5.0) de Cortex Framework Data Foundation en tus proyectos con los siguientes lineamientos:
Usa tus conjuntos de datos sin procesar y de CDC existentes de implementaciones anteriores de desarrollo o pruebas
como tus conjuntos de datos sin procesar y de CDC de esta implementación, ya que no se les hace ninguna modificación
durante la implementación.
Establece testData y SAP.deployCDC en False en config/config.json.
Crea un nuevo proyecto de informes de SAP independiente de tu entorno v4.2 existente para realizar pruebas. Esto evalúa de forma segura el proceso de actualización
sin afectar tus operaciones actuales.
Opcional. Si tienes DAG de Airflow activos en ejecución para tu versión anterior de Data Foundation de Framework de Cortex, deténlos antes de continuar con la migración.
Esto se puede hacer a través de la IU de Airflow. Para obtener instrucciones detalladas, consulta Cómo abrir la IU de Airflow desde Composer y la documentación sobre cómo pausar el DAG.
Si sigues estos pasos, puedes realizar la transición de forma segura a la versión 5.0 de Cortex Framework Data Foundation y validar las nuevas funciones y funcionalidades.
Cómo migrar tablas existentes
Para migrar tus tablas existentes a su nueva ubicación, usa jinja-cli para dar formato a la plantilla de secuencia de comandos de migración proporcionada y completar la migración.
Instala jinja-cli con el siguiente comando:
pipinstalljinja-cli
Identifica los siguientes parámetros de tu implementación existente de la versión 4.2 y de la nueva versión 5.0:
Nombre
Descripción
project_id_src
Proyecto Google Cloud de origen: Es el proyecto en el que se encuentra tu conjunto de datos de CDC de SAP existente de la implementación de la versión 4.2. El conjunto de datos K9_PROCESSING también se crea en este proyecto.
project_id_tgt
Es el objetivo Google Cloud en el que se encuentra el conjunto de datos de informes de SAP que se implementó recientemente en la nueva implementación de la versión 5.0. Esto puede ser diferente del proyecto de origen.
dataset_cdc_processed
Conjunto de datos de BigQuery de CDC:
Es el conjunto de datos de BigQuery en el que los datos procesados por la CDC llegan a los
registros más recientes disponibles. Puede ser igual que el conjunto de datos de origen.
dataset_reporting_tgt
Conjunto de datos de informes de BigQuery de destino: Es el conjunto de datos de BigQuery en el que se implementan los modelos de datos predefinidos de Data Foundation for SAP.
k9_datasets_processing
Conjunto de datos de BigQuery de K9:
Es el conjunto de datos de BigQuery en el que se implementa K9 (fuentes de datos aumentadas).
Crea un archivo JSON con los datos de entrada necesarios. Asegúrate de quitar los DAG que no quieras migrar de la sección migrate_list:
Examina el archivo SQL de salida y ejecútalo en BigQuery para migrar tus tablas a la nueva ubicación.
Actualiza y reanuda los DAG de Airflow
Crea una copia de seguridad de los archivos DAG actuales en tu bucket de Airflow. Luego, reemplázalos por los archivos generados recientemente de la implementación de la versión 5.0 de Data Foundation de Cortex Framework. Para obtener instrucciones detalladas, consulta la siguiente documentación:
Se completó la migración. Ahora puedes validar que todas las vistas de informes de la nueva implementación de informes de la versión 5.0 funcionen correctamente. Si todo funciona correctamente, vuelve a realizar el proceso, esta vez, segmentando la implementación de la versión 5.0 para tu conjunto de informes de producción. Luego, no dudes en quitar todas las tablas con la siguiente secuencia de comandos:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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"]]
