//
【PPT+實錄】Kyligence史少鋒：使用Apache Kylin搭建企業級開源大數據分析平臺
http://mp.weixin.qq.com/s?src=3&timestamp=1486430922&ver=1&signature=YfS7PgVR0SjjLt4KwIQ297t4SDiLrrJu5C7uuMXpkCsyWJATNcTsLzO1j4nmqoYqW0LnQD6VoQOTFo4Hu0y7zPM-pPVeFJnRh12GJUFT2SxzHtlV-DNTB62iGOoHuh6WoSRBNmYFjgelfl18SgWFfHF8Ylboe30xgn6Ll9*m0=

本篇文章整理自史少鋒4月23日在『1024大數據技術峰會』上的分享實錄：使用Apache Kylin搭建企業級開源大數據分析平臺。

正文如下

我先做一個簡單介紹我叫史少鋒，我曾經在IBM、eBay做過大數據、云架構的開發，現在是Kyligence的技術合伙人。

Kylin是這兩年在國內發展非常快的開源大數據項目。今天大會合作廠商中有超過一半的企業已經在使用或者正在試用Kylin，應主辦方邀請，今天跟大家做一個關于如何使用Kylin構建開源大數據分析平臺的分享。

這是我今天的議程，分兩部分。

前半部分：
針對Kylin的初級和入門用戶介紹Kylin項目的由來以及技術核心。

后半部分：
介紹如何基于Kylin構建開源大數據分析平臺，把Hadoop數據平臺和業務分析系統連接起來。

從名字上或許可以猜到，它來自中國，的確這也是我們想讓世界知道的，有一群來自中國的工程師在向Hadoop貢獻著這樣一個獨特的項目。

Apache Kylin 是在Hadoop之上的分布式的大數據分析引擎，它對外暴露的是標準SQL接口，支持TB到PB量級的數據，以秒級甚至亞秒級的時間返回響應。

任何一個項目的誕生都有一定的背景和原因。

今天我們看到越來越多的企業正在使用Hadoop，正在把Hadoop作為他們的基礎平臺來管理和分析數據。

但是，企業在使用Hadoop的時候，往往發現有一個很大的Gap：

一方面，現有的分析系統或分析工具，不能很好支持Hadoop； Hadoop上的數據的體量是遠遠超過傳統單機或者傳統關系型數據庫的體量，原有的系統接入Hadoop根本無法承受這么大的數據量。

此外這些遺留系統當初設計的時候就不是一個分布式的架構，沒辦法水平地擴容。

另一方面，對于數據使用者或者分析師，讓他們直接使用Hadoop，寫MapReduce或者Spark的任務，是難以接受的。此外，Hadoop主要是用于做批量運算， 通常需要幾十分鐘，最快也要幾分鐘，對于分析人員來說很難有一個好的使用體驗；等幾分鐘才能看到結果數據，大大影響了他們的工作效率。

這個問題當年就是在eBay內部就被提出來，為此專門成立了一個項目。

2013年的時候，Kylin項目的創始人韓卿(Luke)，授命帶著工程師研究這個難題，經過不斷的嘗試和摸索，Kylin探索出了在Hadoop之上做預計算、做Cube這條路線，這是之前沒有人嘗試過的。

最終這個項目在2014年10月在Github開源 。一個月之后項目被Apache接受成為其一個孵化器項目。

2015年11月份，經過Apache軟件基金會（ASF）的投票，Kylin正式畢業，稱為其大數據領域的一個頂級項目。值得一提的是，2015年的9月，Kylin獲得 了美國InfoWorld評選的最佳開源大數據工具獎，同時獲獎的還有Spark、Storm、Kafka等知名項目。

2016年3月, 由Apache Kylin主要開發人員組成的公司Kyligence成立，致力于Kylin在業界的推廣和使用。

前面講的是Kylin發展的歷史，接下來講一下Kylin核心技術。

做過BI分析的人，對Cube都會有概念，就是用空間換時間。通過預計算把用戶需要查詢的維度以及他們所對應的考量的值，存儲在多維空間里。

當用戶查詢某幾個維度的時候，通過這些維度條件去定位到預計算的向量空間，通過再聚合處理，快速返回最終結果給用戶。

所不同的是，Kylin的cube不是單一維度的組合，而是所有組合都可以計算。N個維度的完整Cube， 會有2的N次方種組合。

分析工具發送標準SQL查詢,Kylin將它轉換成對HBase的Scan，快速查到結果返回給請求方。

這是在1.5之前版本中的的算法，也叫逐層算法。它會啟動N+1輪MapReduce計算。

第一輪讀取原始數據，去掉不相關的列，只保留相關的。同時對維度列進行壓縮編碼；以此處的四維Cube為例，經過第一輪計算出ABCD組合，我們也稱為Base Cuboid；

此后的每一輪MapReduce，輸入是上一輪的輸出，以重用之前計算的結果，去掉要聚合的維度，算出新的Cuboid。以此往上，直到最后算出所有的Cuboid。

Cube在Storage上是怎么存儲的？

星形模型會先被拉成一張平表， Dimension的值拼接在一起，后面接著是Metrics。為了標示這是哪幾個維度的組合，會在行的開始加上Cuboid ID。最后，Cuboid ID ＋ dimensions會被用作Rowkey，Metrics會作為Value放到Column中 。

查詢的時候，SQL語句被SQL解析器翻譯成一個解釋計劃，從這個計劃可以準確知道用戶要查哪些表，它們是怎樣join起來，有哪些過濾條件等等。Kylin會用這個計劃去匹配尋找合適的Cube。

