時間プロパティは、DataWorks がスケジュールタスクをいつ、どのようにトリガーするかを定義する、スケジューリングの中核的な条件です。実行タイミングを設定する スケジュール時刻 だけでなく、インスタンス生成モード、スケジューリングカレンダー、再実行設定、タイムアウトポリシー といった一連の高度な設定も含まれます。これらのパラメーターが一体となって、タスクの時間的振る舞いを計画し、トリガールール、実行境界、エラーからの自動復旧を制御します。本ガイドでは、各時間プロパティの設定方法とその動作原理を詳しく解説し、無人運用で安定した信頼性の高い自動データワークフローの構築を支援します。
クイックスタート
シナリオ: ある EC サイト企業が、毎日 02:00 に前日の総売上を自動計算する必要があります。ネットワークの変動などでタスクが失敗した場合、システムは自動的に 3 回再試行します。
ステップ 1: スケジュール時刻の設定
スケジュールの設定: タスク名をダブルクリックします。タスクの右側にある セクションで、Scheduling Cycle を Day に設定します。
スケジュール時刻の設定: スケジュール時刻を 02:00 に設定します。
ステップ 2: スケジューリングポリシーの設定
再実行プロパティの設定: 再実行プロパティを You can run again after successful or failed operation. に設定します。
失敗時の自動再実行: [失敗時の自動再実行] を選択し、再試行回数を
3に、間隔を5 分に設定します。その他のプロパティはデフォルト値のままにします。
結果:
タスクをデプロイすると、システムは翌日 (T+1) から毎日 02:00 にタスクを自動的にトリガーします。タスクが失敗した場合、システムは 5 分ごとに再試行します。タスクは最大 4 回実行されます (通常実行 1 回 + 再試行 3 回)。
仕組み
時間プロパティの設定は、インスタンス生成から実行まで、スケジュールタスクのライフサイクル全体を定義します。これには、以下の中核となる要素が含まれます:
スケジュール時刻: タスク実行の頻度と具体的な時刻を視覚的に定義します。
インスタンスのライフサイクル管理: インスタンスがいつ作成され、いつ有効になるかを決定します。これには以下が含まれます:
インスタンス生成モード: インスタンスをデプロイ当日に生成するか、翌日にするかを制御します。
有効期間: タスクの全体的な有効時間範囲を設定します。
スケジューリングカレンダー: 非営業日 (休日など) を除外するために使用されます。
実行ポリシー: スケジューリングタイプを通じて、予定時刻におけるインスタンスの振る舞いを定義します (通常実行、ドライラン (スキップ)、または一時停止)。
例外とフォールトトレランス: タイムアウト定義と再実行設定を通じて、タスクの失敗とタイムアウトに対する自動処理を提供します。
スケジュール時刻
スケジュール時刻は、タスクがいつ実行される予定か (「実行予定時刻」とも呼ばれます) を制御します。本番環境では、タスクノードが自動的にトリガーされる頻度を決定します。設定されたスケジュールに基づいて、システムは対応する数のスケジュールインスタンスを生成し、これらのインスタンスのスケジュール時刻と依存関係を通じて、ワークフロー全体の自動実行を駆動します。
スケジュール時刻と業務日付は、DataWorks における最も重要な 2 つの基準時間概念です。詳細については、「スケジューリングパラメーター」をご参照ください。
スケジュールと依存関係の独立性
頻度の独立性: タスクのスケジューリング頻度 (「毎時」や「毎日」など) は、そのタスク自身の設定によって決定され、上位タスクの頻度とは独立しています。たとえば、日次でスケジュールされたレポートタスクは、時間単位でスケジュールされたデータ準備タスクに依存できます。異なるスケジューリング頻度を持つタスク間の依存関係の設定については、「クロスサイクル依存関係の設定」をご参照ください。
インスタンス依存関係: 異なるスケジュールを持つタスク間の依存関係 (クロスサイクル依存関係) は、本質的にインスタンスレベルの依存関係です。システムはこれらの依存関係を自動的に解決し、下位インスタンスが、その業務日付に対応するすべての上位インスタンスが正常に完了した後にのみトリガーされることを保証します。
ドライランの仕組み: ブロッキングを回避するため、非日次タスク (週次、月次、年次タスクなど) は、非実行日にドライランインスタンスを生成します。このインスタンスは、コードを実行したりリソースを消費したりすることなく、即座に成功ステータスに設定され、下位の日次タスクが正常にトリガーされることを保証します。
スケジュール時刻と実際の実行時刻
スケジュール時刻: スケジュール設定で指定する時刻は、タスクの実行予定開始時刻であり、タスクが実行を開始できる最も早い時刻です。
実際の実行時刻: タスクの実際の実行開始時刻は、以下の両方の条件が満たされた場合に決まります:
すべての上位インスタンスが正常に完了している。
コンピューティングリソースが利用可能である。
スケジューリングタイムゾーン
タスクのスケジュール時刻は、デフォルトで、そのワークスペースが存在するリージョンのタイムゾーンになります。タイムゾーンを変更するには、「スケジューリングタイムゾーンの設定」をご参照し、夏時間の切り替えなどのシナリオに対応してください。詳細については、スケジューリングタイムゾーン FAQ をご参照ください。
以下のセクションでは、さまざまなシナリオの設定例を示します:
分単位のスケジュール
開始時刻、終了時刻、実行間隔を設定します。最小間隔は 1 分です。指定された時間範囲内で、システムは固定間隔で複数のインスタンスを生成します。
設定例
対象ノードは、毎日 00:00 から 23:59 の時間範囲内で 30 分ごとにスケジュールされます。
インスタンスの詳細
次の図は、30 分ごとにスケジュールされるノードのインスタンスのスケジュール時刻とスケジューリングパラメーター置換を示しています。
時間単位のスケジュール
高頻度の同期やニアリアルタイムコンピューティングのシナリオに適しています。
インスタンスの生成ロジック: システムは、閉区間 [開始時刻, 終了時刻] に基づいてスケジュールインスタンスを計算します。
例: 時間範囲が
[00:00,03:00]に設定され、間隔が1 時間の場合、システムは 00:00、01:00、02:00、03:00 にスケジュール実行時刻を持つ 4 つのインスタンスを生成します。
設定方法:
頻度ベースのトリガー: 指定された時間範囲内で固定間隔 (毎時など) で実行されます。
時刻ポイントトリガー: 1 つまたは複数の特定の離散時刻ポイントで実行されます。
設定例
対象タスクは、毎日 00:00 から 23:59 の時間範囲内で 6 時間ごとにスケジュールされます。
スケジューリングの詳細
スケジューリングシステムは 1 日あたり 4 つのインスタンスを生成し、00:00、06:00、12:00、18:00 のスケジュール時刻に実行します。
日次スケジュール
日次スケジュールは最も一般的なスケジューリング方法です。有効期間内の指定された時刻に、1 日 1 回タスクを実行できます。デフォルトでは、新しく作成されたタスクは日次スケジュールを使用し、スケジュール時刻は 00:00 から 00:30 の時間範囲内でランダムに生成されます。必要に応じてカスタム実行時刻を指定できます。たとえば、タスクを 1 日 1 回 13:00 に実行するように指定できます。
設定例
[スケジューリング周期] を [日] に設定し、[スケジュール時刻] を 13:00 に設定します。システムは自動的に cron 式 00 00 13 * * ? を生成します。
スケジューリングの詳細
スケジューリングシステムは、タスクのインスタンスを自動的に生成して実行します。次の図は、各業務日付のデータ処理時刻を示しています。
週次スケジュール
週次の業務集計や定期的なデータメンテナンスタスクに適しています。
インスタンスの生成ロジック: システムは、有効期間内で 毎日 インスタンスを生成します。
通常実行: コードロジックは、選択された実行日 (月曜日と金曜日など) にのみスケジュール通りにトリガーされます。
自動ドライラン: 選択されていない日 (火曜日、水曜日、木曜日、土曜日、日曜日など) に生成されたインスタンスは、自動的に「ドライラン成功」ステータスに設定されます。これらはロジックを実行せず、コンピューティングリソースも消費しません。
設定例
対象タスクが毎週月曜日と金曜日に実行されるように設定されている場合、月曜日と金曜日に生成されたインスタンスは通常どおりスケジュールおよび実行されますが、火曜日、水曜日、木曜日、土曜日、日曜日に生成されたインスタンスはドライランを実行します。これらはスケジュール時刻に即座に成功ステータスに設定され、コードロジックは実行されません。
[スケジュール時刻] は 13:00 に設定され、システムは自動的に cron 式 00 00 13 ? * 1,5 を生成します。
スケジューリングの詳細
スケジューリングシステムは、タスクのインスタンスを自動的に生成して実行します。
月次スケジュール
月単位でのデータ処理が必要なシナリオに適しています。財務決算、月次パフォーマンスレポート、月次ユーザー行動分析などの中核タスクでよく使用されます。
インスタンスの生成ロジック: システムは、選択した月の特定の日に基づいてインスタンスを生成します。1 つの月次スケジュールインスタンスは、完全な暦月を表します。
通常実行: コードロジックは、選択された実行日 (毎月 15 日または月末など) にのみスケジュール通りにトリガーされます。
自動ドライラン: 選択されていない日 (毎月 1 日から 14 日など) に生成されたインスタンスは、自動的に「ドライラン」ステータスに設定されます。これらはロジックを実行せず、コンピューティングリソースも消費しません。
設定例
対象タスクが決算のために毎月末日に実行されるように設定されている場合、毎月末日に生成されたインスタンスは通常どおりスケジュールおよび実行されますが、他の日に生成されたインスタンスはドライランを実行します。これらはスケジュール時刻に即座に成功ステータスに設定され、コードロジックは実行されません。
[指定日] は [毎月15日] と [毎月末日] に設定され、[スケジュール時刻] は 02:00 に設定されます。システムは自動的に cron 式 00 00 02 15,L * ? を生成します。
スケジューリングの詳細
スケジューリングシステムは、タスクのインスタンスを自動的に生成して実行します。
データバックフィル 機能を使用して月次スケジュールタスクのデータをバックフィルする場合、バックフィルには 業務日付 を選択する必要がある点にご注意ください (業務日付 = スケジュール日 - 1 日)。
例:
毎月 1 日にスケジュールされたタスクの場合、データをバックフィルする際は前月の末日を業務日付として選択します。
毎月末日にスケジュールされたタスクの場合、データをバックフィルする際は月末の前日を業務日付として選択します。
バックフィルに他の業務日付を選択した場合、バックフィルインスタンスはドライランを実行します。
その他の依存関係シナリオについては、「月次スケジューリング依存関係シナリオ」をご参照ください。
年次スケジュール
四半期集計、年次監査、または特定の休日に関連付けられたタスクなど、長周期のデータタスクに適しています。
インスタンスの生成ロジック: インスタンスは年間 365 日すべてに対して生成されますが、実際の計算は指定された月と日付でのみトリガーされます。
柔軟な組み合わせ: 月をまたぐ複数日付の選択がサポートされています。たとえば、各四半期の初日または末日にのみタスクを実行するように設定できます。
ドライランの仕組み: 実行条件を満たさない日付では、インスタンスは数秒でドライランを実行し、ロジックを実行したりコンピューティングリソースを消費したりしません。
設定例
対象タスクが毎年 1 月、4 月、7 月、10 月の末日に実行されるように設定されている場合、これらの指定日に生成されたインスタンスは通常どおりスケジュールおよび実行されますが、他の日付に生成されたインスタンスはドライランを実行します。これらはスケジュール時刻に即座に成功ステータスに設定され、コードロジックは実行されません。
月は1月、4月、7月、10月に、指定日は毎月末日に設定され、スケジュール時刻は00:00に設定されます。システムは自動的に cron 式 00 00 00 L 1,4,7,10 ? を生成します。
スケジューリングの詳細
スケジューリングシステムは、タスクのインスタンスを自動的に生成して実行します。
cron 式は選択した時刻に基づいて自動的に生成され、手動で変更することはできません。
インスタンスのライフサイクル管理
これらの設定は、タスクインスタンスが作成されるかどうかを決定します。タスクの具体的な実行時刻とは関係なく、マクロレベルでインスタンスを作成すべきかどうか、およびスケジューリングルール自体が有効かどうかを管理します。
インスタンス生成モード: 設定変更が当日に有効になるか、翌日に有効になるかを決定します。翌日モード (デフォルト) は、変更が当日のタスクに干渉しないことを保証し、スムーズな移行を可能にします。即時モードは、当日のインスタンスを強制的にリセットして変更を適用します。影響を十分に理解して評価した後、緊急の修正にのみ使用してください。
有効期間: スケジューリングルール全体の有効期間を定義します。
スケジューリングカレンダー: スケジュールを特定のカレンダーに関連付けることができます。たとえば、取引日にのみタスクを実行できます。これにより、週次スケジュールよりも柔軟な制御が可能になります。
インスタンス生成モード
ノードをコミットし、本番環境のスケジューリングシステムにデプロイすると、プラットフォームはノードに設定された [Instance Generation Mode] (Next Day および Immediately After Deployment を含む) に基づき、自動的にスケジュールされる [Auto Triggered Instances] を生成します。使用するインスタンス生成モードにかかわらず、オペレーションセンターの スケジュールタスク ページで、タスクの最新の依存関係情報を表示できます。ただし、スケジュールインスタンス がいつ有効になるか、または依存関係がいつ更新されるかは、選択したインスタンス生成モードによって異なります。
デプロイ直後に生成されたインスタンスが「期限切れドライラン」を発生させずに正常にスケジュールされるようにするには、タスクの スケジュール時刻 が デプロイ時刻 より少なくとも 10 分 後であることを確認してください。タスクは、デプロイから少なくとも 10 分後の有効時刻ポイントでのみ、コードロジックを実行するか、最新のスケジュール設定に基づいてインスタンスを再生成します。
インスタンス生成モードにかかわらず、
23:30~24:00の時間帯に行われた変更は、ノードが本番環境にデプロイされた 3 日後に有効になります。この時間帯にタスク変更を行うことは避けてください。
インスタンス生成モード | 説明 |
T+1 翌日 (デフォルト) |
|
当日のインスタンスは、デプロイ直後に生成されます。インスタンスは、そのスケジュール時刻がデプロイ時刻より少なくとも 10 分 後である場合にのみ、正常にトリガーされます。スケジュール時刻がこのしきい値より前 (過去の時刻やバッファ期間内の時刻を含む) の場合、インスタンスは自動的に ドライラン 状態になります (コードを実行せずに即座に成功に設定されます)。
|
タスクコードとスケジュール設定の有効化の違い: インスタンス生成モードにかかわらず、インスタンスは実行時に常にタスクの 最新のコード を読み取ります。ただし、スケジュール設定 (スケジューリングパラメーターや再実行ポリシーなど) は、インスタンスが生成された時点 でそのインスタンスに固定されます。インスタンスが生成された後にタスクのスケジュール設定を変更した場合、既存のインスタンスは自動的に更新されず、生成時の古い設定で引き続き実行されます。変更を適用するには、オペレーションセンター の [インスタンスの更新] を使用して、既存のインスタンスのスケジュール設定をその場で更新できます。特定の実行にのみ最新の設定を使用する必要がある場合は、タスクの データバックフィル を実行して、最新の設定で再実行することもできます。詳細については、「インスタンス生成モード: デプロイ直後」をご参照ください。
有効期間
タスクの自動スケジューリングの有効時間範囲を定義します。有効期間が終了すると、インスタンスは生成されなくなり、タスクは期限切れタスクになります。期限切れタスクは、O&M概要 ページで監視および管理できます。
スケジューリングカレンダー
タスクのスケジューリング日とスケジューリング方法を定義するために使用されます。DataWorks は以下の 2 種類のカレンダーをサポートしています:
デフォルトカレンダー: プラットフォームによって提供され、一般的なシナリオに適しています。
カスタムスケジューリングカレンダー: ユーザー定義で、柔軟なスケジューリング日が必要な業界やシナリオ (金融業界など) に適しています。カレンダーが適用されるワークスペース、カレンダーの有効期間、指定日のタスクのスケジューリング方法などのルールを設定できます。詳細については、「カスタムスケジューリングカレンダーの作成」をご参照ください。
選択したスケジューリングカレンダーに基づいて、実行ポリシー や スケジュール時刻 などのスケジュール設定と組み合わせて、指定された時刻にタスクをスケジュールする必要があります。
実行ポリシー
この設定は、タスクがトリガーされたときにどのように実行されるべきかを定義します。
スケジューリングタイプ
DataWorks でサポートされているスケジューリングタイプを次の表に示します。
スケジューリングタイプ | 説明 | ユースケース |
Normal | コードを正常に実行し、下位ノードをトリガーします。 | 正常ステータスで実行されているスケジュールタスク。生成されたスケジュールインスタンスも正常ステータスで実行されます。 |
Suspend scheduling | インスタンスは実行されず、スケジュール時刻に達すると失敗状態に設定されます。これにより下位ノードがブロックされます。スケジューリングの一時停止は、オペレーションセンターでの凍結と同等です。スケジューリングが一時停止されたノードは、オペレーションセンターで凍結アイコン | 業務ワークフローを緊急に中断する場合に適しています。 業務ワークフローを一定期間実行する必要がない場合、このスケジューリングタイプを選択してワークフローのルートノードを凍結できます。業務を再開する必要がある場合は、ルートノードの凍結を解除できます。タスクの凍結解除の詳細については、「タスクの凍結解除」をご参照ください。 |
Dry Run | インスタンスは、スケジュール時刻に達すると即座に成功に設定されます (所要時間は | ノードを一定期間実行する必要がなく、下位ノードをブロックしたくない場合に適しています。 |
例外とフォールトトレランス
データパイプラインの安定性を確保する上で、さまざまな例外を想定し、対応計画を事前に設定しておくことが不可欠です。
再実行プロパティ: タスクが失敗したときに、システムが自動的に再試行するかどうか、およびどのように再試行するかを決定します。
タイムアウト設定: タスクの妥当な最大実行時間を設定します。タスクがこの時間を超えた場合、システムは自動的にアラートをトリガーするか、タスクを終了して、単一ノードがスタックして過剰なリソースを消費するのを防ぐことができます。
タイムアウト定義
タスクの実行に許可される最大実行時間を設定します。実行時間がこの値を超えた場合、タスクは自動的に終了されて失敗状態となり、スタックしてワークフロー全体に影響が及ぶのを防ぎます。
範囲: スケジュールインスタンス、データバックフィルインスタンス、テストインスタンスに対して有効です。
デフォルト値: デフォルトは 3~7 日です。システムは、実際のワークロードに基づいてこの値を動的に調整します。
制限: 手動で設定可能な最大値は 168 時間 (7 日) で、最小値は 1 分です。
再実行設定
再実行ポリシーは、タスクの失敗からの自動復旧を可能にします。
再実行プロパティを使用する場合、データ品質の問題を回避するために、可能な限りタスクの冪等性を確保してください (特殊なタスクを除く)。たとえば、ODPS SQL 開発では、
insert overwriteを使用し、insert intoは使用しないでください。
再実行プロパティ:
タイプ
ユースケース
[実行ステータスに関係なく許可]
結果に影響を与えることなく繰り返し実行できる冪等タスクに適しています。
Do not re-run after successful operation, and re-run after failure.
成功したタスクを誤って再実行することによるデータ破損を防ぎます。
Disallow Regardless of Running Status
非冪等タスク (特定のデータ同期タスクなど) に適しています。このオプションを選択すると、[失敗時の自動再実行] 機能は使用できなくなります。
失敗時の自動再実行: タスクが失敗すると、システムは自動的に再実行をトリガーします。
パラメーター
説明
[再実行回数]
失敗後の自動再試行回数。有効な値: 1~10。
[Rerun Interval]
再試行間の間隔。有効な値: 1~30 分。
説明タイムアウト による失敗では、自動再実行はトリガーされません。
FAQとベストプラクティス
Q: タスクの実際の実行時刻がスケジュール時刻と異なるのはなぜですか?
A: スケジュール時刻は、タスクの「予定」開始時刻にすぎません。実際の実行には、さらに 2 つの条件が満たされる必要があります: ① すべての上位依存タスクが正常に完了している。② スケジューリングリソースが利用可能である。いずれかの条件が満たされない場合、タスクは待機状態のままになります。
Q: 上位タスクは時間単位で実行され、下位タスクは日単位で実行されます。これらは相互に依存できますか?
A: DataWorks は、スケジュールの異なるタスク間の依存関係をサポートしています。システムは高度な依存関係解決アルゴリズムを使用することで、下流タスクが実行される前に、すべての上流インスタンスが完了するまで正しく待機するようにします。詳細については、「周期をまたぐ依存関係を設定する」をご参照ください。
Q: 先週の金曜日のデータをバックフィルしましたが、
bizdate変数に金曜日の日付が表示されません。なぜですか?A: これは通常、「業務日付」と「実行日」の混同が原因です。DataWorks では、業務日付 = スケジュール日 - 1 日です。例えば、土曜日の朝に実行されるタスクのデータをバックフィルする場合、業務日付として金曜日を選択する必要があります。
Q: タスクにデータ書き込みロジックがあります。再実行するとデータが重複しますか?
A: その可能性があります。したがって、タスクの冪等性を確保することを強く推奨します。データ書き込みタスクの場合、
INSERT OVERWRITE(上書き) を使用し、INSERT INTO(追加) は使用しないでください。これにより、複数回の再実行でも一貫した結果が保証されます。