蘇寧大資料離線任務開發排程平臺實踐
1.背景
在資料倉庫的建立過程中，核心技術是抽取、轉換、裝載（ETL），它為資料倉庫提供及時、高質而準確的資料。由於ETL包括眾多的處理任務，且這些任務之間有一定的約束關係，如何高效的排程和管理這些任務是資料倉庫ETL實施中非常重要的工作，也是提高資料倉庫開發效率和資源利用率的關鍵。
在大資料平臺，隨著業務發展，每天承載著成千上萬的ETL任務排程，這些任務的形態各種各樣。怎麼樣讓大量的ETL任務準確的完成排程而不出現問題，甚至在任務排程執行中出現錯誤的情況下，任務能夠完成自我恢復甚至執行錯誤告警與完整的日誌查詢。IDE大資料離線任務排程系統就是在這種背景下衍生的一款分散式排程系統。
在闡述IDE平臺之前，首先討論一下作業排程系統和資源排程系統的區別，因為往往有同學把這兩者混為一談。資源排程系統的典型代表比如：Yarn／Mesos／Omega／Borg，還有阿里的伏羲，騰訊的蓋婭（Gaia），百度的諾曼底(Normandy)等等。我們今天的內容主要講述的是作業排程系統。不過，IDE除了完成了大資料的任務各種複雜排程外，還包含了任務開發、依賴組織、狀態維護、任務監控、任務治理、服務監控、動態擴縮容等諸多內容。
2.設計目標
2.1使用者互動的產品功能
從使用者互動的產品功能上看，主要包括以下幾點：
- 提供視覺化的操作頁面，任務的開發、運維、監控等操作圖形化頁面化
- 對擁有許可權的作業／任務進行管理，包括設計排程週期和時間、新增、修改、刪除任務節點、組織依賴關係、查詢等
- 對任務執行狀態進行檢視、監控，進行殺死、重跑、補資料、檢視執行日誌、檢視操作記錄等運維操作
- 支援作業失敗自動重試，可以設定自動重試次數，重試間隔等
- 支援任務失敗報警，超時報警，到達指定時間未執行報警等異常情況的報警監控
- 支援動態按應用／業務／優先順序等維度調整作業執行的併發度排程時間和資料時間的分離
- 支援歷史任務獨立重刷或按照依賴關係重刷後續整條作業鏈路允許設定作業生命週期，可以臨時禁止或啟用一個週期作業
- 提供任務鏈路依賴分析，便於分析任務的上下游影響，排程執行延遲的溯源分析
- 提供任務的異常自助診斷分析和優化建議，便於使用者及時合理的整改任務
- 提供任務的匯入匯出、複製等功能，便於使用者在多個執行環境和資料中心快速開發任務，提高開發效率
- 支援多使用者的併發訪問控制，便於多使用者的協同開發而不出問題
- 提供任務的釋出管控和許可權管控的配置功能，規範任務開發流程，降低生產風險
詳細的使用者產品功能如圖1所示：
(圖1：使用者產品功能清單)
2.2後臺排程功能
從後臺排程系統自身邏輯看，主要包括以下幾點：
- 準實時排程，支援僅執行一次和週期性任務（分鐘、小時、天、周、月），作業計劃的變更，即時生效
- 靈活的排程策略，觸發方式需要支援：時間觸發，依賴觸發或者混合觸發，支援多種依賴關係等
- 做好多租戶隔離，執行器資源隔離、內建流控，負載均衡和作業優先順序等機制
- 系統高可用，元件模組化，核心元件無狀態化
- 支援任務失敗轉移、執行機器資源發現和健康度評估
- 提供排程記憶體物件的跟蹤捕捉，便於複雜場景下的任務排程異常原因分析
- 開放系統介面，對外提供REST API，便於對接周邊系統
- 提供任務狀態的釋出訂閱，便於對接外部系統根據任務狀態的變化完成其他業務邏輯
詳細的排程模組功能如圖2所示：
(圖2：排程模組的功能清單)
2.3 任務執行器功能
從任務執行器方面看，主要包括以下幾點：
- 支援多種型別大資料任務執行，包括：資料交換、Hive、Python、Java、MapReduce、Spark、SparkSQL、Sqoop、機器學習任務等
- 支援任務程序之間的隔離，防止任務之間的互相影響
- 支援自動健康檢查和狀態彙報，不健康時及時彙報排程系統，不再繼續領取執行任務
- 部署無狀態，支援動態擴縮容
- 能夠支援異常任務跟蹤，高耗CPU和記憶體的任務的自助發現和記錄
- 支援固定、動態、智慧分配任務執行資源，合理利用伺服器資源
- 能夠進行很好的容錯處理
詳細的任務執行器功能如圖3所示：
(圖3：任務執行器功能清單)
2.4 任務運維功能
從任務運維角度看，主要包括以下幾點：
- 提供任務狀態的監控告警功能，任務異常時及時告警和干預，避免造成任務堆積和業務異常
- 提供自動化部署，包括排程模組和執行器模組，支援動態擴縮容
- 任務執行進度和完成時間預測
- 提供任務執行分析和自助診斷功能
- 任務日誌分析，自動識別錯誤原因和型別
- 提供PC和移動端運維功能，便於隨時隨地發現和解決問題
- 提供知識庫建立和應急解決方案、系統降級方案
平臺運維能力如圖4所示：
(圖4：平臺運維能力)
2.5 平臺對外功能
從平臺對外的能力輸出方面，主要包括以下幾點
- 提供任務建立、狀態查詢和殺死、重跑、補資料等運維介面，便於複雜業務場景根據業務邏輯動態操作任務
- 介面授權和安全性校驗，打通與外部系統的對接，擴充套件平臺和業務系統的大資料開發能力
平臺的對外服務能力如圖5所示：
(圖5：平臺對外服務能力)
3.平臺價值
目前蘇寧八大產業齊聚併發，資料爆發增長，依託大資料平臺打通各產業資料，服務智慧零售。在整個智慧零售中和大資料開發戰略中，ETL是BI（商業智慧）的基礎，資料排程是ETL的靈魂。
使用該平臺能夠對企業中批量執行作業進行集中管理，並通過強大的排程引擎功能實現作業的邏輯執行，並提供直觀詳細的監控手段，輔助運維工作。平臺為系統的開發與運維提供以下價值：
- 解放人力，提高工作效率。
通過使用平臺對大資料作業進行自動化管理和監視。當系統出現異常的情況時，以郵件、簡訊等多種方式通知相應的管理員進行人工參與，大大減輕了現有管理員的工作壓力，提高了IT系統的管理效率。
- 靈活的配置及告警機制。
利用平臺提供的靈活配置功能和完善的告警處理機制，大大避免了因為故障處理不及時而帶來的損失。
- 強大的許可權管理。
將各種執行操作許可權合理的分配給作業及操作人員，進行許可權限定的批量作業設定、執行和監視，使核心許可權得到有效保護。
- 全面的作業執行狀況分析。
通過自動採集作業執行狀況、時間，分析故障分佈、作業執行時長等業務執行指標，整體把握系統執行健康度。
4.平臺建設
IDE平臺旨在為使用者提供從資料來源申請、任務建立、任務排程編排、任務運維、任務告警、執行分析等一站式大資料開發平臺，幫助企業快速完全資料中臺搭建。
IDE大資料開發平臺在架構上分為任務管理平臺、任務排程、任務執行、任務監控、和API服務五部分。平臺採用了先進的JavaEE技術架構，具有很強的跨平臺性。部署簡便，維護簡單，容易使用。支援分步式的多機叢集，能承載大規模資料的高負荷執行，具有良好的穩定性。平臺採用了多層架構，結構清晰，具有良好的擴充套件性、穩定性和容錯性。
平臺整體架構如圖6所示。
(圖6：平臺架構設計)
接下來，我們重點闡述部分設計實現細節和相關實踐經驗。
4.1 使用者功能實現說明
使用者互動的產品功能，注重圖形化視覺化，易操作易維護
讓使用者能夠儘可能的自助服務，同時降低操作代價，減少犯錯的可能性。支援當日任務計劃和執行歷史的查詢，支援週期作業資訊的檢索，包括作業概況，歷史執行流水，執行日誌，變更記錄，依賴關係、任務執行明細查詢等。這部分功能的目的，是為了讓系統更加透明，讓業務更加可控，讓排查和分析問題更加容易。儘可能的讓一切作業任務資訊和變更記錄都有源可查，做到任務操作都可以追蹤和溯源。
- 主要操作全部圖形化視覺化，降低使用者使用成本，提高開發效率。
任務流和任務的開發設計頁面如圖7所示。
(圖7：任務開發主頁面)
- 任務流的開發提供畫布操作，任務節點拖拽方便，編排簡單，如圖8和圖9所示。
(圖8：任務流設計畫布)
(圖9：任務節點依賴關係編排)
- 任務配置視覺化，簡單化，降低犯錯率，如圖10所示。
(圖10：任務視覺化配置頁面)
- 任務執行狀態進行檢視、監控，進行殺死、重跑、補資料、檢視執行日誌、檢視操作記錄等運維操作。如圖11和圖12所示
(圖11：任務運維管理頁面)
(圖12：任務流畫布上的運維操作)
- 提供豐富的告警，便於及時跟蹤任務執行狀態，降低事故率。如圖13和14所示
(圖13：任務告警型別)
(圖14：任務告警配置頁面)
- 提供任務鏈路依賴分析，便於分析任務的上下游影響，排程執行延遲的溯源分析。
如圖15所示。
(圖15：任務執行依賴分析)
4.2 排程週期設計說明
準實時排程，支援週期性任務（分鐘、小時、天、周、月），作業計劃的變更
所謂準時實排程，首先指的是平臺會按照各個上線的任務流的排程時間生成排程執行計劃，當觸發時間到了，平臺會按照排程執行計劃精確的生成任務流例項和任務例項。但是在任務執行上，並不保證準實時的分配機器執行。實際上平臺以整體資源使用情況為最高原則，並按照一定的限流策略控制任務的執行，比如：任務優先順序、任務組併發度、平臺任務併發數、任務特定執行時間等因素。在保證平臺資源允許的情況下，儘量按時執行任務。為了保障任務的實時性，必須保障任務資源的可用性和計劃可控性。
作業計劃的變更允許使用者調整自己上線的任務流執行計劃。比如天任務調整為小時任務，排程開始時間從1點開始調整為2點開始。如果對上線已經生成任務例項的任務流進行調整，必須下線後再調整，此時會提示使用者殺死當前的任務，然後完成計劃調整。如果上線的任務流還未到觸發時間，沒有生成任務例項，使用者可以及時修正，並對任務執行無影響。
圖16是平臺的任務流頻率支援的型別。
(圖16：任務流排程頻率型別)
4.3 排程策略設計說明
靈活的排程策略，觸發方式需要支援：時間觸發，依賴觸發或者混合觸發，支援多種依賴關係等
首先，在一些複雜的業務場景裡，存在跨流任務依賴排程，不同的任務流的頻率和時間週期不一致，比如天依賴小時、周依賴天等
其次，針對不同優先順序的任務，在資源利用高峰和任務執行高峰時段，可以適當調整中低優先順序的任務的執行時間視窗，避免低優先順序的任務和高優先順序的任務進行資源搶佔，錯峰執行，提高資源利用率和均衡性。
在解決跨流依賴方面，平臺目前僅支援 大頻率依賴小頻率，比如：天依賴小時、周依賴天、月依賴天，以及同頻依賴，比如：小時依賴小時、天依賴天、周依賴周、月依賴月。平臺在設計之初限制了一個任務只能屬於一個任務流，不允許任務跨流存在，如何解決跨流依賴的問題呢？我們建議使用者對任務建立任務事件，可以理解成任務的一個執行副本。這個事件是允許跨流存在的。如果一個任務流需要依賴另外一個任務流的的某個任務，只要依賴這個任務的事件即可，通過事件我們將任務流進行串聯起來。如圖17所示。
(圖17：任務事件依賴)
在解決跨系統之間的依賴問題，我們提供了FTP事件，即在FTP伺服器上建立標識檔案，一個事件對應一個標識檔案地址，當FTP伺服器上的標識檔案生成的時候，我們認為業務系統已經完成作業，需要觸發平臺任務執行。
因為FTP事件存在實時性和穩定性的問題，即排程服務是不停的輪詢各個FTP事件伺服器，當FTP伺服器負荷較重，往往會連線超時，導致掃描檔案標識延遲，進而導致下游任務延遲，我們對使用者系統了API事件，即業務系統作業完成後可以呼叫平臺的API介面，觸發下游任務執行，解決了時效性和穩定性的問題。
(圖18：事件列表)
4.4 排程流控設計說明
做好多租戶隔離，執行器資源隔離、內建流控，負載均衡和作業優先順序等機制。
大多數的工作流排程系統，多租戶的隔離比較簡單，業務上租戶之間完全獨立，租戶之間的業務很難相互關聯。同一租戶的工作流方面也不能互相依賴和關聯。更多的考慮是物理資源層面的隔離，這個，多半通過獨立叢集或者虛擬化的方案來解決，同一租戶內部，做得好的可能再考慮一下業務佇列管理。
我司的業務環境則不適合採取類似的方案，首先從業務的角度來說，不同的業務組（亦即租戶），雖然管理的作業會有不同，但是往往不同租戶之間的作業，相互依賴關係複雜，犬牙交錯，變化也頻繁，基本不可能在物理叢集或機器的層面進行隔離，業務組之間的人員流動，業務變更也比較頻繁。
其次在同一租戶業務內部，不同優先順序的任務，不同型別的任務，不同應用來源的任務，包括週期任務，一次性任務，失敗重試任務，歷史重刷任務等各種情況，也有不同的資源和流控管控需求。
目前本平臺在開發實踐中，主要從以下幾方面進行限流控制：
- 任務優先順序，任務分為高中低三個優先順序，分別對應底層yarn的資源排程不同的權重，高優先順序的優先分配執行機器和計算資源
- 系統呼叫和使用者補資料操作分開，平臺絕大部分的任務執行都是依賴自身的排程週期執行，無需使用者干涉，優先保證這部分的任務的執行資源；在某些業務場景下，需要對歷史資料進行彌補，通過指定執行的資料時間強制任務執行，這類任務往往不是很緊急，可以將優先順序降低
- 失敗重試和使用者重跑優先順序高於系統呼叫的優先順序。當任務出現異常需要進行重跑或者重試，需要人工進行干預的情況下，一般屬於緊急情況，需要優先保證這部分的任務的計算資源
- 部分任務可以設定固定時間，錯峰執行，避免高峰時段的資源壓力
- 對於同一任務流內同一層級內部的多個任務，可以設定任務組，通過設定任務組的併發度來限制任務的並行個數，降低對業務系統的訪問壓力。這個往往在對分庫資料庫或者同一資料庫進行多工訪問操作的時候，減輕業務資料庫的訪問壓力，可以限制任務的並行執行個數
- 按照任務型別進行限流。平臺支援的任務型別很多，當底層對應的計算或者儲存資源壓力過大，可以限制某些型別的任務的併發個數，降低底層的計算壓力。這個限流可以做到平臺全域性層面，也可以做到系統賬號層面。
- 可以為某些型別任務或者某個系統賬號下的任務指定固定的機器資源執行，這樣可以降低大資源消耗任務對其他任務的資源搶佔，保障特殊任務的資源需求，也可以進行部分賬號的任務的灰度釋出，降低生產事故率
- Worker節點的被動負載反饋（負載高的情況拒絕接收任務）和主節點的主動負載均衡（輪詢和Worker節點併發數控制等策略）。在分配任務和領取任務方面都進行了任務佇列深度控制，防止過度分配和過度領取而導致分配不均而引起的任務堆積
4.5 系統高可用設計說明
系統高可用，元件模組化，核心元件無狀態化
從系統架構的角度出發，模組化的設計有利於功能隔離，降低元件耦合度和單個元件的複雜度，提升系統的可拓展性，一定程度上有利於提升系統穩定性，但帶來的問題是開發除錯會更加困難，從這個角度來說又不利於穩定性的改進。所以各個功能模組拆不拆，怎麼拆往往是需要權衡考慮的。
平臺採用常見的主從式架構，按照功能模組劃分清晰，職責單一而不緊耦合，避免繁重複雜的業務耦合設計。Master節點負責作業計劃的管理和任務的排程分配，worker節點負責具體任務的執行。使用者通過Web控制後臺管理作業，而Web控制後臺與Master伺服器之間的互動透過Rest服務來執行，Rest服務也可以給Web控制後臺以外的其它系統提供服務（用於支援外部系統和排程系統的對接）。平臺部署架構圖如圖19所示。
（圖19：部署架構圖）
Master排程除了引入Quartz的負責時間排程外，核心的就是任務例項在執行過程中的狀態變化以及變化後觸發的操作邏輯。任務例項狀態的變化切換目前仿照yarn的狀態機實現原理，重新進行了改造封裝。這塊的核心元件受限研發時間和技術問題沒有做到無狀態。
這裡所說的無狀態化，更多的強調的是各個排程元件執行時狀態的持久化，在元件崩潰重啟後，所有的執行時狀態都應該能夠通過外部持久化的資料中快速的恢復重建。
為了保證狀態的一致統一，平臺的所有作業和任務的資訊變更，無論是使用者發起的作業配置修改，還是執行器反饋的作業狀態變更，都會提交給Master節點同步寫入到資料庫。
在HA方面，按照準實時的設計目標，平臺並沒有打算做到秒級別的崩潰恢復速度，系統崩潰時，只要能在分鐘級別範圍內，重建系統狀態，就基本能滿足系統的設計目標需求。
所以其實高可用性設計的重點，關鍵在於重建的過程中，系統的狀態能否準確的恢復。比如，主節點崩潰或維護期間，發生狀態變更的任務在主節點恢復以後，能否正確更新狀態等等。而雙機熱備份無縫切換，目前來看實現難度較大（太多流程需要考慮原子操作，資料同步和避免競爭衝突），實際需求也不強烈，通過監控，自動重啟和雙機冷備的方式來加快系統重建速度，基本也就足夠了。
另外，為了提高系統區域性維護／升級期間的系統可用性，平臺支援Worker節點的動態上下線，可以對worker節點進行滾動維護，當Master節點下線時，Worker節點和ZK節點也會快取任務的狀態變更資訊，等到Master節點重新上線後再次彙報結果。所以一定程度上也能減少和規避系統不可用的時間。
4.6 任務失敗策略
支援任務失敗轉移、執行機器資源發現和健康度評估
作業失敗的原因很多，有上游表資料不對、指令碼配置錯誤等主要原因，也有一些臨時性的原因，比如網路原因、外部DB負載原因，可能重試了就好了。所以，為了降低運維代價，我們需要可以支援相關重試策略的配置。當然，更加理想的情況是系統可以智慧的根據失敗的原因自動採取不同的策略。
(圖20：任務失敗重試配置)
(圖21：任務失敗重試執行記錄)
4.7 任務執行分析設計說明
任務執行自助分析，對任務進行診斷分析，便於使用者發現和調整問題。
針對失敗的任務提供任務執行日誌，方便查看出錯問題，識別常見的錯誤模式，明確的告訴使用者錯誤型別，如果可能，告知解決方案。
(圖22：任務執行日誌)
針對成功的任務提供診斷資訊，比如某個任務跑得慢，是因為GC，還是資料量變化，是因為叢集資源不夠，還是自身業務在某個環節被限流？各種情況下，使用者該如何應對解決，能否自動給出建議？此外，是否能夠定期自動診斷，及時提醒使用者，敦促使用者自主優化？避免問題積壓到影響業務正常執行的時候才被關注。
目前我們自研了“華佗”平臺，可以針對在hadoop上執行的hive、mr、spark任務進行執行診斷，對於出現GC、資料傾斜、資源消耗等方面做出綜合的診斷。
(圖23：任務執行診斷)
(圖24：任務執行診斷詳情)
5.現狀和未來
整體來說，本文前面所描述的設計目標，平臺基本上都已經實現了。經過3年的開發和持續改進過程，當前排程系統日常大概日均承載約20萬個週期排程作業，接入集團絕大部分的離線計算相關的開發任務。平臺目前趨於穩定，由於系統自身原因造成的大規模系統故障已經非常罕見。
但是，由於前期平臺過分追求滿足使用者的離線作業需求，未考慮任務配置的合理性、優先順序和業務的關聯性以及任務之間的血緣關係等，在後期任務量快速上升的情況下，經常出現資源競爭激烈、任務小檔案碎片化嚴重、任務變更影響和追蹤定位鏈路過長等等問題。另外在極端環境下，尤其是在高負載大流量情況下，遇到系統硬體，記憶體，DB或網路異常問題時，能否較好的進行容錯處理，還是需要經歷更多的複雜場景來加以磨練的。
未來，我們將從以下幾個方面進行優化提升。
使用者層面
- 在保證現有平臺功能穩定的基礎上，進一步豐富平臺的任務型別、任務引數、任務樣例、幫助手冊等，提高平臺的易用性
- 提供任務分析報表，視覺化分析跟蹤任務的總體執行情況、排程資源、計算資源、健康度，更好的按不同維度（個人／系統／全域性等）彙總展示給使用者，方便使用者隨時掌控和調整自身業務
- 提供任務異常的快速分析診斷能力，提高使用者的自運維能力
- 能夠定期自動診斷，及時提醒使用者，敦促使用者自主優化。避免問題積壓到影響業務正常執行的時候才被關注。
排程層面
- 準實時排程，支援短週期任務，作業計劃的變更，即時生效
- 靈活的排程策略，觸發方式需要支援：時間觸發，依賴觸發或者混合觸發，支援多種依賴關係等
- 系統高可用，元件模組化，核心元件無狀態化
- 支援使用者許可權管理，能和各種周邊系統和底層儲存計算框架既有的許可權體系靈活對接
- 做好多租戶隔離，內建流控，負載均衡和作業優先順序等機制
- 開放系統介面，對外提供REST API，便於對接周邊系統
任務分析治理層面
- 系統整體業務健康度檢測和評估手段改進
- 業務診斷專家系統的改進
- 非標準任務的轉換和大任務流的拆分
- 優化任務配置
6.後續
我司的大資料離線任務開發排程平臺從設計、開發到上線運營經歷了很多問題，尤其是在第二次版本改造升級過程中，除了自身調研外，還參考和借鑑了一些其他產品的設計理念。平臺的部分設計內容和思想參考了 蘑菇街 劉旭輝的《大資料平臺排程系統架構理論和實踐》的相關內容，在此特別感謝劉旭輝的理論文章，同時也感謝參與平臺設計開發的每一位小夥伴的付出。