DataArts(DGC) から DataWorks への移行 - Migration Hub - Alibaba Cloud ドキュメントセンター

本トピックでは、LHM スケジューリング移行ツールを用いて、DataArts (DGC) のスケジューリングワークフローを DataWorks に移行する手順について説明します。このプロセスは、以下の 3 つのステップで構成されます：DataArts (DGC) タスクのエクスポート、スケジューリングタスクの変換、および DataWorks へのタスクインポート。

1. DataArts スケジューリングワークフローのエクスポート

Huawei DataArts では、ジョブ、スクリプト、リソースを一括エクスポートできます。本トピックの手順に従って、DataArts スケジューリング情報パッケージを作成してください。LHM スケジューリングエクスポートツールは、この DataArts スケジューリング情報パッケージを解析し、標準化されたスケジューリング移行パッケージを生成します。

1.1. 前提条件

JDK 17 の実行環境と Huawei Cloud アカウントを準備してください。また、移行対象の DataArts ジョブ、スクリプト、リソースをエクスポートする権限がアカウントに付与されている必要があります。

1.2. DataArts スケジューリング情報パッケージの作成

2.1. DataArts スケジューリング情報パッケージの構造

スケジューリング情報パッケージの構造は以下のとおりです。データ開発ジョブ（ワークフロー）、データ開発ノードスクリプト、リソースファイル、およびデータ統合スクリプトが含まれます。これらの各要素を DataArts からエクスポートし、パッケージ化してください。

.
├── project.json // 基本プロジェクト情報
├── cdms
│   └──<cluster_name>
│       └── <cdm_***>.json // データ統合スクリプト
└── jobs
    ├── jobs
    │   └── <***>.job // データ開発ジョブ（ワークフロー）
    ├── resources
    │   └── <***>.resource // リソースファイル
    └── scripts
        └── <***>.script // データ開発ノードスクリプト

1.2.2. 基本プロジェクト情報の作成

`project.json` ファイルに、プロジェクト ID およびプロジェクト名を含む基本プロジェクト情報を入力してください。

{
  "dataArtsWorkSpaceId": "d494af814b4b496e8b1bc7a8eee68d7a",
  "dataArtsWorkspaceName": "default"
}

1.2.3. データ開発ジョブ（ワークフロー定義）のエクスポート

DataArts コンソールを開き、**[データ開発]** をクリックします：https://console.huaweicloud.com/dayu

ジョブ開発ページで、ジョブをエクスポートします。ダウンロードが完了したら、パッケージを `./jobs/jobs` ディレクトリに解凍してください。

2.4. タスクスクリプトのエクスポート

DataArts コンソールを開き、**[データ開発]** をクリックします：https://console.huaweicloud.com/dayu

スクリプト開発ページで、スクリプトをエクスポートします。ダウンロードが完了したら、パッケージを `./jobs/scripts` ディレクトリに解凍してください。

2.5. リソースファイルのエクスポート

DataArts コンソールを開き、データ開発をクリックします：https://console.huaweicloud.com/dayu

リソース管理ページで、リソースをエクスポートします。ダウンロードが完了したら、パッケージを `./jobs/resources` ディレクトリに解凍してください。

2.6. データ統合タスクスクリプトのエクスポート

DataArts コンソールを開き、**[Data Integration]** をクリックします：https://console.huaweicloud.com/dayu

クラスタ管理ページで、データ統合タスクスクリプトをエクスポートします。ダウンロードが完了したら、パッケージを `./cdms` ディレクトリに解凍してください。

1.3. スケジューリング解析ツールの実行

コマンドラインから解析ツールを呼び出します。コマンドは以下のとおりです：

sh ./bin/run.sh read \
-f ./data/0_OriginalPackage/<DataArts_scheduling_information_package>.zip \
-o ./data/1_ReaderOutput/<source_exploration_export_package>.zip \
-t dataartsstudio-reader

`-f` は入力パッケージのパスを指定します。`-o` はソース探索エクスポートパッケージの生成先パスを指定します。`-t` は探索プラグインの名称を指定します。

