Apache Kylin 概述

1 Kylin是什麼

今天，隨著移動互聯網、物聯網、AI等技術的快速興起，數據成為了所有這些技術背後最重要，也是最有價值的“資產”。如何從數據中獲得有價值的信息？這個問題驅動了相關技術的發展，從最初的基於文件的檢索、分析程式，到數據倉庫理念的誕生，再到基於資料庫的商業智能分析。而現在，這一問題已經變成瞭如何從海量的超大規模數據中快速獲 取有價值的信息，新的時代、新的挑戰、新的技術必然應運而生。

在大數據處理技術領域，用戶最普遍的訴求就是希望以很簡易的方式從大數據平臺上快速獲取查詢結果，同時也希望傳統的商務智能工具能夠直接和大數據平臺連接起來，以便使用這些工具做數據分析。目前已經出現了很多優秀的SQL on Hadoop引擎，包括Hive、Impala及 SparkSQL等，這些技術的出現和應用極大地降低了用戶使用Hadoop平臺的難度。
為了進一步滿足“在高併發、大數據量的情況下，使用標準SQL查詢聚合結果集能夠達到毫秒級”這一應用場景，Apache Kylin應運而生，在 eBay孵化並最終貢獻給開源社區。Apache Kylin是2013年由eBay 在上海的一個中國工程師團隊發起的、基於Hadoop大數據平臺的開源 OLAP引擎，它採用多維立方體預計算技術，利用空間換時間的方法，把很多分鐘級別乃至小時級別的大數據查詢速度一下子提升到了亞秒級別，極大地提高了數據分析的效率，填補了業界在這方面的空白。該引擎為超大規模數據集上的互動式大數據分析打開了大門。

2 為什麼要用Kylin

自從10年前Hadoop誕生以來，大數據的存儲和批處理問題均得到了 妥善解決，而如何高速地分析數據也就成為了下一個挑戰。於是各式各 樣的“SQLon Hadoop”技術應運而生，其中以Hive為代表，Impala、Presto、 Phoenix、Drill、SparkSQL等緊隨其後。它們的主要技術是“大規模並行處理”（Massive Parallel Processing，MPP）和“列式存儲”（Columnar Storage）。 大規模並行處理可以調動多台機器一起進行並行計算，用線性增加的資源來換取計算時間的線性下降。列式存儲則將記錄按列存放，這樣做不僅可以在訪問時只讀取需要的列，還可以利用存儲設備擅長連續讀取的特點，大大提高讀取的速率。這兩項關鍵技術使得Hadoop上的SQL查詢 速度從小時提高到了分鐘。

然而分鐘級別的查詢響應仍然離互動式分析的現實需求還很遠。分析師敲入查詢指令，按下回車，還需要去倒杯咖啡，靜靜地等待查詢結 果。得到結果之後才能根據情況調整查詢，再做下一輪分析。如此反覆， 一個具體的場景分析常常需要幾小時甚至幾天才能完成，效率低下。 這是因為大規模並行處理和列式存儲雖然提高了計算和存儲的速 度，但並沒有改變查詢問題本身的時間複雜度，也沒有改變查詢時間與 數據量成線性增長的關係這一事實。假設查詢1億條記錄耗時1分鐘，那麼查詢10億條記錄就需10分鐘，100億條記錄就至少需要1小時40分鐘。 當然，可以用很多的優化技術縮短查詢的時間，比如更快的存儲、更高效 的壓縮演算法，等等，但總體來說，查詢性能與數據量呈線性相關這一點是 無法改變的。雖然大規模並行處理允許十倍或百倍地擴張計算集群，以 期望保持分鐘級別的查詢速度，但購買和部署十倍或百倍的計算集群又 怎能輕易做到，更何況還有高昂的硬體運維成本。

另外，對於分析師來說，完備的、經過驗證的數據模型比分析性能更 加重要，直接訪問紛繁複雜的原始數據併進行相關分析其實並不是很友 好的體驗，特別是在超大規模的數據集上，分析師將更多的精力花在了 等待查詢結果上，而不是在更加重要的建立領域模型上。

3 Kylin怎樣解決關鍵問題

Apache Kylin的初衷就是要解決千億條、萬億條記錄的秒級查詢問 題，其中的關鍵就是要打破查詢時間隨著數據量成線性增長的這個規 律。仔細思考大數據OLAP，可以註意到兩個事實。

