Externe DAGs von Version 4.2 zu Version 5.0 migrieren

In dieser Anleitung 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-Architektur Version 5.0 zu verschieben. Beispiele sind Wetter und Trends. Diese Anleitung wurde speziell für Nutzer entwickelt, die externe DAGs in früheren Cortex Framework Data Foundation-Versionen (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 diese Anleitung nicht relevant.

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 mit bestimmten Arbeitslasten verknüpft (z. B. Währungsumrechnung für SAP). In Version 5.0 wurde dieses Flag jedoch entfernt. Jetzt gibt es ein neues Modul zum Verwalten von DAGs, das für mehrere Arbeitslasten verwendet werden kann. In dieser Anleitung werden die Schritte beschrieben, mit denen Sie Ihre vorhandenen Datenpipelines an diese neue Struktur anpassen können.

Wiederverwendbare DAGs für mehrere Arbeitslasten

Mit Cortex Framework Data Foundation Version 5.0 wird K9 eingeführt, eine neue Komponente zum Erfassen, Verarbeiten und Modellieren wiederverwendbarer Datenelemente, die für verschiedene Datenquellen freigegeben sind. Berichtsansichten verweisen jetzt auf das Dataset K9_PROCESSING, um auf diese wiederverwendbaren Komponenten zuzugreifen. Dadurch wird der Datenzugriff optimiert und die Redundanz verringert. Die folgenden externen Datenquellen werden jetzt als Teil von K9 im Dataset K9_PROCESSING bereitgestellt:

date_dimension
holiday_calendar
trends
weather

SAP-abhängige DAGs

Die folgenden SAP-abhängigen DAGs werden weiterhin durch das Skript generate_external_dags.sh ausgelöst, werden aber jetzt während des Berichts-Build-Schritts ausgeführt und in das SAP-Berichts-Dataset anstelle der CDC-Phase (Change Data Capture) geschrieben.

currency_conversion
inventory_snapshots
prod_hierarchy_texts

Migrationsanleitung

In dieser Anleitung werden die Schritte beschrieben, mit denen Sie ein Upgrade von Cortex Framework Data Foundation auf Version 5.0 durchführen.

Cortex Framework Data Foundation 5.0 bereitstellen

Stellen Sie zuerst die neueste Version (5.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 während der Bereitstellung keine Änderungen daran vorgenommen werden.
Setzen Sie sowohl testData als auch SAP.deployCDC in config/config.json auf False.
Erstellen Sie für Testzwecke ein neues SAP-Berichtsprojekt, das von Ihrer vorhandenen Version 4.2-Umgebung getrennt ist. So können Sie den Upgrade-Prozess sicher bewerten, ohne Ihre aktuellen Abläufe zu beeinträchtigen.
Optional. Wenn für Ihre vorherige Cortex Framework Data Foundation-Version aktive Airflow-DAGs ausgeführt werden, pausieren Sie sie, bevor Sie mit der Migration fortfahren. Das können Sie über die Airflow-UI tun. Eine detaillierte Anleitung finden Sie unter Airflow-UI über Composer öffnen und DAG pausieren.

Wenn Sie diese Schritte ausführen, können Sie sicher zu Cortex Framework Data Foundation Version 5.0 wechseln und die neuen Funktionen validieren.

Vorhandene Tabellen migrieren

Verwenden Sie jinja-cli, um Ihre vorhandenen Tabellen an ihren neuen Speicherort zu migrieren. Formatieren Sie dazu die bereitgestellte Vorlage für das Migrationsskript.

Installieren Sie jinja-cli mit dem folgenden Befehl:
```
pip install jinja-cli
```
Ermitteln Sie die folgenden Parameter aus Ihrer vorhandenen Version 4.2- und der neuen Version 5.0-Bereitstellung:
<td"> Name <td"> Beschreibung </td"></td"><td"> project_id_src <td"> Source Google Cloud Project: Projekt, in dem sich Ihr vorhandenes SAP-CDC-Dataset aus der Version 4.2-Bereitstellung befindet. Das Dataset K9_PROCESSING wird ebenfalls in diesem Projekt erstellt. </td"></td"><td"> project_id_tgt <td"> Target Google Cloud Projekt, in dem sich Ihr neu bereitgestelltes SAP-Berichts-Dataset aus der neuen Version 5.0-Bereitstellung befindet. Dieses kann sich vom Quellprojekt unterscheiden. </td"></td"><td"> dataset_cdc_processed <td"> CDC BigQuery-Dataset: BigQuery-Dataset, in dem die verarbeiteten CDC-Daten und die neuesten verfügbaren Datensätze gespeichert werden. Dieses kann mit dem Quelldataset identisch sein. </td"></td"><td"> dataset_reporting_tgt <td"> BigQuery-Ziel-Dataset für Berichte: BigQuery Dataset, in dem die vordefinierten Datenmodelle von Data Foundation for SAP bereitgestellt werden. </td"></td"><td"> k9_datasets_processing <td"> K9 BigQuery-Dataset: BigQuery-Dataset, in dem K9 (erweiterte Datenquellen) bereitgestellt wird. </td"></td">

Erstellen Sie eine JSON-Datei mit den erforderlichen Eingabedaten. Entfernen Sie alle DAGs, die Sie nicht migrieren möchten, aus dem Abschnitt 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

Wenn Sie beispielsweise weather und trends entfernen möchten, sieht das Skript so aus:

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

Erstellen Sie mit dem folgenden Befehl einen Ausgabefordner:
```
  mkdir output
```
Generieren Sie das geparste Migrationsskript mit dem folgenden Befehl. Dabei wird davon ausgegangen, dass Sie sich im Stammverzeichnis des Repositorys befinden:
```
  jinja -d data.json -o output/migrate_external_dags.sql docs/external_dag_migration/scripts/migrate_external_dags.sql
```
Prüfen Sie die SQL-Ausgabedatei und führen Sie sie in BigQuery aus, um Ihre Tabellen an den neuen Speicherort zu migrieren.

Airflow-DAGs aktualisieren und pausieren

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-Bereitstellung Version 5.0. Eine detaillierte Anleitung finden Sie in der folgenden Dokumentation:

Überprüfung und Bereinigung

Die Migration ist jetzt abgeschlossen. Sie können jetzt prüfen, ob alle Berichtsansichten in der neuen Version 5.0-Berichtsbereitstellung ordnungsgemäß funktionieren. Wenn alles ordnungsgemäß funktioniert, wiederholen Sie den Vorgang. Diesmal richten Sie die Version 5.0-Bereitstellung auf Ihr Produktions-Berichtsset aus. Anschließend können Sie alle Tabellen mit dem folgenden Skript entfernen:

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