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典型的應用場景如下：

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

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

3. * 有10個以內較為固定的分析維度

Kylin的核心思想是利用空間換時間，在資料ETL匯入OLAP引擎時提前計算各維度的聚合結果並持久化儲存， 由於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的過程如下：

1. 根據Cube定義的事實表以及維度表，利用Hive建立一張寬表
2. 抽取事實表上的維度的distinct值，將事實表上的維度以字典樹方式壓縮編碼成目錄，將維度表以字典樹的方式編碼
3. 利用MapReduce從第一步得到的寬表文件作為輸入，建立 N－Dimension cuboid，然後每次根據前一步的結果序列生成 N-1 cuboid, N-2 cuboid ... 0-Cuboid
4. 根據生成的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的合併操作，合併是一個非同步操作，並不會影響到正常的查詢服務。合併操作步驟如下：

1. 遍歷指定的Cube Segment
2. 合併維度字典目錄和維度錶快照
3. 利用MapReduce合併他們的 N-Dimension cuboid
4. 將cuboid轉換成HFile，生成新的HTable，替代原有的多個HTable 實際上merge cube是合成了一個新的大的Cube Segment來替代，Merge操作是一個非同步的線上操作，不會對前端的查詢業務產生影響。。

Kylin對傳統MOLAP的改進

Kylin Cube的儲存代價以及計算代價都是比較大的， 傳統OLAP的維度爆炸的問題Kylin也一樣會遇到。 Kylin提供給使用者一些優化措施,包括減輕維度爆炸的問題，提高資料查詢效率等：

Cube 建模優化：

1. Hierachy Dimension（層級維度）
2. Derived Dimension （衍生維度）

3. Group Dimensions （維度組）

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

5. Derived Dimension, 如果在某張維度表上有多個維度，那麼可以將其設定為Derived Dimension， 在Kylin內部會將其統一用維度表的主鍵來替換，以此來達到降低維度組合的數目，當然在一定程度上Derived Dimension 會降低查詢效率，在查詢時，Kylin使用維度表主鍵進行聚合後，再通過主鍵和真正維度列的對映關係做一次轉換，在Kylin內部再對結果集做一次聚合後返回給使用者
6. Group Dimension， 這是一個將維度進行分組，以求達到降低維度組合數目的手段。不同分組的維度之間不會進行組合計算。Group的優化措施與查詢SQL緊密依賴，可以說是為了查詢的定製優化。 維度組合從2的（k+m+n）次冪降低到 2的k次冪加2的m次冪加2的n次冪。如果查詢的維度是誇Group的，那麼Kylin需要以較大的代價從N－Cuboid中聚合得到所需要的查詢結果

資料壓縮：

Kylin針對維度字典以及維度錶快照採用了特殊的壓縮演算法，保證儲存在Hbase以及記憶體中的資料儘可能的小。 由於DataCube中會出現非常多的重複的維度值，因此直觀的做法就是利用資料字典的方式將維度值對映成ID， Kylin中採用了Trie樹的方式對維度值進行編碼

distinct count聚合查詢優化：

kylin SQL查詢的實現

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

Kylin完成了一個針對性的Calcite Adapter，在Calcite完成SQL解析，形成語法樹（AST）之後，Kylin定義語法樹各個節點的執行規則，以及查詢優化準則。Calcite在遍歷語法樹節點後生成一個Kylin描述查詢模型的SQL 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 與 RTOLAP

Kylin 可以說是與市面上流行的RTOLAP走了一條完全不同的道路。 Kylin在如何快速求得預計算結果，以及優化查詢解析使得更多的查詢能用上預計算結果方面在優化，後續Kylin的版本會優化預計算速度，使得Kylin可以變成一個近似實時的分析引擎。然而其缺點就是SQL支援方面可能在一定程度上會有所犧牲，儲存開銷也會比較大， 而像Presto，SparkSQL，Hawq等是著重於優化查詢資料的過程環節，像一些其它的資料倉庫一樣，使用列存、壓縮、並行查詢等技術，優化查詢。這種方案的好處就在於擴充套件性強、能適配更廣泛的查詢， 然而由於每次的聚合計算是 On Fly的，因此效能上相較Kylin還是有所不如。

3. Kylin在網易

Kylin服務化

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

目前Kylin的部署架構如下：

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

Kylin效能表現

在Kylin上線前，我們針對NRPT的報表業務進行過效能對比，對比內容在相同的資料下、Kylin查詢與Mondrian 結合Oracle的查詢比較。 我們選取了資料量較大的DataStream報表業務進行了測試：

再看Kylin的吞吐量，利用Haproxy進行請求轉發後隨著Kylin伺服器的增加吞吐量的表現：

根據測試結果可見，Kylin OLAP在效能上能達到秒級，並且在查詢吞吐量可以通過增加查詢伺服器來達到線性擴充套件的目的

網易對Kylin的改進

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

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

綜合分析現實的場景之後，我們選擇了公司內最大的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的簡化管理工作。猛獁平臺對接控制節點，作為資料模型師的操作入口

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

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

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