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