大資料開發過程中常遇到不同執行週期的任務進行依賴，常見 天任務依賴小時任務、 小時任務依賴分鐘任務 。那麼如何通過大資料開發套件開發這兩種場景呢？

本文將從這兩個場景出發，結合排程依賴/引數/排程執行等，介紹不同週期排程依賴的最佳操作實踐。

再此之前，我們先明確幾個概念：

• 業務日期：業務資料產生的日期，這裡指完整一天的業務資料。在大資料開發套件裡任務每天能處理的最近的完整一天業務資料是昨天的資料，所以業務日期=日常排程日期-1天。
• 依賴關係：依賴關係是描述兩個或多個節點/工作流之間的語義連線關係，其中上游節點/工作流的執行狀態可以影響下游節點/工作流的執行狀態，反之則不成立。
• 排程例項：大資料開發套件的排程系統對週期任務進行排程執行時，會先根據任務的配置進行例項化，每個例項帶上具體的定時時間、狀態、上下游依賴等屬性。

注意：目前數加大資料開發套件每天自動排程的例項都是在昨天晚上23:30生成。

• 排程規則：排程任務是否能執行起來要滿足的條件：

  1. 上游任務例項是否都執行成功。若所有上游任務例項都執行成功則觸發任務進入等待時間狀態。
  2. 任務例項定時時間是否已經到。任務例項進入等待時間狀態後會check本身定時時間是否到，如果時間到了則進入等待資源狀態；
  3. 當前排程資源是否充足。任務例項進入等待資源狀態後，check當前本專案排程資源是否充足，若充足則可以執行起來。

天任務依賴小時任務

業務場景

系統需求統計截止到每小時的業務資料增量，然後在最後一個小時的資料彙總完成後需要一個任務進行一整天的彙總 。

需求分析

1）每個小時的增量，即每整點起任務統計上個小時時間段的資料量 。需要配置一個每天每整點排程一次的任務，每天最後一個小時的資料是在第二天第一個例項進行統計 。

2）最後的彙總任務為每天執行一次，且必須是在每天最後一個小時的資料統計完成之後才能執行，那麼需要配置一個天任務，依賴小時任務的第一個例項 。

分析得出的排程形態如下圖：

但是，真正如上圖排程任務定義那樣配置排程依賴後，排程任務例項並沒有得到上圖的效果，而是如下圖：

上圖中，天任務必須等小時任務當天其他所有例項也執行完成才能執行，而需求是天任務只需依賴小時任務第一個例項，此效果明顯不能滿足需求 。

要達到該場景需求，此時就需要結合任務“跨週期依賴”進行配置，可以將小時任務“跨週期依賴”屬性配置成“自依賴”，然後天任務配置定時時間為零點整，且依賴屬性配置依賴小時任務 。

分析得出的最終方案排程形態如下圖：

此時，小時任務的例項為序列執行，第一個例項能執行成功，可保證它前面（昨天）的例項都已經執行成功，因此天任務可以只需要依賴第一個例項 。

配置實踐

小時任務的排程配置如下圖：

天任務的排程配置如下圖：

引數配置：小時任務每整點例項處理前一小時的資料，如可以用$[yyyy-mm-dd-hh24-1/24]，天任務 若時間格式為yyyymmdd，用${bdp.system.bizdate}；若時間格式為yyyy-mm-dd，用自定義引數$[yyyy-mm-dd-1]，具體視詳細設計而定 。引數配置如下圖所示：

測試/補資料/自動排程

測試和補資料：都是手動生成的排程例項，選擇的是業務日期 。
如選擇業務日期為 2017-01-10：

• 天任務例項的定時時間是 2017-01-11 00:00:00；
• 小時例項的定時時間是 2017-01-11 00:00:00 至 2017-01-11 23:00:00；
• ${bdp.system.bizdate} 賦值結果為 20170110（例項定時間年月日減1天）；
• $[yyyy-mm-dd-hh24-1/24] 賦值結果為 2017-01-10-23 至 2017-01-11-22（例項定時間年月日時減1小時）。

自動排程：排程系統自動生成的例項，每天的例項定時時間都是當天，如“需求分析”中的最終方案效果圖 。

小時任務依賴分鐘任務

業務場景

