目錄

背景 2

設計目標 2

2.1 用戶交互的產品功能 2
2.2 后臺調度功能 3
2.3 任務執(zhí)行器功能 4
2.4 任務運維功能 5
2.5 平臺對外功能 6

平臺價值 7

平臺建設 7

4.1 用戶功能實現說明 8
4.2 調度周期設計說明 12
4.3 調度策略設計說明 13
4.4 調度流控設計說明 15
4.5 系統(tǒng)高可用設計說明 16
4.6 任務失敗策略 17
4.7 任務運行分析設計說明 18

現狀和未來 20

后續(xù) 21

 

 

 

1. 背景

在數據倉庫的建立過程中，核心技術是抽取、轉換、裝載(ETL)，它為數據倉庫提供及時、高質而準確的數據。由于 ETL 包括眾多的處理任務，且這些任務之間有一定的約束關系，如何高效的調度和管理這些任務是數據倉庫 ETL 實施中非常重要的工作，也是提高數據倉庫開發(fā)效率和資源利用率的關鍵。

在大數據平臺，隨著業(yè)務發(fā)展，每天承載著成千上萬的 ETL 任務調度，這些任務的形態(tài)各種各樣。怎么樣讓大量的 ETL 任務準確的完成調度而不出現問題，甚至在任務調度執(zhí)行中出現錯誤的情況下，任務能夠完成自我恢復甚至執(zhí)行錯誤告警與完整的日志查詢。IDE 大數據離線任務調度系統(tǒng)就是在這種背景下衍生的一款分布式調度系統(tǒng)。

在闡述 IDE 平臺之前，首先討論一下作業(yè)調度系統(tǒng)和資源調度系統(tǒng)的區(qū)別，因為往往有同學把這兩者混為一談。資源調度系統(tǒng)的典型代表比如：Yarn/Mesos/Omega/Borg，還有阿里的伏羲，騰訊的蓋婭(Gaia)，百度的諾曼底 (Normandy) 等等。我們今天的內容主要講述的是作業(yè)調度系統(tǒng)。不過，IDE 除了完成了大數據的任務各種復雜調度外，還包含了任務開發(fā)、依賴組織、狀態(tài)維護、任務監(jiān)控、任務治理、服務監(jiān)控、動態(tài)擴縮容等諸多內容。

2. 設計目標

2.1 用戶交互的產品功能

從用戶交互的產品功能上看，主要包括以下幾點：

提供可視化的操作頁面，任務的開發(fā)、運維、監(jiān)控等操作圖形化頁面化
對擁有權限的作業(yè)／任務進行管理，包括設計調度周期和時間、添加、修改、刪除任務節(jié)點、組織依賴關系、查詢等
對任務運行狀態(tài)進行查看、監(jiān)控，進行殺死、重跑、補數據、查看運行日志、查看操作記錄等運維操作
支持作業(yè)失敗自動重試，可以設置自動重試次數，重試間隔等
支持任務失敗報警，超時報警，到達指定時間未執(zhí)行報警等異常情況的報警監(jiān)控
支持動態(tài)按應用／業(yè)務／優(yōu)先級等維度調整作業(yè)執(zhí)行的并發(fā)度調度時間和數據時間的分離
支持歷史任務獨立重刷或按照依賴關系重刷后續(xù)整條作業(yè)鏈路允許設置作業(yè)生命周期，可以臨時禁止或啟用一個周期作業(yè)
提供任務鏈路依賴分析，便于分析任務的上下游影響，調度執(zhí)行延遲的溯源分析
提供任務的異常自助診斷分析和優(yōu)化建議，便于用戶及時合理的整改任務
提供任務的導入導出、復制等功能，便于用戶在多個運行環(huán)境和數據中心快速開發(fā)任務，提高開發(fā)效率
支持多用戶的并發(fā)訪問控制，便于多用戶的協同開發(fā)而不出問題
提供任務的發(fā)布管控和權限管控的配置功能，規(guī)范任務開發(fā)流程，降低生產風險

 

詳細的用戶產品功能如圖 1 所示：

 

 

(圖 1：用戶產品功能清單)

2.2 后臺調度功能

