DataWorks において、「スケジューリング依存関係」とは、定期的にスケジューリングされるノード間のアップストリームとダウンストリームの関係を定義するものです。依存関係を設定すると、システムは、すべてのアップストリームの ノード インスタンス が成功した後にのみ、ダウンストリームの ノード インスタンス がトリガーされるようにします。これにより、データが正しい順序で生成および消費されることを保証します。本ドキュメントでは、スケジューリング依存関係の基本概念、種類、設定方法を紹介し、基本を理解して関連する手順を見つけられるようにサポートします。
仕組み
「スケジューリング依存関係」は、DataWorks においてノード間のアップストリームとダウンストリームの関係を定義するメカニズムです。依存関係を設定することで、ノード がそのアップストリームノードの成功後にのみ開始するように指定でき、データ処理の正しい順序を保証します。依存関係が設定されると、DataWorks のスケジューリングシステムが自動的に実行順序を調整します。ダウンストリームの インスタンス は、すべてのアップストリームの インスタンス が成功し、時間やリソースの可用性といった他のすべての条件が満たされた場合にのみトリガーされます。
DataWorks は、アップストリームノードの出力名とダウンストリームノードの入力名を照合することで依存関係を確立します。依存関係を設定するための主要なワークフローは以下のとおりです。
アップストリームノードの出力設定：アップストリームの
ノードに出力名を追加します。通常はproject_name.table_nameの形式 (例：my_project.dim_user) で、そのノードが生成するデータテーブルを表します。ダウンストリームノードの入力設定：ダウンストリームの
ノードで、アップストリームノードの出力名を検索して選択し、その入力 (依存関係) として設定します。これにより、依存関係が確立されます。自動解析 (オプション)：SQL ベースのノードの場合、DataWorks はコード内の
INSERT文とSELECT文を自動的に解析し、入力テーブルと出力テーブルを特定して依存関係設定を生成できます。自動解析された設定を手動で調整することも可能です。自動解析をサポートするノードタイプの一覧については、「ノードタイプ別の自動解析シナリオ」をご参照ください。
各 ノード には、少なくとも1つの出力名が必要です。システムは、各 ノード に対して project_name.nodeID_out という形式でデフォルトの出力を自動的に生成します。このデフォルト出力は、すべてのカスタム出力を削除しても保持されます。
ルールと制限
デプロイ時に有効化：
スケジューリング依存関係は、ノードを [コミット] してオペレーションセンターに [デプロイ] した後にのみ有効になります。開発環境で行われた設定は、自動的に本番環境に同期されません。アップストリームとダウンストリームのスケジューリングステータス：依存関係が機能するためには、アップストリームとダウンストリームの両方の
ノードインスタンスが生成され、正常なスケジューリング状態にある必要があります。ノードの設定が誤っているか、アップストリームのインスタンスが失敗した場合、ダウンストリームのノードは孤立し、スケジュール通りに実行できなくなる可能性があります。循環依存の制限：システムは、直接的 (AがBに依存し、BがAに依存する) および間接的な循環依存を禁止しています。
コミット時に循環依存が検出された場合、システムは [デプロイ] をブロックし、エラーを報告します。
依存関係の種類
DataWorks は、同周期依存と クロスサイクル依存 の2種類のスケジューリング依存関係をサポートしています。それぞれの種類は、異なるビジネスシナリオに適しています。
前提となる概念
周期とは、ノードの スケジューリング時間によって定義される相対的な概念です。「スケジューリング周期」とは、ある ノード の連続する2つのスケジュール済みインスタンス間の時間オフセットであり、そのスケジューリング頻度によって決まります。例えば、日次でスケジュールされたタスクの場合、前の周期とは前日の インスタンス を指します。時間単位でスケジュールされたタスクの場合、前の時間の インスタンス を指します。
スケジューリング頻度 | 1周期 |
日次、週次、月次、年次 | 1日 説明 週次、月次、年次のタスクであっても、インスタンスは日次ベースで生成されますが、スケジュールされていない日はドライランインスタンスとなります。したがって、依存関係の計算は日次粒度で行われ、前周期の |
時間単位 | 1時間の間隔 |
分単位 | 分単位の間隔 (例：5分ごと) |
2種類の依存関係
例えば、日次でスケジュールされた ノード A がテーブル dim_user を生成し、ダウンストリームの ノード B がこのテーブルを消費する場合を考えます：
同周期依存：ノード B の本日の
インスタンスは、ノード A の本日のインスタンスが成功するのを待ちます。これは、ノード B が同日にノード A によって生成されたデータを消費することを意味します。クロスサイクル依存：ノード B の本日の
インスタンスは、ノード A の昨日のインスタンスが成功するのを待ちます。これは、ノード B が前日にノード A によって生成されたデータを消費することを意味します。
項目 | 同周期依存 | クロスサイクル依存 (前周期への依存) |
定義 |
|
|
DAG表現 | 実線で表現されます。 | 破線で表現されます。 |
典型的なユースケース | ノード B は、本日ノード A によって生成されたデータを読み取る必要があります。 |
|
設定方法 | 自動解析、ワークフローエディターでのドラッグアンドドロップ接続、および手動設定をサポートします。 | [スケジューリング設定] パネルの [前周期] セクションで、依存関係の形式を選択し、 |
注：同じノードペア間に同周期依存とクロスサイクル依存が共存できますが、それぞれのビジネスロジックを理解する必要があります。クロスサイクル依存のみが必要な場合は、自動的に生成された可能性のある同周期依存を削除することを忘れないでください。そうしないと、ダウンストリームのインスタンスは依然としてアップストリームの現周期のインスタンスの完了を待ち、予期せぬ遅延を引き起こす可能性があります。
設定
スケジューリングパイプラインの完全性と保守性を確保するため、すべてのノードは オペレーションセンター にデプロイして自動スケジューリングを行う前に、アップストリームの依存関係を設定する必要があります。ノード にデータ依存関係がない場合、ゼロロードノード または ルートノード に依存する必要があります。スケジューリング依存関係 を設定するには、ノードのビジネスロジックを分析し、依存オブジェクトとタイプを特定し、堅牢なデータワークフローを構築するための最適な方法を選択します。
1. 依存オブジェクトの特定
依存関係を設定する前に、以下の準備を完了してください：
データリネージの分析：アップストリームのノードが生成するテーブルまたはパーティションが、ダウンストリームのノードが読み取るテーブルまたはパーティションと一致することを確認します。スケジューリングプロパティの確認：ノードのスケジューリング周期、有効日、
スケジューリングパラメーターが正しく設定されていることを確認します。これらのプロパティは依存関係の振る舞いに直接影響します。
ノードのデータ依存要件に基づいて依存オブジェクトを選択します。
シナリオ1：直接出力への依存 |
|
シナリオ2：非スケジュールデータへの依存 |
|
シナリオ3：ビジネスロジック依存 |
|
2. 依存関係の種類の選択
ノードがアップストリームノードの直接出力に依存している場合 (シナリオ1)、同じ周期からの出力に依存するのか、異なる周期からの出力に依存するのかを判断する必要があります。
重要な判断
ダウンストリームの ノード が実際にどの周期のデータを読み取っているかを確認します。ほとんどの場合、ノード は スケジューリングパラメーター を使用して、テーブルの特定のパーティションに動的にデータを書き込みます。スケジューリングパラメーター の置換がどのように機能するかを理解するには、「サポートされているスケジューリングパラメーターの形式」をご参照ください。同じ ワークスペース 内の ノード に依存する必要がある場合は、その スケジューリングパラメーター の設定を確認できます。
確認方法
同じ
ワークスペース内のノードの場合：アップストリームノードのコード内のスケジューリングパラメーターを確認し、書き込まれたパーティションがパラメーター置換後に「本日」または「昨日」に対応するかどうかを確認します。開発環境では、アップストリームノードのスケジューリングパラメーター設定とコードを確認します。本番環境では、インスタンスの詳細でパラメーター置換結果を確認します。
異なる
ワークスペース内のノードの場合：データマップを使用して、アップストリームテーブルのパーティション情報と変更履歴を表示します。毎日書き込まれる実際のパーティション値を確認します。
種類の選択
ダウンストリームコードが当日/現周期のアップストリームパーティションを取得する場合：同周期。
ダウンストリームコードが前日/前周期のアップストリームパーティションを取得する場合：クロスサイクル。
時間/分単位のタスクが並行処理なしで直列に実行される必要がある場合：クロスサイクル (
ノード自体への自己依存)。
データリネージ 検証が不正確な場合の結果：
依存関係欠落のリスク：
データリネージ関係が存在するにもかかわらず、スケジューリング依存関係が設定されていない場合、ダウンストリームタスクはアップストリームのインスタンスが成功する前に開始される可能性があり、データの欠落や不完全さにつながります。パラメーター不一致のリスク：依存関係が設定されているが、パーティションパラメーターが不一致の場合 (例えば、アップストリームの
ノードが本日のパーティションを生成するが、ダウンストリームのノードが昨日のパーティションを読み取る場合)、これはデータロジックエラーや品質問題につながる可能性があります。
3. 依存関係の設定
ステップ1と2で特定した依存オブジェクトと種類に基づいて、依存関係を設定するための適切な方法を選択します。
DataWorks では、スケジューリング頻度が異なるタスク間に依存関係を作成できます。同周期またはクロスサイクルの依存関係を スケジューリングパラメーター と組み合わせることで、さまざまな高度なスケジューリングパターンを実装できます。詳細については、以下をご参照ください：
4. 依存関係の検証
設定後、[デプロイ] する前に、依存関係を検証する必要があります：
検証方法 | 説明 |
設定されたスケジューリング依存関係をプレビューして、期待通りであることを確認します。
| |
自動解析が有効な場合、[コミット] 中にノードのスケジューリング設定への変更も確認する必要があります。これにより、依存関係の変更が本番タスクに悪影響を及ぼさないことを保証できます。 | |
|
依存関係削除の影響
タスクの運用やイテレーション中に、既存のスケジューリング依存関係を削除または調整する必要がある場合があります。
依存関係を削除する前に、孤立ノードの作成やデータインシデントの発生を避けるため、ダウンストリームタスクのスケジューリング動作への影響を評価する必要があります。
ダウンストリームの依存関係シナリオ | 削除の影響 | リスクレベル |
ダウンストリームタスクが現在の | ダウンストリームタスクは | 高 |
ダウンストリームタスクが複数の親ノードに依存している | ダウンストリームタスクは、必要なすべてのアップストリームデータが準備される前に開始される可能性があり、データの欠落や計算エラーにつながります。 | 中 |
ダウンストリームタスクがクロスサイクルの |
| 中 |
ユースケース
階層化されたオフラインデータウェアハウス：
ODS → DWD → DWS → ADS パイプライン全体にわたって依存関係を設定し、各層でデータが正しい順序で生成されることを保証します。標準的なETLパイプライン：
同周期依存を設定して、ダウンストリームタスクがそのアップストリームインスタンスの成功を待つようにし、シーケンシャルで一貫性のあるデータ処理を保証します。翌日 (T+1) レポート：
クロスサイクル依存(オフセット -1) を設定して、本日のタスクが昨日の完全な業務データに依存するようにし、正確な翌日分析と出力を可能にします。複数周期のハイブリッド集計：
クロスサイクル依存を設定して、日次タスクが時間単位タスクのすべてのインスタンスに依存するようにし、集計前に基盤となるデータが完全に準備されていることを保証します。外部データ準備完了トリガー：カスタム依存関係またはチェッカー
ノードを設定して、外部ファイルが到着したか、API が準備できたかを確認してからワークフローをトリガーし、クロスシステムのスケジューリングを可能にします。複雑なワークフロー制御：
ゼロロードノードを使用して複数の依存関係ブランチを集約し、制御マイルストーンとして機能させることで、パイプライン構造を簡素化し、監視の可視性を向上させます。
よくある質問
以下のセクションでは、一般的なシナリオについて説明します。スケジューリング依存関係に関するその他のよくある質問については、「依存関係に関するFAQ」をご参照ください。
ノードの一意性
ノードは異なる設定を持つことができますが、論理的には一意です：単一のノードは、開発環境と本番環境で異なるスケジューリング依存関係の設定を持つことができます。その形式は異なる場合がありますが、依然として単一の一意なノードです。ノードを廃止する前に、両方の環境でダウンストリームの依存関係を削除する必要があります：
ノードは一意であるため、ダウンストリームタスクが正しく実行されるようにするには、まずダウンストリームノードの設定から依存関係を削除し、新しいアップストリームノードに依存するように再設定してから、変更を [コミット] して [デプロイ] する必要があります。元のアップストリームタスクを廃止するのは、開発環境と本番環境の両方でその依存関係が削除されたことを確認した後です。
インスタンス生成モード
ノードを作成する際は、そのインスタンス生成モードがアップストリームおよびダウンストリームのノードと同じであることを確認してください。インスタンス生成モードが異なる場合、例えばアップストリームのノードが当日にインスタンスを生成するが、ダウンストリームのノードが翌日に生成する場合、ダウンストリームのインスタンスは孤立ノードになる可能性があります。既存の
ノードのスケジューリング周期を変更し、[デプロイ] 直後にインスタンスを生成することを選択した場合、以前に生成されたインスタンスは自動的に削除されません。これにより、[デプロイ] 当日のインスタンスの依存関係がずれる可能性があります。詳細については、「リアルタイムインスタンス変換が同日インスタンスの依存関係に与える影響」をご参照ください。
API を使用してジョブを更新する際に、200 を超えるアップストリーム依存関係があるというエラーが報告される。
エラー詳細： 'One file could not have more than 200 inputs'。
DataStudio でアップストリームとダウンストリームのノードの間に
ゼロロードノードを追加して、直接のアップストリーム依存関係の数を減らすことができます。ゼロロードノードの設定方法の詳細については、「ゼロロードノード」をご参照ください。