DataWorks:同一サイクル依存の設定

ノード出力

ノード出力は、現在のノードの出力名 です。これは、他のノードがこのノードとの依存関係を確立するための識別子として機能し、ノードによって生成される実際のデータではありません。他のノードは、この出力名を通じてこのノードを特定し、このノードを上流依存関係として設定します。

DataWorks は、各ノードに対して自動的に 2 つの出力名を生成します。

• ランダム ID：グローバルに一意であり、変更または削除できません。

• [プロジェクト名].[ノード名] または [ide].[ノード名]：ノード名を含む出力で、変更可能です。この出力名は、ノード名が変更されても自動的に更新されません。

さらに、DataWorks は、手動での出力追加や 「コードから入出力を解析」 の使用をサポートしています。各ノードタイプにおける自動コード解析のサポート状況については、「自動コード解析がサポートされているノードタイプ」をご参照ください。

ノード入力

ノード入力とは、現在のノードが依存する上流ノードを指し、上流ノードの 出力名 (推奨)、ノード名、または ノード ID で指定できます。

ノード ID は、上流ノードが本番環境にデプロイされた後にのみ生成されます。

1. コードからテーブルリネージを解析してノード依存関係を設定する

コード解析は、ノードのコード内のテーブルリネージを分析し、ノードの出力名と上流依存関係を自動的に設定します。解析後、ノードが書き込むテーブルは、projectname.tablename 形式でノード出力として自動的に追加され、ノードがクエリするテーブルはノード入力として自動的に追加されます。

たとえば、テーブルを SELECT すると、現在のノードの上流依存関係として自動的に解析されます。テーブルに INSERT すると、現在のノードの出力として自動的に解析されます。各ノードタイプの自動解析でサポートされているキーワードについては、「各ノードタイプの自動コード解析でサポートされているキーワード」をご参照ください。

• 依存関係を設定する

  コード解析には、手動で [コードから入力と出力を解析] をクリックする方法と、コミット前の自動解析 の 2 つの方法があります。どちらの方法も同じ原理で動作します。[コミット前の自動解析] では、コードを提出すると入力と出力が自動的に解析され、依存関係を設定するよう促されます。

  たとえば、ワークスペース yunwan_lingyi には、MaxCompute ノード mc1 の出力テーブル dws_user_info_all_di に依存する MaxCompute ノード mc2 があります。ノード mc2 のコードは次のとおりです。

  INSERT OVERWRITE TABLE ads_user_info_1d PARTITION (dt='${workflow.var}')
  SELECT uid
    , MAX(region)
    , MAX(device)
    , COUNT(0) AS pv
    , MAX(gender)
    , MAX(age_range)
    , MAX(zodiac)
  FROM dws_user_info_all_di
  WHERE dt = '${workflow.var}'
  GROUP BY uid;

  [コードから入力と出力を解析] をクリックすると、システムは現在のノードの入力を dws_user_info_all_di テーブルとして解析し、上流ノードの出力テーブル名と上流ノード名を自動的に照合します：

  上流ノード出力名	上流ノード出力テーブル名	上流ノード名	ノード ID	ワークスペース	所有者	スケジューリングサイクル	方法	最近の実行ステータス	アクション
  yunwan_lingyi.dws_user_info_all_di	yunwan_lingyi.dws_user_info_all_di	mc1	-	テストワークスペース	lingyi01_testcloud_com	日	コード解析	データなし	削除

  システムはまた、このノードの出力を ads_user_info_1d テーブルとして解析します。 解析結果は以下のとおりです。

  出力名	出力テーブル名	下流ノード名	所有者	方法	下流ノードの影響を受けるベースライン	アクション
  ide.505487297_out	-	-	-	システムによるデフォルト追加	-	削除
  ide.mc2	-	-	-	手動で追加	-	削除
  yunwan_lingyi.ads_user_info_1d	yunwan_lingyi.ads_user_info_1d	-	-	コード解析	-	削除

  この時点で、ノード mc2 はノード mc1 との依存関係の設定が完了しました。