如果有Cube命中，這個計劃會發送到存儲引擎，翻譯成對存儲(默認HBase)相應的Scan操作。Groupby和過濾條件的列，用來找到Cuboid，過濾條件會被轉換成Scan的開始和結束值， 以縮小Scan的范圍; Scan的result，Rowkey會被反向解碼成各個dimension的值，Value會被解碼成Metrics值 。

接下來介紹Kylin的企業級特性；Kylin的特性比較多，這里就不一一列舉，主要講一下對企業比較友好的特性。

首先，毋庸置疑, Kylin對外暴露的是標準的SQL，支持大多數的SELECT語法，可以把各種工具和系統直接對接進來。這意味著當您使用Kylin的時候，不需要對業務系統做額外的改動。

第二，Kylin提供了各種接入方式， 如ODBC、JDBC; 如果您的系統不使用這兩種方式，還可以使用RESTful API查詢。

Kylin架構天生就非常適合Scale out，當查詢量上升，單節點不能滿足的時候，只需要相應增加Kylin的節點就可以滿足。

針對企業對安全的要求，我們有不同力度做安全控制。Kylin有不同用戶角色做不同的事情，此外在project和cube層級可以定義ACL幫助在更細力度掌控對cube的使用。

企業通常會使用目錄服務來管理用戶和群組，Kylin支持LDAP認證登錄；如果對安全有更高的要求，Kylin還支持了基于SAML的單點登錄(SingleSign-On)，只要做一些配置就可以完成，不需要額外開發。

Kylin提供了豐富的RESTful API，非常方便從用各種已有系統，如任務調度，監控等接入Kylin。Kylin的Web UI做到的事情通過API都可以做到。我們看到網易、美團等在Kylin之上開做了封裝，跟他們各自的BI做深度的融合，就是利用了這個特性。

怎么樣用Kylin來構建大數據的分析平臺？

很簡單。Kylin部署和安裝是非常方便的，我們稱為非侵入式的安裝。如果你已經有一套Hadoop，安裝Kylin，只要增加一臺機器，下載Kylin安裝包運行就可以了，Kylin使用標準Hadoop API跟各種組件通信，不需要對現有的Hadoop安裝額外的agent。

架構上就是個分層的結構，最底層是數據，放置在HDFS，其上是Hadoop層，需要有HBase、 Hive， MapReduce等。Kylin運行中Hadoop之上，安裝好了之后，業務系統連入Kylin，Kylin把壓力分布到Hadoop上做計算和查詢。

有四種典型的部署架構，分別從簡單到復雜。

第一種，Single instance的部署，通常一兩天就可以完成。首先要有Hadoop，版本在2.4或以上。加一臺Hadoop客戶機，下載Kylin，即可一鍵啟動。 建模人員通過Kylin Web登錄，進行建模和cube的創建。業務分析系統或者工具發SQL到Kylin，Kylin查詢Cube返回結果。

這種部署最大特點是簡單；缺點也很明顯: Kylin是單點，并發請求上來的時候它會成為瓶頸，所以需要Cluster的部署。

Kylin部署到Cluster非常簡單，只需要增加Kylin的節點數，因為Kylin的metadata也是存儲在HBase，只需要讓它們用同一張metadata表就可以組成cluster 。通常在這個時候會用LDAP來管理用戶權限。

為了將負載分布到Kylin cluster, 需要建立一個Load Balancer(負載均衡器). 在LB這里可以啟用SSL加密，申請域名，還可以安裝防火墻，對外只暴露LB的地址和端口，確保Hadoop和Kylin在網絡上對外是隔離的。

業務系統和用戶通過LB的地址訪問Kylin。這樣的部署，Kylin將不是單點，一個節點失效，不會影響業務分析。是不是這樣就完美了呢？也不是。

Kylin非常適合于做讀寫分離，原因是Kylin的工作負載有兩種：

前者是Cube的計算，它是批量的、延時很長的計算，有密集的CPU和IO；

后者是在線的計算，是只讀的，因為面向用戶，它要求低延遲。Cube計算的過程會對集群帶來很大的負載，從而產生噪音；所以我們有充足的理由進行讀寫分析。

Kylin很容易做到這一點，你可以把HBase單獨部署成一個集群，在部署Kylin的節點上，hadoop 配置指向運算的集群，Hbase的配置指向HBase集群。通過這樣的部署，可以確保Hbase的查詢可以在很短時間完成，而計算集群可以跟公司其它部門分享。

現在目前Kylin使用中估計99%的情況是前面三種部署。還有一種更高級的部署是Staging和Prod多環境的部署。

在一個大的企業里，往往需要多套環境，用于測試，生產等不同目的。

舉例來說，新用戶上到Kylin來的時候，最初他對cube不是很了解，可能創建了一個設計不是很好的cube，導致產生大量的不必要的運算，或者查詢花了很長時間。我們不希望這樣的情況發生在生產環境，對其它業務造成影響，所以會建立一個staging，或者稱為QA的環境。

新用戶必須先走staging環境創建和調優cube，直到cube性能達到要求，數據膨脹率也在一個可控范圍內，這時候由用戶提出請求，由Kylin專家來做一個審核，審核通過后，再允許這個cube被遷移到生產環境。

這里Kylin提供了一個工具， 幾分鐘就可以講一個Cube從一個環境遷移到另一個環境，不需要在新環境中重新build。 在生產環境的Cube，將不允許修改， 只能做增量的build 。

這樣做Staging和Prod分離，Prod中的cube都是經過專家的審核的，所以將是非常穩定的，里面的每個cube都是有據可循的。

這就是關于Kylin的部署的分享。

到今天Kylin已經有了很多的使用案例，這里簡單列一些已知的。最早是在eBay，國內有京東、運營、美團、中國移動(包括廣東移動和北京移動)，還有微軟 。

以上是今天的分享，謝謝大家。