準實時調度，支持僅執(zhí)行一次和周期性任務（分鐘、小時、天、周、月），作業(yè)計劃的變更，即時生效
靈活的調度策略，觸發(fā)方式需要支持：時間觸發(fā)，依賴觸發(fā)或者混合觸發(fā)，支持多種依賴關系等
做好多租戶隔離，執(zhí)行器資源隔離、內建流控，負載均衡和作業(yè)優(yōu)先級等機制
系統(tǒng)高可用，組件模塊化，核心組件無狀態(tài)化
支持任務失敗轉移、執(zhí)行機器資源發(fā)現和健康度評估
提供調度內存對象的跟蹤捕捉，便于復雜場景下的任務調度異常原因分析
開放系統(tǒng)接口，對外提供 REST API，便于對接周邊系統(tǒng)
提供任務狀態(tài)的發(fā)布訂閱，便于對接外部系統(tǒng)根據任務狀態(tài)的變化完成其他業(yè)務邏輯

詳細的調度模塊功能如圖 2 所示：

 

 

(圖 2：調度模塊的功能清單)

2.3 任務執(zhí)行器功能

支持任務進程之間的隔離，防止任務之間的互相影響
支持自動健康檢查和狀態(tài)匯報，不健康時及時匯報調度系統(tǒng)，不再繼續(xù)領取執(zhí)行任務
部署無狀態(tài)，支持動態(tài)擴縮容
能夠支持異常任務跟蹤，高耗 CPU 和內存的任務的自助發(fā)現和記錄
支持固定、動態(tài)、智能分配任務執(zhí)行資源，合理利用服務器資源
能夠進行很好的容錯處理

詳細的任務執(zhí)行器功能如圖 3 所示：

(圖 3：任務執(zhí)行器功能清單)

2.4 任務運維功能

從任務運維角度看，主要包括以下幾點：

提供任務狀態(tài)的監(jiān)控告警功能，任務異常時及時告警和干預，避免造成任務堆積和業(yè)務異常
提供自動化部署，包括調度模塊和執(zhí)行器模塊，支持動態(tài)擴縮容
任務執(zhí)行進度和完成時間預測
提供任務運行分析和自助診斷功能
任務日志分析，自動識別錯誤原因和類型
提供 PC 和移動端運維功能，便于隨時隨地發(fā)現和解決問題
提供知識庫建立和應急解決方案、系統(tǒng)降級方案

平臺運維能力如圖 4 所示：

 

 

(圖 4：平臺運維能力)

2.5 平臺對外功能

從平臺對外的能力輸出方面，主要包括以下幾點

提供任務創(chuàng)建、狀態(tài)查詢和殺死、重跑、補數據等運維接口，便于復雜業(yè)務場景根據業(yè)務邏輯動態(tài)操作任務

接口授權和安全性校驗，打通與外部系統(tǒng)的對接，擴展平臺和業(yè)務系統(tǒng)的大數據開發(fā)能力

平臺的對外服務能力如圖 5 所示：

 

 

(圖 5：平臺對外服務能力)

3. 平臺價值

目前蘇寧八大產業(yè)齊聚并發(fā)，數據爆發(fā)增長，依托大數據平臺打通各產業(yè)數據，服務智慧零售。在整個智慧零售中和大數據開發(fā)戰(zhàn)略中，ETL 是 BI(商業(yè)智能)的基礎，數據調度是 ETL 的靈魂。

使用該平臺能夠對企業(yè)中批量運行作業(yè)進行集中管理，并通過強大的調度引擎功能實現作業(yè)的邏輯運行，并提供直觀詳細的監(jiān)控手段，輔助運維工作。平臺為系統(tǒng)的開發(fā)與運維提供以下價值：

解放人力，提高工作效率。

通過使用平臺對大數據作業(yè)進行自動化管理和監(jiān)視。當系統(tǒng)出現異常的情況時，以郵件、短信等多種方式通知相應的管理員進行人工參與，大大減輕了現有管理員的工作壓力，提高了 IT 系統(tǒng)的管理效率。

靈活的配置及告警機制。

利用平臺提供的靈活配置功能和完善的告警處理機制，大大避免了因為故障處理不及時而帶來的損失。

