スケジューリング依存関係の設定ガイド

概要

スケジューリング依存関係は、DataWorks におけるノード間の上流と下流の関係を定義するメカニズムです。スケジューリング依存関係を設定すると、指定した上流ノードが正常に実行された後にのみノードが実行を開始するように指定でき、データ処理の正しい順序を確保できます。依存関係を設定すると、DataWorks のスケジューリングシステムが実行順序を自動的にオーケストレーションします。下流インスタンスは、すべての上流インスタンスが正常に実行され、時間やリソースの可用性などの条件が満たされた場合にのみトリガーされます。

DataWorks は、ノードの出力名 と ノードの入力名 を照合することで、ノード間の依存関係を確立します。現在のノードの観点では、依存関係の設定には次の 2 つの主要な操作があります。

上流依存関係 (ノード入力) の設定
現在のノードに入力を追加して、上流依存関係を指定します。設定パネルでは、ノードの出力名 (推奨)、ノード名、または ノード ID で上流ノードを検索することで依存関係を確立できます。現在のノードインスタンスは、指定したすべての上流ノードインスタンスが正常に実行された後にのみ実行を開始します。
ノード出力の設定
現在のノードの出力名を、下流ノードが依存関係の指定に使う一意の識別子として設定します。出力名には、ノードが生成するデータテーブルを明確に示すため、project_name.table_name 形式 (例：my_project.dim_user) を使用することを推奨します。設定後、下流ノードはこの出力名を参照することで現在のノードに依存できるようになります。

自動解析 (オプション)：SQL タイプのノードでは、DataWorks はコード内の INSERT 文と SELECT 文を自動的に解析し、入力テーブルと出力テーブルを特定して、依存関係の設定を自動生成できます。自動解析の結果は手動で調整することもできます。自動解析をサポートするノードタイプについては、「自動解析機能のサポート」をご参照ください。

重要

各ノードには少なくとも 1 つの出力名が必要です。システムは各ノードに対してデフォルトの出力を自動生成します。カスタム出力をすべて削除した場合でも、このデフォルト出力は保持されます。

ルールと制約

デプロイ後に有効：スケジューリング依存関係の設定は、ノードをオペレーションセンターに デプロイ した後にのみ有効になります。開発中に行った設定は、スケジューリング環境に自動的には同期されません。
上流と下流のスケジューリングステータス：依存関係は、上流ノードと下流ノードの両方のインスタンスが生成され、スケジューリングステータスが正常である場合にのみ有効になります。ノードの設定が不適切である場合、または上流インスタンスが異常である場合、ノードが孤立してスケジューリングできなくなることがあります。
循環依存の制限：システムは、ノード間の循環依存 (例：A が B に依存し、B が A に依存する) を、直接的および間接的なサイクルを含め禁止します。デプロイ時に循環依存が検出された場合、システムはデプロイをブロックし、エラーを返します。

依存関係の種類

DataWorks は、スケジューリング依存関係の主要なカテゴリとして、同一サイクル依存とクロスサイクル依存の 2 つを提供しており、これらは異なるビジネスシナリオに適用されます。同一サイクル依存は、デフォルトで同一サイクル内の最も近い上流インスタンスに関連付けられます。高度なスケジューリング依存関係設定を有効にすると、さらに 指定範囲 または 指定セット を選択することで、依存する上流インスタンスの範囲を正確に制御し、タイムゾーンをまたぐ依存やウィンドウをまたぐ依存などの柔軟なシナリオに対応できます。

前提となる概念

サイクルは相対的な概念であり、その意味はノードのスケジューリング時間によって定義されます。スケジューリングサイクルとは、ノードの隣接する 2 つのスケジューリングインスタンス間の時間オフセットのことで、そのスケジューリング頻度によって決まります。たとえば、日次スケジューリングタスクの場合、前のサイクルは前日のインスタンスに対応し、時間単位のスケジューリングタスクの場合は、1 時間前のインスタンスに対応します。

スケジューリング頻度	1 サイクル
日次、週次、月次、年次スケジューリング	1 日説明週次、月次、年次スケジューリングタスクの場合でも、インスタンスは日次ベースで生成されます (スケジューリング日以外のインスタンスはドライランインスタンスです)。したがって、依存関係の計算は日の粒度に基づいて行われ、前サイクルのインスタンスがドライランステータスになることがあります。
時間単位のスケジューリング	時間単位の間隔
分単位のスケジューリング	分単位の間隔 (例：5 分ごと)