• 大數據查詢要的一般是統計結果，是多條記錄經過聚合函數計算後 的統計值。原始的記錄則不是必需的，或者訪問頻率和概率都極低。
• 聚合是按維度進行的，由於業務範圍和分析需求是有限的，有意義 的維度聚合組合也是相對有限的，一般不會隨著數據的膨脹而增長。
  基於以上兩點，我們可以得到一個新的思路——“預計算”。應儘量多 地預先計算聚合結果，在查詢時刻應儘量使用預算的結果得出查詢結果，從而避免直接掃描可能無限增長的原始記錄。

舉例來說，使用如下的SQL來查詢10月1日那天銷量最高的商品：

select item,sum(sell_amount) 
from sell_details
where sell_data=’2016-10-1’
group by item
order by sum(sell_amount) desc; 

用傳統的方法時需要掃描所有的記錄，再找到10月1日的銷售記錄，然後按商品聚合銷售額，最後排序返回。假如10月1日有1億條交易，那麼 查詢必須讀取並累計至少1億條記錄，且這個查詢速度會隨將來銷量的增 加而逐步下降。如果日交易量提高一倍到2億，那麼查詢執行的時間可能 也會增加一倍。

而使用預計算的方法則會事先按維度[sell_date，item]計算 sum（sell_amount）並存儲下來，在查詢時找到10月1日的銷售商品就可以 直接排序返回了。讀取的記錄數最大不會超過維度[sell_date，item]的組 合數。顯然這個數字將遠遠小於實際的銷售記錄，比如10月1日的1億條 交易包含了100萬條商品，那麼預計算後就只有100萬條記錄了，是原來 的百分之一。並且這些記錄已經是按商品聚合的結果，因此又省去了運 行時的聚合運算。從未來的發展來看，查詢速度只會隨日期和商品數目 的增長而變化，與銷售記錄的總數不再有直接聯繫。假如日交易量提高 一倍到2億，但只要商品的總數不變，那麼預計算的結果記錄總數就不會 變，查詢的速度也不會變。

“預計算”就是Kylin在“大規模並行處理”和“列式存儲”之外，提供給大數據分析的第三個關鍵技術。

4 Kylin的工作原理

Apache Kylin的工作原理本質上是MOLAP（Multidimensional Online Analytical Processing）Cube，也就是多維立方體分析。這是數據分析中相當經典的理論，在關係資料庫年代就已經有了廣泛的應用，下麵將對其做簡要介紹。

4.1 維度和度量簡介

在說明MOLAP Cube之前需要先介紹一下維度（Dimension）和度量 （Measure）這兩個概念。 簡單來講，維度就是觀察數據的角度。比如電商的銷售數據，可以從 時間的維度來觀察（如圖1-2的左側所示），也可以進一步細化，從時間和 地區的維度來觀察（如圖1-2的右側所示）。維度一般是一組離散的值，比 如時間維度上的每一個獨立的日期，或者商品維度上的每一件獨立的商 品。因此統計時可以把維度值相同的記錄聚合在一起，然後應用聚合函 數做累加、平均、去重覆計數等聚合計算。

度量就是被聚合的統計值，也是聚合運算的結果，它一般是連續的 值，如圖1-2中的銷售額，抑或是銷售商品的總件數。通過比較和測算度 量，分析師可以對數據進行評估，比如今年的銷售額相比去年有多大的 增長，增長的速度是否達到預期，不同商品類別的增長比例是否合理等。

4.2 Cube和Cuboid

有了維度和度量，一個數據表或數據模型上的所有欄位就可以分類 了，它們要麼是維度，要麼是度量（可以被聚合）。於是就有了根據維度和 度量做預計算的Cube理論。

給定一個數據模型，我們可以對其上的所有維度進行組合。對於N個 維度來說，組合的所有可能性共有2N 種。對於每一種維度的組合，將度 量做聚合運算，然後將運算的結果保存為一個物化視圖，稱為Cuboid。所 有維度組合的Cuboid作為一個整體，被稱為Cube。所以簡單來說，一個 Cube就是許多按維度聚合的物化視圖的集合。

下麵來列舉一個具體的例子。假定有一個電商的銷售數據集，其中 維度包括時間（Time）、商品（Item）、地點（Location）和供應商（Supplier）， 度量為銷售額（GMV）。那麼所有維度的組合就有2 4 =16種（如圖1-3所 示），比如一維度（1D）的組合有[Time]、[Item]、[Location]、[Supplier]4種； 二維度（2D）的組合有[Time，Item]、[Time，Location]、[Time、Supplier]、 [Item，Location]、[Item，Supplier]、[Location，Supplier]6種；三維度（3D）的 組合也有4種；最後零維度（0D）和四維度（4D）的組合各有1種，總共就有 16種組合。