• コード解析された依存関係を変更する

  コード解析された依存関係が期待どおりでない場合、または スケジューリング依存関係をサポートしないシナリオ (非周期的なデータ生成を持つテーブル) があり、依存関係を手動で削除する必要がある場合は、以下を参照して、自動的に解析された依存関係を変更できます。

  操作	説明
  解析結果を手動で削除する	上流ノード依存関係リストで、予期しない入力を削除してから、再解析します。削除後、次回の解析時に依存関係が再度追加されないように、対応するコメントがコードに自動的に追加されます。 --@exclude_input=Remove input --@exclude_output=Remove output
  入力と出力を手動で追加する	コードエディタで、テーブル名を右クリックし、[入力を追加] または [出力を追加] を選択します。追加後、対応するコメントがコードに自動的に追加されます。 --@extra_output=Add output --@extra_input=Add input または、「スケジューリング設定パネルを使用して上流ノード依存関係を手動で追加する」または「ワークフローパネルで線を引いてノード依存関係を設定する」を参照して依存関係を追加することもできます。

  重要

  DataWorks では、下流依存関係を持つノード出力を直接削除することはできません。削除すると、下流タスクの実行またはデータ取得が失敗する可能性があります。まず下流ノードから上流依存関係を削除して下流タスクを調整してから、上流ノードからノード出力を削除することを推奨します。

• 自動解析から除外されるシナリオ

  DataWorks の一時テーブル (名前が t_ で始まるテーブルなど、ワークスペースのテーブル管理で定義された固定フォーマットのテーブル) は、現在のノードの出力または上流ノードの依存関係として自動的に解析されません。

• 自動解析の使用に関する注意事項

  自動解析を使用して依存関係を設定する場合は、ノード出力が現在のリージョン内で一意であることを確認してください。DataWorks 開発シナリオで自動解析を使用する場合は、次の点に注意してください。

  • ノードの作成：各ノードには、ノードと同じ名前のデフォルトのノード出力があります。同じワークスペースに同じ名前のノードが存在する場合は、いずれかのノードのノード出力を手動で変更する必要があります。

  • コード開発：自動解析では、ノードの出力テーブルをノード出力として使用します。同じワークスペース内の 2 つのスケジューリングノードが同じテーブルにデータを挿入すると、自動解析によっていずれかのノードでエラーが発生します。詳細については、「複数のノードが同じテーブルにデータを書き込み、自動解析でノード出力名が同じであるとレポートされる」をご参照ください。

  • 依存関係の設定：SQL タスクを使用してバッチ同期タスクの出力テーブルを処理する場合、SQL タスクがリネージベースの自動解析を通じてバッチ同期タスクに迅速に依存できるようにするには、バッチ同期ノードの出力テーブルをノード出力として手動で設定するか、バッチ同期タスクの出力テーブル名をバッチ同期タスクのノード名として使用する必要があります (プラットフォームは、ノードと同じ名前のノード出力を自動的に作成します)。そうしないと、下流 SQL ノードが送信されたときに、次のエラーが発生する可能性があります：現在のノードが依存する親ノード出力名 ${projectname.tablename} が存在しません。現在のノードを送信できません。この出力名を持つ親ノードが送信されていることを確認してください。

2. スケジューリング設定パネルを使用して上流ノード依存関係を手動で追加する

スケジューリング設定 -> スケジュールの依存関係 -> 同一エポックの依存関係 設定パネルで、ノードの出力、ノード名、またはノード ID を入力して、上流ノードの依存関係を手動で追加します。ノード名は重複する可能性があるため、ノードの出力を使用して依存関係を設定することをお勧めします。

3. ワークフローパネルで線を引いてノード依存関係を設定する

ワークフロー の DAG パネルで線を引いて依存関係を設定すると、DataWorks は自動的に上流ノードから下流ノードに _out 形式の出力を追加して、ノード依存関係を確立します。

ワークフローパネルから依存関係の線が削除されると、対応する依存関係もノードのスケジューリング設定から削除されます。

1. 最近接依存 (標準的な同一サイクル依存)

