摘要: 對於剛剛成長起來的京東大數據平台來說,數據產品並不是一個新鮮事物,2011年自建數據倉庫上線的同時,第一款數據產品調度平台也一同上線並正式投入使用。在Tiger的指導下,調度平台無論是UI、功能還是用戶體驗各方...
 

 

調度平台

訂單交易,倉儲物流等眾多京東系統都會產生數據,僅日誌內容每天的大小約為100TB,大量的數據如何統一匯總到數據倉庫來呢?這就需要調度產品來實現數據 生產。京東調度平台發展至今已經是3.0版本,每一次的更新迭代都凝聚著阿敏等幾位開發工程師的許許多多個日夜的心血,也是我們技術突破與功能升級的具體體現。

 

調度平台1.0版本架構


1.0 版本於2011年8月上線,一台服務器作為中心節點指揮調度,另外3台服務器負責相關數據作業,任務之間通過後置變量的方式設定前後依賴關係,調度機制便運行起來了。數據倉庫建立之初的任務並不太多,數據量沒有太過龐大,數據ETL過程所需計算資源也都完全應付得來。但隨著倉庫收納數據的增加,數據生產任務越來越多,任務之間的依賴關係也變得越來越複雜。每個BI工程師需要根據自己的生產任務設定後置變量的值以建立任務依賴關係,任務多了之後不但設置起來耗時費力且不易管理,當一個人的任務需要重跑時後置變量的修改可能會影響到別人的任務。


2.0 版本上線了新的調度引擎,徹底解決了這個問題。新任務上線只需要選擇依賴的父任務即可建立關係,且流程獨立,不會因同一個任務被多個依賴而造成乾擾。除此之外,任務可視化配置與瀏覽功能也在這個版本上線,任務運行狀態監控預警功能也投入使用。這之後的功能升級也一直在進行,較大的功能改進莫過於虛擬節點了。數據生產過程中,儘管機率很低,但仍然還是會出現一些物理節點掛掉的情況,而這種情況一旦出現,影響將會很嚴重。於是,虛擬節點的功能應運而生,原理就是在原來的物理機集群上做一層虛擬化,如果遇到生產節點故障的情況自動切換到另一個節點。同時,根據不同節點的負荷,將新的任務自動分配到負荷較小的節點,做到負載均衡。這一系列功能的上線使得平台的穩定性大大提高。


3.0版本從功能上更加豐富,並且實現了數據生產的半自動化運行機制。所謂的半自動化是指數據任務可在配置目標數據庫、表之後自動生成ETL模板並完成數據清洗,之後是人工創建調度任務完成數據生產。另外,自主研發的抽數模塊Plumber也在這個版本中上線,Plumber技術實現了異構數據庫之間的快速數據交換,且具有較高的穩定性,數據導入導出的維護成本也大大降低。還有服務器運行狀態的監控系統Phenix也集成到了調度監控中,實時採集服務器運行狀態數據並對服務器心跳、存儲空間使用、CPU資源消耗等進行預警。對於上游系統故障造成的歷史數據補充問題,之前的版本中需要人工查找相關依賴任務,然後一個一個配置參數後點擊重跑,而在新的版本中BI工程師們期待已久的一鍵重跑功能上線了,並且支持批量操作。一千多個重跑任務,BI工程師加班到半夜一個一個點鼠標的日子永遠成為了過去。
作為大數據平台的核心系統,調度平台不僅承擔著數據生產的重要使命,同時也負責集市數據推送,模型數據加工等任務,部門有超過三分之一的人都在圍著它轉,重要性可想而知。今後的功能升級迭代將在增強生產能力的同時更加註重自動化服務及開放運營等平台產品的特性,為大數據管理及挖掘大數據價值提供可靠保障。

 

數據集成開發平台


數據集成開發平台是京東大數據發展的一個里程碑產品,它的出現結束了數據分析師和業務部門數據需求人員通過客戶端工具手工提取數據的痛苦經歷,並對後來的數據知識管理平台等產品的出現產生直接影響。當前平台用戶接近3000人,數據訂閱任務總量逾8萬個。
早期版本的數據集成開發平台就是命名為提數工具,提數也是當時寄予這款產品的最重要的期望。相信每一家公司對於數據的需求都是“剛需”,快速發展的京東,流動並且快速流動的數據更是像一個人身體裡的血液一樣不可或缺。毫無疑問,數據提取的任務由數據部來承擔,無論是拆分狀態時還是合併一體時的數據部,數據分析師總是最繁忙的,每到月初需要支持財務經營分析的人員提取數據時,還要拉上不少工​​程師共同參與這場提數大戰。前後台數據部拆分狀態時的最後幾個月裡,財務經營分析的數據提取任務幾乎被平均的分到了這兩個部門,每到月初,提數情況便成了兩個部門最直接的競爭內容,完成的不錯的話業務方可能會發個感謝信,當然,就算不提出批評,完成的不好的部門也會覺得很沒面子。前後台數據部合併後最瘋狂日子裡,數據部實行“全員提數”,業務方通過公司的服務管理平台發起數據提取需求,部門內幾名負責人會將需求分配給不同的人來處理。一段時間內,數據提取的數量和難易度甚至與績效考核掛鉤,提數,成了大家工作中非常重要的一部分。

