1. OLAP簡介
OLAP的歷史與基本概念
OLAP全稱爲在線聯機分析應用，是一種對於多維數據分析查詢的解決方案。典型的OLAP應用場景包括銷售、市場、管理等商務報表，預算決算，經濟報表等等。
最早的OLAP查詢工具是發佈於1970年的Express，然而完整的OLAP概念是在1993年由關係數據庫之父EdgarF.Codd 提出，伴隨而來的是著名的“twelvelaws of online analytical processing”. 1998年微軟發佈MicrosoftAnalysis Services，並且在早一年通過OLE DB for OLAP API引入MDX查詢語言，2001年微軟和Hyperion發佈的XML forAnalysis 成爲了事實上的OLAP查詢標準。如今，MDX已成爲與SQL旗鼓相當的OLAP 查詢語言，被各家OLAP廠商先後支持。
OLAPCube是一種典型的多維數據分析技術，Cube本身可以認爲是不同維度數據組成的dataset，一個OLAP Cube 可以擁有多個維度（Dimension），以及多個事實（Factor Measure）。用戶通過OLAP工具從多個角度來進行數據的多維分析。通常認爲OLAP包括三種基本的分析操作：上卷（rollup）、下鑽（drilldown）、切片切塊（slicingand dicing），原始數據經過聚合以及整理後變成一個或多個維度的視圖。
ROLAP和MOLAP
傳統OLAP根據數據存儲方式的不同分爲ROLAP（Relational OLAP）以及MOLAP（Multi-dimensionOLAP）
ROLAP 以關係模型的方式存儲用作多維分析用的數據，優點在於存儲體積小，查詢方式靈活，然而缺點也顯而易見，每次查詢都需要對數據進行聚合計算，爲了改善短板，ROLAP使用了列存、並行查詢、查詢優化、位圖索引等技術
MOLAP 將分析用的數據物理上存儲爲多維數組的形式，形成CUBE結構。維度的屬性值映射成多維數組的下標或者下標範圍，事實以多維數組的值存儲在數組單元中，優勢是查詢快速，缺點是數據量不容易控制，可能會出現維度爆炸的問題。
大數據時代OLAP的挑戰
近二十年內，ROLAP技術隨着MPP並行數據庫技術的發展，尤其是列存技術的支持下，實現了分析能力大幅度的跨越提升，同時伴隨着內存成本的進一步降低，單節點內存擴展性增強，集羣單節點的查詢性能實現了飛躍，內存數據庫的實用性跨上了一個新臺階，這些技術進步共同作用的結果是類似的技術基本覆蓋了TB級別的數據分析需求。 Hadoop以及相關大數據技術的出現提供了一個幾近無限擴展的數據平臺，在相關技術的支持下，各個應用的數據已突破了傳統OLAP所能支持的容量上界。每天千萬、數億條的數據，提供若干維度的分析模型，大數據OLAP最迫切所要解決的問題就是大量實時運算導致的響應時間遲滯。
2. Apache Kylin 大數據下的OLAP解決方案
Apache Kylin的背景
Apache Kylin 是一個Hadoop生態圈下的MOLAP系統，是eBay大數據部門從2014年開始研發並開源的支持TB到PB級別數據量的分佈式OLAP分析引擎。其特點包括:
- 可擴展的超快的OLAP引擎
- 提供ANSI-SQL接口
- 交互式查詢能力
- MOLAP Cube 的概念
- 與BI工具可無縫整合
Apache Kylin典型的應用場景如下：
- 用戶數據存在於Hadoop HDFS中，利用Hive將HDFS文件數據以關係數據方式存取，數據量巨大，在500G以上
- 每天有數G甚至數十G的數據增量導入
- 有10個左右爲固定的分析維度
ApacheKylin的核心思想是利用空間換時間，由於查詢方面制定了多種靈活的策略，進一步提高空間的利用率，使得這樣的平衡策略在應用中是值得采用的。
Apache Kylin的總體架構
Apache Kylin 作爲一個OLAP引擎完成了從數據源抓取數據，ETL到自己的存儲引擎，提供REST服務等一系列工作，其架構如圖所示：
Apache Kylin 的生態圈包括：
- Kylin Core: Kylin 引擎的框架，查詢、任務、以及存儲引擎都集中於此，除此之外還包括一個REST 服務器來響應各種客戶端請求。
- 擴展插件: 各種提供額外特性的插件，如安全認證、SSO等
- 完整性組件: Job管理器，ETL、監控以及報警
- 交互界面: 基於Kylin Core之上的用戶交互界面
- 驅動: 提供了JDBC以及ODBC的連接方式
Apache kylin Cube 多維數據的計算
Apache Kylin的多維計算主要是體現在OLAPCube的計算。Cube由多個Cuboid組合而成，Cuboid上的數據是原始數據聚合的數據，因此創建Cube可以看作是在原始數據導入時做的一個預計算預處理的過程。Kylin的強大之處在於充分利用了Hadoop的MapReduce並行處理的能力，高效處理導入的數據。
Apache Kylin的數據來自於Hive，並作爲一個Hive的加速器希望最終的查詢SQL類似於直接在Hive上查詢。因此Kylin在建立Cube的時候需要從Hive獲取Hive表的元數據。雖然有建立Cube的過程，但是並不想對普通的查詢用戶暴露Cube的存在。
Apache Kylin創建Cube的過程如下圖所示：
- 根據Cube定義的事實表以及維度表，利用Hive創建一張寬表
- 抽取事實表上的維度的distinct值，將事實表上的維度以字典樹方式壓縮編碼成目錄，將維度表以字典樹的方式編碼
- 利用MapReduce從第一步得到的寬表文件作爲輸入，創建 N－Dimension cuboid，然後每次根據前一步的結果串行生成 N-1 cuboid, N-2 cuboid … 0-Cuboid
- 根據生成的Cuboid數據量計算HTable的Region分割策略，創建HTable，將HFile導入進來
Apache Kylin與傳統的OLAP一樣，無法應對數據Update的情況（更新數據會導致Cube的失效，需要重建整個Cube）。面對每天甚至每兩個小時這樣固定週期的增量數據，Kylin使用了一種增量Cubing技術來進行快速響應。
Apache Kylin的Cube可以根據時間段劃分成多個Segment。在Cube第一次Build完成之後會有一個Segment，在每次增量Build後會產生一個新的Segment。增量Cubing依賴已有的CubeSegments和增量的原始數據。增量Cubing的步驟和新建 Cube的步驟類似，Segment之間以時間段進行區分。
增量Cubing所需要面對的原始數據量更小，因此增量Cubing的速度是非常快的。然而隨着CubeSegments的數目增加，一定程度上會影響到查詢的進行，所以在Segments數目到一定數量後可能需要進行CubeSegments的合併操作，實際上MergeCube是合成了一個新的大的CubeSegment來替代，Merge操作是一個異步的在線操作，不會對前端的查詢業務產生影響。
合併操作步驟如下：
- 遍歷指定的Cube Segment
- 合併維度字典目錄和維度錶快照
- 利用MapReduce合併他們的 N-Dimension cuboid
- 將cuboid轉換成HFile，生成新的HTable，替代原有的多個HTable
Apache Kylin對傳統MOLAP的改進
計算Cube的存儲代價以及計算代價都是比較大的， 傳統OLAP的維度爆炸的問題Kylin也一樣會遇到。 Kylin提供給用戶一些優化措施，在一定程度上能降低維度爆炸的問題：
- Cube 優化：
- Hierachy Dimension
- Derived Dimension
- Aggregation Group
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內部再對結果集做一次聚合後返回給用戶
Aggregation Group， 這是一個將維度進行分組，以求達到降低維度組合數目的手段。不同分組的維度之間組成的Cuboid數量會大大降低，維度組合從2的（k+m+n）次冪至多能降低到 2的k次冪加2的m次冪加2的n次冪。Group的優化措施與查詢SQL緊密依賴，可以說是爲了查詢的定製優化。 如果查詢的維度是誇Group的，那麼Kylin需要以較大的代價從N－Cuboid中聚合得到所需要的查詢結果，這需要Cube構建人員在建模時仔細地斟酌。
- 數據壓縮：
Apache Kylin針對維度字典以及維度錶快照採用了特殊的壓縮算法，對於Hbase中的聚合計算數據利用了Hadoop的LZO或者是Snappy，從而保證存儲在Hbase以及內存中的數據儘可能的小。其中維度字典以及維度錶快照的壓縮考慮到DataCube中會出現非常多的重複的維度成員值，最直接的處理方式就是利用數據字典的方式將維度值映射成ID， Kylin中採用了Trie樹的方式對維度值進行編碼
- distinct count聚合查詢優化：
Apache Kylin 採用了HypeLogLog的方式來計算DistinctCount。好處是速度快，缺點是結果是一個近似值，會有一定的誤差。在非計費等通常的場景下DistinctCount的統計誤差應用普遍可以接受。
具體的算法可見Paper，本文不再贅述：
http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf
Apache kylin SQL查詢的實現
ANSI SQL查詢是Apache Kylin 非常明顯的優勢。Kylin的SQL語法解析依賴於另一個開源數據管理框架 ApacheCalcite， Calcite即之前的Optiq，是一個沒有存儲模塊的數據庫，即不管理數據存儲、不包含數據處理的算法，不包含元信息的存儲。因此它非常適合來做一個應用到存儲引擎之間的中間層。在Calcite的基礎之上只要爲存儲引擎寫一個專用的適配器（Adapter）即可形成一個功能豐富的支持DML甚至DDL的“類數據庫”。
Kylin完成了一個定製的Adapter，在Calcite完成SQL解析，形成語法樹（AST）之後，由Kylin定義語法樹各個節點的執行規則來進行查詢。Calcite在遍歷語法樹節點後生成一個Kylin描述查詢模型的Digest， Kylin會爲此Digest去判斷是否有匹配的Cube。如果有與查詢匹配的Cube，即選擇一個查詢代價最小的Cube進行查詢（KylinCube的查詢代價計算目前是一個開放接口，可以根據維度數目，可以根據數據量大小來計算Cost）
Kylin目前的多維數據存儲引擎是HBase， Kylin利用了HBase的Coprocessor機制在HBase的RegionServer完成部分聚合以及全部過濾操作，在HbaseScan時提前進行計算，利用HBase多個Region Server的計算能力加速Kylin的SQL查詢。目前Kylin仍然有部分查詢語法不支持，特別是過濾器Where部分的約束較多、對SQL有一定的要求，但是如果有針對性的對Coprocessor部分進行改造相信SQL兼容度可以有大幅的提升。
Apache kylin 與 RTOLAP
ApacheKylin 可以說是與市面上流行的Presto、SparkSQL、Impala等直接在原始數據上查詢的系統（暫且歸於RTOLAP）走了一條完全不同的道路。前者在如何快速求得預計算結果，以及優化查詢解析使得更多的查詢能用上預計算結果方面在優化。後續Kylin的版本會改進預計算引擎，優化預計算速度，使得Kylin可以變成一個近似實時的分析引擎。而像Presto，SparkSQL等是着重於優化查詢數據的過程環節，像一些其它的數據倉庫一樣，使用列存、壓縮、並行查詢等技術，優化查詢。這種方案的好處就在於擴展性強、能適配更廣泛的查詢。但是在查詢速度上，可以說Apache Kylin 要比ROLAP 至少快上一個數量級，所以對與查詢響應時間要求較高的應用，ApacheKylin是最好的選擇。
3. Apache Kylin在網易
Kylin服務化
在網易，Apache Kylin作爲大數據平臺的OLAP查詢模塊，可以爲公司的各種分析類需求以及應用提供服務。所有數據存在Hadoop Hive 上的數據都能夠通過Kylin OLAP 引擎進行加速查詢。在公司內部Kylin作爲一個統一平臺，與各產品的數據倉庫進行接駁。
目前Kylin的部署架構如下：
Kylin集羣由多個查詢節點以及控制節點組成。 控制節點唯一，負責集羣項目、任務調度與Cube增刪查改。 多個查詢節點前用Nginx做負載均衡，後段節點可按需水平擴容。前端可同時支持JDBC與ODBC的客戶端查詢。
Kylin性能表現
在Kylin上線前，我們選取了公司內部原有的一些報表業務進行過性能對比，對比內容在相同的數據下、Kylin查詢與Mondrian 結合Oracle的查詢比較。
測試結果通過數據量較大的DataStream報表來進行比較：
再看Kylin的吞吐量，利用Haproxy進行請求轉發後隨着Kylin服務器的增加吞吐量的表現：
網易對Kylin的改進
原生的社區版Aapche Kylin 是需要部署在一個統一底層的Hadoop、Hive、HBase集羣之上的。而網易內部的大數據平臺由於各種原因，分爲了多個Hadoop集羣、各應用會在不同的Hadoop集羣上建立Hive數據倉庫。最原始而自然的想法就是在每一個Hadoop環境上部署一套Kylin服務來滿足不同的需求，但是集羣資源管理、計算資源調度、管理運維的複雜性都會是一個比較突出的問題。例如用戶數據在A機房的Hive上，而A機房的Hadoop集羣並沒有足夠的計算資源來保證KylinOLAP的高效運行。因此根據公司內部實際的大數據平臺分佈情況及機房建設情況，將Kylin打造成一個公司內統一的服務平臺是一個更好的選擇。OLAP小組對開源版本的Kylin進行了二次開發，並將改進補丁提交給了社區並受到了積極反饋。
目前的改進主要包括：
- Kylin對Kerberos認證的支持
- Kylin非Hadoop節點的部署支持
- 多數據源的支持
在公司內，由於性能以及安全性方面的考量，不同部門的應用會搭建各自的Hive進行數據分析，並且由於公司內還沒有跨機房的Hadoop集羣，因此會出現用戶數據在A地方的Hive上，而A機房的Hadoop集羣並沒有足夠的計算資源來保證KylinOLAP的高效運行。
綜合分析現實的場景之後，我們選擇了公司內最大的hadoop集羣作爲KylinOLAP的計算引擎集羣，保證有充足的存儲以及計算資源。 HBase採用一個獨立的集羣，避免Hbase查詢和Hadoop集羣任務之間的互相干擾。數據源Hive允許用戶自定義，目前已支持同Hadoop集羣下不同Hive 以及不同Hadoop集羣下的不同Hive節點使用KylinOLAP服務。根據用戶數據倉庫的實際配置情況可能會出現跨集羣的數據源抽取計算，由於公司同城機房有專線網絡，數據倉庫Hive裏的源數據量也遠小於Kylin實際的聚合後的數據存儲（存於Hbase，數據量大小一般爲數據源Hive中的10倍以上），因此可認爲這樣的開銷可以認爲帶來的影響不大，並且在我們的測試中得到了印證。
Kylin OLAP與猛獁以及有數的結合
猛獁是網易內部的統一大數據入口平臺，爲了讓Kylin更快更好的融入到大平臺中，OLAP小組已計劃在不久之後全面與猛獁大數據平臺進行打通和整合， Kylin OLAP將深度內嵌於猛獁，用戶可以基於猛獁平臺完成KylinOLAP的簡化管理工作。猛獁平臺對接控制節點，作爲專業數據建模師的操作入口
- Kylin將利用猛獁的用戶管理功能
- 猛獁將接管用戶項目的創建以及Cube的管理
- 猛獁將原有的Hive數據源徹底與Kylin打通，便於Kylin管理用戶的數據源
Kylin原生的用戶管理是基於LDAP的，如果不使用LDAP服務需要利用SpringSecurity重新開發一套，網易的內部的猛獁大數據平臺有一套成熟且完善的用戶權限訪問控制體系，因此可以利用現成的機制對Kylin的訪問、修改做保護性的限制。
Kylin的Data Cube建模，特別是一些高級的Cube優化功能如RowKey順序、維度分組、分層等需要較高的學習成本，所以認爲不適合讓一般的數據分析師來直接操作，我們設計了一套簡化版的Cube 建模流程，以用戶申請——運維審批的方式進行數據的接入。
有數是網易內部重要的報表分析平臺，有數將KylinOLAP作爲一個單獨的數據源進行支持。已有的以及潛在的Hive查詢客戶可以輕鬆的將報表遷移到KylinOLAP，使得大數據量下的交互式報表分析成爲可能。
- 有數能基於在猛獁上創建的Cube創建報表
- 有數主動識別Kylin Cube定義的維度和度量
- 用戶在Kylin OLAP允許的範圍內自由操作，完成報表的編輯和查詢。
與有數結合後的Kylin 查詢結果可以用更多更豐富的圖表的方式展示給數據分析人員：
轉載請註明：數據平臺技術博客 » Apache Kylin 大數據時代的OLAP利器