このページは Cloud Translation API によって翻訳されました。

外部 DAG の v4.2 から v5.0 への移行

このガイドでは、出力テーブルを外部有向非循環グラフ（DAG）から Cortex Data Foundation v5.0 アーキテクチャ内の新しい場所に再配置するために必要な手順について説明します。たとえば、[天気] や [トレンド] などです。このガイドは、以前の Cortex Framework Data Foundation バージョン（4.2 ～ 5.0）で外部 DAG を実装し、現在アップグレードしているユーザーを対象としています。外部 DAG を使用していない場合や SAP をデプロイしていない場合は、このガイドは適用されません。

コンテキスト

4.2 より前のバージョンの Cortex Framework Data Foundation では、_GEN_EXT フラグを使用して外部データソースのデプロイを管理していました。一部のソースは特定のワークロード（SAP の通貨換算など）に関連付けられていました。ただし、バージョン 5.0 ではこのフラグが削除されています。複数のワークロードを処理できる DAG の管理専用の新しいモジュールが追加されました。このガイドでは、この新しい構造で動作するように既存のデータパイプラインを調整する手順について説明します。

ワークロード間の再利用可能な DAG

Cortex Framework Data Foundation v5.0 では、K9 という新しいコンポーネントが導入されています。これは、さまざまなデータソース間で共有される再利用可能なデータ要素の取り込み、処理、モデリングを担当するコンポーネントです。レポートビューは、これらの再利用可能なコンポーネントにアクセスするために K9_PROCESSING データセットを参照するようになりました。これにより、データアクセスが効率化され、冗長性が削減されます。次の外部データソースが K9 の一部として K9_PROCESSING データセットにデプロイされるようになりました。

date_dimension
holiday_calendar
trends
weather

SAP 依存の DAG

次の SAP 依存 DAG は引き続き generate_external_dags.sh スクリプトによってトリガーされますが、レポートのビルドステップで実行され、CDC（変更データキャプチャ）ステージではなく SAP レポートデータセットに書き込まれます。

currency_conversion
inventory_snapshots
prod_hierarchy_texts

移行ガイド

このガイドでは、Cortex Framework Data Foundation をバージョン 5.0 にアップグレードする手順について説明します。

Cortex Framework Data Foundation 5.0 をデプロイする

まず、Cortex Framework Data Foundation の最新バージョン（v5.0）をプロジェクトにデプロイします。手順は次のとおりです。

デプロイ中に変更されないため、以前の開発またはステージングデプロイメントの既存の RAW データセットと CDC データセットを、このデプロイメントの RAW データセットと CDC データセットとして使用します。
config/config.json で testData と SAP.deployCDC の両方を False に設定します。
テスト用に、既存の v4.2 環境とは別に新しい SAP Reporting プロジェクトを作成します。これにより、現在の運用に影響を与えることなく、アップグレードプロセスを安全に評価できます。
省略可。以前の Cortex Framework Data Foundation バージョンで実行中のアクティブな Airflow DAG がある場合は、移行を続行する前に一時停止します。これは Airflow UI から行えます。詳細な手順については、Composer から Airflow UI を開くと DAG を一時停止するのドキュメントをご覧ください。

次の手順に沿って、Cortex Framework Data Foundation バージョン 5.0 に安全に移行し、新機能と機能を検証できます。

既存のテーブルを移行する

既存のテーブルを新しい場所に移行するには、jinja-cli を使用して、提供された移行スクリプトテンプレートをフォーマットし、移行を完了します。

次のコマンドを使用して jinja-cli をインストールします。
```
pip install jinja-cli
```

既存のバージョン 4.2 デプロイと新しいバージョン 5.0 デプロイから次のパラメータを特定します。

名前	説明
`project_id_src`	ソース Google Cloud プロジェクト: バージョン 4.2 デプロイの既存の SAP CDC データセットが配置されているプロジェクト。`K9_PROCESSING` データセットもこのプロジェクトに作成されます。
`project_id_tgt`	ターゲット Google Cloud 新しいバージョン 5.0 デプロイから新しくデプロイされた SAP Reporting データセットが配置されている場所。これは、ソースプロジェクトとは異なる場合があります。
`dataset_cdc_processed`	CDC BigQuery データセット: CDC で処理されたデータが最新の利用可能なレコードを格納する BigQuery データセット。これはソースデータセットと同じでもかまいません。
`dataset_reporting_tgt`	ターゲット BigQuery レポートデータセット: Data Foundation for SAP の事前定義されたデータモデルがデプロイされている BigQuery データセット。
`k9_datasets_processing`	K9 BigQuery データセット: K9（拡張データソース）がデプロイされている BigQuery データセット。

必要な入力データを含む JSON ファイルを作成します。移行しない DAG は、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

たとえば、weather と trends を削除する場合、スクリプトは次のようになります。

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

次のコマンドを使用して出力フォルダを作成します。
```
  mkdir output
```
次のコマンドを使用して、解析された移行スクリプトを生成します（このコマンドは、リポジトリのルートにいることを前提としています）。
```
  jinja -d data.json -o output/migrate_external_dags.sql docs/external_dag_migration/scripts/migrate_external_dags.sql
```
出力 SQL ファイルを調べて BigQuery で実行し、テーブルを新しい場所に移行します。

Airflow DAG を更新して一時停止を解除する

Airflow バケット内の現在の DAG ファイルをバックアップします。次に、Cortex Framework Data Foundation バージョン 5.0 デプロイメントから新しく生成されたファイルに置き換えます。詳細な手順については、次のドキュメントをご覧ください。

検証とクリーンアップ

これで移行は完了です。これで、新しい v5.0 レポートのデプロイメント内のすべてのレポートビューが正常に動作していることを確認できます。すべてが正常に動作している場合は、このプロセスをもう一度行います。今回は、本番環境の Reporting セットへの v5.0 のデプロイをターゲットにします。その後、次のスクリプトを使用してすべてのテーブルを削除できます。

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