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=https://www.cnblogs.com/alannever/p/’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，我們不用再擔心查詢速度會隨著資料量的增長而減慢，面對未來的資料挑戰時也能更有信心，

標籤：其他

上一篇：JDBC

下一篇：redis系列之------鏈表