強大的權限管理。

將各種運行操作權限合理的分配給作業(yè)及操作人員，進行權限限定的批量作業(yè)設置、運行和監(jiān)視，使核心權限得到有效保護。

全面的作業(yè)運行狀況分析。

通過自動采集作業(yè)運行狀況、時間，分析故障分布、作業(yè)運行時長等業(yè)務運行指標，整體把握系統(tǒng)運行健康度。

4. 平臺建設

IDE 平臺旨在為用戶提供從數據源申請、任務創(chuàng)建、任務調度編排、任務運維、任務告警、運行分析等一站式大數據開發(fā)平臺，幫助企業(yè)快速完全數據中臺搭建。

IDE 大數據開發(fā)平臺在架構上分為任務管理平臺、任務調度、任務執(zhí)行、任務監(jiān)控、和 API 服務五部分。平臺采用了先進的 JavaEE 技術架構，具有很強的跨平臺性。部署簡便，維護簡單，容易使用。支持分步式的多機集群，能承載大規(guī)模數據的高負荷運行，具有良好的穩(wěn)定性。平臺采用了多層架構，結構清晰，具有良好的擴展性、穩(wěn)定性和容錯性。

平臺整體架構如圖 6 所示。

 

 

(圖 6：平臺架構設計)

接下來，我們重點闡述部分設計實現細節(jié)和相關實踐經驗。

4.1 用戶功能實現說明

用戶交互的產品功能，注重圖形化可視化，易操作易維護

讓用戶能夠盡可能的自助服務，同時降低操作代價，減少犯錯的可能性。支持當日任務計劃和執(zhí)行歷史的查詢，支持周期作業(yè)信息的檢索，包括作業(yè)概況，歷史運行流水，運行日志，變更記錄，依賴關系、任務運行明細查詢等。這部分功能的目的，是為了讓系統(tǒng)更加透明，讓業(yè)務更加可控，讓排查和分析問題更加容易。盡可能的讓一切作業(yè)任務信息和變更記錄都有源可查，做到任務操作都可以追蹤和溯源。

主要操作全部圖形化可視化，降低用戶使用成本，提高開發(fā)效率。

任務流和任務的開發(fā)設計頁面如圖 7 所示

 

 

(圖 7：任務開發(fā)主頁面)

任務流的開發(fā)提供畫布操作，任務節(jié)點拖拽方便，編排簡單，如圖 8 和圖 9 所示。

 

 

(圖 8：任務流設計畫布)

 

 

(圖 9：任務節(jié)點依賴關系編排)

任務配置可視化，簡單化，降低犯錯率，如圖 10 所示。

 

 

(圖 10：任務可視化配置頁面)

任務運行狀態(tài)進行查看、監(jiān)控，進行殺死、重跑、補數據、查看運行日志、查看操作記錄等運維操作。如圖 11 和圖 12 所示

 

 

(圖 11：任務運維管理頁面)

 

 

(圖 12：任務流畫布上的運維操作)

提供豐富的告警，便于及時跟蹤任務執(zhí)行狀態(tài)，降低事故率。如圖 13 和 14 所示

 

 

(圖 13：任務告警類型)

 

 

(圖 14：任務告警配置頁面)

提供任務鏈路依賴分析，便于分析任務的上下游影響，調度執(zhí)行延遲的溯源分析。

如圖 15 所示。

 

 

(圖 15：任務執(zhí)行依賴分析)

4.2 調度周期設計說明

準實時調度，支持周期性任務(分鐘、小時、天、周、月)，作業(yè)計劃的變更

所謂準時實調度，首先指的是平臺會按照各個上線的任務流的調度時間生成調度執(zhí)行計劃，當觸發(fā)時間到了，平臺會按照調度執(zhí)行計劃精確的生成任務流實例和任務實例。但是在任務執(zhí)行上，并不保證準實時的分配機器執(zhí)行。實際上平臺以整體資源使用情況為最高原則，并按照一定的限流策略控制任務的執(zhí)行，比如：任務優(yōu)先級、任務組并發(fā)度、平臺任務并發(fā)數、任務特定執(zhí)行時間等因素。在保證平臺資源允許的情況下，盡量按時執(zhí)行任務。為了保障任務的實時性，必須保障任務資源的可用性和計劃可控性。

