本篇文章主要說明了設置調度依賴的原因，調度依賴的原理及其在DataWorks上的具體體現，同時介紹了在DataWorks上設置調度依賴的3種方式，並提出了一些常見問題和相應的解決方案
分享人：DataWorks技術支持團隊
我們在開發者社區學習路線裡有發佈一個DataWorks的學習路線，裡面包含了入門講解和熟能生巧系列的直播內容，大家可以去學習一下，需要主賬號登陸學習哦：https://developer.aliyun.com/learning/course/81
一、為什麼要設置調度依賴
設置調度依賴是為了保證業務數據有效、適時地產出，形成規範化的數據研發場景。這裡針對的是調度的場景，也就是表數據每天都有更新的情況，是為了保障每個節點在取數的時候都能取到準確的數據。
規範的依賴關係配置後，無需關心當前節點需要依賴表由哪個節點產出，通過DataWorks自動解析一鍵為您設置任務依賴。
假設某個節點B會產出表B數據，節點B任務執行成功後，平臺默認數據已經準備就緒，下游依賴該表B數據的節點（表）就可以開始取數了。如下圖，如果xc_rpt_user_info_d這個節點要運行，那這個節點需要正確地取到上游數據，也就是說上游的這些節點都需要先正確地執行完畢。這裡有一個重要概念，就是“表之間的依賴”要轉換成“產出該表的節點之間的依賴”。
DataWorks上通過節點輸出來掛依賴，也就是上游節點的輸出作為下游節點的輸入形成依賴關係。比如節點B產出表 B數據，表 B數據依賴表 A，那麼我們將產出表 A的節點A作為當前節點B的上游依賴。
二、如何設置調度依賴
方式一：自動解析
當前表A的數據是依賴於項目B下面的表B數據，自動解析時會將表A表作為節點輸出，格式是“項目名.表名”，然後當前節點select 的表B表會作為節點的輸入，也就是父節點的輸出（B是A的上游）。
自動解析掛好以後可以看下依賴關係。上游節點b（父節點）產出表table_b作為父節點輸出，而下游節點代碼裡用到了這個表，所以自動解析的時候會將table_b作為當前表a的上游（節點a的輸入），通過這個輸入可以找到父節點b，從而掛上依賴線。這樣自動解析就能一鍵設置任務依賴。
為什麼要推薦自動解析？
- 根據代碼的邏輯，判斷您在當前節點需要產出某張表。當您以project_name.tablename的方式將其作為本節點輸出時，後續其它節點需要查詢該表時，您無需關注要依賴哪個節點，您只需要關注要依賴該表當前週期產出的數據。
- 當您無法確定當前工作空間產出該表數據的具體節點時，您可以使用自動解析，幫助您快速開發業務流程。
- 使用自動解析該操作的前提是遵循自動解析規範。
- 同地域的工作空間支持自動解析依賴關係，即支持同地域跨工作空間配置節點調度依賴關係。
方式二：自定義依賴
有三種：代碼編輯輸入輸出、手動添加上游依賴和自動推薦。
這裡有個問題，如果某個表數據是本地上傳的，自動解析將它解析出來了，但是提交的時候報錯依賴的父節點輸出不存在，這裡的依賴關係又因為是自動解析出來的而不能刪除，這個時候該怎麼辦呢？
第一種解決方案是直接在代碼中編輯輸入輸出。假如ods_user_info_d這個表是本地上傳的表數據，那麼我們可以在代碼中選中這個表，右鍵刪除輸入，隨後右側依賴的父節點就不會有表了，然後重新解析輸入輸出，不過這裡會出現一個血緣關係不一致的提示。
為什麼會有輸入與代碼血緣分析不匹配的提示呢？就是因為剛剛代碼有刪除輸入輸出，也就是在代碼中select和insert這個表，但是節點的依賴關係沒有將它作為輸入或輸出，通過代碼的解析和配置的節點依賴不匹配。此時，我們就需要關注這張表的數據源來源，以採取不同的應對策略。
第二種方式是手動添加依賴。這裡有兩個場景，一個是需要依賴某個表數據，一個是需要依賴某個節點，不一定存在表血緣依賴。當需要依賴某個節點的時候，我們可以輸入節點的輸出，如果需要依賴某個表數據，可以直接在這個依賴的上游輸入這個表名。
第三種方式是自動推薦，當對自動解析比較困惑或經常報錯的時候可以選擇。
拉線設置依賴關係也符合DataWorks掛依賴的原理，即上游節點的輸出會作為下游節點的輸入，這樣形成的依賴關係。
最佳實踐：這裡有3點要注意
- 首先產出表數據的節點要設置該表作為該節點的輸出，避免下游取這個表數據的時候，自動解析將它掛為依賴的父節點，但是通過這個表找不到產出這個表數據的節點，下一個節點用這個表的時候提交就會報錯。
- 其次一張表數據由一個節點產出，保證節點輸出同region下唯一。因為DataWorks通過節點輸出來掛依賴，需要保證通過這個輸出可以定位到唯一的節點。
- 最後建議任務名稱和輸出表名保持一致。
三、常見問題
因為同步任務是不支持調度依賴自動解析的，所以需要手動配置。DataWorks在節點輸出時會默認添加兩個輸出，一個是_out，一個是節點名輸出，而把節點名設置為該同步任務產出的表名，就可以避免再單獨操作節點輸出。
另外，出現血緣關係不正確的原因剛才也說過了，這個時候需要確認代碼中用到的表是不是本地上傳的，或者是週期調度產出的，要關注數據源的來源。
父節點輸出不存在這個場景也經常遇到，我們首先要明確的就是依賴的父節點輸出不存在並不是說這個表不存在，只是沒有通過這個表找到產出這個表數據的節點，也就是沒有任何一個節點的輸出是這個表。
如果當前需要將節點提交上去不報錯，有兩種解決方式。一是直接將自動解析設置為否，但不推薦，因為會導致血緣關係不匹配，也會導致下游用當前節點產出表數據的時候，提交會報錯。自動解析關掉後，它不會將當前界面insert的表作為節點的輸出；第二是確認該表數據來源是什麼，是本地上傳的還是調度每天產出的。
關於節點輸出相同，提交失敗的情況。因為DataWorks需要保證節點輸出唯一，通過這個唯一的輸出定位到唯一的節點上，所以建議大家一個表數據由一個節點產出，如果有同名節點的情況，那也需要更改其中一個節點的輸出。
刪除節點失敗，當前節點存在下游的情況。可以看到下圖的這個節點沒有下游依賴，但是刪除的時候會報錯說節點存在依賴。這個時候需要先檢查一下這個節點，在配置頁面看是否有下游節點依賴它，或者在運維中心搜索這個節點看有無任務，隨後找到下一個節點去刪除依賴關係。下游節點依賴去除乾淨後，這個節點才能下線。
舉例演示一下，現在要刪除dw_user_info_all_d這個節點，我們先把下游依賴線刪除掉：
我們雙擊打開我們想刪除的dw_user_info_all_d節點，找到下游依賴該節點的所有節點，本例中只有rtp_user_info_d，我們打開運維中心生產環境和開發環境，通過dw_user_info_all_d節點的節點ID搜索，可以發現dw_user_info_all_d節點下游依然有rtp_user_info_d節點。
我們回到DataWorks開發界面，雙擊rtp_user_info_d節點，因為提交節點需要有父節點，我們可以把rtp_user_info_d節點掛在根節點上，這樣rtp_user_info_d節點不再依賴我們要刪除的節點。我們提交rtp_user_info_d節點到開發環境，顯示提交成功後，我們發佈rtp_user_info_d節點到開發環境：
然後我們檢查一下開發環境，rtp_user_info_d節點已經沒有依賴我們要下線的那個任務節點了，但是生產環境還存在依賴。
接下來我們把更新操作發佈到生產環境：
再到生產環境查看rtp_user_info_d節點，也已經不再依賴我們要下線的節點了：
同樣，我們也可以到開發環境和生產環境看我們想刪除的dw_user_info_all_d節點是否還有下游依賴。確認都沒有了，就可以下線這個任務了。
這樣我們就成功下線我們想刪除的dw_user_info_all_d節點了。
以上就是本次調度依賴基本使用的全部內容了，有問題需要解答的同學可以加一下我們的釘釘大群，群裡有直播回放可以觀看。
感謝大家的關注！