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:

  1. 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.
  2. Legen Sie in config/config.json sowohl testData als auch SAP.deployCDC auf False fest.
  3. 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.
  4. 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.

  1. Installieren Sie jinja-cli mit dem folgenden Befehl:

    pip install jinja-cli

  2. 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.

  3. Erstellen Sie eine JSON-Datei mit den erforderlichen Eingabedaten. Entfernen Sie alle DAGs, die Sie nicht migrieren möchten, aus dem Bereich 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, würde das Script so aussehen:

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

  4. Erstellen Sie mit dem folgenden Befehl einen Ausgabeordner:

      mkdir output

  5. 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

  6. 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:

Validierung und Bereinigung

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:

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