正是在這樣的背景下,數據集成開發平台的1.0版本誕生了。這是一款查詢數據並且支持週期性數據訂閱的產品,同時打通了京東私有云服務Jbox,可以供已授權人員安全、便捷的查詢和提取數據,尤其對於需要定期提取大量數據做分析的人員(如財務經營分析同事)有很大幫助。功能上來講,通過Web端在線數據查詢和數據訂閱是兩大主要功能,同時,SQL編寫界面還支持元數據信息的查看,並且可以在線保存編輯中的代碼,這給提數人員帶來很大便利。底層接入的數據庫包括當時存在的SQL Server、MySQL和Hive,SQL語法上根據不同的數據庫類型選擇不同的語法即可,其它執行邏輯都是一樣的。產品開發主要由彥偉團隊負責,從初期版本上線到後​​期功能升級,Tiger也給出了很多極具參考價值的意見,不斷完善的產品吸引了大量用戶的註冊使用。

同樣採用Extjs的前端頁面偶爾存在一些滾動條失靈的小Bug,這給用戶體驗上帶來一定影響。另外,雖然Extjs強大的表單功能成就了集成開發平台這樣的富客戶端應用,但是其UI風格的局限性也是非常明顯的。隨著後期產品線的豐富,新推出的產品已經棄用Extjs,轉而採用Bootstrap前端,於是在2014年7月份,採用新的前端技術,數據集成開發平台與後期推出的數據知識管理及數據質量監控產品融合後統一在一個系統上線。

 

數據知識管理平台


數據知識管理平台產品的出現是個水到渠成的結果,在數據倉庫模型規範確定之後,元數據信息也有了標準的分類體系。按照標準的分類體係將元數據信息分門別類管理起來,同時提供內容搜索、類Wiki的編輯維護以及諮詢評論功能,數據知識管理平台就呈現在大家面前了。後期版本升級過程中又提供了維度表的維護功能, 給模型開發維護的同事帶來很大便利。

 

京東分析師


Apricot(杏子)、Blueberry(藍莓)、Cloudberry(雲莓),水果連連看?不,這是報表展現平台三個版本命名的代號,也是產品域名的首段字符串,首字母分別是ABC也代表了產品演進的過程。當前版本代號為Cloudberry,產品正式名稱為京東分析師,毫無疑問,我們賦予這款產品的除了基本的數據可視化能力,還有數據分析的能力。體驗過Tableau的用戶都會被其靈活的控制台和美妙絕倫的圖表展現所征服。我們所做的就是在Web系統中盡可能的實現Tableau桌面系統所能達到的效果,並且在產品服務能力上更加強調自助服務的智能軟件分析平台。
技術架構上,京東分析師前端自主開發可自定義的展現佈局,封裝了豐富的圖表展現組件,後端報表配置系統支持MySQL、SQL Server、Oracle、API及Hive等作為數據源,並支持在線接入。交互方面,報表收藏、基於圖表的條件過濾、數據排序、深度鑽取是其基本功能,自定義報表頁面還提供郵件推送報表的功能,當某個報表數據比較重要,系統可通過郵件的形式定期發送報表供查閱。對於自己權限範圍內可瀏覽的表,系統還可根據瀏覽記錄將經常查看的表排在靠前的位置以提升體驗。

 

數據挖掘平台


大數據的數據挖掘與傳統意義上的處理方法存在很大區別,京東數據挖掘平台產品定位於構建一站式的數據挖掘算法平台;在基礎的機器學習算法之上,可根據具體實際業務開發訂制算法,滿足算法應用場景。這一產品主要利用分佈式計算,採取適用於機器學習算法的計算模型進行迭代,以解決大數據量的算法處理問題。

 

數據挖掘平台架構

為減少數據實體化的開銷,挖掘平台採用基於內存的存儲引擎,集群資源調度與管理基於Hadoop Yarn框架,保證了集群計算性能的高可利用性和高可擴展性。平台自2014年年中正式推出後,已經開始為廣告系統、推薦系統等提供個性化的數據挖掘算法服務。

數據質量監控平台

數據的及時性、準確性和完整性關係到一系列數據應用的效果,大數據平台建設之初便已著手實施數據治理的相關工作,統一數據計算口徑,設置數據校驗規則,以保證數據質量數據倉庫升級之後,對於數據質量的關注程度更高,於是便從產品層面進行管理。從數據生產過程來看,數據質量監控平台的基本功能包括數據生產過程中的質量檢驗、數據入庫後的質量評估以及全部生產日誌的掃描存檔並生成數據質量分析報告。數據生產過程中的質量監控主要對數據生產中源表結構的變化、字段信息的一致性進行規則校驗,並依據校驗結果進行質量評估,對存在質量問題的數據將進行自動重跑並通知後續依賴任務。入庫之後的數據將進行具體到字段粒度的數據檢查,可以對枚舉值、字段類型,甚至數值型字段的最大最小值及均值等進行規則校驗,以確定數據是否在合理的範圍內變化

 


留下你的回應

以訪客張貼回應

0

在此對話中的人們

熱門標籤雲

每月文章