依存関係の種類

DataWorks は、依存関係のマウント方法に基づいて、以下の依存関係の種類を提供します。

最近接依存 (同一サイクル依存)：下流インスタンスは、近接性の原則に基づいて、同一サイクル内の最も近い上流インスタンスにマウントされます。
指定範囲：開始オフセットと終了オフセットを使用して連続した範囲を指定し、依存する上流インスタンスの範囲を正確に制御します。これは、タイムゾーンをまたぐデータ依存などのシナリオに適用されます。
指定セット：複数の離散的な上流インスタンスを選択します。これは、下流ノードが複数の特定の上流サイクルインスタンスに依存するシナリオに適用されます。
クロスサイクル依存：指定されたノードの前サイクルのインスタンス結果を迅速に指定します。指定ノードとして、現在のノード自体 (自己依存)、下流の第 1 レベルの子ノード、またはその他の任意のノードが指定可能です。

説明

指定範囲 と 指定セット は、DataStudio のスケジューリング設定で [高度なスケジューリング依存関係設定] スイッチ (デフォルトでは無効) をオンにした場合にのみ使用できます。範囲の上限は前日と当日です。分単位のタスクの場合、最大オフセットは ±1440 分、時間単位のタスクの場合、最大オフセットは ±24 時間、日次以上の頻度のタスクの場合、最大範囲は前日の 00:00 から当日の 23:59 までです。

4 種類の依存関係の比較

例：日次スケジューリングノード A が dim_user テーブルを生成し、下流ノード B がこのテーブルを消費する場合：

最近接依存 (同一サイクル依存)
下流の日次タスクは、同日に上流の日次タスクによって生成されたデータに依存します。たとえば、今日の売上レポート (ノード B) は、今日の売上合計 (ノード A) が計算されるまで待機する必要があります。
指定範囲
下流タスクは、特定の時間ウィンドウ内のすべての上流インスタンスに依存します。たとえば、中国リージョン (ノード B) の日次タスクは、インドリージョン (ノード A) の毎時タスクのうち、 [-3, 21] の時間ウィンドウ内にある全 24 インスタンスに依存します。
指定セット
下流タスクは、特定の時点の上流インスタンスにのみ依存します。たとえば、集計タスク (ノード B) は、上流のデータ収集タスク (ノード A) が 0:00、6:00、12:00、および 18:00 に生成したインスタンスが完了するのを待つだけで済みます。
クロスサイクル依存 (前サイクルに依存)
下流タスクは、前サイクルで上流タスクによって生成された完全なデータに依存するか、自己依存によって直列実行を実現します。たとえば、T+1 レポート (ノード B) は昨日ノード A によって生成されたデータに依存するか、時間単位のタスクが 1 時間前の自身のインスタンスに依存して、複数サイクルインスタンスの同時実行を回避します。

比較項目	同一サイクル依存			クロスサイクル依存 (前サイクルに依存)
比較項目	最近接依存 (同一サイクル依存)	指定範囲	指定セット	クロスサイクル依存 (前サイクルに依存)
説明	このノードの現在のインスタンスは、同一サイクル内の上流ノードのインスタンスの実行結果に依存します。近接性の原則に基づいて、最も近い上流インスタンスがマウントされます。	開始/終了オフセットを使用して連続した範囲を指定し、依存する上流インスタンスの範囲を正確に制御します。	個別に指定することで、複数の離散的な上流インスタンスを選択します。	このノードの現在のインスタンスは、指定されたノードの前サイクルのインスタンスの実行結果に依存します。指定ノードとして、このノード自体 (自己依存)、下流の第 1 レベルの子ノード、またはその他の任意のノードが指定可能です。
DAG での表現	実線で表示されます。	実線で表示されます。	実線で表示されます。	破線で表示されます。
典型的なシナリオ	ノード B は、今日ノード A によって生成されたデータを読み取る必要があります。	タイムゾーンをまたぐデータ依存 (例：中国の日次タスクが、インドまたはサウジアラビアの時間単位タスクインスタンスの連続した範囲に依存する場合)。	一部の上流サイクルインスタンスにのみ依存します (例：0:00、6:00、12:00、18:00 の時点のみ)。	ノードが昨日生成されたデータに依存します (例：T-1データ取得)。時間単位または分単位のタスクは、自己依存によって直列実行を実現し、複数サイクルインスタンスの同時実行を回避します。
設定方法	自動解析、ワークフローでの線による指定、および手動追加をサポートします。	開始/終了オフセットを設定します。	上流タスクインスタンスから目的の離散セットを選択します。	スケジューリング設定パネルの「前サイクル」セクションで、依存関係の種類を選択し、ノード ID を指定します。
高度な設定が必要かどうか	いいえ	はい	はい	いいえ

