Kylin的背景

Kylin 是一個Hadoop生態圈下的MOLAP系統，是ebay大資料部門從2014年開始研發的支援TB到PB級別資料量的分散式Olap分析引擎。其特點包括:

可擴充套件的超快的OLAP引擎

提供ANSI-SQL介面

互動式查詢能力

MOLAP Cube 的概念

與BI工具可無縫整合

Kylin典型的應用場景如下：

使用者資料存在於Hadoop HDFS中，利用Hive將HDFS檔案資料以關係資料方式存取，資料量巨大，在500G以上

每天有數G甚至數十G的資料增量匯入

有10個左右為固定的分析維度

Kylin的核心思想是利用空間換時間，由於查詢方面制定了多種靈活的策略，進一步提高空間的利用率，使得這樣的平衡策略在應用中是值得采用的。

kylin的總體架構

Kylin 作為一個Olap引擎完成了從資料來源抓取資料，ETL到自己的儲存引擎，提供REST服務等一系列工作，其架構如圖所示：

Kylin 大資料時代的OLAP利器

Kylin 的生態圈包括：

Kylin Core: Kylin 引擎的框架，查詢、任務、以及儲存引擎都集中於此，除此之外還包括一個REST 伺服器來響應各種客戶端請求。

擴充套件外掛: 各種提供額外特性的外掛，如安全認證、SSO等

完整性元件: Job管理器，ETL、監控以及報警

互動介面: 基於Kylin Core之上的使用者互動介面

驅動: 提供了JDBC以及ODBC的連線方式

kylin Cube 多維資料的計算

Kylin的多維計算主要是體現在OLAP Cube的計算。Cube由多個Cuboid組合而成，Cuboid上的資料是原始資料聚合的資料，因此建立Cube可以看作是在原始資料匯入時做的一個預計算預處理的過程。Kylin的強大之處在於充分利用了Hadoop的MapReduce並行處理的能力，高效處理匯入的資料。

Kylin的資料來自於Hive，並作為一個Hive的加速器希望最終的查詢SQL類似於直接在Hive上查詢。因此Kylin在建立Cube的時候需要從Hive獲取Hive表的元資料。雖然有建立Cube的過程，但是並不想對普通的查詢使用者暴露Cube的存在。

Kylin建立Cube的過程如下圖所示：

Kylin 大資料時代的OLAP利器

根據Cube定義的事實表以及維度表，利用Hive建立一張寬表

抽取事實表上的維度的distinct值，將事實表上的維度以字典樹方式壓縮編碼成目錄，將維度表以字典樹的方式編碼

利用MapReduce從第一步得到的寬表文件作為輸入，建立 N－Dimension cuboid，然後每次根據前一步的結果序列生成 N-1 cuboid, N-2 cuboid … 0-Cuboid

根據生成的Cuboid資料量計算HTable的Region分割策略，建立HTable，將HFile匯入進來

Kylin與傳統的OLAP一樣，無法應對資料Update的情況（更新資料會導致Cube的失效，需要重建整個Cube）。面對每天甚至每兩個小時這樣固定週期的增量資料，Kylin使用了一種增量Cubing技術來進行快速響應。

Kylin的Cube可以根據時間段劃分成多個Segment。在Cube第一次Build完成之後會有一個Segment，在每次增量Build後會產生一個新的Segment。增量Cubing依賴已有的Cube Segments和增量的原始資料。增量Cubing的步驟和新建 Cube的步驟類似，Segment之間以時間段進行區分。

增量Cubing所需要面對的原始資料量更小，因此增量Cubing的速度是非常快的。然而隨著Cube Segments的數目增加，一定程度上會影響到查詢的進行，所以在Segments數目到一定數量後可能需要進行Cube Segments的合併操作，實際上merge cube是合成了一個新的大的Cube Segment來替代，Merge操作是一個非同步的線上操作，不會對前端的查詢業務產生影響。。

Olap全稱為線上聯機分析應用，是一種對於多維資料分析查詢的解決方案。 典型的Olap應用場景包括銷售、市場、管理等商務報表，預算決算，經濟報表等等。

1. Olap簡介Olap的歷史與基本概念

Olap全稱為線上聯機分析應用，是一種對於多維資料分析查詢的解決方案。 典型的Olap應用場景包括銷售、市場、管理等商務報表，預算決算，經濟報表等等。