計算Cuboid，即按維度來聚合銷售額。如果用SQL語句來表達計算 Cuboid[Time，Loca-tion]，那麼SQL語句如下：

Select Time,Location,Sum(GMV) as GMV from Sales group by Time,Location

將計算的結果保存為物化視圖，所有Cuboid物化視圖的總稱就是 Cube。

4.3 工作原理

Apache Kylin的工作原理就是對數據模型做Cube預計算，並利用計算 的結果加速查詢，具體工作過程如下。

1）指定數據模型，定義維度和度量。
2）預計算Cube，計算所有Cuboid並保存為物化視圖。
3）執行查詢時，讀取Cuboid，運算，產生查詢結果。
由於Kylin的查詢過程不會掃描原始記錄，而是通過預計算預先完成 表的關聯、聚合等複雜運算，並利用預計算的結果來執行查詢，因此相比 非預計算的查詢技術，其速度一般要快一到兩個數量級，並且這點在超 大的數據集上優勢更明顯。當數據集達到千億乃至萬億級別時，Kylin的 速度甚至可以超越其他非預計算技術1000倍以上。

5 Kylin的技術架構

Apache Kylin系統可以分為線上查詢和離線構建兩部分，技術架構如 圖1-4所示，線上查詢的模塊主要處於上半區，而離線構建則處於下半區。

我們首先來看看離線構建的部分。從圖1-4可以看出，數據源在左側，目前主要是Hadoop Hive，保存著待分析的用戶數據。根據元數據的 定義，下方構建引擎從數據源抽取數據，並構建Cube。數據以關係表的形 式輸入，且必須符合星形模型（Star Schema）（更複雜的雪花模型在成文時塊做任意的擴展和替換。

Kylin的三大依賴模塊分別是數據源、構建引擎 和存儲引擎。在設計之初，作為Hadoop家族的一員，這三者分別是Hive、 MapReduce和HBase。但隨著推廣和使用的深入，漸漸有用戶發現它們均 存在不足之處。比如，實時分析可能會希望從Kafka導入數據而不是從 Hive；而Spark的迅速崛起，又使我們不得不考慮將MapReduce替換為 Spark，以期大幅提高Cube的構建速度；至於HBase，它的讀性能可能還不 如Cassandra或Kudu等。可見，是否可以將一種技術替換為另一種技術已成為一個常見的問題。於是我們對Kylin1.5版本的系統架構進行了重構，將數據源、構建引擎、存儲引擎三大依賴抽象為介面，而Hive、 MapReduce、HBase只是預設實現。深度用戶可以根據自己的需要做二次開發，將其中的一個或多個替換為更適合的技術。

這也為Kylin技術的與時俱進埋下了伏筆。如果有一天更先進的分佈 式計算技術取代了MapReduce，或者更高效的存儲系統全面超越了 HBase，Kylin可以用較小的代價將一個子系統替換掉，從而保證Kylin能 夠緊跟技術發展的最新潮流，從而保持最高的技術水平。 可擴展架構也帶來了額外的靈活性，比如，它可以允許多個引擎同 時並存。例如Kylin可以同時對接Hive、Kafka和其他第三方數據源；抑或 用戶可以為不同的Cube指定不同的構建引擎或存儲引擎，以期達到最極 致的性能和功能定製。

6 Kylin的主要特點

Apache Kylin的主要特點包括支持SQL介面、支持超大數據集、秒級 響應、可伸縮性、高吞吐率、BI工具集成等。

6.1 標準SQL介面

Apache Kylin以標準SQL作為對外服務的主要介面。因為SQL是絕大 多數分析人員最熟悉的工具，同時也是大多數應用程式使用的編程接 口。儘管Kylin內部以Cube技術為核心，對外卻沒有選用 MDX（MultiDimensional eXpressions）作為介面。雖然MDX作為OLAP查詢 語言，從學術上來說，它是更加適合Kylin的選擇，然而實踐表明，SQL簡 單易用，代表了絕大多數用戶的第一需求，這也是Kylin能夠快速推廣的 一個關鍵。

SQL需要以關係模型作為支撐。Kylin使用的查詢模型是數據源中的 關係模型表，一般而言，也就是指Hive表。終端用戶只需要像原來查詢 Hive表一樣編寫SQL，就可以無縫地切換到Kylin，幾乎不需要額外的學 習，甚至原本的Hive查詢也因為與SQL同源，大多都無須修改就能直接在 Kylin上運行。 Apache Kylin在將來也可能會推出MDX介面。事實上已經有方法可 以通過MDX轉SQL的工具，讓Kylin也能支持MDX。