作業(yè)計劃的變更允許用戶調整自己上線的任務流執(zhí)行計劃。比如天任務調整為小時任務，調度開始時間從 1 點開始調整為 2 點開始。如果對上線已經生成任務實例的任務流進行調整，必須下線后再調整，此時會提示用戶殺死當前的任務，然后完成計劃調整。如果上線的任務流還未到觸發(fā)時間，沒有生成任務實例，用戶可以及時修正，并對任務執(zhí)行無影響。

圖 16 是平臺的任務流頻率支持的類型。

 

 

(圖 16：任務流調度頻率類型)

4.3 調度策略設計說明

靈活的調度策略，觸發(fā)方式需要支持：時間觸發(fā)，依賴觸發(fā)或者混合觸發(fā)，支持多種依賴關系等

首先，在一些復雜的業(yè)務場景里，存在跨流任務依賴調度，不同的任務流的頻率和時間周期不一致，比如天依賴小時、周依賴天等

其次，針對不同優(yōu)先級的任務，在資源利用高峰和任務執(zhí)行高峰時段，可以適當調整中低優(yōu)先級的任務的執(zhí)行時間窗口，避免低優(yōu)先級的任務和高優(yōu)先級的任務進行資源搶占，錯峰執(zhí)行，提高資源利用率和均衡性。

在解決跨流依賴方面，平臺目前僅支持 大頻率依賴小頻率，比如：天依賴小時、周依賴天、月依賴天，以及同頻依賴，比如：小時依賴小時、天依賴天、周依賴周、月依賴月。平臺在設計之初限制了一個任務只能屬于一個任務流，不允許任務跨流存在，如何解決跨流依賴的問題呢?我們建議用戶對任務創(chuàng)建任務事件，可以理解成任務的一個執(zhí)行副本。這個事件是允許跨流存在的。如果一個任務流需要依賴另外一個任務流的的某個任務，只要依賴這個任務的事件即可，通過事件我們將任務流進行串聯起來。如圖 17 所示。

 

 

(圖 17：任務事件依賴)

在解決跨系統(tǒng)之間的依賴問題，我們提供了 FTP 事件，即在 FTP 服務器上建立標識文件，一個事件對應一個標識文件地址，當 FTP 服務器上的標識文件生成的時候，我們認為業(yè)務系統(tǒng)已經完成作業(yè)，需要觸發(fā)平臺任務執(zhí)行。

因為 FTP 事件存在實時性和穩(wěn)定性的問題，即調度服務是不停的輪詢各個 FTP 事件服務器，當 FTP 服務器負荷較重，往往會連接超時，導致掃描文件標識延遲，進而導致下游任務延遲，我們對用戶系統(tǒng)了 API 事件，即業(yè)務系統(tǒng)作業(yè)完成后可以調用平臺的 API 接口，觸發(fā)下游任務執(zhí)行，解決了時效性和穩(wěn)定性的問題。

 

 

(圖 18：事件列表)

4.4 調度流控設計說明

做好多租戶隔離，執(zhí)行器資源隔離、內建流控，負載均衡和作業(yè)優(yōu)先級等機制

大多數的工作流調度系統(tǒng)，多租戶的隔離比較簡單，業(yè)務上租戶之間完全獨立，租戶之間的業(yè)務很難相互關聯。同一租戶的工作流方面也不能互相依賴和關聯。更多的考慮是物理資源層面的隔離，這個，多半通過獨立集群或者虛擬化的方案來解決，同一租戶內部，做得好的可能再考慮一下業(yè)務隊列管理。

我司的業(yè)務環(huán)境則不適合采取類似的方案，首先從業(yè)務的角度來說，不同的業(yè)務組(亦即租戶)，雖然管理的作業(yè)會有不同，但是往往不同租戶之間的作業(yè)，相互依賴關系復雜，犬牙交錯，變化也頻繁，基本不可能在物理集群或機器的層面進行隔離，業(yè)務組之間的人員流動，業(yè)務變更也比較頻繁。

