摘要：?DataWorks基于MaxCompute作為核心的計算、存儲引擎，提供了海量數據的離線加工分析、數據挖掘的能力。通過DataWorks，可對數據進行數據傳輸、數據轉換等相關操作，從不同的數據存儲引入數據，對數據進行轉化處理，最后將數據提取到其他數據系統。
摘要：DataWorks基于MaxCompute作為核心的計算、存儲引擎，提供了海量數據的離線加工分析、數據挖掘的能力。通過DataWorks，可對數據進行數據傳輸、數據轉換等相關操作，從不同的數據存儲引入數據，對數據進行轉化處理，最后將數據提取到其他數據系統。在本文中，阿里巴巴計算平臺產品專家祎休為大家介紹了通過DataWorks進行新增調度資源、調度資源管理、配置不同周期任務依賴等最佳實踐。
更多精彩內容傳送門：大數據計算技術共享計劃 — MaxCompute技術公開課第二季?
以下內容根據演講視頻及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個小時調度一次，那么對應的實例里面就會產生對應的依賴關系。
在進行配置時需要選擇上游的節點進行自依賴，在如下所示的依賴圖中可以看出，分鐘級別的依賴任務有自依賴，它會依賴上一周期的成功，并觸發下游的小時任務的統計。
本文為云棲社區原創內容，未經允許不得轉載
