スケジューリング依存関係とは、子孫ノードが開始する前に正常終了しなければならない先祖ノードを定義するものです。適切に設定することで、各ノードが上流テーブルから有効なデータを確実に取得できるようになります。
仕組み
DataWorks は、有向非循環グラフ（DAG）に基づいて自動トリガーされたノードを実行します。2 つのノード間にスケジューリング依存関係を設定すると、子孫ノードはすべての先祖ノードが正常に完了するまで待機し、その後に開始します。これにより、下流ノードは常に現在または前回のスケジューリングサイクルで生成されたデータを対象に処理を行います。
ノードのスケジューリング時刻は、その最も早い開始時刻を設定します。先祖ノードがまだ完了していない場合、子孫ノードはスケジュールされた開始時刻を過ぎても待機し続けます。待機状態の診断方法については、「インテリジェント診断機能の利用」をご参照ください。
依存関係の設定方法の選択
利用可能な設定方法は 2 種類あります。使用する方法は、現在のノードの出力テーブルと先祖ノードの出力テーブルとの間に強いデータリネージが存在するかどうかによって決まります。
強いリネージとは、現在のノードが先祖ノードが書き込んだデータを読み取ることを意味します。先祖ノードがデータを生成できなかった場合、現在のノードも有効なデータを取得できません。
| 設定方法 | 使用タイミング |
|---|---|
| テーブルのデータリネージに基づく設定 | 現在のノードのテーブルと先祖ノードのテーブルの間に強いリネージが存在し、かつ先祖ノードが自動トリガーされたノードである場合 |
| カスタム依存関係の設定 | 強いリネージが存在しない場合、または上流のデータソースが自動トリガーされたノードでない場合 |
テーブルのデータリネージに基づくスケジューリング依存関係の設定
強いリネージが存在し、かつ上流テーブルが自動トリガーされたノードによって生成される場合は、テーブルのリネージに基づく依存関係を設定します。DataWorks はノードの完了ステータスを追跡し、上流データが準備できたタイミングを判断します。
DataWorks は、分単位、時単位、日単位、週単位、月単位、または年単位でスケジュールされるノード間の依存関係をサポートしています。ノードごとのインスタンス数は、そのスケジューリング頻度およびサイクル数に応じて変化するため、先祖インスタンスと子孫インスタンス間の依存マッピングも異なります。先祖ノードと子孫ノードのスケジューリング頻度またはスケジューリング時刻が異なる場合は、デプロイ前に依存関係をプレビューしてください。詳細については、「複雑な依存関係シナリオにおけるスケジューリング構成の原則とサンプル」をご参照ください。
ステップ 1：テーブルのデータリネージの確認
現在のノードの出力が先祖ノードの出力に依存しているかを確認します。「先祖ノードが本日のデータを生成できなかった場合、現在のノードは依然として有効な結果を生成できますか？」という問いに対し、「いいえ」の場合、強いリネージが存在します。
ワークスペース間の依存関係や、先祖ノードのスケジューリングパラメーター構成を確認できない場合は、「テーブルのリネージの確認」をご参照ください。
ステップ 2：依存関係タイプの選択
ノードコード内のスケジューリングパラメーターは、現在のインスタンスがどの特定の先祖インスタンスに依存するかを決定します。DataWorks は、ノードのデータタイムスタンプおよびスケジュール時刻に基づき、スケジューリング時にパラメーター値を置き換えます。以下の図は、この選択ロジックを示しています。
現在のノードが必要とするデータに応じて、依存関係タイプを選択します。
| 依存関係タイプ | 使用タイミング | 例 |
|---|---|---|
| 同一サイクル | 現在のノードが、先祖ノードが同日に | 日次レポートノード（06:00 実行）が日次集約ノード（05:00 実行）に依存する場合 — 06:00 のインスタンスは、同日の 05:00 のインスタンスに依存します |
| クロスサイクル | 現在のノードが、先祖ノードが前日に生成したデータを必要とする場合、または時単位／分単位でスケジュールされたインスタンスが前回サイクルのインスタンスに依存する場合 | 日次レポートノード（01:00 実行）が前日の終日集約に依存する場合 — 1 月 15 日のインスタンスは、1 月 14 日の先祖インスタンスに依存します |
特殊ケース — 時単位および分単位のスケジューリング：
-
時単位または分単位でスケジュールされたノードは、自身の前回サイクルのインスタンスに依存できます。たとえば、現在のサイクルで生成された時単位ノードのインスタンスは、同じノードの前回サイクルで生成されたインスタンスに依存します。詳細については、「前回サイクルで生成された現在のノードのインスタンスへの依存」をご参照ください。
-
ノード A（時単位）とノード B（時単位）が同じスケジュール時刻を持つ場合、ノード A に対してクロスサイクル依存関係を設定します。これにより、ノード A の 02:00 のインスタンスは、同じ時間帯のインスタンスを待機するのではなく、ノード B の 01:00 のインスタンスに依存します。分単位でスケジュールされたノードにも同様のロジックが適用されます。
ステップ 3：依存関係の検証
設定後に、デプロイ前後で依存関係が想定通りに動作することを検証します。
| 方法 | 検証内容 | 使用タイミング |
|---|---|---|
| スケジューリング依存関係のプレビュー | 各子孫インスタンスがどの先祖インスタンスに依存するかを表示 — デプロイ前に周波数の異なるノード間でのマッピングエラーを検出 | 異なるスケジューリング頻度のノード間（例：日次ノードが時次ノードに依存する場合）で依存関係を設定するとき、またはクロスサイクル依存関係を設定するとき |
| コード解析結果の比較 | 現在の依存関係と新しい依存関係の差分を表示 — 変更が本番環境のデータに影響を与えないことを確認 | 自動コード解析を利用するノードの依存関係を変更するとき |
| 自動トリガーされたノードページの表示（デプロイ後） | 本番環境における実際の依存関係グラフを表示 — 開発環境の構成と本番環境の状態の不一致を検出 | ノードをデプロイした後、本番環境が意図した依存関係を反映しているかを確認するとき |
本番環境での検証：
標準モードで実行中のワークスペースでは、開発環境と本番環境で異なる依存関係構成が許容されます。DataStudio でノードをデプロイした後、オペレーションセンターの自動トリガーされたノードページに移動し、先祖／子孫ビューを展開して、本番環境の依存関係を確認します。
また、先祖ノードが生成したパーティションデータが、現在のノードの期待値と一致しているかも確認してください。正しく設定された依存関係であっても、パーティションの配置（alignment）が保証されるわけではありません。
自動トリガーされたノードページには、本番環境における最新のノードステータスが表示されます。インスタンスが追加または削除されるかどうかは、インスタンス生成モードによって異なります。詳細については、「インスタンス生成モード」セクションをご参照ください。
デプロイ手順がプロセス制御承認によってブロックされている場合、オペレーションセンターのサイクルタスクページに移動し、依存関係構成およびデプロイステータスを確認してください。「ノードのデプロイメント」をご参照ください。
カスタム依存関係の設定
ノード間に強いリネージが存在しない場合、または上流のデータが自動トリガーされたノードによって生成されていない場合に、カスタム依存関係を使用します。
ルール：DataWorks は、自社の自動トリガーされたノードによって生成されたテーブルのみを追跡できます。この仕組み外で生成されたテーブル（更新頻度に関わらず）は、スケジューリング依存関係のチェック対象となりません。
DataWorks のスケジューリング対象外となるテーブルの一般的な例：
-
リアルタイム同期ノードによって生成されたテーブル
-
オンプレミスマシンからアップロードされたテーブル
-
ディメンションテーブル
-
手動でトリガーされたノードによって生成されたテーブル
-
DataWorks 内の自動トリガーされたノードではなく、外部システムによって定期的に更新されたテーブル
これらのケースでは、以下のいずれかのオプションを使用します：
ワークスペースのルートノードを先祖として指定
データ同期ノードが他のビジネスデータベースに依存する場合、または SQL ノードがリアルタイム同期ノードからのデータを処理する場合に使用します。ルートノードを先祖として設定すると、子孫ノードは上流データの準備状況を待機せず、スケジュールされた時刻に実行されます。
ゼロロードノードを先祖として指定
多数のノードや複雑な関係性を持つワークフローにおいて、ゼロロードノードを使用します。ゼロロードノードは調整ポイントとして機能し、スケジュール時刻の設定、ノードのバッチフリーズ、依存関係管理の集中化などに活用できます。これにより、ワークスペース内のデータ転送パスを容易にトレースできます。
注意事項
ノードの一意性
ノードは、開発環境と本番環境で異なる依存関係構成を持つことができますが、ノード自体は両環境を通じて一意である必要があります。ノードをアンデプロイする前に、以下の手順を実行します。
-
開発環境および本番環境の両方から、すべての子孫ノードを削除します。
-
これらの子孫ノードに対して、代替の先祖ノードを再構成します。
-
すべての変更をコミットおよびデプロイします。
これにより、アンデプロイ後に子孫ノードが引き続き有効なデータを取得できるようになります。
インスタンス生成モード
インスタンス生成モードパラメーターを、ノードおよびそのすべての先祖ノードで同一の値に設定します。
先祖ノードがデプロイ直後に設定されており、子孫ノードが翌日に設定されている場合、子孫ノードが孤立ノードになる可能性があります。
既存のノードのスケジューリング頻度を変更し、インスタンス生成モードをデプロイ直後に設定した場合、以前に生成されたインスタンスは自動的に削除されません。これにより、当日に生成されたインスタンスについて複雑な依存関係状態が生じる可能性があります。「インスタンス生成モードを「デプロイ直後」に設定した場合のスケジューリング依存関係への影響」をご参照ください。
200 上流ノード制限
ジョブの更新 API を呼び出した際に、エラー 'One file could not have more than 200 inputs' が発生した場合、そのノードの直接の上流依存関係が 200 を超えています。
この問題を解決するには、DataStudio を使用して先祖ノードと子孫ノードの間にゼロロードノードを挿入し、現在のノードに対する直接の依存関係数を減らします。