最早的Olap查詢工具是釋出於1970年的Express，然而完整的Olap概念是在1993年由關係資料庫之父 Edgar F.Codd 提出，伴隨而來的是著名的“twelve laws of online analytical processing”. 1998年微軟釋出 Microsoft Analysis Services， 並且在早一年透過OLE DB for OLAP API引入MDX查詢語言，2001年微軟和Hyperion釋出的XML for Analysis 成為了事實上的OLAP查詢標準。 如今，MDX已成為與SQL旗鼓相當的OLAP 查詢語言，被各家OLAP廠商先後支援。

Olap Cube是一種典型的多維資料分析技術，Cube本身可以認為是不同維度資料組成的dataset，一個Olap Cube 可以擁有多個維度（Dimension），以及多個事實（Fact or Measure）。使用者透過Olap工具從多個角度來進行資料的多維分析。通常認為Olap包括三種基本的分析操作： 上卷（rollup）、下鑽（drill down）、切片切塊（slicing and dicing），原始資料經過聚合以及整理後變成一個或多個維度的檢視。

ROLAP和MOLAP

傳統OLAP根據資料儲存方式的不同分為ROLAP（relational olap）以及MOLAP（multi-dimension olap）

ROLAP 以關係模型的方式儲存用作多維分析用的資料，優點在於儲存體積小，查詢方式靈活，然而缺點也顯而易見，每次查詢都需要對資料進行聚合計算，為了改善短板，ROLAP使用了列存、並行查詢、查詢最佳化、點陣圖索引等技術

MOLAP 將分析用的資料物理上儲存為多維陣列的形式，形成CUBE結構。維度的屬性值對映成多維陣列的下標或者下標範圍，事實以多維陣列的值儲存在陣列單元中，優勢是查詢快速，缺點是資料量不容易控制，可能會出現維度爆炸的問題。

大資料時代Olap的挑戰

近二十年內，ROLAP技術隨著MPP並行資料庫技術的發展，尤其是列存技術的支援下，實現了分析能力大幅度的跨越提升，同時伴隨著記憶體成本的進一步降低，單節點記憶體擴充套件性增強，叢集單節點的查詢效能實現了飛躍，記憶體資料庫的實用性跨上了一個新臺階，這些技術進步共同作用的結果是類似的技術基本覆蓋了TB級別的資料分析需求。 Hadoop以及相關大資料技術的出現提供了一個幾近無限擴充套件的資料平臺，在相關技術的支援下，各個應用的資料已突破了傳統OLAP所能支援的容量上界。每天千萬、數億條的資料，提供若干維度的分析模型，大資料OLAP最迫切所要解決的問題就是大量實時運算導致的響應時間遲滯。

2. Apache Kylin 大資料下的Olap解決方案Kylin的背景

Kylin 是一個Hadoop生態圈下的MOLAP系統，是ebay大資料部門從2014年開始研發的支援TB到PB級別資料量的分散式Olap分析引擎。其特點包括:

可擴充套件的超快的OLAP引擎提供ANSI-SQL介面互動式查詢能力MOLAP Cube 的概念與BI工具可無縫整合

Kylin典型的應用場景如下：

使用者資料存在於Hadoop HDFS中，利用Hive將HDFS檔案資料以關係資料方式存取，資料量巨大，在500G以上每天有數G甚至數十G的資料增量匯入有10個左右為固定的分析維度

Kylin的核心思想是利用空間換時間，由於查詢方面制定了多種靈活的策略，進一步提高空間的利用率，使得這樣的平衡策略在應用中是值得采用的。

kylin的總體架構

Kylin 作為一個Olap引擎完成了從資料來源抓取資料，ETL到自己的儲存引擎，提供REST服務等一系列工作，其架構如圖所示：

Kylin 的生態圈包括：

Kylin Core: Kylin 引擎的框架，查詢、任務、以及儲存引擎都集中於此，除此之外還包括一個REST 伺服器來響應各種客戶端請求。擴充套件外掛: 各種提供額外特性的外掛，如安全認證、SSO等完整性元件: Job管理器，ETL、監控以及報警互動介面: 基於Kylin Core之上的使用者互動介面驅動: 提供了JDBC以及ODBC的連線方式

