京東云海是由京東和ISV共同合作的模式對商家提供服務。云海提供基礎的京東POP(商家開放平臺)數據，包括商品、商家、客服績效、品牌、行業等主題數據，目前可提供T+1匯總計算結果，以及上百個實時指標訂閱。ISV通過商家授權可以獲取商家基礎數據，ISV通過JOS的API接口上傳相關維表數據，數據上傳到數據倉庫后，ISV可以在云海開放平臺上開發相關的Hive SQL對上傳數據和商家基礎數據進行關聯計算，計算結果可以通過數據開放API查詢，ISV獲取到數據后通過應用展現給商家使用。
需求場景一：JOS開放API調用情況分析（OLAP分析）
JOS開放接近500個API，每天調用量在7億次左右。針對API的調用情況進行多維分析，分析查詢延遲要求達到秒級，并使用BI工具進行分析展現。
JOS的API訪問日志數據通過定時抓取存儲在Hive數據倉庫中。所以需要一種能夠在大數據量情況下進行交互式多維分析的SQL on Hadoop引擎。并且要支持和BI工具的集成，提供標準的JDBC、ODBC接口。
需求場景二：云海結果數據下載（原始明細數據查詢）
云海通過JOS的API將結果表的數據查詢服務開放給ISV，開放服務中允許ISV定義標準SQL模板，在接口調用時傳遞不同參數來查詢數據，接口單次調用返回數據量限制為5000條，接口查詢延遲要保證在毫秒級別，并支持高并發調用。結果表數據存儲在Hive數據倉庫中。所以需要一種SQL on Hadoop引擎能夠支撐基于大表的原始明細數據毫秒級查詢。
關于Apache Kylin
現在開源社區各種優秀的SQL on Hadoop引擎不斷涌現，比如Impala，SparkSQL，Phoenix等等。但是針對于以上場景的考慮：大數據量情況下秒級多維分析、支持與傳統BI工具無縫集成、在大數據量基礎上使用標準SQL查詢小數據量結果集能夠達到毫秒級、完全基于Hadoop生態系統、T+1和實時處理數據、支持水平擴展等。最終我們把目標鎖定在了Apache Kylin。
Apache Kylin是一個開源的分布式分析引擎，提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持超大規模數據，能夠支持TB到PB級別的數據量，最初由eBay Inc開發并于2014年10月貢獻至開源社區，于2014年11月加入Apache孵化器項目，于今年11月正式畢業成為Apache 頂級項目。
Apache Kylin旨在減少Hadoop在10億及百億規模以上數據級別的情況下的查詢延遲，目前底層數據存儲基于HBase，具有較強的可伸縮性。Apache Kylin為Hadoop數據提供了ANSI-SQL接口，并且支持大多數的ANSI-SQL的函數；能夠支持在秒級別延遲的情況下同Hadoop進行交互式查詢；支持多維聯機分析處理數據倉庫（MOLAP Cube）；用戶能夠定義數據模型；并且通過Apache Kylin能夠預建超過10多億行原始數據記錄的數據模型；可與其他BI工具無縫集成，包括Tableau，Excel，PowerBI等；并提供了JDBC，ODBC接口；可分布式部署，Query Server可以水平擴展，存儲基于HBase也可以水平擴展。并且Apache Kylin將在后續版本支持流式近實時Cube計算，支持實時數據多維分析等各種場景。
更多關于Apache Kylin的詳細信息可以訪問：http://kylin.io
Apache Kylin在京東云海的應用部署及性能
系統架構及集群部署
Apache Kylin集群：
- 1個任務服務器，4個查詢服務器。
- Apache HBase集群規模：
- 27個節點，和其他業務共用。
- 兩種場景使用同一個集群。
模塊關系圖：
部署圖：
Apache Kylin性能表現：
1.OLAP分析
單個Cube最大維度16個，最大數據條數100億，最大存儲空間400G。
性能：數據分析人員采用BI工具進行查詢，95%的查詢響應時間在15秒以內。
2.原始明細數據查詢
單個Cube最大維度8個，最大數據條數4億，最大存儲空間800G。30個Cube占用總空間4T左右。
性能：單次查詢返回數據條數限制在5000條以內，查詢QPS在50左右，所有查詢平均響應時間200ms，查詢QPS在200左右平均響應時間可以保持在1s以內。
查詢的并發能力和響應時間和HBase集群規模有關，這兩個場景的數據只使用了一個小集群，可以對Apache Kylin Query Server和HBase集群水平擴容來提高并發查詢能力和減小響應時間。
Apache Kylin原不支持此功能，京東對其實現邏輯做了修改，并已經貢獻回社區。
京東對于Apache Kylin的二次開發
主要的改造是增加了支持原始明細數據查詢的實現。
Apache Kylin在使用SQL查詢時，至少需要指定一個Group by條件，在類似Select dimension_column1,measure_column2,measure_column3 from fact_table這種包含指標列明細數據的查詢時不能返回結果。
由于Apache Kylin的Cube計算是根據所有聚合維度的組合計算定義指標的值，在Cube定義階段必須包含聚合維度和計算指標的配置。計算指標目前包括SUM，MAX，MIN，COUNT，COUNT_DISTINCT。
由此想要實現原始數據的查詢有以下方案：
方案一
在原始數據表中增加一列唯一值列，并將所有列都配置為維度列，如果某列的基數非常高，則不創建字典指定固定列長度的方式設置維度屬性。這樣的Cube計算結果相當于對唯一值列進行Group by，會查詢到所有行的值。
方案的優點：不用修改Apache Kylin代碼，只需要處理原始數據增加唯一列即可。
方案的缺點：雖然是支持了原始明細數據的查詢，但是所有列都作為了維度聚合，在原始表列的數量非常多的情況下，Cube的大小會膨脹的非常大，構建時間增長。所以需要更優的方法來處理。
方案二
1、在原始數據表中增加一列唯一值列，并把此列配置在維度中。
2、修改源碼增加一個新的聚合函數，此聚合函數的輸入和輸出保持相同，不做任何聚合計算。通過這個聚合函數和對唯一列的聚合來保證每一個指標列的原始值都能被獲取到。由于Apache Kylin本身帶有的聚合函數只支持數字類型的列，所以需要增加新的聚合函數支持所有數據類型的輸入和輸出。這樣能夠減少不必要的維度組合，減小Cube的大小，縮短構建的時間。
方案的優點：能夠解決方案一中Cube膨脹的問題和構建時間長的問題。
方案的缺點：如果數據表中不存在唯一列的情況時，不能夠查詢到所有的明細數據。更好的解決方案是在沒有唯一列的情況下同樣也能夠支持明細數據查詢。
我們是對方案二進行了實現，并且將Patch貢獻回社區，目前正在和社區一起優化：即方案三。
方案三
1、不需要在原始表中增加唯一列。
2、修改源碼增加新的聚合函數，此聚合函數能使被聚合的明細數據存儲在HBase中的一行。在查詢時將數據進行展開。
3、修改源碼增加對聚合函數值的字典支持，以減少存儲數據大小。
此方案是改進方案，我們正在和社區共同進行優化改造，請關注KYLIN-1122以跟蹤最新進展。
使用Apache Kylin的實踐總結
1、大的事實表采用天分區增量構建，為了不影響查詢性能，可以定期做合并(Merge)，周期可以根據實際情況確定，我們一周進行一次合并。
2、對于維表比較大的情況，或者查詢Select部分存在復雜的邏輯判斷，存在Apache Kylin不支持的函數或語句時，可以將事實表和維表的關聯處理創建為Hive視圖，之后根據視圖創建Cube模型。
3、每次查詢必然帶有的條件建議在字典設置步驟將其設置為Mandatory。這樣會最終 Build出來Cube的大小會減少一半。
4、Cube的維度如果超過10個，建議將常用的聚合字段做分組，我們對于最大的16個維度分了三個組，每組大概在5個維度左右。
5、Cube定義中RowKey順序：Mandatory維度，Where過濾條件中出現頻率較多的維度，高基數維度，低基數維度。
6、對于Hierarchies，Derived維度方面配置優化可以參考社區文檔：http://kylin.incubator.apache.org/docs/howto/howto_optimize_cubes.html
7、部署層面，可以通過Nginx在前端做負載均衡，后端啟動多個Query Server接收查詢請求處理。
名詞解釋：
云海：京東云海數據開放平臺
ISV ：與京東云合作的第三方服務廠商
JOS：京東API開放服務
關于作者：王曉雨，Apache Kylin Committer，京東大數據資深架構師，北京郵電大學軟件工程碩士，2014年加入京東云平臺-數據平臺部，參與京東公有云數據分析平臺的整體架構設計及開發，致力于對客戶提供云上的實時數據倉庫的探索。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
相關文章