注：同一サイクル依存とクロスサイクル依存は、同じノードペア間に共存できますが、それぞれのビジネス目的を明確に定義する必要があります。クロスサイクル依存のみが必要な場合は、システムによって自動的に生成された同一サイクル依存を削除してください。そうしないと、下流インスタンスは実行される前に現在のサイクルの上流インスタンスが完了するのを待つことになり、予期しない遅延が発生します。

スケジューリングチェーンの整合性と保守性を確保するために、すべてのノードは、オペレーションセンターにデプロイして自動スケジューリングを行う前に、アップストリーム依存関係を設定する必要があります。ノードにデータ依存関係がない場合は、仮想ノードまたはルートノードに依存させる必要があります。スケジューリング依存関係を設定する際は、ノードのビジネスロジックを分析し、依存対象と依存関係のタイプを特定し、最も適切な設定方法を選択して、堅牢で明確な構造のデータワークフローを構築する必要があります。

1. 依存対象の特定

依存関係を設定する前に、以下の準備を完了してください。

データリネージの分析：アップストリームが生成するテーブルまたはパーティションが、ダウンストリームが読み取るテーブルまたはパーティションと一致するかどうかを確認してください。
スケジューリングプロパティの確認：ノードのスケジューリング周期、有効時間、スケジューリングパラメーターなどのプロパティが正しく設定されていることを確認してください。スケジューリングプロパティは依存関係のマウント動作に直接影響します。

現在のノードがデータにどのように依存するかに基づいて、依存オブジェクトを選択します。

シナリオ 1：アップストリームノードの直接出力に依存する

適用シナリオ：ダウンストリームノードが必要とするデータが、DataWorks によって自動的にスケジュールされるアップストリームノードが生成したテーブルから直接取得される場合。
設定戦略：データリネージに基づいてノード依存関係を設定することを強く推奨します。
主要な価値：これは最も直接的で堅牢なアプローチです。スケジューリングシステムは、アップストリームデータの準備が完了した後にのみダウンストリームノードが開始されることを保証し、エンドツーエンドのデータ整合性を確保します。

シナリオ 2：スケジュールされていないアップストリームデータに依存する (データ準備完了駆動)

適用シナリオ：アップストリームデータが DataWorks スケジューリングシステムの外部で生成され、ダウンストリーム依存関係のためのスケジューリングインスタンスを生成できない場合。例：
- 外部ビジネスシステムによって OSS または FTP にプッシュされたファイル。
- リアルタイム同期によって生成されたテーブル。
- DataWorks によってスケジュールされていないサードパーティの同期ツールによって生成されたテーブル。
- 手動でアップロードされた、または手動実行によって生成された一時テーブル。
設定戦略：チェックノードなどを設定して、データの準備が完了しているかどうかを能動的に検証します (例：ファイルが存在するか、テーブルパーティションが生成されているかを確認)。次に、ダウンストリームビジネスノードがこのチェックノードに依存するように設定します。
主要な価値：このアプローチは、「データ生成」を「スケジューリングイベント」に変換し、後続のプロセスが「データ準備完了」イベントによって駆動されるようにし、スケジュールされていないパイプラインシナリオにおけるデータの正確性を確保します。

シナリオ 3：直接的なデータ依存関係はないが、ビジネスロジックの関連性が存在する

適用シナリオ：ノードがデータ処理とコードロジックの面では完全に独立しているが、ビジネスロジックの観点から特定のワークフローに属するか、または定期的にスケジュールされる必要がある場合。
設定戦略：
- 仮想ノードに依存する：関連するタスクのグループを論理ユニットに集約し、統一された開始/停止、監視、保守を行うことで、ビジネスロジックを整理された状態に保てます。
- ワークスペースのルートノードに依存する：これにより、タスクがスケジューリングシステムによって適切にインスタンス化され、スケジュール通りに実行されることを保証し、自動的にスケジュールできない孤立ノードになることを防ぎます。
主要な価値：これにより、ノードが孤立することを防ぎ、ワークフローの開始/停止とステータス監視がより明確になり、ビジネスロジック構造の整合性が確保されます。

