摘要： DataWorks基於MaxCompute作為核心的計算、儲存引擎，提供了海量資料的離線加工分析、資料探勘的能力。通過DataWorks，可對資料進行資料傳輸、資料轉換等相關操作，從不同的資料儲存引入資料，對資料進行轉化處理，最後將資料提取到其他資料系統。

摘要：DataWorks基於MaxCompute作為核心的計算、儲存引擎，提供了海量資料的離線加工分析、資料探勘的能力。通過DataWorks，可對資料進行資料傳輸、資料轉換等相關操作，從不同的資料儲存引入資料，對資料進行轉化處理，最後將資料提取到其他資料系統。在本文中，阿里巴巴計算平臺產品專家禕休為大家介紹了通過DataWorks進行新增排程資源、排程資源管理、配置不同週期任務依賴等最佳實踐。

以下內容根據演講視訊及PPT整理而成。

大家在使用MaxCompute的時候更多地是在DataWorks上面實現基於ETL加工、排程、配置以及雲上數倉的構建任務。本文將與大家分享DataWorks後臺強大排程系統的實現邏輯以及一些具體的實現案例，希望能夠對大家在做雲上數倉相關工作時有所幫助。

本次分享主要分成3個部分，在第一部分是排程的基本介紹，主要為大家分享DataWorks的基本概念，這部分將幫助大家理解後續的依賴關係。第二部分將與大家分享依賴關係的簡介，比如自依賴、跨週期依賴以及版本依賴等，以及這些依賴之間會在後臺生成什麼樣的例項等。最後一部分將與大家分享依賴關係的實戰，為大家剖析兩個案例，並回顧本次分享的內容。總體上而言，通過本次分享希望能夠幫助大家區分DataWorks和MaxCompute的不同點，讓大家更好地理解DataWorks的定位是MaxCompute之上雲上數倉的開發工具。

一、排程基本介紹首先需要明確兩個概念：節點和例項。如下圖左側所示，節點是描述DataWorks資料分析和處理過程的基本單元，比如Shell、ODPS SQL、ODPS MR、PyODPS等。而在Dataworks後臺前一天23:30的節點會生成快照，統一生成的執行例項。對於使用者而言，在配置排程上的最大感觸就是在23:30分之前提交的排程配置，會在23:30分之後生效，而在23:30分之後配置的一些依賴關係只能夠間隔一天再統一地生成例項。例項會對非天任務進行拆分，如一小時一次的小時節點將會拆分成具體的24個例項。

此外，還需要明白兩個關係，就是排程規則和依賴關係。對於排程規則而言，首先需要滿足依賴關係，即上游節點必須完成，才能排程下游節點；其次，需要判斷定時的時間是否已經到了，如果到了就立即執行，如果沒有到，就需要等待時間。對於依賴關係而言，正如下圖中右側所示，是描述兩個或多個節點之間的語義連線關係，其中上游節點的狀態將影響其他下游節點的執行狀態，反之則不成立。

此外，還需要為大家介紹跨週期依賴和自依賴關係。在如下圖右側的欄目去開啟就能看到，跨週期的依賴有很多選項，在這些選項背後有很多的概念。第一個就是跨週期依賴，這其實也分了跨週期和跨版本的兩個概念，如何理解呢？其實，跨週期依賴是針對小時任務的，也就是小時任務依賴同一天的上一個週期。比如每個節點按照小時進行排程，那當前的節點能否排程起來需要依賴於上一個週期是否成功返回了。另外一部分就是跨版本依賴，這種依賴就是針對於天依賴的任務做的，比如今天任務能否成功執行依賴於昨天的任務能否成功返回，這裡更多的會有一些資料的先後依賴關係，因此在這部分需要做跨版本的依賴配置。而自依賴可以理解成為跨週期和跨版本的依賴，針對於天任務，如果配置了自依賴，那麼就是會依賴於昨天版本的例項。針對於小時任務，就會依賴於每天的最後一個週期。

二、依賴關係簡介排程屬性：凍結在依賴關係裡面，可以通過整體的架構圖來看。在WorkFlow裡面可以看到，屬性裡面有一個凍結的概念，週期例項中的凍結只針對當前例項，且正在執行中的例項，凍結操作無實際效果，並不會殺掉正在執行的例項。凍結狀態的任務會生成例項，但是不會執行，可以理解為空跑狀態。如果需要執行凍結的例項，需要解凍例項，單擊重跑，例項才會開始執行。

出錯機制在公共雲上，如果開啟了出錯機制，那麼預設會重試3次，每次間隔2分鐘，如果經歷了3次重試還是失敗，那麼就會返回失敗狀態。

對於排程屬性而言，DataWorks有5種排程週期，分別是分鐘、小時、日、周和月。如果週期大於天的，那麼由於排程的例項劃分時按天生成的，所以周月任務在不執行的哪一天實際是按照空跑處理的。如果選擇日排程，而且不勾選定時排程的，定時時間統一按照0點處理。

