http://www.tuicool.com/m/articles/Yjm6bq7

本文是5月23日大資料雜談群分享的內容。

關注“大資料雜談”公眾號，點選“加群學習”，更多大牛一手技術分享等著你。

實習編輯：Melody

大家好，我是今天做微信分享的李棟，來自Kyligence公司，也是Apache Kylin Committer & PMC member，在加入Kyligence之前曾就職於eBay、微軟。

今天分享的主題是：聊聊“神獸”Apache Kylin的最新特性。本次分享將首先對Apache Kylin進行基本介紹；接下來介紹1.5.x最新版本在架構上的重要更新；然後對即將釋出的1.5.2版本進行功能預告。

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內返回。在上個月舉辦的ApacheKylin 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