其次在同一租戶業(yè)務內部，不同優(yōu)先級的任務，不同類型的任務，不同應用來源的任務，包括周期任務，一次性任務，失敗重試任務，歷史重刷任務等各種情況，也有不同的資源和流控管控需求。

目前本平臺在開發(fā)實踐中，主要從以下幾方面進行限流控制：

任務優(yōu)先級，任務分為高中低三個優(yōu)先級，分別對應底層 yarn 的資源調度不同的權重，高優(yōu)先級的優(yōu)先分配執(zhí)行機器和計算資源

系統(tǒng)調用和用戶補數據操作分開，平臺絕大部分的任務執(zhí)行都是依賴自身的調度周期執(zhí)行，無需用戶干涉，優(yōu)先保證這部分的任務的執(zhí)行資源;在某些業(yè)務場景下，需要對歷史數據進行彌補，通過指定運行的數據時間強制任務執(zhí)行，這類任務往往不是很緊急，可以將優(yōu)先級降低

失敗重試和用戶重跑優(yōu)先級高于系統(tǒng)調用的優(yōu)先級。當任務出現異常需要進行重跑或者重試，需要人工進行干預的情況下，一般屬于緊急情況，需要優(yōu)先保證這部分的任務的計算資源

部分任務可以設置固定時間，錯峰執(zhí)行，避免高峰時段的資源壓力

對于同一任務流內同一層級內部的多個任務，可以設置任務組，通過設置任務組的并發(fā)度來限制任務的并行個數，降低對業(yè)務系統(tǒng)的訪問壓力。這個往往在對分庫數據庫或者同一數據庫進行多任務訪問操作的時候，減輕業(yè)務數據庫的訪問壓力，可以限制任務的并行執(zhí)行個數

按照任務類型進行限流。平臺支持的任務類型很多，當底層對應的計算或者存儲資源壓力過大，可以限制某些類型的任務的并發(fā)個數，降低底層的計算壓力。這個限流可以做到平臺全局層面，也可以做到系統(tǒng)賬號層面。

可以為某些類型任務或者某個系統(tǒng)賬號下的任務指定固定的機器資源執(zhí)行，這樣可以降低大資源消耗任務對其他任務的資源搶占，保障特殊任務的資源需求，也可以進行部分賬號的任務的灰度發(fā)布，降低生產事故率

Worker 節(jié)點的被動負載反饋(負載高的情況拒絕接收任務)和主節(jié)點的主動負載均衡(輪詢和 Worker 節(jié)點并發(fā)數控制等策略)。在分配任務和領取任務方面都進行了任務隊列深度控制，防止過度分配和過度領取而導致分配不均而引起的任務堆積

4.5 系統(tǒng)高可用設計說明

系統(tǒng)高可用，組件模塊化，核心組件無狀態(tài)化

從系統(tǒng)架構的角度出發(fā)，模塊化的設計有利于功能隔離，降低組件耦合度和單個組件的復雜度，提升系統(tǒng)的可拓展性，一定程度上有利于提升系統(tǒng)穩(wěn)定性，但帶來的問題是開發(fā)調試會更加困難，從這個角度來說又不利于穩(wěn)定性的改進。所以各個功能模塊拆不拆，怎么拆往往是需要權衡考慮的。

平臺采用常見的主從式架構，按照功能模塊劃分清晰，職責單一而不緊耦合，避免繁重復雜的業(yè)務耦合設計。Master 節(jié)點負責作業(yè)計劃的管理和任務的調度分配，worker 節(jié)點負責具體任務的執(zhí)行。用戶通過 Web 控制后臺管理作業(yè)，而 Web 控制后臺與 Master 服務器之間的交互透過 Rest 服務來執(zhí)行，Rest 服務也可以給 Web 控制后臺以外的其它系統(tǒng)提供服務(用于支持外部系統(tǒng)和調度系統(tǒng)的對接)。平臺部署架構圖如圖 19 所示。

 

 

(圖 19：部署架構圖)