此外，跨週期依賴裡面有4個選項，他們分別對應了不同的概念。比如“不依賴上一排程週期”就是其不會形成跨週期和版本的依賴關係，而如果勾選了“自依賴”，那麼就會依賴當前節點的上一週期，只有當上一週期執行結束並且返回成功，當前節點才能執行。另外一部分，如果選擇瞭如圖所示的，依賴於“一層子節點”或者等待“下游任務的上一週期結束”才能執行。此外，還能自定義一些節點，當然在節點裡面可以輸入節點ID或者名稱與一些自定義的任務進行依賴關係配置。而如果勾選了“等待自定義任務的上一週期結束，才能繼續執行”，這樣當前的工作流任務就會等待依賴的任務節點結束才會執行。

自依賴的使用如下圖所示，大家可以在DataWorks運維中心裡面看到每天生成的執行例項的圖。這與開發面板不太一樣，如果存在實現的上下游依賴關係，那麼就是正常的依賴關係，而有虛線的就是跨週期或者自依賴的關係。從這些可以判斷，一些使用者配置了自依賴，如果發現今天的任務沒有跑起來，就需要去追溯昨天的任務是否執行正常，如果昨天的任務也沒有正常執行就需要繼續向上追溯。

三、依賴配置實戰排程依賴關係如下所示的整頁圖裡面是天任務的相互依賴，箭頭表示的資料流向。如果根據下圖將箭頭反方向調整就可以理解成依賴關係，也就是下游會依賴上游。現在箭頭則表示資料的流向，假設現在有兩個天排程的任務，兩個都是凌晨開始執行的，那麼當上遊任務成功運行了，下游才會執行起來，而且如果上游任務沒有執行完成，下游任務即使定時時間到了也無法執行。

在下圖中可以看出，天任務可以相互依賴，上游存在跨週期依賴。如果下游任務想要成功執行，就需要上游任務成功執行作為前提。下圖中可以看出，2014年和2015年的兩個例項分別存在相互依賴關係，上游的任務會依賴上一週期的一層子節點，如果上游昨天的任務未成功執行，那麼就會阻塞昨天的任務和今天的下游任務。

如下圖所示的小時任務比較流行，大家可能會經常配置6個小時或者8個小時的任務，這樣會生成3至4個例項，這樣只要一個週期未成功，後續的所有周期都會阻塞，並且可以有效避免一個週期任務執行慢了導致後續週期定時到了之後併發執行。

排程基礎依賴型別介紹(1) 小時任務依賴天任務從下圖中可以看出，是小時任務依賴天任務。在左側中是2014年12月31日的情況，例項B1、B2和B3都會依賴例項A，例項A是12點執行，而例項B1、B2以及B3都是小時任務，所以需要依賴天任務，需要等待天任務完成之後才能執行。而當定時的時間到了，這些任務才會併發地執行，在這裡就是上游例項A成功運行了，下游的B1、B2和B3才能同時併發地執行。

(2) 天任務依賴小時任務例項A是例項B1、B2和B3的下游節點，也就是說例項A依賴於上游的幾個小時任務節點。這樣一來，天任務就需要等待小時任務的所有周期都完成了才能去排程這樣的天任務，所以如果按照每8個小時跑一個小時任務，這樣就能夠拆分成3個例項，只有當這些小時例項都成功執行之後，下游的天任務才能在時間已經到了的情況下執行起來。

(3) 小時任務依賴小時任務且週期數一樣比如上游節點是小時任務，下游的節點也是小時任務，當這兩個小時任務都是按照每幾個小時生成時，其生成的例項數是一樣的，在這種情況下可以理解為父子節點都是小時任務，同時其週期數也是一樣的。而每一個執行的例項都會形成一個一一對應的關係。當然，若下游的定時晚於上游的定時，在下游定時時間到了的時候也不能排程，需要等待上游對應的週期完成之後才能開始排程。

(4) 小時任務依賴小時任務且週期數不同在這種情況下，可能上游按照12個小時執行一次，那麼一天可能會生成兩個例項，下游則可能每天按照6個小時，那麼這個時候可能生成6個例項。其實，可以從圖中看出其是如何依賴的關係，小時任務依賴小時任務，如果其週期數不同，如果下游週期數大於上有的週期數，則會依據就近原則掛依賴，也就是時間小於或者等於自己且不重複的依賴。

自依賴的使用案例1：小時任務依賴天任務在如下圖所示的任務依賴中，箭頭表示了資料的流向。之前案例也講到，如果上游天任務完成時下游有多個週期定時時間已到，會導致這些週期被併發排程起來，如果不希望下游併發排程起來，則需要將下游小時任務設定成自依賴，即依賴上一週期，也就是本節點，這樣形成一個自依賴。需要注意的是，自依賴會依賴跨版本（跨天），如果昨天最後一個週期未完成，會導致今天的任務無法排程。如下圖所示，例項A屬於天任務，而下游例項B則是每8小時執行一次的小時任務，例項B之間則會有一些虛線的依賴關係。比如例項A在12點執行成功了，那麼例項B在執行的時候需要先去判斷例項A的狀態與自己的定時時間，生成完之後才會依次執行B2、B3，而當出現了跨天的情況，比如執行到B4的時候，需要去判斷昨天最後一個例項的狀態。