6.2 支持超大數據集

Apache Kylin對大數據的支撐能力可能是目前所有技術中最為領先 的。早在2015年eBay的生產環境中Kylin就能支持百億記錄的秒級查詢， 之後在移動的應用場景下又有了千億記錄秒級查詢的案例。這些都是實 際場景的應用，而非實驗室中的理論數據。

因為使用了Cube預計算技術，在理論上，Kylin可以支撐的數據集大 小沒有上限，僅受限於存儲系統和分散式計算系統的承載能力，並且查 詢速度不會隨數據集的增大而減慢。Kylin在數據集規模上的局限性主要 在於維度的個數和基數。它們一般由數據模型來決定，不會隨著數據規 模的增長而線性增長，這也意味著Kylin對未來數據的增長有著更強的適 應能力。

對於Apache Kylin，除了eBay將其作為孵化公司有廣泛應用之外，國內外一線的互聯網公司對此幾乎都有大規模的 使用，包括百度、網易、京東、美團、唯品會、Expedia等。此外，其在傳統 行業中也有非常多的實際應用，包括中國移動、銀聯、國美等。據不完全 統計，真實上線的Apache Kylin用戶已經超過了一百多家，在開源後一年 多一點的時間內能有如此大的全球用戶基礎，足見Kylin在處理超大規模 數據集上的能力和優勢。

6.3 亞秒級響應

Apache Kylin擁有優異的查詢響應速度，這點得益於預計算，很多復 雜的計算，比如連接、聚合，在離線的預計算過程中就已經完成，這大大 降低了查詢時刻所需要的計算量，提高了響應速度。

根據可查詢到的公開資料可以得知，Apache Kylin在某生產環境中 90%的查詢可以在3s內返回結果。這並不是說一小部分SQL相當快，而是 在數萬種不同SQL的真實生產系統中，絕大部分的查詢都非常迅速；在另 外一個真實的案例中，對1000多億條數據構建了立方體，90%的查詢性能 都在1.18s以內，可見Kylin在超大規模數據集上表現優異。這與一些只在 實驗室中，只在特定查詢情況下採集的性能數據不可同日而語。當然並 不是使用Kylin就一定能獲得最好的性能。針對特定的數據及查詢模式， 往往需要做進一步的性能調優、配置優化等，性能調優對於充分利用好 Apache Kylin至關重要。

6.4 可伸縮性和高吞吐率

在保持高速響應的同時，Kylin有著良好的可伸縮性和很高的吞吐 率。圖1-5是來自網易的性能分享。圖1-5中左側是Kylin查詢速度與 Mondrian/Oracle的對比，可以看到在3個測試查詢中，Kylin分別比 Mondrian/Oracle快147倍、314倍和59倍。

同時，圖1-5中右側展現了Kylin的吞吐率及其可伸縮性。在只有1個 Kylin實例的情況下，Kylin每秒可以處理近70個查詢，已經遠遠高於每秒 20個查詢的一般水平。更為理想的是，隨著伺服器的增加，吞吐率也呈線 性增加，存在4個實例時可達到每秒230個查詢左右，而這4個實例僅部署 在一臺機器上，理論上添加更多的應用伺服器後可以支持更大的併發 率。

這主要還是歸功於預計算降低了查詢時所需的計算總量，令Kylin可 以在相同的硬體配置下承載更多的併發查詢。

6.5 BI及可視化工具集成

Apache Kylin提供了豐富的API，以與現有的BI工具集成，具體包括 如下內容。

• ODBC介面，與Tableau、Excel、Power BI等工具集成。
• JDBC介面，與Saiku、BIRT等Java工具集成。
• Rest API，與JavaScript、Web網頁集成。

分析師可以沿用他們最熟悉的BI工具與Kylin一同工作，或者在開放 的API上做二次開發和深度定製。

另外，Kylin核心開發團隊也貢獻了Apache Zeppelin的插件，現在已 經可以用Zeppelin來訪問Kylin服務。

6.6 與其他開源產品比較

與Apache Kylin一樣致力於解決大數據查詢問題的其他開源產品也 有不少，比如Apache Drill、Apache Impala、Druid、Hive、 Presto（Facebook）、SparkSQL等。本節試圖將Kylin與它們做一個簡單的比 較。 從底層技術的角度來看，這些開源產品有很大的共性，一些底層技 術幾乎被所有的產品一致採用，Kylin也不例外。