Master 調度除了引入 Quartz 的負責時間調度外，核心的就是任務實例在執(zhí)行過程中的狀態(tài)變化以及變化后觸發(fā)的操作邏輯。任務實例狀態(tài)的變化切換目前仿照 yarn 的狀態(tài)機實現原理，重新進行了改造封裝。這塊的核心組件受限研發(fā)時間和技術問題沒有做到無狀態(tài)。

這里所說的無狀態(tài)化，更多的強調的是各個調度組件運行時狀態(tài)的持久化，在組件崩潰重啟后，所有的運行時狀態(tài)都應該能夠通過外部持久化的數據中快速的恢復重建。

為了保證狀態(tài)的一致統(tǒng)一，平臺的所有作業(yè)和任務的信息變更，無論是用戶發(fā)起的作業(yè)配置修改，還是執(zhí)行器反饋的作業(yè)狀態(tài)變更，都會提交給 Master 節(jié)點同步寫入到數據庫。

在 HA 方面，按照準實時的設計目標，平臺并沒有打算做到秒級別的崩潰恢復速度，系統(tǒng)崩潰時，只要能在分鐘級別范圍內，重建系統(tǒng)狀態(tài)，就基本能滿足系統(tǒng)的設計目標需求。

所以其實高可用性設計的重點，關鍵在于重建的過程中，系統(tǒng)的狀態(tài)能否準確的恢復。比如，主節(jié)點崩潰或維護期間，發(fā)生狀態(tài)變更的任務在主節(jié)點恢復以后，能否正確更新狀態(tài)等等。而雙機熱備份無縫切換，目前來看實現難度較大(太多流程需要考慮原子操作，數據同步和避免競爭沖突)，實際需求也不強烈，通過監(jiān)控，自動重啟和雙機冷備的方式來加快系統(tǒng)重建速度，基本也就足夠了。

另外，為了提高系統(tǒng)局部維護/升級期間的系統(tǒng)可用性，平臺支持 Worker 節(jié)點的動態(tài)上下線，可以對 worker 節(jié)點進行滾動維護，當 Master 節(jié)點下線時，Worker 節(jié)點和 ZK 節(jié)點也會緩存任務的狀態(tài)變更信息，等到 Master 節(jié)點重新上線后再次匯報結果。所以一定程度上也能減少和規(guī)避系統(tǒng)不可用的時間。

4.6 任務失敗策略

支持任務失敗轉移、執(zhí)行機器資源發(fā)現和健康度評估

作業(yè)失敗的原因很多，有上游表數據不對、腳本配置錯誤等主要原因，也有一些臨時性的原因，比如網絡原因、外部 DB 負載原因，可能重試了就好了。所以，為了降低運維代價，我們需要可以支持相關重試策略的配置。當然，更加理想的情況是系統(tǒng)可以智能的根據失敗的原因自動采取不同的策略。

 

 

(圖 20：任務失敗重試配置)

 

 

(圖 21：任務失敗重試運行記錄)

4.7 任務運行分析設計說明

任務運行自助分析，對任務進行診斷分析，便于用戶發(fā)現和調整問題。

針對失敗的任務提供任務運行日志，方便查看出錯問題，識別常見的錯誤模式，明確的告訴用戶錯誤類型，如果可能，告知解決方案。

 

 

(圖 22：任務執(zhí)行日志)

針對成功的任務提供診斷信息，比如某個任務跑得慢，是因為 GC，還是數據量變化，是因為集群資源不夠，還是自身業(yè)務在某個環(huán)節(jié)被限流?各種情況下，用戶該如何應對解決，能否自動給出建議?此外，是否能夠定期自動診斷，及時提醒用戶，敦促用戶自主優(yōu)化?避免問題積壓到影響業(yè)務正常運行的時候才被關注。

目前我們自研了“華佗”平臺，可以針對在 hadoop 上執(zhí)行的 hive、mr、spark 任務進行運行診斷，對于出現 GC、數據傾斜、資源消耗等方面做出綜合的診斷。

 

 

(圖 23：任務運行診斷)

 

 

(圖 24：任務運行診斷詳情)

5. 現狀和未來