案例2：天任務依賴小時任務在下圖裡面，箭頭表示依賴關係。如果天任務依賴小時任務，需要等待小時任務的所有周期都完成了才能開始排程。比如在上游按照每小時執行一次的資料，等所有資料都落入到對應的分割槽之後，再按照一定的資料彙總24小時的資料。如果需要天任務儘量按照定時時間開始排程。則可以配置上游小時任務自依賴，待上游小時任務定時時間最近（且小於）的週期完成後，下游天任務就會被排程。

案例3：小時任務依賴天任務小時任務依賴天任務且天任務存在跨週期依賴，則小時任務的所有周期都會依賴昨天的天任務。

案例4：天任務依賴小時任務對於這樣的情況需要配置依賴一層子節點，比如上游的小時任務跨週期依賴下游的定時天任務，效果即上游小時任務會在每一週期都會依賴上一版本的下游任務。

案例5：小時任務依賴小時任務這種情況比較複雜，圖中的實線表示依賴關係，虛線則表示自依賴關係。為了實現這樣的依賴關係，需要在下游節點設定依賴自定義節點（父節點ID）。在這個case比較特別，即可看出其實這個依賴圖中存在兩個概念，既有跨週期（依賴上游小時任務的上一週期），又存在跨版本（依賴上游小時任務的上一版本的所有周期）。

排程依賴關係的具體實現示意圖首先對於定義關係圖而言，上游三個節點，下游一個節點這樣的情況而言，在每天23:30分會生成一個節點快照，生成一個可執行的例項。當例項執行的時候，會依次執行上游的各個節點，當各個節點全部執行成功了之後，下游節點就會判斷是否已經到了自己能夠執行的時間，如果符合執行條件就會去執行。而如果上游任何一個節點執行失敗了，就會導致下游節點一直處於等待狀態。

跨週期跨版本的使用(1) 針對跨週期跨版本依賴的優化和之前的依賴關係對比，可以看到有了自依賴後，跨週期依賴的邊少了很多。這是因為如果有了自依賴，當前週期成功的前提必須是前一個週期成功了，於是下游跨週期並跨版本依賴就減少成了跨週期依賴。

(2) 天任務依賴小時任務在天任務依賴小時任務的場景下，系統需求統計截止到每小時的業務資料增量，然後在最後一個小時的資料彙總完成後,需要一個任務進行一整天的彙總。對於這樣的場景進行需求分析得到以下兩點：1）每個小時的增量，即每整點起任務統計上個小時時間段的資料量。需要配置一個每天每整點排程一次的任務，每天最後一個小時的資料是在第二天第一個例項進行統計。2）最後的彙總任務為每天執行一次，且必須是在每天最後一個小時的資料統計完成之後才能執行，那麼需要配置一個天任務，依賴小時任務的第一個例項。

如下圖中左側所示，可能期望的結果就是在排程任務的定義時，上游是小時任務，每個小時執行一次，下游是天任務，每天凌晨開始執行，就形成了這樣的依賴關係。而對於綠色的圖而言，對應的任務例項的狀況，只有當每天最後一個小時任務處理完成之後，才會去處理天任務。而當真正按照這種依賴關係進行配置，直接掛靠這種依賴關係，在排程系統中會生成右側所示的例項，但是這是不符合預期的。

而如果想要達到整體的需求，就需要配置上游小時任務的自依賴。如果上游的小時任務形成自依賴，那麼上游的24個小時任務例項就會按照下圖左側中的例項進行依賴，當小時任務都生成之後才會去執行天任務。對於這樣的依賴關係，只需要去DataWorks裡面選擇跨週期依賴的自依賴就可以了。

(3) 小時任務依賴分鐘任務對於小時任務依賴分鐘任務而言，有這樣的一種業務場景：已經有任務每30分鐘進行一次同步，將前30分鐘的系統資料增量匯入到MaxCompute，任務定時為每天的每個整點和整點30分執行。現在需要配置一個小時任務，每6個小時進行一次統計，即每天分別統計0點到6點之間、6點到12點之間、12點到18點之間、18點到明天0點整之間的資料。從分析來看，我們期望的效果就是如下圖中左側所示，上游的分鐘任務，每隔30分鐘排程一次，下游是小時任務，每隔6個小時排程一次，那麼對應的例項裡面就會產生對應的依賴關係。

在進行配置時需要選擇上游的節點進行自依賴，在如下所示的依賴圖中可以看出，分鐘級別的依賴任務有自依賴，它會依賴上一週期的成功，並觸發下游的小時任務的統計。