點選上方藍色字型，選擇“設為星标”
回複”資源“擷取更多資源
大資料技術與架構
點選右側關注，大資料開發領域最強公衆号！
暴走大資料
點選右側關注，暴走大資料！
前言
随着移動網際網路、物聯網等技術的發展，近些年人類所積累的資料正在呈爆炸式的增長，大資料時代已經來臨。但是海量資料的收集隻是大資料技術的第一步，如何讓資料産生價值才是大資料領域的終極目标。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安裝
- 叢集部署
在此就不再贅述了。但有兩處問題官網不曾提及：
- 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 Creation
-
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。