【轉】使用Apache Kylin搭建企業級開源大數據分析平臺

http://www.thebigdata.cn/JieJueFangAn/30143.html

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

　　正文以下

　　我先作一個簡單介紹我叫史少鋒，我曾經在IBM、eBay作過大數據、雲架構的開發，如今是Kyligence的技術合夥人。

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

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

　　前半部分：

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

　　後半部分：

　　介紹如何基於Kylin構建開源大數據分析平臺，把Hadoop數據平臺和業務分析系統鏈接起來。

　　Kylin(麒麟)是什麼?咱們聽到過有麒麟芯片、麒麟OS等等，咱們這個全名是叫Apache Kylin，是一個大數據分析的項目。

　　從名字上或許能夠猜到，它來自中國，的確這也是咱們想讓世界知道的，有一羣來自中國的工程師在向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次方種組合。

　　Kylin架構是這樣的，首先要求用戶把數據放在Hadoop上，經過Hive管理，用戶在Kylin中進行數據建模之後，Kylin會生成一系列的MapReduce任務來計算Cube，算好的Cube最後以K-V的方式存儲在HBase中。

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

　　Cube是怎麼計算出來的?

　　這是在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，國內有京東、運營、美團、中國移動(包括廣東移動和北京移動)，還有微軟 。

　　以上是今天的分享，謝謝你們。