看過一些kylin資料之後，自己對kylin的一些基本知識做一些總結，也算是對知識的一個備份吧。、
kylin的歷史背景之內的我就介紹了，網上一大堆信息。
kylin官網 : http://kylin.apache.org
1. 爲什麼要使用kylin？
自Hadoop誕生以來，大數據的存儲和批處理問題均得到了妥善解決，而如何高速地分析數據也就成爲了下一個挑戰。於是各式各樣的“SQL on Hadoop”技術應運而生，其中以Hive爲代表，Impala、Presto、Phoenix、Drill、SparkSQL等緊隨其後。它們的主要技術是“大規模並行處理”（Massive Parallel Processing，MPP）和“列式存儲”（Columnar Storage）。大規模並行處理可以調動多臺機器一起進行並行計算，用線性增加的資源來換取計算時間的線性下降。列式存儲則將記錄按列存放，這樣做不僅可以在訪問時只讀取需要的列，還可以利用存儲設備擅長連續讀取的特點，大大提高讀取的速率。這兩項關鍵技術使得Hadoop上的SQL查詢速度從小時提高到了分鐘。
然而分鐘級別的查詢響應仍然離交互式分析的現實需求還很遠。分析師敲入查詢指令，按下回車，還需要去倒杯咖啡，靜靜地等待查詢結果。得到結果之後才能根據情況調整查詢，再做下一輪分析。如此反覆，一個具體的場景分析常常需要幾小時甚至幾天才能完成，效率低下。
這是因爲大規模並行處理和列式存儲雖然提高了計算和存儲的速度，但並沒有改變查詢問題本身的時間複雜度，也沒有改變查詢時間與數據量成線性增長的關係這一事實。假設查詢1億條記錄耗時1分鐘，那麼查詢10億條記錄就需10分鐘，100億條記錄就至少需要1小時40分鐘。當然，可以用很多的優化技術縮短查詢的時間，比如更快的存儲、更高效的壓縮算法，等等，但總體來說，查詢性能與數據量呈線性相關這一點是無法改變的。雖然大規模並行處理允許十倍或百倍地擴張計算集羣，以期望保持分鐘級別的查詢速度，但購買和部署十倍或百倍的計算集羣又怎能輕易做到，更何況還有高昂的硬件運維成本。
另外，對於分析師來說，完備的、經過驗證的數據模型比分析性能更加重要，直接訪問紛繁複雜的原始數據並進行相關分析其實並不是很友好的體驗，特別是在超大規模的數據集上，分析師將更多的精力花在了
等待查詢結果上，而不是在更加重要的建立領域模型上。
2. kylin是怎麼做的
Apache Kylin的初衷就是要解決千億條、萬億條記錄的秒級查詢問題，其中的關鍵就是要打破查詢時間隨着數據量成線性增長的這個規律。仔細思考大數據OLAP，可以注意到兩個事實。
- 大數據查詢要的一般是統計結果，是多條記錄經過聚合函數計算後的統計值。原始的記錄則不是必需的，或者訪問頻率和概率都極低。
- 聚合是按維度進行的，由於業務範圍和分析需求是有限的，有意義的維度聚合組合也是相對有限的，一般不會隨着數據的膨脹而增長。
基於以上兩點，我們可以得到一個新的思路——“預計算”。應儘量多地預先計算聚合結果，在查詢時刻應儘量使用預算的結果得出查詢結果，從而避免直接掃描可能無限增長的原始記錄。
“預計算”就是Kylin在“大規模並行處理”和“列式存儲”之外，提供給大數據分析的第三個關鍵技術。
舉個例子
使用如下的SQL來查詢10月1日那天銷量最高的商品：
select item, sum(seller_amount) from sell_details where sell_date='2017-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億，但只要商品的總數不變，那麼預計算的結果記錄總數就不會變，查詢的速度也不會變。
3. kylin的核心
Apache Kylin的工作原理本質上是MOLAP（Multidimensional OnlineAnalytical Processing）Cube，也就是多維立方體分析。
kylin中有兩個主要概念： 維度（Dimension）和度量（Measure）
簡單來講，維度就是觀察數據的角度。比如電商的銷售數據，可以從時間的維度來觀察也可以進一步細化，從時間和地區的維度來觀察。維度一般是一組離散的值，比如時間維度上的每一個獨立的日期，或者商品維度上的每一件獨立的商品。因此統計時可以把維度值相同的記錄聚合在一起，然後應用聚合函數做累加、平均、去重複計數等聚合計算。
度量就是被聚合的統計值，也是聚合運算的結果，它一般是連續的值，銷售額，抑或是銷售商品的總件數。通過比較和測算度量，分析師可以對數據進行評估，比如今年的銷售額相比去年有多大的增長，增長的速度是否達到預期，不同商品類別的增長比例是否合理等。
類比與座標系，維度就是各個軸（x軸，y軸），是從分析具體數據的角度，而度量就是軸對應的具體點或者數值，在kylin中，度量也是hbase中儲存的具體的值。
有了維度和度量，一個數據表或數據模型上的所有字段就可以分類了，它們要麼是維度，要麼是度量（可以被聚合）。於是就有了根據維度和度量做預計算的Cube理論。
給定一個數據模型，我們可以對其上的所有維度進行組合。對於N個維度來說，組合的所有可能性共有2N 種。對於每一種維度的組合，將度量做聚合運算，然後將運算的結果保存爲一個物化視圖，稱爲Cuboid。所有維度組合的Cuboid作爲一個整體，被稱爲Cube。所以簡單來說，一個Cube就是許多按維度聚合的物化視圖的集合。
4. 具體流程
Apache Kylin的工作原理就是對數據模型做Cube預計算，並利用計算的結果加速查詢，具體工作過程如下。
- 指定數據模型，定義維度和度量。
- 預計算Cube，計算所有Cuboid並保存爲物化視圖。
- 執行查詢時，讀取Cuboid，運算，產生查詢結果。
由於Kylin的查詢過程不會掃描原始記錄，而是通過預計算預先完成表的關聯、聚合等複雜運算，並利用預計算的結果來執行查詢，因此相比非預計算的查詢技術，其速度一般要快一到兩個數量級，並且這點在超大的數據集上優勢更明顯。當數據集達到千億乃至萬億級別時，Kylin的速度甚至可以超越其他非預計算技術1000倍以上。
5. 技術構架
kylin默認是使用hive作爲數據源，hbase作爲存儲模塊，mapreduce作爲計算引擎，但是在kylin1.5版本之後引入了spark計算引擎，數據源和存儲引擎也可替換爲其他組件，比如可使用kafka作爲數據源，構建流式數據。
從圖中可以看出，數據源在左側，目前主要是Hadoop Hive，保存着待分析的用戶數據。根據元數據的定義，下方構建引擎從數據源抽取數據，並構建Cube。數據以關係表的形式輸入，且必須符合星形模型（Star Schema）（更復雜的雪花模型在成文時還不被支持，可以用視圖將雪花模型轉化爲星形模型，再使用Kylin）。MapReduce是當前主要的構建技術。構建後的Cube保存在右側的存儲引擎中，一般選用HBase作爲存儲。
完成了離線構建之後，用戶可以從上方查詢系統發送SQL進行查詢分析。Kylin提供了各種Rest API、JDBC/ODBC接口。無論從哪個接口進入，SQL最終都會來到Rest服務層，再轉交給查詢引擎進行處理。這裏需要注意的是，SQL語句是基於數據源的關係模型書寫的，而不是Cube。Kylin在設計時刻意對查詢用戶屏蔽了Cube的概念，分析師只需要理解簡單的關係模型就可以使用Kylin，沒有額外的學習門檻，傳統SQL應用也很容易遷移。查詢引擎解析SQL，生成基於關係表的邏輯執行計劃，然後將其轉譯爲基於Cube的物理執行計劃，最後查詢預計算生成的Cube併產生結果。整個過程不會訪問原始數據源。
6. kylin的主要特點
- 標準SQL接口
- 支持超大數據集
- 亞秒級響應
- 可伸縮性和高吞吐率
- BI及可視化工具集成
參考文獻
Apache kylin 權威指南