78
【大數據開發套件調度配置實踐】——不同周期任務依賴配置
大數據開發過程中常遇到不同運行周期的任務進行依賴，常見**天任務依賴小時任務**、**小時任務依賴分鍾任務**。那麼如何通過大數據開發套件開發這兩種場景呢？
本文將從這兩個場景出發，結合調度依賴/參數/調度執行等，介紹不同周期調度依賴的最佳操作實踐。
再此之前，我們先明確幾個概念：
- 業務日期：業務數據產生的日期，這裏指完整一天的業務數據。在大數據開發套件裏任務每天能處理的最近的完整一天業務數據是昨天的數據，所以業務日期=日常調度日期-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天 。
最後更新：2017-06-14 15:01:56