已經有任務每 30 分鐘進行一次同步，將前 30 分鐘的系統資料增量匯入到 MaxCompute，任務定時為每天的每個整點和整點 30 分執行 。現在需要配置一個小時任務，每 6 個小時進行一次統計，即每天分別統計 0 點到 6 點之間、6 點到 12 點之間、12 點到 18 點之間、18 點到明天 0 點整之間的資料 。

需求分析

1） 分鐘任務：

• 00:00 例項同步的是昨天最後 30 分鐘的資料，產出的表分割槽如“昨天日期年-月-日-23:30”；
• 00:30 例項同步的是今天 00:00-00:30 之間的資料，產出的分割槽如“今天日期年-月-日-00:00”；
• 01:00 例項同步到是今天 00:30-01:00 之間的資料，產出的分割槽如“今天日期年-月-日-00:30”；
• 以此類推， 23:30 例項同步的是今天 23:00-23:30 之間的資料，產出的分割槽如：“今天日期年-月-日-23:00”

2）小時任務：

• 每 6 個小時進行一次統計，則一天排程 4 次；
• 統計 0 點到 6 點之間的資料，則依賴分鐘任務當天的 00:30—6:00 共 12 個例項；
• 統計 6 點到 12 點之間的資料，則依賴分鐘任務當天的 6:30—12:00 共 12 個例項；
• 統計 12 點到 18 點之間的資料，則依賴分鐘任務當天的 12:30—18:00 共 12 個例項；
• 統計 18 點到第二天 0 點之間的資料，則依賴分鐘任務當天的 18:30—23:30 以及第二天 00:00 共 12 個例項 。

分析得出的排程形態如下圖：

但是，真正如上圖排程任務定義那樣配置排程依賴後，排程任務例項並沒有得到上圖的效果，而是如下圖：

如上圖，10 日 18 點到 11 日 0 點之間的資料，11 日小時任務 0 點整點例項只依賴了分鐘任務 11 日 0 點整例項，不能確保分鐘任務 10 日 18:30 至 23:30 的例項是否執行成功 。

要達到該場景需求，此時就需要結合任務“跨週期依賴”進行配置，可以將分鐘任務“跨週期依賴”屬性配置成“自依賴”，然後小時任務依賴屬性配置依賴小時任務 。

分析得出的最終方案排程形態如下圖：

此時，分鐘任務的例項為序列，每個例項能執行成功，可保證它前面（或昨天）的例項都已經執行成功，因此小時任務每個例項可以只需要依賴分鐘任務定時時間離它最近（小於等於）的一個例項 。

配置實踐

分鐘任務的排程配置如下圖：

小時任務排程配置如下圖：

引數配置：分鐘任務每個例項處理前面30分鐘資料產出的分割槽可以用引數如 $[yyyy-mm-dd-hh24:mi-30/24/60] , 具體視詳細設計而定 。配置類似下圖：

測試/補資料/自動排程

測試和補資料：都是手動生成的排程例項，選擇的是業務日期。如選擇業務日期為 2017-01-10：

• 分鐘任務例項的定時時間是 2017-01-11 00:00:00 至 2017-01-11 23:30:00，共 48 個例項；
• 小時例項的定時時間是 2017-01-11 00:00:00、06:00:00、12:00:00、18:00:00 共 4 個例項；
• $[yyyy-mm-dd-hh24:mi-30/24/60] 賦值結果為 2017-01-10-23:30 至 2017-01-11-23:00（例項定時間年月日時分減 30 分鐘）。

自動排程：排程系統自動生成的例項，每天都例項定時時間都是當天，如“需求分析”中的最終方案效果圖 。

總結

• 長週期任務依賴短週期任務時，如果短週期有自依賴：當天的排程例項中，長週期任務的每個例項只依賴短週期例項中定時時間與它最近（且小於）的一個例項 。
• 長週期任務（小時）依賴短週期任務（分鐘）時，如果短週期無自依賴：當天的排程例項中，長週期任務的每個例項會依賴定時時間小於等於且沒被本任務其他例項依賴的短週期例項；天/周/月依賴小時/分鐘任務例外，因為天任務例項會依賴所有小時/分鐘任務 。
• 排程週期和排程時間引數配合使用，最終排程引數替換的值取決於每次排程的例項定時時間，而排程上看到的 業務日期=例項定時時間年月日減1天 。