たとえば、プロジェクト A を解析する場合：

sh ./bin/run.sh read \
-f ./data/0_OriginalPackage/projectA_DataArtsPkg.zip \
-o ./data/1_ReaderOutput/projectA_ReaderOutput.zip \
-t dataartsstudio-reader

探索ツールは実行中に処理情報を出力します。エラーがないか確認してください。

4. エクスポート結果の確認

`./data/1_ReaderOutput/` ディレクトリ内に生成された `ReaderOutput.zip` パッケージを開き、解析結果をプレビューしてください。

統計レポートには、DataArts エクスポートパッケージ内のワークフロー、ノード、リソース、関数、データソースに関する基本情報の要約が記載されています。

`data/project` フォルダには、標準化された DataArts スケジューリング情報が格納されています。

統計レポートには以下の 2 つの特徴があります：

1. レポート内のワークフローおよびノードの一部プロパティは変更可能です。変更可能なフィールドは青色フォントで表示されます。次のステップであるスケジューリング変換では、ツールがこのテーブルからプロパティの変更内容を取得し、初期化時に適用します。

2. レポートでは、ワークフロー子テーブル（ワークフローブラックリスト）から行を削除することで、変換対象から特定のワークフローを除外できます。ただし、相互依存関係のあるワークフローは、同一のバッチで変換する必要があります。ブラックリストを使用して分離すると例外が発生するため、避けてください。

詳細については、「スケジューリング移行における概要レポートの活用：スケジューリングプロパティの補完と修正」をご参照ください。

2. DataArts ワークフローから DataWorks ワークフローへの変換

1. 前提条件

探索ツールは正常に実行されました。DataArts スケジューリング情報がエクスポートされ、`ReaderOutput.zip` パッケージが生成されます。

（任意：推奨）探索エクスポートパッケージを開き、統計レポートを確認して、移行範囲が完全にエクスポートされていることを検証してください。

2. 変換設定項目

2.1. 設定項目テンプレートの変換

テンプレートを使用する前に、JSON ファイル内のコメントを削除してください。

{
  "name": "dataartsarts-dw-conveter",
  "self": {
    "if.use.migrationx.before": false,
    "if.use.default.convert": false,
    "if.use.dataworks.newidea": true,
    "param.map": {
      "TODAY": "$[yyyy-mm-dd]",
      "YYYY_MM_DD_1HOUR": "$[yyyy-mm-dd-hh24-1-1/24]",
      "DT": "${yyyy-mm-dd}",
      "DT_HH": "$[yyyy-mm-dd-hh24-1-1/24]",
      "DT_PRE_DAY": "$[yyyy-mm-dd-7]",
      "DT_PRE_BY_DAYS": "",
      "YESTERDAY": "${yyyy-mm-dd}",
      "DT_PRE_2DAYS": "$[yyyy-mm-dd-2]",
      "DT_PRE_3DAYS": "$[yyyy-mm-dd-3]",
      "DT_PRE_4DAYS": "$[yyyy-mm-dd-4]",
      "DT_PRE_5DAYS": "$[yyyy-mm-dd-5]",
      "YYYY_MM_DD_HOUR": "$[yyyy-mm-dd-hh24]"
    },
    "param.value.map": {
      "#{Job.getYesterday(\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-1]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-1),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-1]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-8),\"yyyyMMddHH\")}": "$[yyyymmddhh24-8]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-1),\"yyyyMMdd\")}": "$[yyyymmdd-1]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-100),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-100]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-185),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-185]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,0),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-2),\"yyyyMMdd\")}": "$[yyyymmdd-2]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-31),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-31]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,0),\"yyyyMMddHH\")}": "$[yyyymmddhh24]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,0),\"yyyyMMdd\")}": "$[yyyymmdd]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-0),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-62),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-62]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-2),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-2]"
    },
    "di.datasource.map": [
      {
        "dataArtsLinkDataSourceType": "DWS",
        "dataArtsLinkName": "dws_source1",
        "dwDataSourceType": "HOLOGRES",
        "dwConnectionName": "hologres_source1"
      },
      {
        "dataArtsLinkDataSourceType": "MYSQL",
        "dataArtsLinkName": "mysql_source1",
        "dwDataSourceType": "MYSQL",
        "dwConnectionName": "mysql_source1"
      },
      {
        "dataArtsLinkDataSourceType": "HIVE",
        "dataArtsLinkName": "hive_source1.db1",
        "dwDataSourceType": "ODPS",
        "dwConnectionName": "odps_source1_1"
      }
    ],
    "table.meta.list": [
      {
        "tableName": "",
        "partition": ""
      }
    ],
    "hBasePluginVersion": ""
  },
  "schedule_datasource": {},
  "target_schedule_datasource": {}
}

