このトピックでは、LHM スケジューリング移行ツールを使用して DolphinScheduler のスケジューリングワークフローを DataWorks に移行する方法について説明します。このプロセスには、DolphinScheduler からのタスクのエクスポート、変換、そして DataWorks へのインポートが含まれます。
1. DolphinScheduler スケジューリングワークフローのエクスポート
エクスポートツールは、DolphinScheduler API を呼び出すことによって、プロジェクト、ワークフロー定義、データソース定義、およびリソースファイル情報を取得します。このツールは、1.x、2.x、3.x を含むすべてのバージョンの DolphinScheduler をサポートしています。ワークフローをエクスポートするには、次の手順に従ってください。
1. 前提条件
JDK 17 ランタイム環境を準備します。ランタイム環境と DolphinScheduler 間のネットワーク接続を確保してください。スケジューリング移行ツールをダウンロードし、ローカルで解凍します。
ネットワーク接続をテストするには、DolphinScheduler ListProject API を呼び出して、情報が返されること、および返されたリストに移行したいプロジェクトが含まれていることを確認します。トークンの取得方法については、次のセクションをご参照ください。
# DolphinScheduler 1.x
curl -H "token:<YourToken>" -X GET http://<YourIp>:12345/dolphinscheduler/projects/query-project-list
# DolphinScheduler 2.x
curl -H "token:<YourToken>" -X GET http://<YourIp>:12345/dolphinscheduler/projects/list
# DolphinScheduler 3.x
curl -H "token:<YourToken>" -X GET http://<YourIp>:12345/dolphinscheduler/projects/list2. 接続情報の構成
プロジェクトディレクトリの `conf` フォルダに、`read.json` などの JSON 形式でエクスポート構成ファイルを作成します。
使用する前に JSON ファイルからコメントを削除してください。
{
"schedule_datasource": {
"name": "YourDolphin", // DolphinScheduler データソースに名前を付けます。
"type": "DolphinScheduler", // データソースタイプ (DolphinScheduler)
"properties": {
"endpoint": "http://localhost:12345", // エンドポイント
"project": "Comprehensive Test", // プロジェクト名
"token": "***********************" // トークン
},
"operaterType": "AUTO" // 接続タイプ (AUTO: API を介してスケジューリング情報を自動的に取得)
},
"conf": {
}
}2.1. エンドポイントの取得
エンドポイントは API エンドポイントであり、通常はフロントエンドページのアドレスと同じです。たとえば、次の図では、エンドポイントは `http://120.55.X.XXX:12345` です。
DolphinScheduler のアドレスが `http://your-company:12345/dolphinscheduler/ui/home` の場合、エンドポイントは `http://your-company:12345` です。
DolphinScheduler はオープンソースのスケジューリングエンジンであるため、その API モジュールはカスタマイズされている可能性があります。API 呼び出しが失敗した場合は、Swagger ページに移動して簡単なテストを実行し、API 属性を確認できます。
2.2. トークンの取得
Security Center のトークン管理ページで、トークンを作成し、長い有効期限を設定します。
注: ユーザートークンには、移行したいプロジェクトに対する権限が必要です。
2.3. プロジェクトの取得
プロジェクト管理ページを開きます。移行したいプロジェクトの名前をコピーし、`Project` パラメーターの値として入力します。
3. スケジューリング検出ツールの実行
スケジューリング検出ツールを実行するたびに、次の情報を格納する 2 つのファイルが生成されます。
DolphinScheduler API によって出力される生情報 (ApiOutput パッケージ)。
検出ツールによって解析されたパッケージ。生情報のデータ構造を標準化します (ReaderOutput パッケージ)。
ReaderOutput パッケージは、スケジューリングエクスポートの最終結果です。ApiOutput パッケージは、エクスポートプロセス中のトラブルシューティングにのみ使用される中間結果です。
コマンドラインから検出ツールを実行します。コマンドは次のとおりです。
sh ./bin/run.sh read \
-c ./conf/<your_config_file>.json \
-f ./data/0_OriginalPackage/<api_raw_info_package>.zip \
-o ./data/1_ReaderOutput/<source_discovery_export_package>.zip \
-t <PluginName>コマンドでは、`-c` は構成ファイルのパスを指定し、`-f` は ApiOutput パッケージのストレージパスを指定し、`-o` は ReaderOutput パッケージのストレージパスを指定し、`-t` は検出プラグイン名を指定します。
DolphinScheduler 1.x、2.x、3.x のエクスポートプラグインは、それぞれ `dolphinv1-reader`、`dolphinv2-reader`、`dolphinv3-reader` です。
たとえば、DolphinScheduler 3.2.0 からプロジェクト A をエクスポートするには、次のようにします。
sh ./bin/run.sh read \
-c ./conf/projectA_read.json \
-f ./data/0_OriginalPackage/projectA_ApiOutput.zip \
-o ./data/1_ReaderOutput/projectA_ReaderOutput.zip \
-t dolphinv3-reader4. エクスポート結果の表示
生成された `ReaderOutput.zip` パッケージを `./data/1_ReaderOutput/` ディレクトリで開き、エクスポート結果をプレビューします。
統計レポートには、DolphinScheduler のワークフロー、ノード、リソース、関数、データソースに関する基本情報が要約されています。
`data/project` フォルダには、DolphinScheduler スケジューリング情報の標準化されたデータ構造が含まれています。
統計レポート:
'Overview' という名前のシート 1 には、Reader エクスポート結果の概要が表示されます。'WORKFLOW'、'WORKFLOWNODE' などの名前のシートには、ワークフロー、ノード、リソース、関数、データソースに関する特定の情報が含まれています。
統計レポートには、2 つの特別な機能があります。
1. レポートでワークフローとノードの一部のプロパティを変更できます。編集可能なフィールドは青色のフォントで表示されます。次の段階であるスケジューリング変換では、ツールはテーブルからプロパティの変更を取得し、初期化中に適用します。
2. レポートでは、ワークフローサブテーブルの行を削除することで、変換中にワークフローをスキップできます。これは、ワークフローブラックリストの作成とも呼ばれます。注: ワークフローが相互に依存している場合、関連するワークフローは同じバッチで変換する必要があります。ブラックリストを使用してそれらを分離しないでください。分離するとエラーが発生します。
詳細については、「スケジューリング移行の概要レポートを使用してスケジューリングプロパティを追加または変更する」をご参照ください。
5. Q&A
5.1. (バッチ検出) 複数のプロジェクトを一度に検出できますか？
はい、できます。`project` 構成項目に複数のプロジェクト名を入力できます。名前はスペースなしのカンマで区切ります。DolphinScheduler のプロジェクト名にはスペースを含めることができるため、スペースは名前の一部として扱われます。
使用する前に JSON ファイルからコメントを削除してください。
{
"schedule_datasource": {
"name": "YourDolphin", // DolphinScheduler データソースに名前を付けます。
"type": "DolphinScheduler", // データソースタイプ (DolphinScheduler)
"properties": {
"endpoint": "http://localhost:12345", // エンドポイント
"project": "Project1,Project2", // プロジェクト名
"token": "***********************" // トークン
},
"operaterType": "AUTO" // 接続タイプ (AUTO: API を介してスケジューリング情報を自動的に取得)
},
"conf": {
}
}実行コマンドでは、`-f` と `-o` の入力パラメーターはフォルダパスである必要があります。ツールはプロジェクトごとに個別のエクスポートパッケージを自動的に作成します。
sh ./bin/run.sh read \
-c ./conf/<your_config_file>.json \
-f ./data/0_OriginalPackage/ \
-o ./data/1_ReaderOutput/ \
-t <dolphinv1/2/3-reader>5.2. (手動モード) API がない場合はどうすればよいですか？
一部の開発者は DolphinScheduler API モジュールを削除するため、API 接続を介してスケジューリング情報を取得できなくなります。代替手段として、`./data/0_OriginalPackage/` ディレクトリに生情報パッケージを手動で作成し、構成項目で `operaterType` を `MANUAL` に変更できます。その後、ツールは手動で作成された生パッケージを入力として使用し、DolphinScheduler の検出を完了します。
使用する前に JSON ファイルからコメントを削除してください。
{
"schedule_datasource": {
"name": "YourDolphin", // DolphinScheduler データソースに名前を付けます。
"type": "DolphinScheduler", // データソースタイプ (DolphinScheduler)
"properties": {
"endpoint": "http://localhost:12345", // エンドポイント
"project": "Comprehensive Test", // プロジェクト名
"token": "***********************" // トークン
},
"operaterType": "MANUAL" // 接続タイプ (MANUAL: オフラインモード)
},
"conf": {
}
}生パッケージ構造の例:
.
├── package_info.json
├── projects.json
├── projects
│ └── Comprehensive Test
│ └── processDefinition
│ └── process_definitions_page_1.json
├── datasource
│ └── datasource_page_1.json
├── resource
│ └── resources.json
└── udfFunction
└── udf_function_page_1.json`package_info.json` には、DolphinScheduler のバージョンを含むパッケージ情報が含まれています。
{
"version": "3.2.0"
}`projects.json` ファイルにはプロジェクト情報が含まれています。このファイルを手動で作成する場合は、`id`、`userId`、`code`、`name` フィールドの入力に集中してください。
[
{
"id": 2,
"userId": 1,
"code": 16372996967936,
"name": "Comprehensive Test",
"description": "",
"createTime": "2025-01-20 11:40:39",
"updateTime": "2025-01-20 11:40:39",
"perm": 0,
"defCount": 0,
"instRunningCount": 0
}
]`projects` フォルダにはワークフロー定義が格納されます。このフォルダを手動で作成する場合は、そのサブディレクトリをプロジェクト名に変更します。次に、DolphinScheduler インターフェイスからワークフロー定義をエクスポートし、それらを `process_definitions_page_*.json` に順次名前変更して、`processDefinition` ディレクトリに配置します。
`datasource`、`resource`、`udfFunction` には、それぞれデータソース、リソースファイル、UDF 情報が含まれています。DolphinScheduler インターフェイスにはこれらの要素のエクスポート機能がないため、省略できます。これを行うには、`datasource_page_1.json`、`resources.json`、`udf_function_page_1.json` ファイルを空の配列 `[]` で埋めます。これらの要素を省略すると、ワークフロー移行の詳細にわずかな影響があります。この影響には、SQL ノードのデータソースへのマッピング、DataX ノード (非カスタムテンプレートモード) のデータソースへのマッピング、およびノードとリソースの参照関係の移行が含まれます。影響を受けるノードは DataWorks で期待どおりに作成されますが、DataWorks でこれらのノードとデータソースおよびリソースとのバインドを手動で構成する必要があります。
5.3. トークンは有効ですが、エクスポートされたワークフローの一部が欠落している場合はどうすればよいですか？
まず、トークンにプロジェクトの権限があるかどうかを確認します。
さらに、DolphinScheduler 1.x の一部のマイナーバージョンの API がエクスポート中にデータ損失を引き起こす可能性があることがわかっています。エクスポート結果の統計レポートを使用して、欠落しているワークフローを特定し、補完することができます。
2. DolphinScheduler ワークフローの DataWorks ワークフローへの変換
DolphinScheduler は、人気のあるオープンソースのスケジューリングエンジンです。DataWorks は、DolphinScheduler のスケジューリング機能を完全にサポートしています。移行ツールがワークフローを変換した後、それらは DolphinScheduler と同じ効果で DataWorks で実行できます。
1. 前提条件
検出ツールが正常に実行され、DolphinScheduler のスケジューリング情報がエクスポートされ、`ReaderOutput.zip` ファイルが生成されました。
(オプション、推奨) 検出エクスポートパッケージを開き、統計レポートを表示して、移行の全範囲がエクスポートされたかどうかを確認します。
2. 変換構成項目
2.1. 変換構成テンプレート
使用する前に JSON ファイルからコメントを削除してください。
{
"conf": {},
"self": {
"if.use.default.convert": false,
"if.use.migrationx.before": false,
"if.use.dataworks.newidea": true,
"owner.map": [ // オーナーマッピング
{
"src": "1", // DolphinScheduler ユーザー ID
"tgt": "202006995118212119" // DataWorks ユーザー ID
}
],
"conf": [
{
"nodes": "all", // ルールグループの範囲
"rule": {
"settings": {
// DolphinScheduler Shell ノードを DataWorks Shell ノードに変換
"workflow.converter.shellNodeType": "DIDE_SHELL",
// 不明なノードをデフォルトで DataWorks 仮想ノードに変換
"workflow.converter.target.unknownNodeTypeAs": "VIRTUAL",
// DolphinScheduler SQL ノードをデータソースタイプに基づいて対応する DataWorks SQL またはデータベースノードに変換
"workflow.converter.dolphinscheduler.sqlNodeTypeMapping": {
"CLICKHOUSE": "CLICK_SQL",
"HIVE": "ODPS_SQL",
"STARROCKS": "StarRocks",
"DORIS": "HOLOGRES_SQL",
"MYSQL": "MYSQL",
"REDSHIFT": "Redshift",
"SQLSERVER": "SQLSERVER",
"PRESTO": "EMR_PRESTO",
"POSTGRESQL": "POSTGRESQL",
"ORACLE": "Oracle",
"ATHENA": "MYSQL"
},
// DolphinScheduler と DataWorks のデータソース名のマッピング
"workflow.converter.connection.mapping": {
"mysqlDb1": "dataworks_mysqlDb1",
"srDb1": "dataworks_srDb1"
},
// DataWorks にアタッチされたメインコンピュートエンジン (EMR、MaxCompute、または Hologres)
"workflow.converter.target.engine.type": "EMR",
// DolphinScheduler Spark ノードを DataWorks MaxCompute Spark ノードに変換
"workflow.converter.sparkSubmitAs": "ODPS_SPARK",
"workflow.converter.sparkVersion": "3.x",
}
}
}
]
},
"schedule_datasource": {
"name": "DsProject",
"type": "DolphinScheduler"
},
"target_schedule_datasource": {}
}2.2. オーナーマッピング
DolphinScheduler は各ワークフローのオーナーを記録します。オーナーはチーム開発にとって重要な情報です。このツールは、DolphinScheduler ユーザーを DataWorks ユーザーにマッピングして、ワークフローとノードに対応するオーナーをマークすることをサポートしています。
ユーザー管理ページから DolphinScheduler のユーザー名と ID を取得します。
ユーザーをメンバーとして DataWorks ワークスペースに追加できます。右上隅からユーザー ID を取得します。
データ開発ページのオーナーのドロップダウンリストから ID を取得することもできます。
2.3. ノード変換ルール
2.3.1. ルールの範囲
ノード変換ルールの範囲を設定できます。たとえば、すべてのノードを統一されたルールに従って変換するには、`"nodes": "all"` を構成し、`Settings` を入力します。通常、`all` ルールグループを 1 つだけ構成すれば十分です。
使用する前に JSON ファイルからコメントを削除してください。
{
"conf": {},
"self": {
"conf": [
{
"nodes": "all", // ルールグループの範囲は ALL です。すべてのノードがこのルールに従って変換されます。
"rule": {
"settings": {
// 設定
}
}
]
}
}一部のノードに個別の変換ルールが必要な場合は、`nodes` にタスク ID または名前を入力してルールの範囲を指定できます。ノードのバッチにルールを設定するには、ID または名前をカンマで区切ります。名前を使用すると設定が正しくない可能性があるため、ID を使用して範囲を指定することをお勧めします。正規表現を使用してノード名を照合することもできます。また、残りのノードにデフォルトの変換ルールを提供するために、`normal` ルールグループを設定することを強くお勧めします。
使用する前に JSON ファイルからコメントを削除してください。
{
"conf": {},
"self": {
"conf": [
{
"nodes": "node1Name, node2Id", // ルールグループの範囲は node1 と node2 です。
"rule": {
"settings": {
// 設定 1
}
},
{
"nodes": "node3Name, node4Id", // ルールグループの範囲は node3 と node4 です。
"rule": {
"settings": {
// 設定 2
}
},
{
"nodes": "regexExpression", // 正規表現によるノード名のフィルタリングをサポートします。
"rule": {
"settings": {
// 設定 3
}
},
{
"nodes": "normal", // 他のノードの変換ルール。
"rule": {
"settings": {
// 設定 4
}
}
]
}
}2.3.2. 変換ルール
DolphinScheduler 1.x、2.x、3.x は異なるノードタイプをサポートしています。そのため、変換ソリューションと構成項目は異なります。詳細は次のとおりです。
2.3.2.1. DolphinScheduler 3.x 変換構成項目
このツールは現在、次の DolphinScheduler 3.x ノードタイプの変換をサポートしています。
SHELL、SQL、PYTHON、DATAX、SQOOP、SEATUNNEL、HIVECLI、SPARK (Java、Python、Sql)、MR、PROCEDURE、HTTP、CONDITIONS、SWITCH、DEPENDENT、および SUB_PROCESS。
次のタイプに対して DataWorks マッピングルールを構成できます。
SHELL (workflow.converter.shellNodeType):
DIDE_SHELL、EMR_SHELL、または VIRTUAL ノードに変換することをお勧めします。
SQL (workflow.converter.dolphinscheduler.sqlNodeTypeMapping):
さまざまな SQL ノードまたはデータベースノードに変換することをお勧めします。
PROCEDURE (workflow.converter.dolphinscheduler.sqlNodeTypeMapping):
さまざまな SQL ノードまたはデータベースノードに変換することをお勧めします。
PYTHON (workflow.converter.pyNodeType):
PYTHON、PYODPS、PYODPS3、または EMR_SHELL ノードに変換することをお勧めします。
HIVECLI (workflow.converter.dolphinscheduler.sqlNodeTypeMapping/HIVE):
EMR_HIVE または ODPS_SQL ノードに変換することをお勧めします。
SPARK (workflow.converter.sparkSubmitAs):
SparkJava および SparkPython ノードを ODPS_SPARK または EMR_SPARK ノードに変換することをお勧めします。
SparkSql ノードを ODPS_SQL または EMR_SPARK_SQL ノードに変換することをお勧めします。
MR (workflow.converter.mrNodeType):
ODPS_MR または EMR_MR ノードに変換することをお勧めします。
DataWorks ノードタイプの詳細については、次の列挙クラスをご参照ください。
固定変換ルールを持つノードタイプ:
DATAX: DI ノードに変換されます。カスタムテンプレートモード (JSON スクリプトモード) と通常モード (フロントエンドエントリモード) の両方がサポートされています。
次のデータソースリーダープラグイン構成の変換がサポートされています: MYSQL から mysql、POSTGRESQL から postgresql、ORACLE から oracle、SQLSERVER から sqlserver、ODPS から odps、OSS から oss、HIVE から hdfs、Hadoop 分散ファイルシステム (HDFS) から hdfs、CLICKHOUSE から clickhouse、MONGODB から mongodb。
次のデータソースライタープラグイン構成の変換がサポートされています: MYSQL から mysql、POSTGRESQL から postgresql、ORACLE から oracle、SQLSERVER から sqlserver、ODPS から odps、OSS から oss、HIVE から hdfs、HDFS から hdfs、CLICKHOUSE から clickhouse、MONGODB から mongodb。
SQOOP: DI ノードに変換されます。
次のデータソースリーダープラグイン構成の変換がサポートされています: Mysql から mysql、Hive から hive、HDFS から hdfs。
次のデータソースライタープラグイン構成の変換がサポートされています: Mysql から mysql、Hive から hive、HDFS から hdfs。
SEATUNNEL: DI ノードに変換されます。
スクリプト変換はまだサポートされていません。ノードとスケジューリング情報のみが変換されます。
HTTP: DIDE_SHELL (汎用 Shell) ノードに変換されます。移行ツールは、リクエストパラメーターを自動的に curl コマンドに連結します。
SWITCH: CONTROLLER_BRANCH (ブランチ) ノードに変換されます。機能は移行前後で同じです。
SUB_PROCESS: SUB_PROCESS ノードに変換されます。機能は移行前後で同じです。注: ワークフローを DataWorks にインポートすると、移行ツールは参照されるワークフローの '参照可能' スイッチを有効にします。参照されるワークフローは、SUB_PROCESS 呼び出しによってのみ開始でき、単独でスケジュールして開始することはできません。
DEPENDENT: VIRTUAL ノードに変換されます。依存関係はノードリネージ依存関係に変換されます。たとえば、Dependent ノードがワークフロー A に依存している場合、依存関係はワークフロー A の末尾ノードから Dependent ノードへのリネージに変換されます。Dependent ノードがノード A に依存している場合、依存関係はノード A から Dependent ノードへのリネージに変換されます。次の図に図解を示します。
CONDITIONS: ノードには 2 層のロジックが含まれており、2 層の CONTROLLER_JOIN (マージ) ノードを使用して実装されます。下の図に示すケースでは、CONDITIONS ノードには 2 つの上流ノード (A と B) と 2 つの下流ノード (C と D) があります。論理式は `((!A&B)|(A&!B)|(!A&!B))` です。式が true の場合、フローは C に進みます。式が false の場合、フローは D に進みます。上層では、`!A&B`、`A&!B`、`!A&!B` の結果を計算するために 3 つのマージノードが生成されます。下層では、2 つのノードが生成されます。1 つのノードは `((!A&B)|(A&!B)|(!A&!B))==true` の場合に下流ノード C の実行をトリガーします。もう 1 つのノードは `(!(!A&B)&!(A&!B)&!(!A&!B))==true` の場合に下流ノード D の実行をトリガーします。このプロセスは、CONDITIONS ノードの効果を複製します。
2.3.2.2. DolphinScheduler 2.x 変換構成項目
このツールは現在、次の DolphinScheduler 2.x ノードタイプの変換をサポートしています。
SHELL、SQL、PYTHON、DATAX、SQOOP、HIVECLI、SPARK (Java、Python、Sql)、MR、PROCEDURE、HTTP、CONDITIONS、SWITCH、DEPENDENT、および SUB_PROCESS。
バージョン 2.x と比較して、DolphinScheduler 3.x は SEATUNNEL ノードタイプのみを追加します。他のノードの変換ソリューションと構成項目は、DolphinScheduler 3.x のものと同じです。詳細については、前のセクションをご参照ください。
2.3.2.3. DolphinScheduler 1.x 変換構成項目
このツールは現在、次の DolphinScheduler 1.x ノードタイプの変換をサポートしています。
SHELL、SQL、PYTHON、DATAX、SQOOP、SPARK (Java、Python、Sql)、MR、CONDITIONS、DEPENDENT、および SUB_PROCESS。
これらのノードの変換ソリューションと構成項目は、DolphinScheduler 3.x のものと同じです。詳細については、前のセクションをご参照ください。
3. スケジューリング変換ツールの実行
コマンドラインから変換ツールを実行します。コマンドは次のとおりです。
sh ./bin/run.sh convert \
-c ./conf/<your_config_file>.json \
-f ./data/1_ReaderOutput/<source_discovery_export_package>.zip \
-o ./data/2_ConverterOutput/<conversion_result_output_package>.zip \
-t <PluginName>コマンドでは、`-c` は構成ファイルのパスを指定し、`-f` は ReaderOutput パッケージのストレージパスを指定し、`-o` は ConverterOutput パッケージのストレージパスを指定し、`-t` は変換プラグイン名を指定します。DolphinScheduler 1.x、2.x、3.x の変換プラグインは、それぞれ `dolphinv1-dw-converter`、`dolphinv2-dw-converter`、`dolphinv3-dw-converter` です。
たとえば、DolphinScheduler 3.x プロジェクト 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 dolphinv3-dw-converter変換ツールは、操作中にプロセス情報を出力します。プロセス中にエラーがないか確認してください。変換が完了すると、成功した変換と失敗した変換に関する統計がコマンドラインに出力されます。一部のノード変換の失敗は、全体の変換プロセスに影響しないことに注意してください。いくつかのノードの変換に失敗した場合は、DataWorks に移行した後に手動で変更できます。
4. 変換結果の表示
生成された `ConverterOutput.zip` パッケージを `./data/2_ConverterOutput/` ディレクトリで開き、エクスポート結果をプレビューします。
統計レポートには、変換されたワークフロー、ノード、リソース、関数、データソースに関する基本情報が要約されています。
`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 ペアを作成し、ワークスペースの管理者権限があることを確認します。書き込みの問題が発生した場合のトラブルシューティングに役立つように、アカウントにバインドされた AccessKey ペアを作成することを強くお勧めします。
3. ワークスペースで、データソースを作成し、計算リソースをアタッチし、リソースグループを作成します。
4. ワークスペースで、リソースファイルをアップロードし、UDF を作成します。
1.3. ネットワーク接続チェック
DataWorks エンドポイントに接続できることを確認します。
サービスエンドポイントのリスト:
ping dataworks.aliyuncs.com2. インポート構成項目
プロジェクトディレクトリの `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 アドレスがアクセスを確立することを許可されていることを確認してください。
2.4. リソースグループ
DataWorks ワークスペース製品ページの左側のナビゲーションウィンドウで、リソースグループページに移動します。リソースグループをアタッチし、その ID を取得します。
汎用リソースグループは、ノードのスケジューリングとデータ統合に使用できます。構成で、スケジューリングリソースグループ (`resource.group.identifier`) とデータ統合リソースグループ (`di.resource.group.identifier`) の両方を同じ汎用リソースグループに設定できます。
2.5. QPS 設定
このツールは、DataWorks API を呼び出すことによってデータをインポートします。DataWorks のエディションによって、読み取りおよび書き込み OpenAPI 呼び出しの 1 秒あたりのクエリ数 (QPS) 制限と 1 日あたりの呼び出し制限が異なります。詳細については、「制限」をご参照ください。
DataWorks Basic Edition、Standard Edition、Professional Edition の場合、`"qps.limit": 5` を設定することをお勧めします。Enterprise Edition の場合、`"qps.limit": 20` を設定することをお勧めします。
注: 複数のインポートツールを同時に実行しないでください。
2.6. DataWorks ノードタイプ ID 設定
DataWorks では、一部のノードタイプにはリージョンごとに異なる TypeId が割り当てられます。特定の TypeID は DataWorks データ開発インターフェイスに依存します。この特性は主にデータベースノードに適用されます。詳細については、「データベースノード」をご参照ください。
たとえば、MySQL ノードの NodeTypeId は、杭州リージョンでは 1000039、深センリージョンでは 1000041 です。
DataWorks リージョン間のこれらの違いに適応するために、このツールは、ツールが使用するノード TypeId テーブルを設定するための構成可能なメソッドを提供します。
テーブルは、インポートツールの構成項目を使用してインポートされます。
"conf": {
"dataworks.node.type.xls": "/Software/bwm-client/conf/CodeProgramType.xls" // DataWorks ノードタイプテーブルへのパス
}DataWorks データ開発インターフェイスからノードタイプ ID を取得するには、インターフェイスで新しいワークフローを作成し、ワークフローで新しいノードを作成してから、[保存] をクリックしてワークフローの仕様を表示します。
ノードタイプが正しく構成されていない場合、ワークフローが公開されるときに次のエラーが報告されます。
3. DataWorks インポートツールの実行
コマンドラインから変換ツールを実行します。コマンドは次のとおりです。
sh ./bin/run.sh write \
-c ./conf/<your_config_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 で結果を表示できます。ワークフローが 1 つずつインポートされるのを監視することもできます。問題を見つけてインポートを停止する必要がある場合は、`jps` コマンドを実行して `BwmClientApp` を見つけ、`kill -9` コマンドを実行してインポートを停止できます。
5. Q&A
5.1. ソースは継続的に開発されています。これらの増分と変更を DataWorks に送信するにはどうすればよいですか？
移行ツールは上書きモードで実行されます。エクスポート、変換、インポートのプロセスを再実行して、ソースからの増分変更を DataWorks に送信できます。ツールは、ワークフローを作成するか更新するかを決定するために、完全なパスでワークフローを照合することに注意してください。変更を移行するには、ワークフローを移動しないでください。
5.2. ソースは継続的に開発されており、DataWorks でもワークフローを変更および管理しています。増分移行は DataWorks での変更を上書きしますか？
はい、上書きされます。移行ツールは上書きモードで実行されます。移行が完了した後に DataWorks でさらに変更を加えることをお勧めします。または、バッチで移行することもできます。移行されたワークフローのバッチが再度上書きされないことを確認した後、DataWorks での変更を開始できます。異なるバッチは互いに影響しません。
5.3. パッケージ全体のインポートに時間がかかりすぎます。一部だけをインポートできますか？
はい、できます。インポートするパッケージを手動でトリミングして、部分的なインポートを実行できます。`data/project/workflow` フォルダで、インポートする必要があるワークフローを保持し、その他を削除します。フォルダをパッケージに再圧縮してから、インポートツールを実行します。相互に依存関係のあるワークフローは一緒にインポートする必要があることに注意してください。そうしないと、ワークフロー間のノードリネージが失われます。