• 意味：これは最も一般的で基本的な同一サイクル依存方法です。「最近接マウント」の原則に従い、下流インスタンスは、追加の設定なしで、同じビジネスサイクル内に上流ノードから生成された最新のインスタンスに自動的に関連付けられ、その完了を待ちます (いくつかの例外があります。詳細については、「複雑な依存関係シナリオのスケジューリング設定の原則と例」をご参照ください)。

• 適用可能なシナリオ：

  • 標準的な日次、週次、または月次の ETL ワークフロー。

  • 上流タスクと下流タスク間の 1 対 1 の依存関係。たとえば、ある日次タスクが別の日次タスクに依存する場合。

2. 指定範囲 (連続した時間ウィンドウに依存)

単純な 1 対 1 の依存関係がニーズを満たさない場合 (たとえば、下流タスクが一定期間にわたって上流タスクからのデータを集約する必要がある場合) は、指定範囲を使用して、より柔軟な設定を行うことができます。

この機能を使用するには、まずノードのスケジューリング設定で [高度なスケジューリング依存関係の設定] トグルを有効にする必要があります。

• 設定方法：

  1. 依存ノードを選択した後、[操作] 列の [設定] をクリックし、依存関係のタイプを [指定範囲] に設定します。

  2. 現在のノードのスケジュール時刻を基準とした左右のオフセットを設定します。許可される最大オフセット範囲は -1440 ~ 1440 (単位: 分) です。

• 説明：これにより、下流タスクは連続した時間範囲内のすべての上流インスタンスに依存できます。この範囲は、下流タスク自体のスケジュール時刻を基準として動的に計算される 「スライディングウィンドウ」 であり、指定された範囲内の当日と前日のインスタンスのみが対象となります。

• コアロジックの例:
  1時間ごとの下流タスクは、別の1時間ごとの上流タスクに依存し、範囲は[-2h, +2h]として設定されています。
  

  • 12:00 の下流インスタンスが実行されると、10:00 ~ 14:00 のすべての上流インスタンスに依存します。

  • 13:00 の下流インスタンスが実行されると、依存関係ウィンドウは自動的に 11:00 ~ 15:00 に「スライド」します。

• 適用可能なシナリオ：

  • タイムゾーンをまたいだデータ集計: 中国 (UTC+8) の日次タスクで、インド (UTC+5:30) の 24 個すべての時間単位のタスクからデータを集計する必要があるとします。 範囲を [-3h, 21h] として設定することで、インドの現地の営業日に対応する物理的な時間ウィンドウを正確にカバーできます。

  • 日をまたぐウィンドウ集計: 早朝に実行される日次タスクで、前日の午後から当日の早朝にわたるデータを処理する必要があるケースです。たとえば、昨日の 12:00 から今日の 04:00 までの上流の時間単位のインスタンスに依存するように、範囲を [-12h, 4h] のように設定できます。

3. 指定セット (離散的な固定インスタンスのグループに依存)

依存関係のロジックが、上流からの特定の離散的な出力インスタンスに関連している場合、「指定セット」が最適な選択肢です。

この機能を使用するには、まずノードのスケジューリング設定で [高度なスケジューリング依存関係の設定] トグルを有効にする必要があります。

• 設定方法：

  1. 依存ノードを選択した後、[操作] 列の [設定] をクリックし、依存関係のタイプを [指定セット] に設定します。

  2. 現在のノードのスケジュール時刻を基準とした左右のオフセットを設定します。許可される最大オフセット範囲は -1440 ~ 1440 (単位: 分) です。

• 説明：これにより、下流タスクは固定された離散的な上流インスタンスのセットに依存できます。「指定範囲」 のスライディングウィンドウとは異なり、このインスタンスセットは静的であり、すべての下流インスタンスで同一です。

• コアロジックの例:
  下流タスクは、{02:00, 06:00, 10:00} の上流インスタンスに依存するように設定されています。下流タスクの 08:00 や 12:00 のインスタンスは、いずれも指定された 3 つのインスタンスがすべて正常に完了するまで実行を待機します。
  

• 適用可能なシナリオ：

  主要なマイルストーンへの依存：下流タスクの開始条件は、1 日を通じた上流からのいくつかの主要な時点 (朝、正午、夕方のスナップショットなど) のデータが準備されていることです。