Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Migration des DAG externes de la version 4.2 vers la version 5.0
Ce guide décrit les étapes nécessaires pour déplacer les tables de sortie des graphiques acycliques dirigés (DAG) externes vers leurs nouveaux emplacements dans l'architecture Cortex Data Foundation v5.0. (par exemple, Météo et Tendances). Ce guide est spécialement conçu pour les utilisateurs qui ont implémenté des DAG externes dans les versions précédentes de Cortex Framework Data Foundation (4.2 à 5.0) et qui effectuent maintenant la mise à niveau. Si vous n'avez pas utilisé de DAG externes ni déployé SAP, ce guide ne s'applique pas.
Contexte
Les versions antérieures à 4.2 de Cortex Framework Data Foundation utilisaient un indicateur _GEN_EXT pour gérer le déploiement de sources de données externes, certaines sources étant associées à des charges de travail spécifiques (comme la conversion de devises pour SAP). Toutefois, avec la version 5.0, cet indicateur a été supprimé. Un nouveau module est désormais dédié à la gestion des DAG pouvant servir plusieurs charges de travail. Ce guide décrit les étapes à suivre pour ajuster vos pipelines de données existants afin qu'ils fonctionnent avec cette nouvelle structure.
DAG réutilisables entre les charges de travail
La version 5.0 de Cortex Framework Data Foundation introduit K9, un nouveau composant chargé d'ingérer, de traiter et de modéliser des éléments de données réutilisables partagés entre différentes sources de données. Les vues de rapports font désormais référence à l'ensemble de données K9_PROCESSING pour accéder à ces composants réutilisables, ce qui simplifie l'accès aux données et réduit la redondance. Les sources de données externes suivantes sont désormais déployées dans le cadre de K9, dans l'ensemble de données K9_PROCESSING:
date_dimension
holiday_calendar
trends
weather
DAG dépendants de SAP
Les DAG dépendants de SAP suivants sont toujours déclenchés par le script generate_external_dags.sh, mais sont désormais exécutés lors de l'étape de création des rapports et écrivent désormais dans l'ensemble de données de reporting SAP au lieu de l'étape CDC (Change Data Capture).
currency_conversion
inventory_snapshots
prod_hierarchy_texts
Guide de migration
Ce guide décrit les étapes à suivre pour mettre à niveau votre Data Foundation Cortex Framework vers la version 5.0.
Déployer Cortex Framework Data Foundation 5.0
Commencez par déployer la dernière version (v5.0) de Cortex Framework Data Foundation dans vos projets, en suivant les consignes suivantes:
Utilisez vos ensembles de données RAW et CDC existants de déploiements de développement ou de préproduction précédents comme ensembles de données RAW et CDC de ce déploiement, car aucune modification n'est apportée pendant le déploiement.
Définissez testData et SAP.deployCDC sur False dans config/config.json.
Créez un projet de reporting SAP distinct de votre environnement v4.2 existant à des fins de test. Cela permet d'évaluer de manière sécurisée le processus de mise à niveau sans affecter vos opérations en cours.
Facultatif. Si des DAG Airflow actifs s'exécutent pour votre précédente version de l'infrastructure de données du framework Cortex, mettez-les en veille avant de procéder à la migration.
Pour ce faire, utilisez l'interface utilisateur d'Airflow. Pour obtenir des instructions détaillées, consultez les pages Ouvrir l'interface utilisateur d'Airflow depuis Composer et Mettre en pause le DAG.
En suivant ces étapes, vous pouvez passer en toute sécurité à la version 5.0 de Cortex Framework Data Foundation et valider les nouvelles fonctionnalités.
Migrer des tables existantes
Pour migrer vos tables existantes vers leur nouvel emplacement, utilisez jinja-cli pour mettre en forme le modèle de script de migration fourni afin de terminer la migration.
Installez jinja-cli avec la commande suivante:
pipinstalljinja-cli
Identifiez les paramètres suivants à partir de votre déploiement existant de la version 4.2 et de la nouvelle version 5.0:
Nom
Description
project_id_src
Source Google Cloud Project: projet dans lequel se trouve votre ensemble de données CDC SAP existant à partir du déploiement de la version 4.2. L'ensemble de données K9_PROCESSING est également créé dans ce projet.
project_id_tgt
Google Cloud cible où se trouve votre nouvel ensemble de données de reporting SAP déployé à partir de la nouvelle version 5.0. Il peut être différent du projet source.
dataset_cdc_processed
Ensemble de données BigQuery du CDC : ensemble de données BigQuery dans lequel les données traitées par le CDC enregistrent les derniers enregistrements disponibles. Il peut être identique à l'ensemble de données source.
dataset_reporting_tgt
Ensemble de données de reporting BigQuery cible: ensemble de données BigQuery dans lequel les modèles de données prédéfinis de Data Foundation pour SAP sont déployés.
k9_datasets_processing
Ensemble de données BigQuery K9 : ensemble de données BigQuery dans lequel K9 (sources de données enrichies) est déployé.
Créez un fichier JSON avec les données d'entrée requises. Assurez-vous de supprimer de la section migrate_list tous les DAG que vous ne souhaitez pas migrer:
Examinez le fichier SQL de sortie et exécutez-le dans BigQuery pour migrer vos tables vers le nouvel emplacement.
Mettre à jour et réactiver les DAG Airflow
Sauvegardez les fichiers DAG actuels dans votre bucket Airflow. Remplacez-les ensuite par les fichiers nouvellement générés à partir de votre déploiement de la version 5.0 de Cortex Framework Data Foundation. Pour obtenir des instructions détaillées, consultez la documentation suivante:
La migration est maintenant terminée. Vous pouvez désormais vérifier que toutes les vues de rapports du nouveau déploiement de rapports v5.0 fonctionnent correctement. Si tout fonctionne correctement, répétez le processus, cette fois en ciblant le déploiement de la version 5.0 dans votre ensemble de rapports de production. Ensuite, n'hésitez pas à supprimer toutes les tables à l'aide du script suivant:
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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"]]