整體來說，本文前面所描述的設計目標，平臺基本上都已經實現了。經過 3 年的開發(fā)和持續(xù)改進過程，當前調度系統(tǒng)日常大概日均承載約 20 萬個周期調度作業(yè)，接入集團絕大部分的離線計算相關的開發(fā)任務。平臺目前趨于穩(wěn)定，由于系統(tǒng)自身原因造成的大規(guī)模系統(tǒng)故障已經非常罕見。

但是，由于前期平臺過分追求滿足用戶的離線作業(yè)需求，未考慮任務配置的合理性、優(yōu)先級和業(yè)務的關聯性以及任務之間的血緣關系等，在后期任務量快速上升的情況下，經常出現資源競爭激烈、任務小文件碎片化嚴重、任務變更影響和追蹤定位鏈路過長等等問題。另外在極端環(huán)境下，尤其是在高負載大流量情況下，遇到系統(tǒng)硬件，內存，DB 或網絡異常問題時，能否較好的進行容錯處理，還是需要經歷更多的復雜場景來加以磨練的。

未來，我們將從以下幾個方面進行優(yōu)化提升。

用戶層面

在保證現有平臺功能穩(wěn)定的基礎上，進一步豐富平臺的任務類型、任務參數、任務樣例、幫助手冊等，提高平臺的易用性
提供任務分析報表，可視化分析跟蹤任務的總體運行情況、調度資源、計算資源、健康度，更好的按不同維度（個人／系統(tǒng)／全局等）匯總展示給用戶，方便用戶隨時掌控和調整自身業(yè)務
提供任務異常的快速分析診斷能力，提高用戶的自運維能力
能夠定期自動診斷，及時提醒用戶，敦促用戶自主優(yōu)化。避免問題積壓到影響業(yè)務正常運行的時候才被關注。

調度層面

準實時調度，支持短周期任務，作業(yè)計劃的變更，即時生效
靈活的調度策略，觸發(fā)方式需要支持：時間觸發(fā)，依賴觸發(fā)或者混合觸發(fā)，支持多種依賴關系等
系統(tǒng)高可用，組件模塊化，核心組件無狀態(tài)化
支持用戶權限管理，能和各種周邊系統(tǒng)和底層存儲計算框架既有的權限體系靈活對接
做好多租戶隔離，內建流控，負載均衡和作業(yè)優(yōu)先級等機制
開放系統(tǒng)接口，對外提供 REST API，便于對接周邊系統(tǒng)

任務分析治理層面

系統(tǒng)整體業(yè)務健康度檢測和評估手段改進
業(yè)務診斷專家系統(tǒng)的改進
非標準任務的轉換和大任務流的拆分
優(yōu)化任務配置

6. 后續(xù)

我司的大數據離線任務開發(fā)調度平臺從設計、開發(fā)到上線運營經歷了很多問題，尤其是在第二次版本改造升級過程中，除了自身調研外，還參考和借鑒了一些其他產品的設計理念。平臺的部分設計內容和思想參考了 蘑菇街 劉旭輝的《大數據平臺調度系統(tǒng)架構理論和實踐》的相關內容，在此特別感謝劉旭輝的理論文章，同時也感謝參與平臺設計開發(fā)的每一位小伙伴的付出。

此次內容主要從理論層面講述蘇寧大數據離線平臺的設計和實踐，后續(xù)將對平臺內部的具體功能的詳細設計、關鍵代碼實現做一次分享，敬請期待。

作者：

桑強，蘇寧易購 IT 總部大數據平臺研發(fā)中心離線計算工具研發(fā)部經理。10 年軟件行業(yè)從業(yè)背景，13 年開始接觸大數據，有著 5 年多的大數據應用和平臺開發(fā)經驗�，F在負責蘇寧大數據基礎工具平臺的研發(fā)工作，主要包括離線計算工具、實時計算工具、數據資產與質量平臺的架構、研發(fā)和項目管理等工作。在對接大數據底層和大數據業(yè)務線之間，如何做好平臺工具化，降低用戶使用難度，支撐大數據應用的實踐和研發(fā)上有著豐富的研發(fā)經驗。

標簽： 安全 大數據 大數據基礎 大數據開發(fā) 大數據平臺 大數據應用 代碼 服務器 腳本 權限 權限管理 數據庫 網絡

版權申明：本站文章部分自網絡，如有侵權，請聯系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯系。