6.Group Dimension， 這是一個(gè)將維度進(jìn)行分組，以求達(dá)到降低維度組合數(shù)目的手段。不同分組的維度之間不會(huì)進(jìn)行組合計(jì)算。Group的優(yōu)化措施與查詢SQL緊密依賴，可以說是為了查詢的定制優(yōu)化。 維度組合從2的(k+m+n)次冪降低到 2的k次冪加2的m次冪加2的n次冪。如果查詢的維度是夸Group的，那么Kylin需要以較大的代價(jià)從N-Cuboid中聚合得到所需要的查詢結(jié)果
數(shù)據(jù)壓縮：
Kylin針對(duì)維度字典以及維度表快照采用了特殊的壓縮算法，保證存儲(chǔ)在Hbase以及內(nèi)存中的數(shù)據(jù)盡可能的小。 由于DataCube中會(huì)出現(xiàn)非常多的重復(fù)的維度值，因此直觀的做法就是利用數(shù)據(jù)字典的方式將維度值映射成ID， Kylin中采用了Trie樹的方式對(duì)維度值進(jìn)行編碼
distinct count聚合查詢優(yōu)化：
Kylin 采用了HypeLogLog的方式來計(jì)算Distinc Count。 好處是速度快，缺點(diǎn)是結(jié)果是一個(gè)近似值，會(huì)有一定的誤差。 具體的算法可見Paper： http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf 本文不再贅述。
kylin SQL查詢的實(shí)現(xiàn)
Kylin支持標(biāo)準(zhǔn)的ANSI SQL, Kylin的SQL語法解析依賴于另一個(gè)開源數(shù)據(jù)管理框架 Apache Calcite， Calcite即之前的Optiq，可以說是一個(gè)沒有存儲(chǔ)模塊的數(shù)據(jù)庫，即不管理數(shù)據(jù)存儲(chǔ)、不包含數(shù)據(jù)處理的算法，不包含元信息的存儲(chǔ)。因此它非常適合來做一個(gè)應(yīng)用到存儲(chǔ)引擎之間的中間層。在Calcite的基礎(chǔ)之上只要為存儲(chǔ)引擎寫一個(gè)專用的適配器(Adapter)即可形成一個(gè)功能豐富的支持DML的“類數(shù)據(jù)庫”。目前Calcite已在Hive、Drill、Phoenix項(xiàng)目中被使用。
Kylin完成了一個(gè)針對(duì)性的Calcite Adapter，在Calcite完成SQL解析，形成語法樹(AST)之后，Kylin定義語法樹各個(gè)節(jié)點(diǎn)的執(zhí)行規(guī)則，以及查詢優(yōu)化準(zhǔn)則。Calcite在遍歷語法樹節(jié)點(diǎn)后生成一個(gè)Kylin描述查詢模型的SQL Digest， Kylin會(huì)為此Digest去判斷是否有匹配的Cube。如果有與查詢匹配的Cube，即選擇一個(gè)查詢代價(jià)最小的Cube進(jìn)行查詢(Kylin Cube的查詢代價(jià)計(jì)算目前是一個(gè)開放接口，可以根據(jù)維度數(shù)目，可以根據(jù)數(shù)據(jù)量大小來計(jì)算Cost)
Kylin目前的多維數(shù)據(jù)存儲(chǔ)引擎是HBase， Kylin利用了HBase的Coprocessor機(jī)制在HBase的Region Server完成部分聚合以及過濾操作，在Hbase Scan時(shí)提前進(jìn)行計(jì)算，利用HBase多個(gè)Region Server的計(jì)算能力加速Kylin的SQL查詢。
再看kylin 與 RTOLAP
Kylin 可以說是與市面上流行的RTOLAP走了一條完全不同的道路。 Kylin在如何快速求得預(yù)計(jì)算結(jié)果，以及優(yōu)化查詢解析使得更多的查詢能用上預(yù)計(jì)算結(jié)果方面在優(yōu)化，后續(xù)Kylin的版本會(huì)優(yōu)化預(yù)計(jì)算速度，使得Kylin可以變成一個(gè)近似實(shí)時(shí)的分析引擎。然而其缺點(diǎn)就是SQL支持方面可能在一定程度上會(huì)有所犧牲，存儲(chǔ)開銷也會(huì)比較大， 而像Presto，SparkSQL，Hawq等是著重于優(yōu)化查詢數(shù)據(jù)的過程環(huán)節(jié)，像一些其它的數(shù)據(jù)倉庫一樣，使用列存、壓縮、并行查詢等技術(shù)，優(yōu)化查詢。這種方案的好處就在于擴(kuò)展性強(qiáng)、能適配更廣泛的查詢， 然而由于每次的聚合計(jì)算是 alt="物聯(lián)網(wǎng)" width="550" height="311" />
Kylin集群由多個(gè)查詢節(jié)點(diǎn)以及控制節(jié)點(diǎn)組成。 控制節(jié)點(diǎn)唯一，負(fù)責(zé)集群項(xiàng)目、任務(wù)調(diào)度與Cube增刪查改。 多個(gè)查詢節(jié)點(diǎn)前用Nginx做負(fù)載均衡，后段節(jié)點(diǎn)可按需水平擴(kuò)容。前端可同時(shí)支持JDBC與ODBC的客戶端查詢
Kylin性能表現(xiàn)
在Kylin上線前，我們針對(duì)NRPT的報(bào)表業(yè)務(wù)進(jìn)行過性能對(duì)比，對(duì)比內(nèi)容在相同的數(shù)據(jù)下、Kylin查詢與Mondrian 結(jié)合Oracle的查詢比較。 我們選取了數(shù)據(jù)量較大的DataStream報(bào)表業(yè)務(wù)進(jìn)行了測(cè)試：
再看Kylin的吞吐量，利用Haproxy進(jìn)行請(qǐng)求轉(zhuǎn)發(fā)后隨著Kylin服務(wù)器的增加吞吐量的表現(xiàn)：
根據(jù)測(cè)試結(jié)果可見，Kylin OLAP在性能上能達(dá)到秒級(jí)，并且在查詢吞吐量可以通過增加查詢服務(wù)器來達(dá)到線性擴(kuò)展的目的
網(wǎng)易對(duì)Kylin的改進(jìn)
原生的Kylin 是需要部署在一個(gè)統(tǒng)一底層的Hadoop、Hive、HBase集群之上的。而網(wǎng)易內(nèi)部的大數(shù)據(jù)平臺(tái)由于各種原因，分為了多個(gè)Hadoop集群、各應(yīng)用會(huì)在不同的Hadoop集群上建立Hive數(shù)據(jù)倉庫。 最原始而自然的想法就是在每一個(gè)Hadoop環(huán)境上部署一套Kylin服務(wù)來滿足不同的需求，但是集群資源管理、計(jì)算資源調(diào)度、管理運(yùn)維的復(fù)雜性都會(huì)是一個(gè)比較突出的問題。例如用戶數(shù)據(jù)在A機(jī)房的Hive上，而A機(jī)房的Hadoop集群并沒有足夠的計(jì)算資源來保證Kylin Olap的高效運(yùn)行。因此根據(jù)公司內(nèi)部實(shí)際的大數(shù)據(jù)平臺(tái)分布情況及機(jī)房建設(shè)情況，將Kylin打造成一個(gè)公司內(nèi)統(tǒng)一的服務(wù)平臺(tái)是一個(gè)更好的選擇。Olap小組對(duì)開源版本的Kylin進(jìn)行了二次開發(fā)，并將改進(jìn)補(bǔ)丁提交了社區(qū)。目前的改進(jìn)主要包括：