Kylin 大數據時代的OLAP利器
1. Olap簡介
</h2>
<h3>
Olap的歷史與基本概念
</h3>
<p>
Olap全稱為在線聯機分析應用，是一種對于多維數據分析查詢的解決方案。 典型的Olap應用場景包括銷售、市場、管理等商務報表，預算決算，經濟報表等等。
</p>
<p>
最早的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廠商先后支持。
</p>
<p>
Olap Cube是一種典型的多維數據分析技術，Cube本身可以認為是不同維度數據組成的dataset，一個Olap Cube 可以擁有多個維度（Dimension），以及多個事實（Fact or Measure）。用戶通過Olap工具從多個角度來進行數據的多維分析。通常認為Olap包括三種基本的分析操作： 上卷（rollup）、下鉆（drill down）、切片切塊（slicing and dicing），原始數據經過聚合以及整理后變成一個或多個維度的視圖。
</p>
<h3>
ROLAP和MOLAP
</h3>
<p>
傳統OLAP根據數據存儲方式的不同分為ROLAP（relational olap）以及MOLAP（multi-dimension olap）
</p>
<p>
ROLAP 以關系模型的方式存儲用作多維分析用的數據，優點在于存儲體積小，查詢方式靈活，然而缺點也顯而易見，每次查詢都需要對數據進行聚合計算，為了改善短板，ROLAP使用了列存、并行查詢、查詢優化、位圖索引等技術
</p>
<p>
MOLAP 將分析用的數據物理上存儲為多維數組的形式，形成CUBE結構。維度的屬性值映射成多維數組的下標或者下標范圍，事實以多維數組的值存儲在數組單元中，優勢是查詢快速，缺點是數據量不容易控制，可能會出現維度爆炸的問題。
</p>
<h3>
大數據時代Olap的挑戰
</h3>
<p>
近二十年內，ROLAP技術隨著MPP并行數據庫技術的發展，尤其是列存技術的支持下，實現了分析能力大幅度的跨越提升，同時伴隨著內存成本的進一步降低，單節點內存擴展性增強，集群單節點的查詢性能實現了飛躍，內存數據庫的實用性跨上了一個新臺階，這些技術進步共同作用的結果是類似的技術基本覆蓋了TB級別的數據分析需求。 Hadoop以及相關大數據技術的出現提供了一個幾近無限擴展的數據平臺，在相關技術的支持下，各個應用的數據已突破了傳統OLAP所能支持的容量上界。每天千萬、數億條的數據，提供若干維度的分析模型，大數據OLAP最迫切所要解決的問題就是大量實時運算導致的響應時間遲滯。
</p>
<h2>
2. Apache Kylin 大數據下的Olap解決方案
</h2>
<h3>
Kylin的背景
</h3>
<p>
Kylin 是一個Hadoop生態圈下的MOLAP系統，是ebay大數據部門從2014年開始研發的支持TB到PB級別數據量的分布式Olap分析引擎。其特點包括:
</p>
<ul>
<li>
可擴展的超快的OLAP引擎
</li>
<li>
提供ANSI-SQL接口
</li>
<li>
交互式查詢能力
</li>
<li>
MOLAP Cube 的概念
</li>
<li>
與BI工具可無縫整合
</li>
</ul>
<p>
Kylin典型的應用場景如下：
</p>
<ul>
<li>
用戶數據存在于Hadoop HDFS中，利用Hive將HDFS文件數據以關系數據方式存取，數據量巨大，在500G以上
</li>
<li>
每天有數G甚至數十G的數據增量導入
</li>
<li>
有10個左右為固定的分析維度
</li>
</ul>
<p>
Kylin的核心思想是利用空間換時間，由于查詢方面制定了多種靈活的策略，進一步提高空間的利用率，使得這樣的平衡策略在應用中是值得采用的。
</p>
<h3>
kylin的總體架構
</h3>
<p>
Kylin 作為一個Olap引擎完成了從數據源抓取數據，ETL到自己的存儲引擎，提供REST服務等一系列工作，其架構如圖所示：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/5e7726a77ba720d776183e6fc9e2857a.png" width="700" height="341" />
</p>
<p>
Kylin 的生態圈包括：
</p>
<ul>
<li>
Kylin Core: Kylin 引擎的框架，查詢、任務、以及存儲引擎都集中于此，除此之外還包括一個REST 服務器來響應各種客戶端請求。
</li>
<li>
擴展插件: 各種提供額外特性的插件，如安全認證、SSO等
</li>
<li>
完整性組件: Job管理器，ETL、監控以及報警
</li>
<li>
交互界面: 基于Kylin Core之上的用戶交互界面
</li>
<li>
驅動: 提供了JDBC以及ODBC的連接方式
</li>
</ul>
<h3>
kylin Cube 多維數據的計算
</h3>
<p>
Kylin的多維計算主要是體現在OLAP Cube的計算。Cube由多個Cuboid組合而成，Cuboid上的數據是原始數據聚合的數據，因此創建Cube可以看作是在原始數據導入時做的一個預計算預處理的過程。Kylin的強大之處在于充分利用了Hadoop的MapReduce并行處理的能力，高效處理導入的數據。
</p>
<p>
Kylin的數據來自于Hive，并作為一個Hive的加速器希望最終的查詢SQL類似于直接在Hive上查詢。因此Kylin在建立Cube的時候需要從Hive獲取Hive表的元數據。雖然有建立Cube的過程，但是并不想對普通的查詢用戶暴露Cube的存在。
</p>
<p>
Kylin創建Cube的過程如下圖所示：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/c5c7943ba4d548a0ec85287633c27e4a.png" width="700" height="360" />
</p>
<ol>
<li>
根據Cube定義的事實表以及維度表，利用Hive創建一張寬表
</li>
<li>
抽取事實表上的維度的distinct值，將事實表上的維度以字典樹方式壓縮編碼成目錄，將維度表以字典樹的方式編碼
</li>
<li>
利用MapReduce從第一步得到的寬表文件作為輸入，創建 N－Dimension cuboid，然后每次根據前一步的結果串行生成 N-1 cuboid, N-2 cuboid … 0-Cuboid
</li>
<li>
根據生成的Cuboid數據量計算HTable的Region分割策略，創建HTable，將HFile導入進來
</li>
</ol>
<p>
Kylin與傳統的OLAP一樣，無法應對數據Update的情況（更新數據會導致Cube的失效，需要重建整個Cube）。面對每天甚至每兩個小時這樣固定周期的增量數據，Kylin使用了一種增量Cubing技術來進行快速響應。
</p>
<p>
Kylin的Cube可以根據時間段劃分成多個Segment。在Cube第一次Build完成之后會有一個Segment，在每次增量Build后會產生一個新的Segment。增量Cubing依賴已有的Cube Segments和增量的原始數據。增量Cubing的步驟和新建 Cube的步驟類似，Segment之間以時間段進行區分。
</p>
<p>
增量Cubing所需要面對的原始數據量更小，因此增量Cubing的速度是非常快的。然而隨著Cube Segments的數目增加，一定程度上會影響到查詢的進行，所以在Segments數目到一定數量后可能需要進行Cube Segments的合并操作，實際上merge cube是合成了一個新的大的Cube Segment來替代，Merge操作是一個異步的在線操作，不會對前端的查詢業務產生影響。。
</p>
<p>
合并操作步驟如下：
</p>
<ol>
<li>
遍歷指定的Cube Segment
</li>
<li>
合并維度字典目錄和維度表快照
</li>
<li>
利用MapReduce合并他們的 N-Dimension cuboid
</li>
<li>
將cuboid轉換成HFile，生成新的HTable，替代原有的多個HTable
</li>
</ol>
<h3>
Kylin對傳統MOLAP的改進
</h3>
<p>
計算Cube的存儲代價以及計算代價都是比較大的， 傳統OLAP的維度爆炸的問題Kylin也一樣會遇到。 Kylin提供給用戶一些優化措施，在一定程度上能降低維度爆炸的問題：
</p>
<ol>
<li>
Cube 優化：
</li>
</ol>
<ul>
<li>
Hierachy Dimension
</li>
<li>
Derived Dimension
</li>
<li>
Group Dimensions
</li>
</ul>
<p>
Hierachy Dimension， 一系列具有層次關系的Dimension組成一個Hierachy， 比如年、月、日組成了一個Hierachy， 在Cube中，如果不設置Hierarchy， 會有 年、月、日、年月、年日、月日 6個cuboid， 但是設置了Hierarchy之后Cuboid增加了一個約束，希望低Level的Dimension一定要伴隨高Level的Dimension 一起出現。設置了Hierachy Dimension 能使得需要計算的維度組合減少一半。
</p>
<p>
Derived Dimension, 如果在某張維度表上有多個維度，那么可以將其設置為Derived Dimension， 在Kylin內部會將其統一用維度表的主鍵來替換，以此來達到降低維度組合的數目，當然在一定程度上Derived Dimension 會降低查詢效率，在查詢時，Kylin使用維度表主鍵進行聚合后，再通過主鍵和真正維度列的映射關系做一次轉換，在Kylin內部再對結果集做一次聚合后返回給用戶
</p>
<p>
Group Dimension， 這是一個將維度進行分組，以求達到降低維度組合數目的手段。不同分組的維度之間不會進行組合計算。Group的優化措施與查詢SQL緊密依賴，可以說是為了查詢的定制優化。 維度組合從2的（k+m+n）次冪降低到 2的k次冪加2的m次冪加2的n次冪。如果查詢的維度是夸Group的，那么Kylin需要以較大的代價從N－Cuboid中聚合得到所需要的查詢結果
</p>
<ol>
<li>
數據壓縮：
</li>
</ol>
<p>
Kylin針對維度字典以及維度表快照采用了特殊的壓縮算法，對于Hbase中的聚合計算數據利用了Hadoop的LZO或者是Snappy，從而保證存儲在Hbase以及內存中的數據盡可能的小。其中維度字典以及維度表快照的壓縮考慮到DataCube中會出現非常多的重復的維度成員值，最直接的處理方式就是利用數據字典的方式將維度值映射成ID， Kylin中采用了Trie樹的方式對維度值進行編碼。
</p>
<ol>
<li>
distinct count聚合查詢優化：
</li>
</ol>
<p>
Kylin 采用了HypeLogLog的方式來計算Distinc Count。好處是速度快，缺點是結果是一個近似值，會有一定的誤差。在非計費等通常的場景下Distinct Count的統計誤差應用普遍可以接受。具體的算法可見Paper： http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf 本文不再贅述
</p>
<h3>
kylin SQL查詢的實現
</h3>
<p>
ANSI SQL查詢是Kylin 非常明顯的優勢。Kylin的SQL語法解析依賴于另一個開源數據管理框架 Apache Calcite， Calcite即之前的Optiq，是一個沒有存儲模塊的數據庫，即不管理數據存儲、不包含數據處理的算法，不包含元信息的存儲。因此它非常適合來做一個應用到存儲引擎之間的中間層。在Calcite的基礎之上只要為存儲引擎寫一個專用的適配器（Adapter）即可形成一個功能豐富的支持DML甚至DDL的“類數據庫”。
</p>
<p>
Kylin完成了一個定制的Adapter，在Calcite完成SQL解析，形成語法樹（AST）之后，由Kylin定義語法樹各個節點的執行規則來進行查詢。Calcite在遍歷語法樹節點后生成一個Kylin描述查詢模型的Digest， Kylin會為此Digest去判斷是否有匹配的Cube。如果有與查詢匹配的Cube，即選擇一個查詢代價最小的Cube進行查詢（Kylin Cube的查詢代價計算目前是一個開放接口，可以根據維度數目，可以根據數據量大小來計算Cost）
</p>
<p>
Kylin目前的多維數據存儲引擎是HBase， Kylin利用了HBase的Coprocessor機制在HBase的Region Server完成部分聚合以及全部過濾操作，在Hbase Scan時提前進行計算，利用HBase多個Region Server的計算能力加速Kylin的SQL查詢。目前Kylin仍然有部分查詢語法不支持，特別是過濾器Where部分的約束較多、對SQL有一定的要求，但是如果有針對性的對Coprocessor部分進行改造相信SQL兼容度可以有大幅的提升。
</p>
<h3>
kylin 與 RTOLAP
</h3>
<p>
Kylin 可以說是與市面上流行的Presto、SparkSQL、Impala等直接在原始數據上查詢的系統（暫且歸于RTOLAP）走了一條完全不同的道路。 前者在如何快速求得預計算結果，以及優化查詢解析使得更多的查詢能用上預計算結果方面在優化。后續Kylin的版本會改進預計算引擎，優化預計算速度，使得Kylin可以變成一個近似實時的分析引擎。 而像Presto，SparkSQL等是著重于優化查詢數據的過程環節，像一些其它的數據倉庫一樣，使用列存、壓縮、并行查詢等技術，優化查詢。這種方案的好處就在于擴展性強、能適配更廣泛的查詢。但是在查詢速度上，可以說Kylin 要比ROLAP 至少快上一個數量級，所以對與查詢響應時間要求較高的應用，Kylin是最好的選擇。
</p>
<h2>
3. Kylin在網易
</h2>
<h3>
Kylin服務化
</h3>
<p>
在網易，Kylin作為大數據平臺的Olap查詢模塊，可以為公司的各種分析類需求以及應用提供服務。所有數據存在Hadoop Hive 上的數據都能夠通過Kylin Olap 引擎進行加速查詢。在公司內部Kylin作為一個統一平臺，與各產品的數據倉庫進行接駁。
</p>
<p>
目前Kylin的部署架構如下：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/89cd98046b25def01e06bc92b2b842c9.png" width="700" height="395" />
</p>
<p>
Kylin集群由多個查詢節點以及控制節點組成。 控制節點唯一，負責集群項目、任務調度與Cube增刪查改。 多個查詢節點前用Nginx做負載均衡，后段節點可按需水平擴容。前端可同時支持JDBC與ODBC的客戶端查詢。
</p>
<h3>
Kylin性能表現
</h3>
<p>
在Kylin上線前，我們選取了公司內部原有的一些報表業務進行過性能對比，對比內容在相同的數據下、Kylin查詢與Mondrian 結合Oracle的查詢比較。
</p>
<p>
測試結果通過數據量較大的DataStream報表來進行比較：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/952f6a7b09c16e9bf27ee6e463dc1194.png" width="480" height="298" />
</p>
<p>
再看Kylin的吞吐量，利用Haproxy進行請求轉發后隨著Kylin服務器的增加吞吐量的表現：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/21289e2125a98587a20221f6527630da.png" width="460" height="284" />
</p>
<h3>
網易對Kylin的改進
</h3>
<p>
原生的社區版Kylin 是需要部署在一個統一底層的Hadoop、Hive、HBase集群之上的。而網易內部的大數據平臺由于各種原因，分為了多個Hadoop集群、各應用會在不同的Hadoop集群上建立Hive數據倉庫。 最原始而自然的想法就是在每一個Hadoop環境上部署一套Kylin服務來滿足不同的需求，但是集群資源管理、計算資源調度、管理運維的復雜性都會是一個比較突出的問題。例如用戶數據在A機房的Hive上，而A機房的Hadoop集群并沒有足夠的計算資源來保證Kylin Olap的高效運行。因此根據公司內部實際的大數據平臺分布情況及機房建設情況，將Kylin打造成一個公司內統一的服務平臺是一個更好的選擇。Olap小組對開源版本的Kylin進行了二次開發，并將改進補丁提交了社區。目前的改進主要包括：
</p>
<ul>
<li>
Kylin對Kerberos認證的支持
</li>
<li>
Kylin非Hadoop節點的部署支持
</li>
<li>
多數據源的支持
</li>
</ul>
<p>
在公司內，由于性能以及安全性方面的考量，不同部門的應用會搭建各自的Hive進行數據分析，并且由于公司內還沒有跨機房的Hadoop集群，因此會出現用戶數據在A地方的Hive上，而A機房的Hadoop集群并沒有足夠的計算資源來保證Kylin Olap的高效運行。
</p>
<p>
綜合分析現實的場景之后，我們選擇了公司內最大的hadoop集群作為Kylin Olap的計算引擎集群，保證有充足的存儲以及計算資源。 HBase采用一個獨立的集群，避免Hbase查詢和Hadoop集群任務之間的互相干擾。數據源Hive允許用戶自定義，目前已支持同Hadoop集群下不同Hive 以及不同Hadoop集群下的不同Hive節點使用Kylin Olap服務。根據用戶數據倉庫的實際配置情況可能會出現跨集群的數據源抽取計算， 由于公司同城機房有專線網絡，數據倉庫Hive里的源數據量也遠小于Kylin實際的聚合后的數據存儲（存于Hbase，數據量大小一般為數據源Hive中的10倍以上）， 因此可認為這樣的開銷可以認為帶來的影響不大，并且在我們的測試中得到了印證。
</p>
<h3>
Kylin OLAP與猛犸以及有數的結合
</h3>
<p>
猛犸是網易內部的統一大數據入口平臺，為了讓Kylin更快更好的融入到大平臺中，OLAP小組已計劃在不久之后全面與猛犸大數據平臺進行打通和整合， Kylin Olap 將深度內嵌于猛犸，用戶可以基于猛犸平臺完成Kylin Olap的簡化管理工作。猛犸平臺對接控制節點，作為專業數據建模師的操作入口
</p>
<ul>
<li>
Kylin將利用猛犸的用戶管理功能
</li>
<li>
猛犸將接管用戶項目的創建以及Cube的管理
</li>
<li>
猛犸將原有的Hive數據源徹底與Kylin打通，便于Kylin管理用戶的數據源
</li>
</ul>
<p>
Kylin原生的用戶管理是基于LDAP的，如果不使用LDAP服務需要利用Spring security重新開發一套，網易的內部的猛犸大數據平臺有一套成熟且完善的用戶權限訪問控制體系，因此可以利用現成的機制對Kylin的訪問、修改做保護性的限制。
</p>
<p>
Kylin的Data Cube建模，特別是一些高級的Cube優化功能如RowKey順序、維度分組、分層等需要較高的學習成本，所以認為不適合讓一般的數據分析師來直接操作，我們設計了一套簡化版的Cube 建模流程，以用戶申請——運維審批的方式進行數據的接入。
</p>
<p>
有數是網易內部重要的報表分析平臺，有數將Kylin Olap作為一個單獨的數據源進行支持。已有的以及潛在的Hive查詢客戶可以輕松的將報表遷移到Kylin Olap，使得大數據量下的交互式報表分析成為可能。
</p>
<ul>
<li>
有數能基于在猛犸上創建的Cube創建報表
</li>
<li>
有數主動識別Kylin Cube定義的維度和度量
</li>
<li>
用戶在Kylin Olap允許的范圍內自由操作，完成報表的編輯和查詢。
</li>
</ul>
<p>
Kylin 的數據查詢結果可以用更多更豐富的圖表的方式展示給數據分析人員：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/151ff92232a7751e64c6c4652d3bf2be.png" width="700" height="335" />
</p>
</div>
1. Olap簡介
</h2>
<h3>
Olap的歷史與基本概念
</h3>
<p>
Olap全稱為在線聯機分析應用，是一種對于多維數據分析查詢的解決方案。 典型的Olap應用場景包括銷售、市場、管理等商務報表，預算決算，經濟報表等等。
</p>
<p>
最早的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廠商先后支持。
</p>
<p>
Olap Cube是一種典型的多維數據分析技術，Cube本身可以認為是不同維度數據組成的dataset，一個Olap Cube 可以擁有多個維度（Dimension），以及多個事實（Fact or Measure）。用戶通過Olap工具從多個角度來進行數據的多維分析。通常認為Olap包括三種基本的分析操作： 上卷（rollup）、下鉆（drill down）、切片切塊（slicing and dicing），原始數據經過聚合以及整理后變成一個或多個維度的視圖。
</p>
<h3>
ROLAP和MOLAP
</h3>
<p>
傳統OLAP根據數據存儲方式的不同分為ROLAP（relational olap）以及MOLAP（multi-dimension olap）
</p>
<p>
ROLAP 以關系模型的方式存儲用作多維分析用的數據，優點在于存儲體積小，查詢方式靈活，然而缺點也顯而易見，每次查詢都需要對數據進行聚合計算，為了改善短板，ROLAP使用了列存、并行查詢、查詢優化、位圖索引等技術
</p>
<p>
MOLAP 將分析用的數據物理上存儲為多維數組的形式，形成CUBE結構。維度的屬性值映射成多維數組的下標或者下標范圍，事實以多維數組的值存儲在數組單元中，優勢是查詢快速，缺點是數據量不容易控制，可能會出現維度爆炸的問題。
</p>
<h3>
大數據時代Olap的挑戰
</h3>
<p>
近二十年內，ROLAP技術隨著MPP并行數據庫技術的發展，尤其是列存技術的支持下，實現了分析能力大幅度的跨越提升，同時伴隨著內存成本的進一步降低，單節點內存擴展性增強，集群單節點的查詢性能實現了飛躍，內存數據庫的實用性跨上了一個新臺階，這些技術進步共同作用的結果是類似的技術基本覆蓋了TB級別的數據分析需求。 Hadoop以及相關大數據技術的出現提供了一個幾近無限擴展的數據平臺，在相關技術的支持下，各個應用的數據已突破了傳統OLAP所能支持的容量上界。每天千萬、數億條的數據，提供若干維度的分析模型，大數據OLAP最迫切所要解決的問題就是大量實時運算導致的響應時間遲滯。
</p>
<h2>
2. Apache Kylin 大數據下的Olap解決方案
</h2>
<h3>
Kylin的背景
</h3>
<p>
Kylin 是一個Hadoop生態圈下的MOLAP系統，是ebay大數據部門從2014年開始研發的支持TB到PB級別數據量的分布式Olap分析引擎。其特點包括:
</p>
<ul>
<li>
可擴展的超快的OLAP引擎
</li>
<li>
提供ANSI-SQL接口
</li>
<li>
交互式查詢能力
</li>
<li>
MOLAP Cube 的概念
</li>
<li>
與BI工具可無縫整合
</li>
</ul>
<p>
Kylin典型的應用場景如下：
</p>
<ul>
<li>
用戶數據存在于Hadoop HDFS中，利用Hive將HDFS文件數據以關系數據方式存取，數據量巨大，在500G以上
</li>
<li>
每天有數G甚至數十G的數據增量導入
</li>
<li>
有10個左右為固定的分析維度
</li>
</ul>
<p>
Kylin的核心思想是利用空間換時間，由于查詢方面制定了多種靈活的策略，進一步提高空間的利用率，使得這樣的平衡策略在應用中是值得采用的。
</p>
<h3>
kylin的總體架構
</h3>
<p>
Kylin 作為一個Olap引擎完成了從數據源抓取數據，ETL到自己的存儲引擎，提供REST服務等一系列工作，其架構如圖所示：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/5e7726a77ba720d776183e6fc9e2857a.png" width="700" height="341" />
</p>
<p>
Kylin 的生態圈包括：
</p>
<ul>
<li>
Kylin Core: Kylin 引擎的框架，查詢、任務、以及存儲引擎都集中于此，除此之外還包括一個REST 服務器來響應各種客戶端請求。
</li>
<li>
擴展插件: 各種提供額外特性的插件，如安全認證、SSO等
</li>
<li>
完整性組件: Job管理器，ETL、監控以及報警
</li>
<li>
交互界面: 基于Kylin Core之上的用戶交互界面
</li>
<li>
驅動: 提供了JDBC以及ODBC的連接方式
</li>
</ul>
<h3>
kylin Cube 多維數據的計算
</h3>
<p>
Kylin的多維計算主要是體現在OLAP Cube的計算。Cube由多個Cuboid組合而成，Cuboid上的數據是原始數據聚合的數據，因此創建Cube可以看作是在原始數據導入時做的一個預計算預處理的過程。Kylin的強大之處在于充分利用了Hadoop的MapReduce并行處理的能力，高效處理導入的數據。
</p>
<p>
Kylin的數據來自于Hive，并作為一個Hive的加速器希望最終的查詢SQL類似于直接在Hive上查詢。因此Kylin在建立Cube的時候需要從Hive獲取Hive表的元數據。雖然有建立Cube的過程，但是并不想對普通的查詢用戶暴露Cube的存在。
</p>
<p>
Kylin創建Cube的過程如下圖所示：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/c5c7943ba4d548a0ec85287633c27e4a.png" width="700" height="360" />
</p>
<ol>
<li>
根據Cube定義的事實表以及維度表，利用Hive創建一張寬表
</li>
<li>
抽取事實表上的維度的distinct值，將事實表上的維度以字典樹方式壓縮編碼成目錄，將維度表以字典樹的方式編碼
</li>
<li>
利用MapReduce從第一步得到的寬表文件作為輸入，創建 N－Dimension cuboid，然后每次根據前一步的結果串行生成 N-1 cuboid, N-2 cuboid … 0-Cuboid
</li>
<li>
根據生成的Cuboid數據量計算HTable的Region分割策略，創建HTable，將HFile導入進來
</li>
</ol>
<p>
Kylin與傳統的OLAP一樣，無法應對數據Update的情況（更新數據會導致Cube的失效，需要重建整個Cube）。面對每天甚至每兩個小時這樣固定周期的增量數據，Kylin使用了一種增量Cubing技術來進行快速響應。
</p>
<p>
Kylin的Cube可以根據時間段劃分成多個Segment。在Cube第一次Build完成之后會有一個Segment，在每次增量Build后會產生一個新的Segment。增量Cubing依賴已有的Cube Segments和增量的原始數據。增量Cubing的步驟和新建 Cube的步驟類似，Segment之間以時間段進行區分。
</p>
<p>
增量Cubing所需要面對的原始數據量更小，因此增量Cubing的速度是非常快的。然而隨著Cube Segments的數目增加，一定程度上會影響到查詢的進行，所以在Segments數目到一定數量后可能需要進行Cube Segments的合并操作，實際上merge cube是合成了一個新的大的Cube Segment來替代，Merge操作是一個異步的在線操作，不會對前端的查詢業務產生影響。。
</p>
<p>
合并操作步驟如下：
</p>
<ol>
<li>
遍歷指定的Cube Segment
</li>
<li>
合并維度字典目錄和維度表快照
</li>
<li>
利用MapReduce合并他們的 N-Dimension cuboid
</li>
<li>
將cuboid轉換成HFile，生成新的HTable，替代原有的多個HTable
</li>
</ol>
<h3>
Kylin對傳統MOLAP的改進
</h3>
<p>
計算Cube的存儲代價以及計算代價都是比較大的， 傳統OLAP的維度爆炸的問題Kylin也一樣會遇到。 Kylin提供給用戶一些優化措施，在一定程度上能降低維度爆炸的問題：
</p>
<ol>
<li>
Cube 優化：
</li>
</ol>
<ul>
<li>
Hierachy Dimension
</li>
<li>
Derived Dimension
</li>
<li>
Group Dimensions
</li>
</ul>
<p>
Hierachy Dimension， 一系列具有層次關系的Dimension組成一個Hierachy， 比如年、月、日組成了一個Hierachy， 在Cube中，如果不設置Hierarchy， 會有 年、月、日、年月、年日、月日 6個cuboid， 但是設置了Hierarchy之后Cuboid增加了一個約束，希望低Level的Dimension一定要伴隨高Level的Dimension 一起出現。設置了Hierachy Dimension 能使得需要計算的維度組合減少一半。
</p>
<p>
Derived Dimension, 如果在某張維度表上有多個維度，那么可以將其設置為Derived Dimension， 在Kylin內部會將其統一用維度表的主鍵來替換，以此來達到降低維度組合的數目，當然在一定程度上Derived Dimension 會降低查詢效率，在查詢時，Kylin使用維度表主鍵進行聚合后，再通過主鍵和真正維度列的映射關系做一次轉換，在Kylin內部再對結果集做一次聚合后返回給用戶
</p>
<p>
Group Dimension， 這是一個將維度進行分組，以求達到降低維度組合數目的手段。不同分組的維度之間不會進行組合計算。Group的優化措施與查詢SQL緊密依賴，可以說是為了查詢的定制優化。 維度組合從2的（k+m+n）次冪降低到 2的k次冪加2的m次冪加2的n次冪。如果查詢的維度是夸Group的，那么Kylin需要以較大的代價從N－Cuboid中聚合得到所需要的查詢結果
</p>
<ol>
<li>
數據壓縮：
</li>
</ol>
<p>
Kylin針對維度字典以及維度表快照采用了特殊的壓縮算法，對于Hbase中的聚合計算數據利用了Hadoop的LZO或者是Snappy，從而保證存儲在Hbase以及內存中的數據盡可能的小。其中維度字典以及維度表快照的壓縮考慮到DataCube中會出現非常多的重復的維度成員值，最直接的處理方式就是利用數據字典的方式將維度值映射成ID， Kylin中采用了Trie樹的方式對維度值進行編碼。
</p>
<ol>
<li>
distinct count聚合查詢優化：
</li>
</ol>
<p>
Kylin 采用了HypeLogLog的方式來計算Distinc Count。好處是速度快，缺點是結果是一個近似值，會有一定的誤差。在非計費等通常的場景下Distinct Count的統計誤差應用普遍可以接受。具體的算法可見Paper： http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf 本文不再贅述
</p>
<h3>
kylin SQL查詢的實現
</h3>
<p>
ANSI SQL查詢是Kylin 非常明顯的優勢。Kylin的SQL語法解析依賴于另一個開源數據管理框架 Apache Calcite， Calcite即之前的Optiq，是一個沒有存儲模塊的數據庫，即不管理數據存儲、不包含數據處理的算法，不包含元信息的存儲。因此它非常適合來做一個應用到存儲引擎之間的中間層。在Calcite的基礎之上只要為存儲引擎寫一個專用的適配器（Adapter）即可形成一個功能豐富的支持DML甚至DDL的“類數據庫”。
</p>
<p>
Kylin完成了一個定制的Adapter，在Calcite完成SQL解析，形成語法樹（AST）之后，由Kylin定義語法樹各個節點的執行規則來進行查詢。Calcite在遍歷語法樹節點后生成一個Kylin描述查詢模型的Digest， Kylin會為此Digest去判斷是否有匹配的Cube。如果有與查詢匹配的Cube，即選擇一個查詢代價最小的Cube進行查詢（Kylin Cube的查詢代價計算目前是一個開放接口，可以根據維度數目，可以根據數據量大小來計算Cost）
</p>
<p>
Kylin目前的多維數據存儲引擎是HBase， Kylin利用了HBase的Coprocessor機制在HBase的Region Server完成部分聚合以及全部過濾操作，在Hbase Scan時提前進行計算，利用HBase多個Region Server的計算能力加速Kylin的SQL查詢。目前Kylin仍然有部分查詢語法不支持，特別是過濾器Where部分的約束較多、對SQL有一定的要求，但是如果有針對性的對Coprocessor部分進行改造相信SQL兼容度可以有大幅的提升。
</p>
<h3>
kylin 與 RTOLAP
</h3>
<p>
Kylin 可以說是與市面上流行的Presto、SparkSQL、Impala等直接在原始數據上查詢的系統（暫且歸于RTOLAP）走了一條完全不同的道路。 前者在如何快速求得預計算結果，以及優化查詢解析使得更多的查詢能用上預計算結果方面在優化。后續Kylin的版本會改進預計算引擎，優化預計算速度，使得Kylin可以變成一個近似實時的分析引擎。 而像Presto，SparkSQL等是著重于優化查詢數據的過程環節，像一些其它的數據倉庫一樣，使用列存、壓縮、并行查詢等技術，優化查詢。這種方案的好處就在于擴展性強、能適配更廣泛的查詢。但是在查詢速度上，可以說Kylin 要比ROLAP 至少快上一個數量級，所以對與查詢響應時間要求較高的應用，Kylin是最好的選擇。
</p>
<h2>
3. Kylin在網易
</h2>
<h3>
Kylin服務化
</h3>
<p>
在網易，Kylin作為大數據平臺的Olap查詢模塊，可以為公司的各種分析類需求以及應用提供服務。所有數據存在Hadoop Hive 上的數據都能夠通過Kylin Olap 引擎進行加速查詢。在公司內部Kylin作為一個統一平臺，與各產品的數據倉庫進行接駁。
</p>
<p>
目前Kylin的部署架構如下：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/89cd98046b25def01e06bc92b2b842c9.png" width="700" height="395" />
</p>
<p>
Kylin集群由多個查詢節點以及控制節點組成。 控制節點唯一，負責集群項目、任務調度與Cube增刪查改。 多個查詢節點前用Nginx做負載均衡，后段節點可按需水平擴容。前端可同時支持JDBC與ODBC的客戶端查詢。
</p>
<h3>
Kylin性能表現
</h3>
<p>
在Kylin上線前，我們選取了公司內部原有的一些報表業務進行過性能對比，對比內容在相同的數據下、Kylin查詢與Mondrian 結合Oracle的查詢比較。
</p>
<p>
測試結果通過數據量較大的DataStream報表來進行比較：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/952f6a7b09c16e9bf27ee6e463dc1194.png" width="480" height="298" />
</p>
<p>
再看Kylin的吞吐量，利用Haproxy進行請求轉發后隨著Kylin服務器的增加吞吐量的表現：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/21289e2125a98587a20221f6527630da.png" width="460" height="284" />
</p>
<h3>
網易對Kylin的改進
</h3>
<p>
原生的社區版Kylin 是需要部署在一個統一底層的Hadoop、Hive、HBase集群之上的。而網易內部的大數據平臺由于各種原因，分為了多個Hadoop集群、各應用會在不同的Hadoop集群上建立Hive數據倉庫。 最原始而自然的想法就是在每一個Hadoop環境上部署一套Kylin服務來滿足不同的需求，但是集群資源管理、計算資源調度、管理運維的復雜性都會是一個比較突出的問題。例如用戶數據在A機房的Hive上，而A機房的Hadoop集群并沒有足夠的計算資源來保證Kylin Olap的高效運行。因此根據公司內部實際的大數據平臺分布情況及機房建設情況，將Kylin打造成一個公司內統一的服務平臺是一個更好的選擇。Olap小組對開源版本的Kylin進行了二次開發，并將改進補丁提交了社區。目前的改進主要包括：
</p>
<ul>
<li>
Kylin對Kerberos認證的支持
</li>
<li>
Kylin非Hadoop節點的部署支持
</li>
<li>
多數據源的支持
</li>
</ul>
<p>
在公司內，由于性能以及安全性方面的考量，不同部門的應用會搭建各自的Hive進行數據分析，并且由于公司內還沒有跨機房的Hadoop集群，因此會出現用戶數據在A地方的Hive上，而A機房的Hadoop集群并沒有足夠的計算資源來保證Kylin Olap的高效運行。
</p>
<p>
綜合分析現實的場景之后，我們選擇了公司內最大的hadoop集群作為Kylin Olap的計算引擎集群，保證有充足的存儲以及計算資源。 HBase采用一個獨立的集群，避免Hbase查詢和Hadoop集群任務之間的互相干擾。數據源Hive允許用戶自定義，目前已支持同Hadoop集群下不同Hive 以及不同Hadoop集群下的不同Hive節點使用Kylin Olap服務。根據用戶數據倉庫的實際配置情況可能會出現跨集群的數據源抽取計算， 由于公司同城機房有專線網絡，數據倉庫Hive里的源數據量也遠小于Kylin實際的聚合后的數據存儲（存于Hbase，數據量大小一般為數據源Hive中的10倍以上）， 因此可認為這樣的開銷可以認為帶來的影響不大，并且在我們的測試中得到了印證。
</p>
<h3>
Kylin OLAP與猛犸以及有數的結合
</h3>
<p>
猛犸是網易內部的統一大數據入口平臺，為了讓Kylin更快更好的融入到大平臺中，OLAP小組已計劃在不久之后全面與猛犸大數據平臺進行打通和整合， Kylin Olap 將深度內嵌于猛犸，用戶可以基于猛犸平臺完成Kylin Olap的簡化管理工作。猛犸平臺對接控制節點，作為專業數據建模師的操作入口
</p>
<ul>
<li>
Kylin將利用猛犸的用戶管理功能
</li>
<li>
猛犸將接管用戶項目的創建以及Cube的管理
</li>
<li>
猛犸將原有的Hive數據源徹底與Kylin打通，便于Kylin管理用戶的數據源
</li>
</ul>
<p>
Kylin原生的用戶管理是基于LDAP的，如果不使用LDAP服務需要利用Spring security重新開發一套，網易的內部的猛犸大數據平臺有一套成熟且完善的用戶權限訪問控制體系，因此可以利用現成的機制對Kylin的訪問、修改做保護性的限制。
</p>
<p>
Kylin的Data Cube建模，特別是一些高級的Cube優化功能如RowKey順序、維度分組、分層等需要較高的學習成本，所以認為不適合讓一般的數據分析師來直接操作，我們設計了一套簡化版的Cube 建模流程，以用戶申請——運維審批的方式進行數據的接入。
</p>
<p>
有數是網易內部重要的報表分析平臺，有數將Kylin Olap作為一個單獨的數據源進行支持。已有的以及潛在的Hive查詢客戶可以輕松的將報表遷移到Kylin Olap，使得大數據量下的交互式報表分析成為可能。
</p>
<ul>
<li>
有數能基于在猛犸上創建的Cube創建報表
</li>
<li>
有數主動識別Kylin Cube定義的維度和度量
</li>
<li>
用戶在Kylin Olap允許的范圍內自由操作，完成報表的編輯和查詢。
</li>
</ul>
<p>
Kylin 的數據查詢結果可以用更多更豐富的圖表的方式展示給數據分析人員：
</p>
<p>
<img alt="Kylin 大數據時代的OLAP利器" src="https://simg.open-open.com/show/151ff92232a7751e64c6c4652d3bf2be.png" width="700" height="335" />
</p>
</div>
</div>
來自： http://www.bitstech.net/2016/01/04/kylin-olap/
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！