2.2. スケジューリングパラメーター変換設定項目

DataArts では、ノードのスケジューリングパラメーターで使用可能な時間式など、多数の式が提供されています。DataArts の式構文は DataWorks の式構文とは異なります。そのため、スケジューリング変換時にこれらの違いに対応する必要があります。詳細については、「式の概要_データガバナンスセンター DataArts Studio_华为云」および「日時パターン_データガバナンスセンター DataArts Studio_华为云」をご参照ください。

スケジューリング変換設定項目には、2 種類の置換パターンが用意されています。

1. `param.map`：指定された変数名の値を置換するためのマッピングを定義します。たとえば `"TODAY": "$[yyyy-mm-dd]"` と設定した場合、変換ツールはすべての `TODAY` という名前のスケジューリング変数の値を `$[yyyy-mm-dd]` に変更します。

2. `param.value.map`：指定された変数値を新しい値に置換するためのマッピングを定義します。たとえば `"#{Job.getYesterday(\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-1]"` と設定した場合、ツールは値が `#{Job.getYesterday("yyyy-MM-dd")}` であるすべての変数を検出し、その値を `$[yyyy-mm-dd-1]` に変更します。

本例では、一般的なマッピングルールを参考として示しています。

{
  "self": {
    "param.map": {
      "TODAY": "$[yyyy-mm-dd]",
      "YYYY_MM_DD_1HOUR": "$[yyyy-mm-dd-hh24-1-1/24]",
      "DT": "${yyyy-mm-dd}",
      "DT_HH": "$[yyyy-mm-dd-hh24-1-1/24]",
      "DT_PRE_DAY": "$[yyyy-mm-dd-7]",
      "DT_PRE_BY_DAYS": "",
      "YESTERDAY": "${yyyy-mm-dd}",
      "DT_PRE_2DAYS": "$[yyyy-mm-dd-2]",
      "DT_PRE_3DAYS": "$[yyyy-mm-dd-3]",
      "DT_PRE_4DAYS": "$[yyyy-mm-dd-4]",
      "DT_PRE_5DAYS": "$[yyyy-mm-dd-5]",
      "YYYY_MM_DD_HOUR": "$[yyyy-mm-dd-hh24]"
    },
    "param.value.map": {
      "#{Job.getYesterday(\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-1]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-1),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-1]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-8),\"yyyyMMddHH\")}": "$[yyyymmddhh24-8]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-1),\"yyyyMMdd\")}": "$[yyyymmdd-1]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-100),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-100]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-185),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-185]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,0),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-2),\"yyyyMMdd\")}": "$[yyyymmdd-2]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-31),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-31]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,0),\"yyyyMMddHH\")}": "$[yyyymmddhh24]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,0),\"yyyyMMdd\")}": "$[yyyymmdd]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-0),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-62),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-62]",
      "#{DateUtil.format(DateUtil.addDays(Job.planTime,-2),\"yyyy-MM-dd\")}": "$[yyyy-mm-dd-2]"
    }
  }

2.3. データ統合変換設定項目

データ統合設定項目は、主に移行前後のデータソース間のマッピングルールを指定します。たとえば、DataArts の DWS データソースは DataWorks の Hologres データソースに、DataArts の Hive データソースは DataWorks の ODPS（MaxCompute）データソースに変更されます。その他の追加情報も提供されます。設定項目は以下のとおりです：

`di.datasource.map`：DataArts と DataWorks のデータソース間のマッピングテーブルです。`dataArtsLinkName` および `dataArtsLinkDataSourceType` は DataArts 内のデータソースの名称およびタイプです。`dwConnectionName` および `dwDataSourceType` は DataWorks 内のデータソースの名称およびタイプです。
Hive データソースは特殊です。Hive から MaxCompute への移行シナリオでは、Hive データソース内の各データベースは通常、MaxCompute のワークスペースに対応します。したがって、Hive データソースの場合、`dataArtsLinkName` にデータベース情報を追加する必要があります（以下に例を示します）。
`table.meta.list`：一部のデータソースを移行した後、特定のテーブルに対する操作でパーティション情報を追加する必要があります。このパラメーターは、現在 Hologres データソースへの書き込み時のみ有効です。
`hBasePluginVersion`：HBase のバージョンです。有効な値については、「HBase データソース」をご参照ください。

{
  "self": {
    "di.datasource.map": [
      {
        "dataArtsLinkDataSourceType": "DWS",
        "dataArtsLinkName": "dws_source1",
        "dwDataSourceType": "HOLOGRES",
        "dwConnectionName": "hologres_source1"
      },
      {
        "dataArtsLinkDataSourceType": "MYSQL",
        "dataArtsLinkName": "mysql_source1",
        "dwDataSourceType": "MYSQL",
        "dwConnectionName": "mysql_source1"
      },
      {
        "dataArtsLinkDataSourceType": "HIVE",
        "dataArtsLinkName": "hive_source1.db1",
        "dwDataSourceType": "ODPS",
        "dwConnectionName": "odps_source1_1"
      }
    ],
    "table.meta.list": [
      {
        "tableName": "",
        "partition": ""
      }
    ],
    "hBasePluginVersion": ""
  }
}

2.4. ノード変換ルール

ツールは現在、以下の DataArts ノードタイプの変換をサポートしています：

・ CDMJob、HiveSQL、DWSSQL、DLISQL、RDSSQL、SparkSQL

・ Shell、DLISpark、MRSSpark、DLFSubJob、RESTAPI、Note、Dummy

現在の変換ルールは固定されており、設定できません。ルールをカスタマイズする場合は、LHM 移行ツールチームにお問い合わせください：

・ `CDMJob（データ統合）`：デフォルトで DataWorks DI（データ統合）タスクに変換されます。

データ統合スクリプト（データ統合リーダープラグインおよびライタープラグインの設定項目）は、`di.datasource.map` に基づいて変換されます。ツールは、現在、データソースに関連する一部の CDM から DI への設定項目変換をカバーしています。`dwDataSourceType` には、DataWorks データソースのタイプを入力します。サポートされるタイプには、ODPS、ELASTICSEARCH、HBASE、HIVE、HOLOGRES、KAFKA、MONGODB、MYSQL、ORACLE、OSS、POSTGRESQL、SQLSERVER があります。

・ `HiveSQL`：デフォルトで ODPS_SQL（MaxCompute）に変換されます。

・ `DWSSQL`：デフォルトで ODPS_SQL（MaxCompute）に変換されます。

・ `DLISQL`：デフォルトで ODPS_SQL（MaxCompute）に変換されます。

・ `RDSSQL`：デフォルトで ODPS_SQL（MaxCompute）に変換されます。

・ `SparkSQL`：デフォルトで ODPS_SQL（MaxCompute）に変換されます。

・ `Shell`：デフォルトで DIDE_SHELL（汎用シェル）に変換されます。

・ `DLISpark`：デフォルトで ODPS_SPARK に変換され、一部のパラメーターがマッピングされます。

・ `MRSSpark`：デフォルトで ODPS_SPARK に変換され、一部のパラメーターがマッピングされます。

・ `DLFSubJob`：デフォルトで SUB_PROCESS ノードに変換されます。参照関係は正しく取得されます。

・ `RESTAPI`：デフォルトで DIDE_SHELL に変換されます。ノード内の HTTP リクエストは `curl` コマンドを構築して実装されます。現在、GET および POST リクエストのみがサポートされています。

・ `Note`：デフォルトで VIRTUAL（ゼロ負荷）ノードに変換されます。コンテンツは保持されます。

・ `Dummy`：デフォルトで VIRTUAL（ゼロ負荷）ノードに変換されます。コンテンツは保持されます。

・その他の未サポートノードタイプは、VIRTUAL ノードに変換されます。

DataWorks ノードタイプの詳細については、以下の列挙クラスをご参照ください：

https://github.com/aliyun/dataworks-spec/blob/b0f4a4fd769215d5f81c0bbe990addd7498df5f4/spec/src/main/java/com/aliyun/dataworks/common/spec/domain/dw/types/CodeProgramType.java#L180

3. スケジューリング変換ツールの実行

コマンドラインから変換ツールを呼び出します。コマンドは以下のとおりです：

sh ./bin/run.sh convert \
-c ./conf/<your_configuration_file>.json \
-f ./data/1_ReaderOutput/<source_exploration_export_package>.zip \
-o ./data/2_ConverterOutput/<conversion_result_output_package>.zip \
-t dataartsstudio-dw-converter

`-c` は設定ファイルのパスを指定します。`-f` は `ReaderOutput` パッケージの保存先パスを指定します。`-o` は `ConverterOutput` パッケージの保存先パスを指定します。`-t` は変換プラグインの名称を指定します。

たとえば、DataArts プロジェクト A を変換する場合：

sh ./bin/run.sh convert \
-c ./conf/projectA_convert.json \
-f ./data/1_ReaderOutput/projectA_ReaderOutput.zip \
-o ./data/2_ConverterOutput/projectA_ConverterOutput.zip \
-t dataartsstudio-dw-converter

変換ツールは実行中に処理情報を出力します。エラーがないか確認してください。変換が完了すると、成功および失敗した変換件数の統計がコマンドラインに出力されます。一部のノードの変換に失敗しても、全体の変換プロセスには影響しません。少数のノードが変換できなかった場合は、DataWorks への移行後に手動で修正できます。

2.4. 変換結果の確認

`./data/2_ConverterOutput/` ディレクトリ内に生成された `ConverterOutput.zip` パッケージを開き、エクスポート結果をプレビューしてください。

統計レポートには、変換後のワークフロー、ノード、リソース、関数、データソースに関する基本情報の要約が記載されています。

`data/project` フォルダには、変換済みのスケジューリング移行パッケージが格納されています。

統計レポートには以下の 2 つの特徴があります：

1. レポート内のワークフローおよびノードの一部プロパティは変更可能です。変更可能なフィールドは青色フォントで表示されます。次のステップである DataWorks へのインポート時には、ツールがこのテーブルからプロパティの変更内容を取得し、適用します。

2. レポートでは、ワークフロー子テーブル（ワークフローブラックリスト）から行を削除することで、DataWorks へのインポート対象から特定のワークフローを除外できます。ただし、相互依存関係のあるワークフローは、同一のバッチでインポートする必要があります。ブラックリストを使用して分離すると例外が発生するため、避けてください。

詳細については、「スケジューリング移行における概要レポートの活用：スケジューリングプロパティの補完と修正」をご参照ください。

3. DataWorks へのインポート

LHM 移行ツールの異種変換機能により、ソースのスケジューリング要素が DataWorks のスケジューリング形式に変換されました。ツールは、異なる移行シナリオ向けに統一されたアップロードエントリを提供し、ワークフローを DataWorks にインポートできます。

インポートツールは複数回の書き込みをサポートし、ワークフローの作成または更新（上書きモード）を自動的に選択します。

1. 前提条件

1.1. 変換の成功

変換ツールは正常に実行されました。ソーススケジューリング情報は DataWorks スケジューリング情報に変換され、`ConverterOutput.zip` パッケージが生成されます。

（任意：推奨）変換出力パッケージを開き、統計レポートを確認して、移行範囲が正常に変換されたことを検証してください。

1.2. DataWorks の構成

DataWorks で以下の操作を行ってください：

1. ワークスペースを作成します。

2. AccessKey ペア（AK および SK）を作成し、ワークスペースに対して管理者権限が付与されていることを確認します。トラブルシューティングを容易にするため、アカウントに紐付けられた AccessKey ペアの作成を強く推奨します。

3. ワークスペース内でデータソースを作成し、計算リソースをアタッチし、リソースグループを作成します。

4. ワークスペース内でリソースファイルをアップロードし、ユーザー定義関数（UDF）を作成します。

1.3. ネットワーク接続性の確認

DataWorks エンドポイントへの接続を確認してください。

エンドポイント一覧：

エンドポイント

ping dataworks.aliyuncs.com

2. インポート設定項目

プロジェクトディレクトリの `conf` フォルダ内に、`writer.json` のような JSON 形式のエクスポート構成ファイルを作成します。

ファイルを使用する前に、JSON ファイル内のコメントを削除してください。

{
  "schedule_datasource": {
    "name": "YourDataWorks", // DataWorks データソースの名称を指定します。
    "type": "DataWorks",
    "properties": {
      "endpoint": "dataworks.cn-hangzhou.aliyuncs.com", // エンドポイント
      "project_id": "YourProjectId", // ワークスペース ID
      "project_name": "YourProject", // ワークスペース名
      "ak": "************", // AK
      "sk": "************" // SK
    },
    "operaterType": "MANUAL"
  },
  "conf": {
    "di.resource.group.identifier": "Serverless_res_group_***_***", // データ統合リソースグループ
    "resource.group.identifier": "Serverless_res_group_***_***", // スケジューリングリソースグループ
    "dataworks.node.type.xls": "/Software/bwm-client/conf/CodeProgramType.xls", // DataWorks ノードタイプテーブルのパス
    "qps.limit": 5 // DataWorks への API リクエスト送信時の QPS 制限
  }
}

2.1. エンドポイント

DataWorks のリージョンに応じてエンドポイントを選択してください。参考資料については、以下のドキュメントをご参照ください：

エンドポイント

2.2. ワークスペース ID およびワークスペース名

DataWorks コンソールを開き、ワークスペースの詳細ページに移動します。右側の「基本情報」セクションからワークスペース ID およびワークスペース名を取得してください。

2.3. AccessKey ペアの作成および権限付与

ユーザー管理ページで、対象の DataWorks ワークスペースに対して管理者レベルの読み取り／書き込み権限を持つ AccessKey ペアを作成してください。

権限管理は 2 か所で行われます。アカウントが Resource Access Management（RAM）ユーザーである場合、まず RAM ユーザーに DataWorks 操作を実行する権限を付与する必要があります。

アクセスポリシー管理ページ：https://ram.console.alibabacloud.com/policies

その後、DataWorks ワークスペース内でアカウントにワークスペース権限を付与します。

注意：AccessKey に対してネットワークアクセス制御ポリシーを設定できます。移行ツールを実行するマシンの IP アドレスが DataWorks にアクセスできるよう、許可設定を行ってください。

2.4. リソースグループ

DataWorks ワークスペースの詳細ページで、左側のメニューバーから「リソースグループ」ページに移動します。リソースグループをアタッチし、その ID を取得してください。

汎用リソースグループは、ノードスケジューリングおよびデータ統合の両方で使用できます。設定項目では、スケジューリングリソースグループ（`resource.group.identifier`）およびデータ統合リソースグループ（`di.resource.group.identifier`）を、同じ汎用リソースグループに設定できます。

2.5. QPS 設定

ツールは DataWorks API を呼び出してデータをインポートします。DataWorks の各エディションでは、読み取り／書き込み用 OpenAPI オペレーションの秒間クエリ数（QPS）制限および 1 日あたりの呼び出し回数制限が異なります。詳細については、「使用制限」をご参照ください。

DataWorks Basic Edition、Standard Edition、Professional Edition の場合、`"qps.limit"` を `5` に設定することを推奨します。Enterprise Edition の場合、`"qps.limit"` を `20` に設定することを推奨します。

注意：同時に複数のインポートツールを実行しないでください。

2.6. DataWorks ノードタイプ ID の設定

DataWorks では、一部のノードタイプがリージョンごとに異なるタイプ ID が割り当てられています。具体的なタイプ ID は、DataWorks の Data Studio インターフェイスに依存します。この特性は、主にデータベースノードに適用されます。詳細については、「データベースノード」をご参照ください。

たとえば、MySQL ノードの `NodeTypeId` は中国（杭州）リージョンでは `1000039`、中国（深セン）リージョンでは `1000041` です。

DataWorks リージョン間のこのような差異に対応するため、ツールではノードタイプ ID テーブルを設定可能になっています。

このテーブルは、インポートツールの設定項目によって導入されます：

"conf": {
    "dataworks.node.type.xls": "/Software/bwm-client/conf/CodeProgramType.xls" // DataWorks ノードタイプテーブルのパス
 }

DataWorks Data Studio インターフェイスからノードタイプ ID を取得するには、新しいワークフローを作成し、ノードを追加して保存した後、ワークフローの spec を確認してください。

ノードタイプが誤って設定された場合、ワークフローの公開時に以下のエラーが報告されます。

3. DataWorks インポートツールの実行

コマンドラインからインポートツールを呼び出します。コマンドは以下のとおりです：

sh ./bin/run.sh write \
-c ./conf/<your_configuration_file>.json \
-f ./data/2_ConverterOutput/<conversion_result_output_package>.zip \
-o ./data/4_WriterOutput/<import_result_storage_package>.zip \
-t dw-newide-writer

`-c` は設定ファイルのパスを指定します。`-f` は `ConverterOutput` パッケージの保存先パスを指定します。`-o` は `WriterOutput` パッケージの保存先パスを指定します。`-t` は送信プラグインの名称を指定します。

たとえば、プロジェクト A を DataWorks にインポートする場合：

sh ./bin/run.sh write \
-c ./conf/projectA_write.json \
-f ./data/2_ConverterOutput/projectA_ConverterOutput.zip \
-o ./data/4_WriterOutput/projectA_WriterOutput.zip \
-t dw-newide-writer

インポートツールは実行中に処理情報を出力します。エラーがないか確認してください。インポートが完了すると、成功および失敗したインポート件数の統計がコマンドラインに出力されます。一部のノードのインポートに失敗しても、全体のインポートプロセスには影響しません。少数のノードがインポートできなかった場合は、DataWorks で手動で修正できます。

4. インポート結果の確認

インポートが完了したら、DataWorks で結果を確認できます。個々のワークフローのインポート状況も確認可能です。問題が発生し、インポートを停止する必要がある場合は、`jps` コマンドを実行して `BwmClientApp` を検出し、`kill -9` コマンドでインポートを停止してください。

5. よくある質問

5.1. ソースが継続的に開発中です。これらの増分および変更を DataWorks にどのように反映させればよいですか？

移行ツールは上書きモードで動作します。ソースの増分を DataWorks に反映させるには、エクスポート、変換、インポートの各プロセスを再実行してください。ツールは、ワークフローの完全なパスで一致判定を行い、作成または更新を決定します。変更を移行する際は、ワークフローの移動を行わないでください。

5.2. ソースが継続的に開発中であり、同時に DataWorks でもワークフローの変換およびガバナンスを実施しています。増分移行は DataWorks での変更を上書きしてしまいますか？

はい、上書きされます。移行が完了した後に DataWorks で後続の変換を実施することを推奨します。あるいは、バッチ移行を採用することもできます。移行済みのワークフローが再度上書きされないことが確認できたら、DataWorks での変換を開始できます。異なるバッチ間は互いに影響しません。

5.3. 全体のパッケージのインポートに時間がかかりすぎます。一部だけをインポートすることは可能ですか？

はい、可能です。インポート対象のパッケージを手動でトリミングできます。`data/project/workflow` フォルダ内では、インポートしたいワークフローのみを保持し、それ以外は削除してください。フォルダを再圧縮してパッケージ化した後、インポートツールを実行します。ただし、相互依存関係のあるワークフローは、必ず一緒にインポートしてください。そうでないと、ワークフロー間のノード系譜が失われる可能性があります。