設計目標

       傳統的離線計算會存在資料反饋不及時，很難保證很多急需實時資料做決策的場景。同時，如果各個業務方自己既負責開發實現各種實時計算程式，同時還需要維護一套實時計算軟體環境，不僅效率低效，對公司的開發資源、硬體資源也是極大的浪費。所以為公司提供統一的實時計算平臺，提升業務團隊開發效率，滿足公司各種精細化運營、監控等的要求，我們近期啟動**實時計算平臺的建設工作。

整體架構

設計要點

• 許可權認證

     沿用離線計算平臺的許可權體系，通過LDAP認證提交任務的使用者是否合法。驗證過程在任務提交前進行，通過呼叫ddw-api的介面實現。需要擴充套件欄位表明是否給該賬號開通了提交實時任務的許可權，防止任何賬號都可以提交。（賬號合法->未禁用->實時許可權->passed）

• 資源隔離

          使用YARN作為資源管理，主要考慮是其本身可與現有許可權體系配合，同時很多分散式程式包括Spark，Storm等都提供了on YARN的部署形式。而由於目前的現狀是所有離線任務都跑在YARN上面，如果僅僅只是將Spark Streaming任務提交上去，勢必會出現離線實時任務混合執行在一起，極易出現資源爭搶而影響實時任務。線上叢集採用的CDH版本，無法使用社群版基於標籤的資源排程方式。

          目前採用的方案是對FairScheduler演算法進行擴充套件，具體方式是所有實時任務提交的時候均用特殊標誌指定到特殊的queue中，同時傳入的引數會告訴RM需要用到哪幾臺機器給其分配資源。如果不是特殊標誌的，統一分配到離線計算專用的一組機器為其分配資源。比如ddw_admin賬號在執行離線計算的時候，提交的queue就是root.ddw_admin, 而如果提交實時任務，提交的queue則為root.spark_ddw_admin。在ddw-ui介面中會維護離線計算的節點和實時計算的節點列表，RM會通過api定期獲取到離線節點列表。實時計算節點列表是每個實時任務提交的時候通過spark.yarn.applicationTags引數傳入的。

           這樣做以後，就可以將離線計算所用資源和離線計算所用資源從物理上隔離開。對於由統一入口提交的實時任務，都會通過其group_code和token生成一個signature，格式為group_code#hash(group_code,token,key)，key為排程服務端寫死的一個字串，這樣做的目的是便於以後好清理非法繞過統一提交入口的行為。

• 部署上線  

          目前大資料平臺幾乎所有定時任務都通過平臺自身的任務排程模組完成。為了統一，對於實時計算任務也會採用任務排程模組進行配置、部署和釋出。但實時計算任務與之前其他任務的相關配置等都會有所差異，需要單獨設計表儲存任務元資訊和執行歷史等。業務方將內容打包成一個uber jar（即包含相關依賴），然後上傳到hdfs，配置任務的時候關聯到對應的執行包。

          由於cdh版本的spark為1.6，目前線上主要提供給搜尋推薦團隊跑離線任務。實時計算到時會消費業務系統依賴的kafka叢集（0.8.2.1）和大資料平臺kafka叢集（0.9.0.0），目前的鑑權均是依賴dmg的鑑權，如果採用cdh版本spark，無法達到消費不同kafka叢集的目的。通過調研，決定採用社群版本spark 2.1作為實時計算的主版本（正好相容dmg sdk客戶端），通過一定技術手段達到了在同一套hadoop叢集上同時支援多套不同需求的spark，也為後期進行版本升級改造提供可能。

• 日誌監控

           對於Spark Streaming on YARN方式，當任務正常提交後，會存在一個監控UI頁面，通過該入口可以清晰知道任務執行情況，相關環境引數等。比如我們的yarn管理頁面為 http://192.168.17.216:8088, 某個Spark Streaming任務id為application_1489730282529_0001, 則可通過 http://192.168.17.216:8088/proxy/application_1489730282529_0001/streaming|[jobs]|[stages]|[environments]|[executors]檢視到相關資訊。同時Spark提供了部分RESTFul介面，我們也可以通過它獲取到部分資訊。需要考慮如何將這部分監控日誌等資訊整合進ddw-ui，採用儘可能低的技術複雜度、儘可能簡單的後期維護方式和儘可能易用的展現形式。

• 多執行引擎

          一期我們僅僅支援Spark Streaming實時任務，基於Spark 2.1。後面會根據業務情況對其他Spark版本提供支援，也會對其他執行引擎比如JStorm|Storm on YARN提供統一的接入方式。為了儘可能降低學習成本和開發複雜度，我們也會持續關注Apache Beam的相關進展，後面可以根據實際情況引入，這樣可以採用統一的程式設計介面，在不同執行引擎間進行方便切換。

• SQL  Layer

          Hive的出現極大方便了人們對結構化大資料的處理，不需要任何簡單的統計都自己從頭開發MapReduce程式來完成。對於實時計算任務也存在同樣的問題，有時可能僅僅是簡單的需求，還是需要開發對應的實時計算程式，對業務方來說是挺麻煩的。好在目前實時計算引擎均逐步在開發基於自身的SQL Layer，如華為的StreamSQL，騰訊的EasyCount，Spark的Structure Streaming，阿里的JStorm等。後期也會針對部分簡單的實時統計需求，通過介面元件固化生成任務，然後上線執行。

參考文章