• 大規模並行處理：可以通過增加機器的方式來擴容處理速度，在相 同的時間里處理更多的數據。
• 列式存儲：通過按列存儲提高單位時間里數據的I/O吞吐率，還能跳 過不需要訪問的列。
• 索引：利用索引配合查詢條件，可以迅速跳過不符合條件的數據塊， 僅掃描需要掃描的數據內容。
• 壓縮：壓縮數據然後存儲，使得存儲的密度更高，在有限的I/O速率 下，在單位時間里讀取更多的記錄。
  綜上所述，我們可以註意到，所有這些方法都只是提高了單位時間 內處理數據的能力，當大家都一致採用這些技術時，它們之間的區別將只停留在實現層面的代碼細節上。最重要的是，這些技術都不會改變一 個事實，那就是處理時間與數據量之間的正比例關係。當數據量翻倍時， MPP（在不擴容的前提下）需要翻倍的時間來完成計算；列式存儲需要翻 倍的存儲空間；索引下符合條件的記錄數也會翻倍；壓縮後的數據大小也 還是之前的兩倍。因此查詢速度也會隨之變成之前的兩倍。當數據量成 十倍百倍地增長時，這些技術的查詢速度就會成十倍百倍地下降，最終 變得不能接受。

Apache Kylin的特色在於，在上述的底層技術之外，另闢蹊徑地使用 了獨特的Cube預計算技術。預計算事先將數據按維度組合進行了聚合， 將結果保存為物化視圖。經過聚合，物化視圖的規模就只由維度的基數 來決定，而不再隨著數據量的增長呈線性增長。以電商為例，如果業務擴 張，交易量增長了10倍，只要交易數據的維度不變（供應商/商品數量不 變），聚合後的物化視圖將依舊是原先的大小，查詢的速度也將保持不變。

與那些類似產品相比，這一底層技術的區別使得Kylin從外在功能上 呈現出了不同的特性，具體如下。

• SQL介面：除了Druid以外，所有的產品都支持SQL或類SQL介面。巧 合的是，Druid也是除了Kylin以外，查詢性能相對更好的一個。這點除了 Druid有自己的存儲引擎之外，可能還得益於其較為受限的查詢能力。

• 大數據支持：大多數產品的能力在億級到十億級數據量之間，再大 的數據量將顯著降低查詢的性能。而Kylin因為採用預計算技術，因此查 詢速度不受數據量限制。有實際案例證明數據量在千億級別時，Kylin系 統仍然能夠保有秒級別的查詢性能。

• 查詢速度：如前文所述，一般產品的查詢速度都會不可避免地隨著 數據量的增長而下降，而Kylin則能夠在數據量成倍增長的同時，查詢速 度保持不變，而且這個差距也將隨著數據量的成倍增長而變得愈加明顯。

• 吞吐率：根據之前的實驗數據，Kylin的單例吞吐量一般在每秒70個 查詢左右，並且可以線性擴展，而普通的產品因為所有計算都在查詢時 完成，所以需要調動集群的更多資源才能完成查詢，通常極限在每秒20 個查詢左右，而且擴容成本較高，需要擴展整個集群。相對的，Kylin系統 因為瓶頸不在整個集群，而在於Kylin伺服器，因此只需要增加Kylin服務 器就能成倍地提高吞吐率，擴容成本低廉。

7 小結

Kylin通過預計算，把計算結果集保存在HBase中，原有的基於行的關係模型被轉換成基於鍵值對的列式存儲；通過維度組合作為HBase的Rowkey，在查詢訪問時不再需要昂貴的表掃描，這為高速高併發分析帶來了可能；Kylin提供了標準SQL查詢介面，支持大多數的SQL函數，同時也支持ODBC/JDBC的方式和主流的BI產品無縫集成。

本文介紹了Apache Kylin的歷史背景和技術特點。尤其是它基於預計算的大數據查詢原理，
理論上可以在任意大的數據規模上達到O（1）常數級別的查詢速度，這一點也是Apache Kylin與傳統查詢技術的關鍵區別，如圖1-6所示。

傳統技術，如大規模並行計算和列式存儲的查詢速度都在 O（N）級別，與數據規模增線性關係。如果數據規模增長10倍，那麼O（N） 的查詢速度就會下降到十分之一，無法滿足日益增長的數據需求。依靠 Apache Kylin，我們不用再擔心查詢速度會隨著數據量的增長而減慢，面對未來的數據挑戰時也能更有信心。