kylin Cube 多維資料的計算

Kylin的多維計算主要是體現在OLAP Cube的計算。Cube由多個Cuboid組合而成，Cuboid上的資料是原始資料聚合的資料，因此建立Cube可以看作是在原始資料匯入時做的一個預計算預處理的過程。Kylin的強大之處在於充分利用了Hadoop的MapReduce並行處理的能力，高效處理匯入的資料。

Kylin的資料來自於Hive，並作為一個Hive的加速器希望最終的查詢SQL類似於直接在Hive上查詢。因此Kylin在建立Cube的時候需要從Hive獲取Hive表的元資料。雖然有建立Cube的過程，但是並不想對普通的查詢使用者暴露Cube的存在。

Kylin建立Cube的過程如下圖所示：

根據Cube定義的事實表以及維度表，利用Hive建立一張寬表抽取事實表上的維度的distinct值，將事實表上的維度以字典樹方式壓縮編碼成目錄，將維度表以字典樹的方式編碼利用MapReduce從第一步得到的寬表文件作為輸入，建立 N－Dimension cuboid，然後每次根據前一步的結果序列生成 N-1 cuboid, N-2 cuboid … 0-Cuboid根據生成的Cuboid資料量計算HTable的Region分割策略，建立HTable，將HFile匯入進來

Kylin與傳統的OLAP一樣，無法應對資料Update的情況（更新資料會導致Cube的失效，需要重建整個Cube）。面對每天甚至每兩個小時這樣固定週期的增量資料，Kylin使用了一種增量Cubing技術來進行快速響應。

Kylin的Cube可以根據時間段劃分成多個Segment。在Cube第一次Build完成之後會有一個Segment，在每次增量Build後會產生一個新的Segment。增量Cubing依賴已有的Cube Segments和增量的原始資料。增量Cubing的步驟和新建 Cube的步驟類似，Segment之間以時間段進行區分。

增量Cubing所需要面對的原始資料量更小，因此增量Cubing的速度是非常快的。然而隨著Cube Segments的數目增加，一定程度上會影響到查詢的進行，所以在Segments數目到一定數量後可能需要進行Cube Segments的合併操作，實際上merge cube是合成了一個新的大的Cube Segment來替代，Merge操作是一個非同步的線上操作，不會對前端的查詢業務產生影響。。

合併操作步驟如下：

遍歷指定的Cube Segment合併維度字典目錄和維度錶快照利用MapReduce合併他們的 N-Dimension cuboid將cuboid轉換成HFile，生成新的HTable，替代原有的多個HTable

Kylin對傳統MOLAP的改進

計算Cube的儲存代價以及計算代價都是比較大的， 傳統OLAP的維度爆炸的問題Kylin也一樣會遇到。 Kylin提供給使用者一些最佳化措施，在一定程度上能降低維度爆炸的問題：

Cube 最佳化：Hierachy DimensionDerived DimensionGroup Dimensions

Hierachy Dimension， 一系列具有層次關係的Dimension組成一個Hierachy， 比如年、月、日組成了一個Hierachy， 在Cube中，如果不設定Hierarchy， 會有 年、月、日、年月、年日、月日 6個cuboid， 但是設定了Hierarchy之後Cuboid增加了一個約束，希望低Level的Dimension一定要伴隨高Level的Dimension 一起出現。設定了Hierachy Dimension 能使得需要計算的維度組合減少一半。

Derived Dimension, 如果在某張維度表上有多個維度，那麼可以將其設定為Derived Dimension， 在Kylin內部會將其統一用維度表的主鍵來替換，以此來達到降低維度組合的數目，當然在一定程度上Derived Dimension 會降低查詢效率，在查詢時，Kylin使用維度表主鍵進行聚合後，再透過主鍵和真正維度列的對映關係做一次轉換，在Kylin內部再對結果集做一次聚合後返回給使用者

Group Dimension， 這是一個將維度進行分組，以求達到降低維度組合數目的手段。不同分組的維度之間不會進行組合計算。Group的最佳化措施與查詢SQL緊密依賴，可以說是為了查詢的定製最佳化。 維度組合從2的（k+m+n）次冪降低到 2的k次冪加2的m次冪加2的n次冪。如果查詢的維度是誇Group的，那麼Kylin需要以較大的代價從N－Cuboid中聚合得到所需要的查詢結果

