Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Migration externer DAGs von Version 4.2 zu Version 5.0
In diesem Leitfaden werden die Schritte beschrieben, die erforderlich sind, um Ausgabetabellen aus externen gerichteten azyklischen Graphen (Directed Acyclic Graphs, DAGs) an ihre neuen Speicherorte in der Cortex Data Foundation v5.0-Architektur zu verschieben. Beispiel: Wetter und Trends. Dieser Leitfaden richtet sich speziell an Nutzer, die externe DAGs in früheren Versionen der Cortex Framework Data Foundation (4.2 bis 5.0) implementiert haben und jetzt ein Upgrade durchführen. Wenn Sie keine externen DAGs verwendet oder SAP nicht bereitgestellt haben, ist dieser Leitfaden nicht für Sie geeignet.
Kontext
In Cortex Framework Data Foundation-Versionen vor 4.2 wurde ein _GEN_EXT-Flag verwendet, um die Bereitstellung externer Datenquellen zu verwalten. Einige Quellen waren dabei mit bestimmten Arbeitslasten verknüpft, z. B. die Währungsumrechnung für SAP. Mit Version 5.0 wurde dieses Flag jedoch entfernt. Jetzt gibt es ein neues Modul zum Verwalten von DAGs, die mehrere Arbeitslasten bedienen können. In diesem Leitfaden erfahren Sie, wie Sie Ihre vorhandenen Datenpipelines an diese neue Struktur anpassen.
Wiederverwendbare DAGs für mehrere Arbeitslasten
In Cortex Framework Data Foundation 5.0 wird K9 eingeführt, eine neue Komponente, die für die Aufnahme, Verarbeitung und Modellierung wiederverwendbarer Datenelemente verantwortlich ist, die für verschiedene Datenquellen freigegeben werden. Berichtsansichten verweisen jetzt auf das K9_PROCESSING-Dataset, um auf diese wiederverwendbaren Komponenten zuzugreifen. So wird der Datenzugriff optimiert und Redundanz reduziert. Die folgenden externen Datenquellen werden jetzt als Teil von K9 im K9_PROCESSING-Dataset bereitgestellt:
date_dimension
holiday_calendar
trends
weather
SAP-abhängige DAGs
Die folgenden SAP-abhängigen DAGs werden weiterhin vom generate_external_dags.sh-Script ausgelöst, aber jetzt während des Berichtsbuild-Schritts ausgeführt und schreiben jetzt in das SAP-Berichtsdatenset anstelle der CDC-Phase (Change Data Capture).
currency_conversion
inventory_snapshots
prod_hierarchy_texts
Migrationsanleitung
In diesem Leitfaden wird beschrieben, wie Sie Ihre Cortex Framework Data Foundation auf Version 5.0 aktualisieren.
Cortex Framework Data Foundation 5.0 bereitstellen
Stellen Sie zuerst die neueste Version (v5.0) von Cortex Framework Data Foundation in Ihren Projekten bereit. Beachten Sie dabei die folgenden Richtlinien:
Verwenden Sie Ihre vorhandenen RAW- und CDC-Datasets aus früheren Entwicklungs- oder Staging-Bereitstellungen als RAW- und CDC-Datasets dieser Bereitstellung, da sie während der Bereitstellung nicht geändert werden.
Legen Sie in config/config.json sowohl testData als auch SAP.deployCDC auf False fest.
Erstellen Sie zu Testzwecken ein neues SAP-Berichtsprojekt, das von Ihrer vorhandenen v4.2-Umgebung getrennt ist. So können Sie den Upgradeprozess sicher bewerten, ohne dass sich dies auf Ihre aktuellen Abläufe auswirkt.
Optional. Wenn für Ihre vorherige Cortex Framework Data Foundation-Version aktive Airflow-DAGs ausgeführt werden, halten Sie sie an, bevor Sie mit der Migration fortfahren.
Das ist über die Airflow-Benutzeroberfläche möglich. Eine ausführliche Anleitung finden Sie in den Dokumenten Airflow-Benutzeroberfläche über Composer öffnen und DAG pausieren.
Wenn Sie diese Schritte ausführen, können Sie sicher zur Cortex Framework Data Foundation-Version 5.0 migrieren und die neuen Funktionen testen.
Vorhandene Tabellen migrieren
Um Ihre vorhandenen Tabellen an den neuen Speicherort zu migrieren, formatieren Sie die bereitgestellte Vorlage für das Migrationsskript mit jinja-cli, um die Migration abzuschließen.
Installieren Sie jinja-cli mit dem folgenden Befehl:
pipinstalljinja-cli
Ermitteln Sie die folgenden Parameter aus Ihrer vorhandenen Version 4.2 und der neuen Bereitstellung der Version 5.0:
Name
Beschreibung
project_id_src
Quell Google Cloud Projekt: Projekt, in dem sich Ihr vorhandener SAP-CDC-Dataset aus der Bereitstellung von Version 4.2 befindet. Das Dataset K9_PROCESSING wird ebenfalls in diesem Projekt erstellt.
project_id_tgt
Ziel Google Cloud , unter dem sich das neu bereitgestellte SAP-Berichtsdatenpool aus der neuen Version 5.0 befindet. Dieser kann sich vom Quellprojekt unterscheiden.
dataset_cdc_processed
CDC-BigQuery-Dataset: BigQuery-Dataset, in dem die vom CDC verarbeiteten Daten die neuesten verfügbaren Datensätze enthalten. Er kann mit dem Quell-Dataset identisch sein.
dataset_reporting_tgt
Ziel-BigQuery-Berichtsdatensatz: BigQuery-Dataset, in dem die vordefinierten Datenmodelle der Data Foundation for SAP bereitgestellt werden.
k9_datasets_processing
K9-BigQuery-Dataset: BigQuery-Dataset, in dem K9 (erweiterte Datenquellen) bereitgestellt wird.
Erstellen Sie eine JSON-Datei mit den erforderlichen Eingabedaten. Entfernen Sie alle DAGs, die Sie nicht migrieren möchten, aus dem Bereich migrate_list:
Erstellen Sie mit dem folgenden Befehl einen Ausgabeordner:
mkdiroutput
Generieren Sie das geparste Migrationsskript mit dem folgenden Befehl. Dabei wird davon ausgegangen, dass Sie sich im Stammverzeichnis des Repositorys befinden:
Prüfen Sie die Ausgabe-SQL-Datei und führen Sie sie in BigQuery aus, um Ihre Tabellen an den neuen Speicherort zu migrieren.
Airflow-DAGs aktualisieren und pausieren aufheben
Sichern Sie die aktuellen DAG-Dateien in Ihrem Airflow-Bucket. Ersetzen Sie sie dann durch die neu generierten Dateien aus Ihrer Cortex Framework Data Foundation-Version 5.0-Bereitstellung. Eine ausführliche Anleitung finden Sie in der folgenden Dokumentation:
Die Migration ist jetzt abgeschlossen. Sie können jetzt prüfen, ob alle Berichtsansichten in der neuen Berichtsbereitstellung der Version 5.0 ordnungsgemäß funktionieren. Wenn alles ordnungsgemäß funktioniert, wiederholen Sie den Vorgang und richten Sie die Bereitstellung der Version 5.0 auf Ihr Produktions-Berichtsset aus. Anschließend können Sie alle Tabellen mit dem folgenden Script entfernen:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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"]]
