DataWorks のデプロイセンターは、データ開発におけるタスク公開機能を強化したものです。複数の環境にまたがって、ノード、関数、リソース、ウィジェットなどのオブジェクトを公開するために使用されます。この機能を使用すると、ワンクリックでソースワークスペースからターゲットワークスペースにオブジェクトを同期できます。このトピックでは、デプロイセンターの一般的なシナリオ、ロジック、および公開プロセスについて説明します。
機能紹介
デプロイセンターでは、公開操作はノード、関数、リソース、ウィジェットなどのオブジェクトを最小実行単位として扱います。関連するビジネスフローとノード依存関係は、同時にターゲットワークスペースにデプロイされます。詳細については、「公開ロジック」をご参照ください。
DataWorks のデプロイセンターは、さまざまな公開環境に基づいて、同一ワークスペース内公開、ワークスペース間公開、およびクラウド間公開をサポートしています。
この機能は、新しい DataStudio を使用する標準モードのワークスペースでのみ利用可能です。これにより、同一ワークスペース内で、ノード、関数、リソース、ウィジェットなどのオブジェクトを開発環境から本番環境へ一括で公開できます。
ワークスペース間デプロイメントは、主に、同一の Alibaba Cloud アカウントおよびリージョン内のある基本モードのワークスペースから別のワークスペースへ、ノード、関数、リソース、コンポーネントなどのオブジェクトをデプロイするために使用されます。この機能により、基本モードのワークスペースで開発環境と本番環境の分離を実装することもできます。詳細については、「基本モードでの環境分離の実現」をご参照ください。
この機能は、アカウント、リージョン、またはクラウドプラットフォームをまたいで、ノード、関数、リソース、コンポーネントなどのオブジェクトのデプロイメントをサポートします。この機能は、以前の DataStudio を使用するワークスペースでのみ利用可能です。本質的に、この機能は、ソースワークスペースから、異なるリージョン、アカウント、またはクラウドプラットフォームに存在するターゲットワークスペースへノードを移行し、デプロイします。
公開の変更ロジック
ノードに依存関係がある場合、子孫ノードを公開する前に、その先祖ノードをターゲットワークスペースに公開する必要があります。公開されたノードは、次のように変更されます。
ノードを公開すると、システムは関連するすべてのノードの入出力において、ソースワークスペース名のプレフィックスをターゲットワークスペース名に置き換えます。ノードにワークスペース間の依存関係がある場合は、公開環境の [依存関係マッピング] パラメーターを設定することもできます。ノードの先祖の依存関係、子孫の依存関係、および入出力名は、設定に基づいて公開後に変更されます。詳細については、以下をご参照ください。
MaxCompute エンジンを使用するタスクを公開すると、システムはタスクコードを変更します。ソースワークスペース名への言及をターゲットワークスペース名に置き換えます。詳細については、「MaxCompute エンジンを使用するタスクのコード変更」をご参照ください。
依存関係マッピングの設定については、「公開環境の設定」をご参照ください。スケジューリング依存関係の設定については、「スケジューリング依存関係の設定」をご参照ください。
このトピックでは、
ワークスペース名.ノード名形式の出力名を例として使用します。実際の出力名は異なる場合があります。
ワークスペース間の依存関係がない場合
project1 内のノードには、ワークスペース間の依存関係はありません。project1 のすべてのノードが project2 に公開されます。
公開後、すべてのノードの入出力名にある project1 プレフィックスは project2 に変更されます。例：
task_A の入力名は
project1_rootからproject2_rootに変更されます。task_A の出力名は
project1.task_Aからproject2.task_Aに変更されます。
ワークスペース間の依存関係は存在するが、ワークスペース間の依存関係マッピングが設定されていない場合
project1.task_A は project2.task_A との間にワークスペース間の依存関係があります。project1 のすべてのノードが project3 に公開されます。
公開後、ノードは次のように変更されます。
ノードの入出力：すべてのノードの入出力名にある
project1プレフィックスはproject3に変更されます。ノードのワークスペース間の依存関係：
project1.task_Aは元々project2.task_Aとの間にワークスペース間の依存関係がありました。公開後も、project3.task_Aはproject2.task_Aとの間にワークスペース間の依存関係を持ち続けます。
ワークスペース間の依存関係が存在し、ワークスペース間の依存関係マッピングが設定されている場合
project1.task_A は project2.task_A との間にワークスペース間の依存関係があります。project1 のすべてのノードが project4 に公開され、project2 から project3 への依存関係マッピングが設定されます。
公開後、ノードは次のように変更されます。
ノードの入出力：すべてのノードの入出力名にある
project1プレフィックスはproject4に変更されます。ノードのワークスペース間の依存関係：
project1.task_Aは元々project2.task_Aとの間にワークスペース間の依存関係がありました。公開後、project4.task_Aのワークスペース間の依存関係はproject3.task_Aに変更されます。
ソースワークスペースのノードがワークスペース間の依存関係にシステム出力名を使用している場合、公開操作が失敗することがあります。これは、ノードの設定の リストに、別のワークスペースのシステム出力名が含まれている場合に発生します。この問題を解決するには、依存関係を非システム出力名を使用するように変更します。
参照しないでください：システムが生成した出力名
[Data Studio (新バージョン) を使用] オプションが有効になっていないワークスペースでは、システム出力名は
ワークスペース名.ファイル ID_outの形式になります (例：shanghai_simple02.504822000_out)。次の形式の出力名を参照してください：
ワークスペース名.出力テーブル名(推奨)ワークスペース名.ノード名
MaxCompute エンジンを使用するタスクのコード変更
ODPS SQL や ODPS Spark タスクなど、MaxCompute エンジンを使用するタスクをターゲットワークスペースに公開すると、実行時にシステムがタスクコード内のソースワークスペース名をターゲットワークスペース名に置き換えます。
たとえば、task_A は ODPS SQL または MaxCompute SQL ノードです。project1 では、table_A をクエリするコードは SELECT * FROM project1.tableA です。その後、project1 のすべてのノードが project2 に公開されます。
ノードが project2 に公開されると、table_A をクエリするコードは SELECT * FROM project2.tableA に変更されます。