1.Apache Kylin是什么？
在現在的大數據時代，越來越多的企業開始使用Hadoop管理數據，但是現有的業務分析工具（如Tableau，Microstrategy等）往往存在很大的局限，如難以水平擴展、無法處理超大規模數據、缺少對Hadoop的支持；而利用Hadoop做數據分析依然存在諸多障礙，例如大多數分析師只習慣使用SQL，Hadoop難以實現快速交互式查詢等等。神獸Apache Kylin就是為了解決這些問題而設計的。
Apache Kylin，中文名麒（shen）麟（shou） 是Hadoop動物園的重要成員。Apache Kylin是一個開源的分布式分析引擎，最初由eBay開發貢獻至開源社區。它提供Hadoop之上的SQL查詢接口及多維分析（OLAP）能力以支持大規模數據，能夠處理TB乃至PB級別的分析任務，能夠在亞秒級查詢巨大的Hive表，並支持高並發。
Apache Kylin於2014年10月在github開源，並很快在2014年11月加入Apache孵化器，於2015年11月正式畢業成為Apache頂級項目，也成為首個完全由中國團隊設計開發的Apache頂級項目。於2016年3月，Apache Kylin核心開發成員創建了Kyligence公司，力求更好地推動項目和社區的快速發展。
Kyligence是一家專注於大數據分析領域創新的數據科技公司，提供基於Apache Kylin的企業級智能分析平台及產品，以及可靠、專業、源碼級的商業化支持；並推出Apache Kylin開發者培訓，頒發全球唯一的Apache Kylin開發者認證證書。
2.Kylin的基本原理和架構
下面開始聊一聊Kylin的基本原理和架構。簡單來說，Kylin的核心思想是預計算，即對多維分析可能用到的度量進行預計算，將計算好的結果保存成Cube，供查詢時直接訪問。把高復雜度的聚合運算、多表連接等操作轉換成對預計算結果的查詢，這決定了Kylin能夠擁有很好的快速查詢和高並發能力。
上圖所示就是一個Cube的例子，假設我們有4個dimension，這個Cube中每個節點（稱作Cuboid）都是這4個dimension的不同組合，每個組合定義了一組分析的dimension（如group by），measure的聚合結果就保存在這每個Cuboid上。查詢時根據SQL找到對應的Cuboid，讀取measure的值，即可返回。
為了更好的適應大數據環境，Kylin從數據倉庫中最常用的Hive中讀取源數據，使用 MapReduce作為Cube構建的引擎，並把預計算結果保存在HBase中，對外暴露Rest API/JDBC/ODBC的查詢接口。因為Kylin支持標准的ANSI SQL，所以可以和常用分析工具（如Tableau、Excel等）進行無縫對接。下面是Kylin的架構圖。
說到Cube的構建，Kylin提供了一個稱作Layer Cubing的算法。簡單來說，就是按照dimension數量從大到小的順序，從Base Cuboid開始，依次基於上一層Cuboid的結果進行再聚合。每一層的計算都是一個單獨的Map Reduce任務。如下圖所示。
MapReduce的計算結果最終保存到HBase中，HBase中每行記錄的Rowkey由dimension組成，measure會保存在column family中。為了減小存儲代價，這里會對dimension和measure進行編碼。查詢階段，利用HBase列存儲的特性就可以保證Kylin有良好的快速響應和高並發。
有了這些預計算的結果，當收到用戶的SQL請求，Kylin會對SQL做查詢計划，並把本該進行的Join、Sum、Count Distinct等操作改寫成Cube的查詢操作。
Kylin提供了一個原生的Web界面，在這里，用戶可以方便的創建和設置Cube、管控Cube構建進度，並提供SQL查詢和基本的結果可視化。
根據公開數據顯示，Kylin的查詢性能不只是針對個別SQL，而是對上萬種SQL 的平均表現，生產環境下90%ile查詢能夠在在3s內返回。在上個月舉辦的Apache Kylin Meetup中，來自美團、京東、百度等互聯網公司分享了他們的使用情況。例如，在京東雲海的案例中，單個Cube最大有8個維度，最大數據條數4億，最大存儲空間800G，30個Cube共占存儲空間4T左右。查詢性能上，當QPS在50左右，所有查詢平均在200ms以內，當QPS在200左右，平均響應時間在1s以內。
北京移動也在meetup上展示了Kylin在電信運營商的應用案例，從數據上看，Kylin能夠在比Hive/SparkSQL在更弱的硬件配置下獲得更好的查詢性能。
目前，有越來越多的國內外公司將Kylin作為大數據生產環境中的重要組件，如ebay、銀聯、百度、中國移動等。大家如果想了解更多社區的案例和動態，可以登錄Apache Kylin官網或Kyligence博客進行查看。
3.Kylin的最新特性
Kylin的最新版本1.5.x引入了不少讓人期待的新功能，可擴展架構將Kylin的三大依賴（數據源、Cube引擎、存儲引擎）徹底解耦。Kylin將不再直接依賴於Hadoop/HBase/Hive，而是把Kylin作為一個可擴展的平台暴露抽象接口，具體的實現以插件的方式指定所用的數據源、引擎和存儲。
開發者和用戶可以通過定制開發，將Kylin接入除Hadoop/HBase/Hive以外的大數據系統，比如用Kafka代替Hive作數據源，用Spark代替MapReduce做計算引擎，用Cassandra代替HBase做存儲，都將變得更為簡單。這也保證了Kylin可以隨平台技術一起演進，緊跟技術潮流。
在Kylin 1.5.x中還對HBase存儲結構進行了調整，將大的Cuboid分片存儲，將線性掃描改良為並行掃描。基於上萬查詢進行了測試對比結果顯示，分片的存儲結構能夠極大提速原本較慢的查詢5-10倍，但對原本較快的查詢提速不明顯，綜合起來平均提速為2倍左右。
除此之外，1.5.x還引入了Fast cubing算法，利用Mapper端計算先完成大部分聚合，再將聚合后的結果交給Reducer，從而降低對網絡瓶頸的壓力。對500多個Cube任務的實驗顯示，引入Fast cubing后，總體的Cube構建任務提速1.5倍。
目前，社區正在着手准備Apache Kylin 1.5.2版本的發布，目前正處於Apache Mailing list投票階段，預計將會在本周在Kylin官網發布正式下載。
在本次的1.5.2版本中，Kylin帶來了總計 36個缺陷修復、33個功能改進、6個新功能。一些主要的功能改進包括對HyperLogLog計算效率的提升、在Cube構建時對Convert data to hfile步驟的提速、UI上對功能提示的體驗優化、支持hive view作為lookup表等等。
另一個新消息是Kylin將支持MapR和CDH的Hadoop發行版，具體信息可見KYLIN-1515和KYLIN-1672。相應的測試版本是MapR5.1和CDH5.7。
UI上提供了一個重要更新，即允許用戶在Cube級別進行自定義配置，以覆蓋kylin.properties中的全局配置。如在cube中定義kylin.hbase.region.count.max 可以設置該cube在hbase中region切分的最大數量。
另一個重要的功能是Diagnosis。用戶經常會遇到一些棘手的問題，例如Cube構建任務失敗、SQL查詢失敗，或Cube構建時間過長、SQL查詢時間過長等。但由於運維人員對Kylin系統了解不深，很難快速定位到root cause所在地。我們在mailing list里也經常看到很多用戶求助，由於不能提供足夠充分的信息，社區也很難給出一針見血的建議。
當用戶遇到查詢、Cube/Model管理的問題，單擊System頁面的Diagnosis按鈕，系統會自動抓取當前Project相關的信息並打包成zip文件下載到用戶本地。這個包會包含相關的Metadata、日志、HBase配置等。當用戶需要在mailing list求助，也可以附上這個包。
當一個cube構建任務執行失敗或時間過長，用戶可以單擊Job下的Diagnosis按鈕。同樣的，系統會抓取和下載Job相關信息成一個zip包。
我是本次Kylin1.5.2版本發布的release manager，歡迎大家到apache kylin郵件列表積極參與release投票。
如果有朋友想更加系統地學習如何高效使用Kylin和進行二次開發，歡迎大家報名Kyligence正在推出的《Apache Kylin開發者認證培訓》，可以登錄http://kyligence.io/training了解相關信息 。
Q&A
Q1、對mdx支持情況如何？
A1：我們現在不支持MDX查詢，查詢入口是SQL，像saiku這種基於MDX的操作，社區已經有人貢獻了Mondrian jar包，可以將saiku 前台提供的mdx轉換為sql，再通過jdbc jar發送到Kylin server，不過功能上有所限制，left join, topN, count distinct支持受限。
Q2、麒麟針對出來T級別的數據，每日制作cube大約話費多久時間？
A2：具體cube構建時間視不同情況而定，具體取決於dimension數量及不同組合情況、Cardinality大小、源數據大小、Cube優化程度、集群計算能力等因素。在一些案例中，在一個shared cluster構建數十GB的數據只需要幾十分鍾。建議大家在實際環境先進行測試，尋找可以對Cube進行優化的點。此外，一般來說，Cube的增量構建可以在ETL完成后由系統自動觸發，往往這個時間和分析師做數據分析是錯峰的。
Q3、如何向kylin提交代碼?
A3：將修改的代碼用git format-patch做成patch文件，然后attache在對應的jira上，kylin committer會來review，沒有問題的話會merge到開發分支
Q4、如果數據是在elastic search，Kylin的支持如何?
A4：目前還不支持直接從es抽取數據，需要先導出到hive再做cube build；有興趣的同學可以基於kylin 1.5的plugin架構實現一個es的data source。
Q5、工作的比較好的前端拖拽控件有什么？
A5：目前應該是tableau支持較好，saiku支持不是很好，有些場景如left join, count distinct,topN支持不是很好，用戶是可以基於Api開發自己的拖拽頁面的。
Q6、社區版和商業版功能上有什么區別？
A6：商業版能夠提供更高的安全性、穩定性、可靠性，以及企業組件的良好集成；以及可靠、專業、源碼級的商業化支持。
Q7、對多並發支持表現如何？
A7：Kylin和其他MPP架構技術想必一大優勢就在高並發。一台Kylin的Query Server就支持幾十到上百的QPS (取決於查詢的復雜度，機器的配置等因素)，而且 Kylin支持良性的水平擴展，即增多kylin server和HBase節點就可迅速增大並發。
Q8、kylin可以整合spark machine learning和spark sql嗎？
A8：基於前面講到的可插拔架構，是可以整合的。
Q9、跟其它工具對比，有沒有考慮cube的構建時間？因為人家是實時計算的，你是預計算的，這從機理上是不一樣的
A9：kylin跟其它mpp架構的技術在查詢性能的對比，時間里是不含cube構建的時間的，所以從某種意義上來講這樣的對比是有些不公平。但是，從用戶角度來看，分析師和最終用戶只關心查詢性能，而Kylin用預計算能大大提高查詢速度，這正是用戶所需要的！
Q10、Kylin ODBC 驅動程序有示例代碼？
A10：目前代碼在master分支，歡迎大家加入社區一起貢獻。
Q11、4億數據有點少，麒麟有沒有做過相關的benchmark ，在百億級別數據，十個緯度的情況下，表現如何？
A11：來自社區的測試數據，在一個近280億條原始數據的cube（26TB）上，90%的查詢在5秒內完成。
Q12、數據量翻倍的話,空間使用會做指數級增長么
A12：通常cube的增長與原數據的增長基本一致，即原數據翻倍，cube也翻倍，或者更小一些；而非指數增長。
Q13、Data Model和Cube Model構建過程能根據UI步驟詳細講下嗎？
A13：歡迎登陸Kylin網站，查詢具體的使用教程。http://kylin.apache.org/
Q14、你好，相關鏈接能貼一下嗎，謝謝！ 來自社區的測試數據，在一個近280億條原始數據的cube（26TB）上，90%的查詢在5秒內完成。
A14：http://www.docin.com/p-1497646649.html