資料壓縮：

Kylin針對維度字典以及維度錶快照採用了特殊的壓縮演算法，對於Hbase中的聚合計算資料利用了Hadoop的LZO或者是Snappy，從而保證儲存在Hbase以及記憶體中的資料儘可能的小。其中維度字典以及維度錶快照的壓縮考慮到DataCube中會出現非常多的重複的維度成員值，最直接的處理方式就是利用資料字典的方式將維度值對映成ID， Kylin中採用了Trie樹的方式對維度值進行編碼。

distinct count聚合查詢最佳化：

Kylin 採用了HypeLogLog的方式來計算Distinc Count。好處是速度快，缺點是結果是一個近似值，會有一定的誤差。在非計費等通常的場景下Distinct Count的統計誤差應用普遍可以接受。具體的演算法可見Paper： http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf 本文不再贅述

kylin SQL查詢的實現

ANSI SQL查詢是Kylin 非常明顯的優勢。Kylin的SQL語法解析依賴於另一個開源資料管理框架 Apache Calcite， Calcite即之前的Optiq，是一個沒有儲存模組的資料庫，即不管理資料儲存、不包含資料處理的演算法，不包含元資訊的儲存。因此它非常適合來做一個應用到儲存引擎之間的中間層。在Calcite的基礎之上只要為儲存引擎寫一個專用的介面卡（Adapter）即可形成一個功能豐富的支援DML甚至DDL的“類資料庫”。

Kylin完成了一個定製的Adapter，在Calcite完成SQL解析，形成語法樹（AST）之後，由Kylin定義語法樹各個節點的執行規則來進行查詢。Calcite在遍歷語法樹節點後生成一個Kylin描述查詢模型的Digest， Kylin會為此Digest去判斷是否有匹配的Cube。如果有與查詢匹配的Cube，即選擇一個查詢代價最小的Cube進行查詢（Kylin Cube的查詢代價計算目前是一個開放介面，可以根據維度數目，可以根據資料量大小來計算Cost）

Kylin目前的多維資料儲存引擎是HBase， Kylin利用了HBase的Coprocessor機制在HBase的Region Server完成部分聚合以及全部過濾操作，在Hbase Scan時提前進行計算，利用HBase多個Region Server的計算能力加速Kylin的SQL查詢。目前Kylin仍然有部分查詢語法不支援，特別是過濾器Where部分的約束較多、對SQL有一定的要求，但是如果有針對性的對Coprocessor部分進行改造相信SQL相容度可以有大幅的提升。

kylin 與 RTOLAP

Kylin 可以說是與市面上流行的Presto、SparkSQL、Impala等直接在原始資料上查詢的系統（暫且歸於RTOLAP）走了一條完全不同的道路。 前者在如何快速求得預計算結果，以及最佳化查詢解析使得更多的查詢能用上預計算結果方面在最佳化。後續Kylin的版本會改進預計算引擎，最佳化預計算速度，使得Kylin可以變成一個近似實時的分析引擎。 而像Presto，SparkSQL等是著重於最佳化查詢資料的過程環節，像一些其它的資料倉庫一樣，使用列存、壓縮、並行查詢等技術，最佳化查詢。這種方案的好處就在於擴充套件性強、能適配更廣泛的查詢。但是在查詢速度上，可以說Kylin 要比ROLAP 至少快上一個數量級，所以對與查詢響應時間要求較高的應用，Kylin是最好的選擇。

3. Kylin在網易Kylin服務化

在網易，Kylin作為大資料平臺的Olap查詢模組，可以為公司的各種分析類需求以及應用提供服務。所有資料存在Hadoop Hive 上的資料都能夠透過Kylin Olap 引擎進行加速查詢。在公司內部Kylin作為一個統一平臺，與各產品的資料倉庫進行接駁。

目前Kylin的部署架構如下：

Kylin叢集由多個查詢節點以及控制節點組成。 控制節點唯一，負責叢集專案、任務排程與Cube增刪查改。 多個查詢節點前用Nginx做負載均衡，後段節點可按需水平擴容。前端可同時支援JDBC與ODBC的客戶端查詢。

Kylin效能表現

