本篇文章主要說明了設定排程依賴的原因，排程依賴的原理及其在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節點了。
以上就是本次排程依賴基本使用的全部内容了，有問題需要解答的同學可以加一下我們的釘釘大群，群裡有直播回放可以觀看。
感謝大家的關注！