2. 依存関係タイプの選択

現在のノードがアップストリームノードの直接出力に依存している場合 (シナリオ 1) 、依存するデータが同じスケジューリング周期のアップストリームノードの出力であるか、クロスサイクルの出力であるかをさらに確認する必要があります。

主要な判断基準

ダウンストリームノードが実際にアップストリームノードのどの周期の出力データを読み取るかを判断します。ほとんどのシナリオでは、ノードはスケジューリングパラメーターを使用して動的に解決し、テーブルの特定のパーティションにデータを定期的に書き込みます。スケジューリングパラメーターがどのように置き換えられるかを理解するには、「スケジューリングパラメーターのソースと式」をご参照ください。同じワークスペース内のノードに依存する必要がある場合は、そのノードのスケジューリングパラメーター設定を確認できます。

確認方法

同じワークスペース内のノード：アップストリームノードコード内のスケジューリングパラメーターを確認します。パラメーター置換後に書き込まれるパーティションが「今日」のパーティションか「昨日」のパーティションかを判断します。
- 開発環境では、アップストリームノードのスケジューリングパラメーター設定とコードの詳細を確認します。本番環境では、インスタンスの詳細でパラメーター置換結果を確認します。
異なるワークスペース内のノード：データマップを使用して、アップストリームテーブルのパーティション情報と変更履歴を表示します。
- 毎日実際に書き込まれるパーティション値を確認します。

タイプの選択

ダウンストリームコードがアップストリームノードから当日または現在のサイクルのパーティションを読み取る場合：同一サイクル依存関係。
ダウンストリームコードがアップストリームノードから前日または前のサイクルのパーティションを読み取る場合：クロスサイクル依存関係。
インスタンスのスケジュール順序で厳密に実行する必要がある時間単位または分単位のタスク：クロスサイクル依存関係、つまり現在のノード自体に依存します。
ダウンストリームノードが業務日付によってタイムゾーン間でアップストリームデータを集約する場合 (例：中国の日次タスクがインドやサウジアラビアなどの地域からの現地の時間単位タスクを集約する) ：高度な設定を有効にし、指定範囲を使用して対応する現地の業務日のインスタンスを対象とします。
ダウンストリーム依存関係のタイムウィンドウが自然日の境界をまたぐ場合 (例：早朝のバッチタスクが前日の午後から当日の早朝までのデータのみを処理する) ：高度な設定を有効にし、指定範囲を使用して日をまたぐ連続ウィンドウを定義します。
ダウンストリームノードがアップストリームノードの最新の数サイクルのインスタンスのみに依存すればよく、デフォルトで当日のすべてのアップストリームインスタンスを待つ必要がない場合：高度な設定を有効にし、指定範囲を使用して依存範囲を制限します。
ダウンストリームノードがアップストリームノードのいくつかの離散した時点 (例：0:00、6:00、12:00、18:00) のみに依存する場合：高度な設定を有効にし、指定セットを使用して対応するインスタンスを選択します。

重要

データリネージを正しく確認しなかった場合の結果：

依存関係の欠落リスク：テーブルリネージが存在するがスケジューリング依存関係が設定されていない場合、アップストリームインスタンスが成功する前にダウンストリームタスクが開始され、データが読み取られない、またはデータが不完全になります。
パラメーターの不一致リスク：依存関係が設定されているがパーティションパラメーターが一致していない場合 (例：アップストリームノードが今日のパーティションを生成するが、ダウンストリームノードが昨日のパーティションを読み取る) 、データロジックエラーとデータ品質の異常が発生します。

3. 依存関係の設定

ステップ 1 と 2 で確認した依存オブジェクトと依存関係タイプに基づいて、適切な設定方法を選択して依存関係を設定します。

DataWorks では、異なるスケジューリング頻度のタスクを相互に依存させることができます。同一サイクル/クロスサイクル依存関係とスケジューリングパラメーターを組み合わせることで、幅広いスケジューリングシナリオを実装できます。詳細については、以下をご参照ください。

複雑な依存関係のスケジューリング原則

依存関係のアップストリームインスタンスの範囲を正確に制御するには (連続したオフセット範囲の指定や離散したインスタンスの選択など) 、DataStudio の [スケジューリング設定] で [高度なスケジューリング依存関係設定を有効にする] トグルを有効にし、[指定範囲] または [指定セット] を使用して依存関係を設定します。