在Kylin上線前，我們選取了公司內部原有的一些報表業務進行過效能對比，對比內容在相同的資料下、Kylin查詢與Mondrian 結合Oracle的查詢比較。

測試結果透過資料量較大的DataStream報表來進行比較：

網易對Kylin的改進

原生的社群版Kylin 是需要部署在一個統一底層的Hadoop、Hive、HBase叢集之上的。而網易內部的大資料平臺由於各種原因，分為了多個Hadoop叢集、各應用會在不同的Hadoop叢集上建立Hive資料倉庫。 最原始而自然的想法就是在每一個Hadoop環境上部署一套Kylin服務來滿足不同的需求，但是叢集資源管理、計算資源排程、管理運維的複雜性都會是一個比較突出的問題。例如使用者資料在A機房的Hive上，而A機房的Hadoop叢集並沒有足夠的計算資源來保證Kylin Olap的高效執行。因此根據公司內部實際的大資料平臺分佈情況及機房建設情況，將Kylin打造成一個公司內統一的服務平臺是一個更好的選擇。Olap小組對開源版本的Kylin進行了二次開發，並將改進補丁提交了社群。目前的改進主要包括：

Kylin對Kerberos認證的支援Kylin非Hadoop節點的部署支援多資料來源的支援

在公司內，由於效能以及安全性方面的考量，不同部門的應用會搭建各自的Hive進行資料分析，並且由於公司內還沒有跨機房的Hadoop叢集，因此會出現使用者資料在A地方的Hive上，而A機房的Hadoop叢集並沒有足夠的計算資源來保證Kylin Olap的高效執行。

綜合分析現實的場景之後，我們選擇了公司內最大的hadoop叢集作為Kylin Olap的計算引擎叢集，保證有充足的儲存以及計算資源。 HBase採用一個獨立的叢集，避免Hbase查詢和Hadoop叢集任務之間的互相干擾。資料來源Hive允許使用者自定義，目前已支援同Hadoop叢集下不同Hive 以及不同Hadoop叢集下的不同Hive節點使用Kylin Olap服務。根據使用者資料倉庫的實際配置情況可能會出現跨叢集的資料來源抽取計算， 由於公司同城機房有專線網路，資料倉庫Hive裡的源資料量也遠小於Kylin實際的聚合後的資料儲存（存於Hbase，資料量大小一般為資料來源Hive中的10倍以上）， 因此可認為這樣的開銷可以認為帶來的影響不大，並且在我們的測試中得到了印證。

Kylin OLAP與猛獁以及有數的結合

猛獁是網易內部的統一大資料入口平臺，為了讓Kylin更快更好的融入到大平臺中，OLAP小組已計劃在不久之後全面與猛獁大資料平臺進行打通和整合， Kylin Olap 將深度內嵌於猛獁，使用者可以基於猛獁平臺完成Kylin Olap的簡化管理工作。猛獁平臺對接控制節點，作為專業資料建模師的操作入口

Kylin將利用猛獁的使用者管理功能猛獁將接管使用者專案的建立以及Cube的管理猛獁將原有的Hive資料來源徹底與Kylin打通，便於Kylin管理使用者的資料來源

Kylin原生的使用者管理是基於LDAP的，如果不使用LDAP服務需要利用Spring security重新開發一套，網易的內部的猛獁大資料平臺有一套成熟且完善的使用者許可權訪問控制體系，因此可以利用現成的機制對Kylin的訪問、修改做保護性的限制。

Kylin的Data Cube建模，特別是一些高階的Cube最佳化功能如RowKey順序、維度分組、分層等需要較高的學習成本，所以認為不適合讓一般的資料分析師來直接操作，我們設計了一套簡化版的Cube 建模流程，以使用者申請——運維審批的方式進行資料的接入。

有數是網易內部重要的報表分析平臺，有數將Kylin Olap作為一個單獨的資料來源進行支援。已有的以及潛在的Hive查詢客戶可以輕鬆的將報表遷移到Kylin Olap，使得大資料量下的互動式報表分析成為可能。

有數能基於在猛獁上建立的Cube建立報表有數主動識別Kylin Cube定義的維度和度量使用者在Kylin Olap允許的範圍內自由操作，完成報表的編輯和查詢。

Kylin 的資料查詢結果可以用更多更豐富的圖表的方式展示給資料分析人員：