雷頓學院大數據：http://www.leidun.site/
“麒麟出沒，必有祥瑞。”
—— 中國古諺語
Kylin思維導圖
前言
隨着移動互聯網、物聯網等技術的發展，近些年人類所積累的數據正在呈爆炸式的增長，大數據時代已經來臨。但是海量數據的收集只是大數據技術的第一步，如何讓數據產生價值纔是大數據領域的終極目標。Hadoop的出現解決了數據存儲問題，但如何對海量數據進行OLAP查詢，卻一直令人十分頭疼。
企業中的查詢大致可分爲即席查詢和定製查詢兩種。之前出現的很多OLAP引擎，包括Hive、Presto、SparkSQL等，雖然在很大程度上降低了數據分析的難度，但它們都只適用於即席查詢的場景。它們的優點是查詢靈活，但是隨着數據量和計算複雜度的增長，響應時間不能得到保證。而定製查詢多數情況下是對用戶的操作做出實時反應，Hive等查詢引擎動輒數分鐘甚至數十分鐘的響應時間顯然是不能滿足需求的。在很長一段時間裏，企業只能對數據倉庫中的數據進行提前計算，再將算好後的結果存儲在MySQL等關係型數據庫中，再提供給用戶進行查詢。但是當業務複雜度和數據量逐漸升高後，使用這套方案的開發成本和維護成本都顯著上升。因此，如何對已經固化下來的查詢進行亞秒級返回一直是企業應用中的一個痛點。
在這種情況下，Apache Kylin應運而生。不同於“大規模並行處理”（Massive Parallel Processing，MPP）架構的Hive、Presto等，Apache Kylin採用“預計算”的模式，用戶只需要提前定義好查詢維度，Kylin將幫助我們進行計算，並將結果存儲到HBase中，爲海量數據的查詢和分析提供亞秒級返回，是一種典型的“空間換時間”的解決方案。Apache Kylin的出現不僅很好地解決了海量數據快速查詢的問題，也避免了手動開發和維護提前計算程序帶來的一系列麻煩。
Apache Kylin最初由eBay公司開發，並貢獻給Apache基金會，但是目前Apache Kylin的核心開發團隊已經自立門戶，創建了Kyligence公司。值得一提的是，Apache Kylin是第一個由中國人主導的Apache頂級項目（2017年4月19日，華爲的 CarbonData成爲Apache頂級項目，因此Apache Kylin不再是唯一由國人貢獻的Apache頂級項目）。由於互聯網技術和開源思想進入我國的時間較晚，開源軟件的世界一直是由西方國家主導，在數據領域也不例外。從Hadoop到Spark，再到最近大熱的機器學習平臺TenserFlow等，均是如此。但近些年來，我們很欣喜地看到以Apache Kylin爲首的各種以國人主導的開源項目不斷地涌現出來，這些技術不斷縮小着我國與西方開源技術強國之間的差距，提升我國技術人員在國際開源社區的影響力。
一、核心概念
在瞭解Apache Kylin的使用以前，我們有必要先來了解一下在Apache Kylin中會出現的核心概念。
數據倉庫
Data Warehouse，簡稱DW，中文名數據倉庫，是商業智能（BI）中的核心部分。主要是將不同數據源的數據整合到一起，通過多維分析等方式爲企業提供決策支持和報表生成。那麼它與我們熟悉的傳統關係型數據庫有什麼不同呢？
簡而言之，用途不同。數據庫面向事務，而數據倉庫面向分析。數據庫一般存儲在線的業務數據，需要對上層業務的改變做出實時反應，涉及到增刪查改等操作，所以需要遵循三大範式，需要ACID。而數據倉庫中存儲的則主要是歷史數據，主要目的是爲企業決策提供支持，所以可能存在大量數據冗餘，但利於多個維度查詢，爲決策者提供更多觀察視角。
在傳統BI領域中，數據倉庫的數據同樣存儲在Oracle、MySQL等數據庫中，而在大數據領域中最常用的數據倉庫就是Apache Hive，Hive也是Apache Kylin默認的數據源。
OLAP
OLAP（Online Analytical Process），聯機分析處理，以多維度的方式分析數據，一般帶有主觀的查詢需求，多應用在數據倉庫。與之對應的是OLTP（Online Transaction Process），聯機事務處理，側重於數據庫的增刪查改等常用業務操作。瞭解了上面數據庫與數據倉庫的區別後，OLAP與OLTP的區別就不難理解了。
維度和度量
維度和度量是數據分析領域中兩個常用的概念。
簡單地說，維度就是觀察數據的角度。比如傳感器的採集數據，可以從時間的維度來觀察：
時間維度
也可以進一步細化，從時間和設備兩個角度觀察：
時間和設備維度
維度一般是離散的值，比如時間維度上的每一個獨立的日期，或者設備維度上的每一個獨立的設備。因此統計時可以把維度相同的記錄聚合在一起，然後應用聚合函數做累加、均值、最大值、最小值等聚合計算。
度量就是被聚合的統計值，也就是聚合運算的結果，它一般是連續的值，如以上兩個圖中的溫度值，或是其他測量點，比如溼度等等。通過對度量的比較和分析，我們就可以對數據做出評估，比如這個月設備運行是否穩定，某個設備的平均溫度是否明顯高於其他同類設備等等。
Cube和Cuboid
瞭解了維度和度量之後，我們可以將數據模型上的所有字段進行分類：它們要麼是維度，要麼是度量。根據定義好的維度和度量，我們就可以構建Cube了。
對於一個給定的數據模型，我們可以對其上的所有維度進行組合。對於N個維度來說，組合所有可能性共有2的N次方種。對於每一種維度的組合，將度量做聚合計算，然後將運算的結果保存爲一個物化視圖，稱爲Cuboid。所有維度組合的Cuboid作爲一個整體，被稱爲Cube。
舉個例子。假設有一個電商的銷售數據集，其中維度包括時間（Time）、商品（Item）、地點（Location）和供應商（Supplier），度量爲銷售額（GMV）。那麼所有維度的組合就有2的4次方，即16種，比如一維度（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種。
計算Cubiod，即按維度來聚合銷售額。如果用SQL語句來表達計算Cuboid [Time, Location]，那麼SQL語句如下：
select Time, Location, Sum(GMV) as GMV from Sales group by Time, Location
將計算的結果保存爲物化視圖，所有Cuboid物化視圖的總稱就是Cube。
事實表和維度表
事實表（Fact Table）是指存儲有事實記錄的表，如系統日誌、銷售記錄、傳感器數值等；事實表的記錄是動態增長的，所以它的體積通常遠大於維度表。
維度表（Dimension Table）或維表，也成爲查找表（Lookup Table），是與事實表相對應的一種表；它保存了維度的屬性值，可以跟事實表做關聯；相當於將事實表上經常重複的屬性抽取、規範出來用一張表進行管理。常見的維度表有：日期表（存儲與日期對應的周、月、季度等屬性）、地區表（包含國家、省/州、城市等屬性）等。維度表的變化通常不會太大。使用維度表有許多好處：
縮小了事實表的大小。
便於維度的管理和維護，增加、刪除和修改維度的屬性，不必對事實表的大量記錄進行改動。
維度表可以爲多個事實表重用。
星形模型
星形模型（Star Schema）是數據挖掘中常用的幾種多維數據模型之一。它的特點是隻有一張事實表，以及零到多個維度表，事實表與維度表通過主外鍵相關聯，維度表之間沒有關聯，就像許多小星星圍繞在一顆恆星周圍，所以名爲星形模型。
另一種常用的模型是雪花模型（SnowFlake Schema），就是將星形模型中的某些維表抽取成更細粒度的維表，然後讓維表之間也進行關聯，這種形狀酷似雪花的的模型稱爲雪花模型。
還有一種各位複雜的模型，具有多個事實表，維表可以在不同事實表之間公用，這種模型被稱爲星座模型。
不過，Kylin目前只支持星形模型。
二、Apache Kylin的技術架構
Apache Kylin系統主要可以分爲在線查詢和離線構建兩部分，具體架構圖如下：
Kylin架構圖，圖片來源於官網首頁
首先來看離線構建部分。從圖中可以看出，左側爲數據源，目前Kylin默認的數據源是Apache Hive，保存着待分析的用戶數據。根據元數據的定義，構建引擎從數據源抽取數據，並構建Cube。數據以關係表的形式輸入，並且必須符合星形模型。構建技術主要爲MapReduce（Spark目前在beta版本）。構建後的Cube保存在右側存儲引擎中，目前Kylin默認的存儲爲Apache HBase。
完成離線構建後，用戶可以從上方的查詢系統發送SQL進行查詢分析。Kylin提供了RESTful API、JDBC/ODBC接口供用戶調用。無論從哪個接口進入，SQL最終都會來到REST服務層，再轉交給查詢引擎進行處理。查詢引擎解析SQL，生成基於關係表的邏輯執行計劃，然後將其轉譯爲基於Cube的物理執行計劃，最後查詢預計算生成的Cube併產生結果。整個過程不會訪問原始數據源。如果用戶提交的查詢語句未在Kylin中預先定義，Kylin會返回一個錯誤。
值得一提的是，Kylin對數據源、執行引擎和Cube存儲三個核心模塊提取出了抽象層，這意味着這三個模塊可以被任意地擴展和替換。比如可以使用Spark替代MapReduce作爲Cube的構建引擎，使用Cassandra替代HBase作爲Cube計算後數據的存儲等。良好的擴展性使得Kylin可以在這個技術發展日新月異的時代方便地使用更先進的技術替代現有技術，做到與時俱進，也使用戶可以針對自己的業務特點對Kylin進行深度定製。
Apache Kylin的這種架構使得它擁有許多非常棒的特性：
SQL接口：
Kylin主要的對外接口就是以SQL的形式提供的。SQL簡單易用的特性極大地降低了Kylin的學習成本，不論是數據分析師還是Web開發程序員都能從中收益。支持海量數據集
不論是Hive、SparkSQL，還是Impala、Presto，都改變不了這樣一個事實：查詢時間隨着數據量的增長而線性增長。而Apache Kylin使用預計算技術打破了這一點。Kylin在數據集規模上的侷限性主要取決於維度的個數和基數，而不是數據集的大小，所以Kylin能更好地支持海量數據集的查詢。亞秒級響應
同樣受益於預計算技術，Kylin的查詢速度非常快，因爲複雜的連接、聚合等操作都在Cube的構建過程中已經完成了。水平擴展
Apache Kylin同樣可以使用集羣部署方式進行水平擴展。但部署多個節點只能提高Kylin處理查詢的能力，而不能提升它的預計算能力。可視化集成
Apache Kylin提供了ODBC/JDBC接口和RESTful API，可以很方便地與Tableau等數據可視化工具集成。數據團隊也可以在開放的API上進行二次開發。
三、Apache Kylin的安裝與使用
關於Apache Kylin的安裝，官網上有詳細的教程：
在此就不再贅述了。但有兩處問題官網不曾提及：
Apache Kylin依賴於Hadoop，但使用Standalone模式部署Hadoop可能會造成構建Cube出現問題，推薦大家使用虛擬機集羣搭建Hadoop和Kylin。
Hadoop除了需要開啓HDFS和YARN，還需要開啓jobhistoryserver，啓動命令爲：
sbin/mr-jobhistory-daemon.sh start historyserver
部署成功後，可以使用Kylin官方自帶的quick start教程來驗證一下Kylin是否安裝正確。
接下來我們來談談Cube構建。Apache Kylin的Cube構建分爲三種，分別爲全量構建、增量構建、流式構建。最簡單的是全量構建，就是每次構建都對Hive表進行全表構建。但是全量構建在實際環境中並不常用，因爲大多數業務場景下，事實數據都在不斷地增長中，所以最常使用的構建方式其實是增量構建。
增量構建可以使Cube每次只構建Hive表中新增部分的數據，而不是全部數據，因此大大降低了構建的成本。爲了實現增量構建，Apache Kylin將Cube分爲多個Segment，每個Segment用起始時間和結束時間來標識。關於Cube的構建，可以參考官網文檔：
Kylin Cube Build and Job Monitoring
官網的教程中圖文並茂地講述了Cube的構建方法和過程。此處需要注意的是使用Web UI構建Cube的過程中增量構建與全量構建的不同之處：
創建Model時在第五步（Settings）需要指定 Partition Date Column，用日期字段來對Cube進行分割。
創建Cube時在第四步（Refresh Setting）需要指定 Partition Start Date，即Cube默認的第一個Segment的起始時間。
增量構建的方式解決了業務數據動態增長的問題。但卻仍然不能滿足分鐘級的近實時返回結果的需求，因爲增量構建與全量構建一樣，使用Hive作爲數據源，而Hive中的數據一般是經過ETL定時導入的（比如每天一次）。數據的時效性對於數據價值的重要性不言而喻，爲了滿足實時數據更新這一普遍需求，Apache Kylin給出了流式構建方案。
不同於前兩種使用Hive做爲數據源的構建方式，流式構建使用Kafka做爲數據源，構建引擎定時從Kafka中拉取數據進行構建，這一設計與Spark-Streaming的微批次（Micro-Batch）思想非常像。官網上同樣給出瞭如何使用流式構建的文檔：Build Cube with Streaming Data，需要注意的一點是，Apache Kylin現在的流式構建方式是v1.6後才存在的，之前的版本可能會出現構建方式不同或不存在流式構建方式等情況。
Apache Kylin除了可以在Web UI界面進行構建和查詢，還爲Cube的構建提供了RESTful API，爲數據的查詢提供了RESTful API和JDBC/ODBC接口，用戶可以根據自身情況選擇合適的構建和查詢方式。另外，Kylin還支持使用第三方數據分析工具來對Kylin中計算好的數據進行分析，如Apache Zeppelin、Tableau等。
四、企業應用案例
Apache Kylin雖然還很年輕，但已經在多個企業的生產項目中得到了應用。下面我們來看一看Kylin在國內兩個著名企業內的應用。
百度地圖
百度地圖數據智能組是國內最早的一批在生產環境中使用Apache Kylin的技術團隊。在2014年末，百度地圖團隊正要搭建一套完整的OLAP數據分析平臺，用來提供百億行級數據單條SQL毫秒到秒級的多維分析查詢服務。在技術選型的過程中，百度地圖團隊參考了Apache Drill、Presto、Impala、Spark SQL、Apache Kylin等技術。當時Apache Drill和Presto因生產環境案例較少，而Impala和Spark SQL則主要基於內存計算，對機器資源要求較高，交互頁面通常含有多條SQL查詢請求，在超大規模的數據集下，動態計算亦難以滿足要求。
最終，百度地圖團隊關注到了基於MapReduce預計算生成Cube並提供低延遲查詢的Apache Kylin解決方案，他們在Apache Kylin集羣上跑了多個Cube測試，結果表明它能夠有效解決大數據計算分析的3大痛點：
痛點一：百億級海量數據多維指標動態計算耗時問題，Apache Kylin通過預計算生成Cube結果數據集並存儲到HBase的方式解決。
痛點二：複雜條件篩選問題，用戶查詢時，Apache Kylin利用router查找算法及優化的HBase Coprocessor解決；
痛點三：跨月、季度、年等大時間區間查詢問題，對於預計算結果的存儲，Apache Kylin利用Cube的Data Segment分區存儲管理解決。
這3個痛點的解決，使百度地圖在百億級大數據規模下，且數據模型確定的具體多維分析產品中，達到單條SQL毫秒級響應。
京東雲海
京東雲海是由京東和ISV（與京東雲合作的第三方服務廠商）共同合作的模式對商家提供服務。雲海提供基礎的京東POP(商家開放平臺)數據，包括商品、商家、客服績效、品牌、行業等主題數據。ISV通過商家授權可以獲取商家基礎數據，ISV通過JOS的API接口上傳相關維表數據，數據上傳到數據倉庫後，ISV可以在雲海開放平臺上開發相關的Hive SQL對上傳數據和商家基礎數據進行關聯計算，計算結果可以通過數據開放API查詢，ISV獲取到數據後通過應用展現給商家使用。
JOS開放接近500個API，每天調用量在7億次左右。針對API的調用情況進行多維分析，分析查詢延遲要求達到秒級，並使用BI工具進行分析展現。JOS的API訪問日誌數據通過定時抓取存儲在Hive數據倉庫中。所以需要一種能夠在大數據量情況下進行交互式多維分析的SQL on Hadoop引擎，並且要支持和BI工具的集成，提供標準的JDBC、ODBC接口。
雖然開源社區各種優秀的SQL on Hadoop引擎不斷涌現，比如Impala，SparkSQL等。但是針對於以上場景的考慮：大數據量情況下秒級多維分析、支持與傳統BI工具無縫集成、在大數據量基礎上使用標準SQL查詢小數據量結果集能夠達到毫秒級、完全基於Hadoop生態系統、支持水平擴展等。最終京東雲海選擇了了Apache Kylin。
五、進一步學習
官方文檔：
學習一個開源軟件最好的途徑永遠是官方文檔。官網地址：http://kylin.apache.org/《Apache Kylin權威指南》
圖片來源於豆瓣
這本《Apache Kylin權威指南》由Apache Kylin的核心開發團隊所作，基本涵蓋了Apache Kylin的方方面面，結合官網閱讀效果拔羣。美中不足的就是這本書是基於v1.5，而在v1.6中，流式構建進行了徹底的重寫。但瑕不掩瑜，這本書依然是除了官網之外最好的入門書，本文在成文的過程中也大量地參考了這本書中的內容。
六、總結
Apache Kylin的出現，填補了OLAP on Hadoop解決方案的空白，相比於市面上其他預計算系統，Apache Kylin具有更強的易用性（使用過Druid的人會對這一點深有體會）。Apache Kylin已經在eBay、百度、京東、美團等著名互聯網公司得到應用，在實際生產環境中證明了自己。對預計算系統有需求的同學們可以踊躍嘗試Apache Kylin。
七、參考
Apache Kylin官方文檔：http://kylin.apache.org/docs20/
《Apache Kylin權威指南》：https://book.douban.com/subject/26975003/
Apache Kylin在百度地圖的實踐：http://www.infoq.com/cn/articles/practis-of-apache-kylin-in-baidu-map
京東王曉雨：Apache Kylin在雲海的實踐：http://www.csdn.net/article/2015-11-27/2826343
作者：柴詩雨
鏈接：https://www.jianshu.com/p/abd5e90ab051
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯繫作者獲得授權並註明出處。
https://www.jianshu.com/p/abd5e90ab051