4. スケジューリング依存関係の検証

設定が完了し、ノードをデプロイする前に、以下の検証を実行する必要があります。

検証方法

説明

コミット時：コード解析結果の比較

ノードをコミットする際に、この方法を使用して、現在のノードバージョンの依存関係の変更が期待どおりであるかどうかを検証し、変更が本番環境に与える影響を評価します。

自動解析が有効になっている場合、本番環境での正常なデータ生成を確保するために、コミット時にノードのスケジューリング変更を確認する必要があります。この機能を使用して、依存関係の変更が本番タスクによるデータ生成に影響を与えないことを確認できます。

デプロイ後：自動トリガーノードの表示

ノードがデプロイされた後、この方法を使用して、オペレーションセンターの本番スケジューリングタスクの依存関係が期待どおりであるかどうかを検証します。

本番タスクのスケジューリング依存関係を検証する

標準モードワークスペースでは、開発環境と本番環境のノード依存関係は異なる場合があります。本番環境ノードのスケジューリング依存関係は DataStudio で設定する必要があり、ノードをデプロイした後にのみ有効になります。

ノードがデプロイされた後、オペレーションセンターの [自動トリガーノード] ページに移動し、現在のタスクのアップストリームノードとダウンストリームノードを展開して、スケジューリング依存関係を表示できます。

重要
[自動トリガーノード] ページには、本番環境のノードの最新ステータスが表示されます。ただし、新しい依存関係が自動トリガーノードインスタンスに追加されるか、既存の依存関係が削除されるかは、インスタンスの生成方法によって異なります。
本番タスクのデータステータスを検証する

スケジューリング依存関係が正しいことを確認した後、アップストリームノードとダウンストリームノードのパーティションデータの読み取りおよび書き込み操作 (つまり、スケジューリングパラメーターが正しく設定されているかどうか) も確認する必要があります。これにより、アップストリームノードが、現在のノードが依存するデータとは異なるパーティションのデータを生成することによって引き起こされる、ダウンストリームノードのデータ品質問題を防ぎます。

説明
タスクのデプロイプロセスでワークフロー制御が設定されている場合は、タスクがデプロイされた後、本番オペレーションセンターの [自動トリガーノード] ページに移動して、タスクのスケジューリング依存関係と関連プロパティを表示することを推奨します。タスクが期待どおりに動作しない場合は、タスクのデプロイプロセスがブロックされているかどうかを確認してください。詳細については、「ノードのデプロイ」をご参照ください。

依存関係の削除がダウンストリームタスクに与える影響

タスクの運用保守やイテレーションの際に、既存のスケジューリングの依存関係を削除または調整する必要がある場合があります。

依存関係を削除する前に、ダウンストリームタスクが孤立したり、データインシデントが発生したりするのを防ぐため、ダウンストリームタスクのスケジューリング動作への影響を評価する必要があります。孤立ノードの詳細については、「孤立ノード」をご参照ください。

ダウンストリームの依存関係シナリオ	依存関係の削除後の影響	リスクレベル
ダウンストリームタスクは、現在のノードにのみ依存します。	ダウンストリームタスクは孤立ノードになり、アップストリームのトリガーメカニズムを失い、自動的にスケジューリングされなくなります。	高
ダウンストリームタスクは、複数の親ノードに依存します。	ダウンストリームタスクは、アップストリームデータの準備が完了する前に開始される可能性があり、データ欠損や計算エラーにつながります。	中
ダウンストリームタスクは、クロスサイクルインスタンスに依存します。	クロスサイクル依存が削除された場合、ダウンストリームタスクが不正な業務日付のデータを読み取り、データロジックエラーを引き起こす可能性があります。	中

ユースケース

オフラインデータウェアハウスの階層化構築： ODS → DWD → DWS → ADS にわたるリンク全体の依存関係を設定し、階層化されたデータが順序通りに生成されることを確保します。
標準的な ETL パイプライン：同一サイクルの依存関係を設定することで、アップストリームインスタンスが成功した後にのみダウンストリームタスクが厳密に実行されるようにし、データ処理パイプラインの順序と一貫性を確保します。
翌日 (T+1) レポート：クロスサイクル依存関係 (オフセット -1) を設定することで、今日のタスクが前日の完全なビジネスデータに依存するようになり、正確な翌日のデータ分析と出力が可能になります。
複数サイクル混合集約：クロスサイクル依存関係を設定し、日次タスクが時間単位のタスクのすべてのサイクルインスタンスに依存するようにすることで、集約前に基礎となるデータが完全に準備できていることを確保します。
外部データの準備完了トリガー：カスタム依存関係またはチェックノードを設定して、ワークフローをトリガーする前に外部ファイルが到着したか、インターフェイスが準備できているかどうかを確認することで、システム間のスケジューリング調整が可能になります。
複雑なワークフロー制御：仮想ノードを使用して、複数ブランチの依存関係をワークフロー制御のマイルストーンとして集約し、依存関係チェーンの構造を簡素化し、モニタリングの可視性を向上させます。
タイムゾーンをまたぐ複数リージョンでのデータ集約：中国のデータウェアハウスが世界中のリージョンからのデータを処理します。各リージョンの現地の業務日に対応するアップストリームの時間単位インスタンスをマウントする間隔を指定することで、タイムゾーンをまたぐオフセットに対応できます (例：インド [-3, 21]、サウジアラビア [-5, 19])。
日をまたぐウィンドウ集約：ダウンストリームタスクは、暦日ではないタイムウィンドウ内のデータを集約します。間隔を指定することで、前日と当日の間の連続したウィンドウを柔軟に選択できます (例：[-12, 4] は前日の 12:00 から当日の 04:00 までを対象とします)。
最新のアップストリームウィンドウのみに依存：ダウンストリームタスクは、アップストリームタスクの最新のインスタンスのみを必要とします (例：過去 6 時間)。間隔を指定することで、マウント範囲を制限し、デフォルトで当日のすべてのアップストリームインスタンスを待たずに済みます。
離散的なアップストリームの時点に依存：ダウンストリームタスクは、特定の時間 (例：00:00、06:00、12:00、18:00) のアップストリームタスクの出力のみを必要とします。セットを指定して、対応するインスタンスを選択できます。

よくある質問

次のセクションでは、代表的なシナリオについて説明します。スケジューリング依存関係に関するその他のよくある質問については、「FAQ about dependencies」をご参照ください。

ノードの一意性
- ノードは開発環境と本番環境で形態が異なる場合がありますが、一意性は維持されます。同一ノードのスケジューリング依存関係設定は、開発環境と本番環境で異なる場合があります。つまり、同一ノードは開発環境と本番環境で 2 つの異なる形態を持つことがありますが、ノード自体は一意です。
- ノードをオフラインにする前に、開発環境と本番環境の両方でダウンストリーム依存関係を削除する必要があります。ノードの一意性により、ダウンストリームタスクがデータを正しく取得して実行できるようにするため、DataWorks では、まずダウンストリームノードのスケジューリング設定で依存関係を削除し、次にダウンストリームノードの依存先となるアップストリームノードを再設定し、変更をコミットしてデプロイする必要があります。開発環境と本番環境の両方で依存関係を削除した後にのみ、アップストリームタスクをオフラインにできます。
インスタンス生成方式
- ノードを作成する際は、アップストリームノードとダウンストリームノードで同じインスタンス生成方式を使用していることを確認してください。両者のインスタンス生成方式：デプロイメント直後の設定が異なる場合、アップストリームノードは当日にインスタンスを生成する一方で、ダウンストリームノードは翌日にインスタンスを生成することがあり、ダウンストリームインスタンスがシナリオ：孤立したノードになる可能性があります。
- 既存ノードのスケジューリングサイクルを変更し、デプロイ直後にインスタンスを生成するオプションを選択した場合、スケジューリング依存関係を変更しても、以前に生成されたインスタンスは自動的に削除されません。デプロイ当日に生成されたサイクルインスタンスの依存関係が不整合になる可能性があります。詳細については、「インスタンス生成方式：デプロイメント直後」をご参照ください。
OpenAPI を使用してタスクを更新する際、アップストリーム依存関係の数が 200 を超えるエラー
- エラーの詳細：'One file could not have more than 200 inputs 'One file could not have more than 200 inputs'.
- DataStudio でアップストリームノードとダウンストリームノードの間に仮想ノードを追加することで、現在のノードの直接的なアップストリーム依存関係の数を減らすことができます。仮想ノードの設定の詳細については、「ゼロロードノード」をご参照ください。