使用Kylin構建企業大數據分析平臺的4種部署方式

本篇博客重點介紹如何使用Kylin來構建大數據分析平臺。根據官網介紹，其實部署Kylin很是簡單，稱爲非侵入式安裝，也就是不須要去修改已有的

Hadoop大數據平臺。你只須要根據的環境下載適合的Kylin安裝包，選擇一個Hadoop節點部署便可，Kylin使用標準的Hadoop API跟各個組件進行通訊，不須要對現有的Hadoop安裝額外的Agent。

      Kylin部署的架構是一個分層的結構，最底層是數據來源層，咱們能夠經過Sqoop等工具將數據遷移到HDFS分佈式文件系統。Kylin依賴Hadoop平臺，包括組件HBase，Hive，MapReduce等，即Kylin運行在Hadoop構建的大數據層之上，Kylin平臺部署好以後，業務系統鏈接Kylin，Kylin就把壓力發佈到Hadoop上作並行計算和查詢。

 

對於Kylin的部署架構，通常都四種典型部署方式，從簡單到複雜。

 

1. 第一種方式：

 

單實例部署方式（Single instance）。在Hadoop集羣的一個節點上部署，而後啓動便可。建模人員經過Kylin Web登陸，進行建模和建立Cube。業務分析系統等發送SQL到Kylin，Kylin查詢Cube並返回結果。

 

這種部署最大特色是簡單快捷，而是單點，若是併發請求比較多（QPS > 50），單臺Kylin節點將成爲瓶頸，因此推薦使用集羣（Cluster）部署方式。

 

2. 第二種方式：

 

Kylin部署集羣方式相對來講也簡單，只須要增長Kylin的節點數，由於Kylin的元數據（Metadata）是存儲在HBase中，只須要在Kylin中配置，讓Kylin的每一個節點都能訪問同一個Metadata表就造成了Kylin集羣（kylin.metadata.url 值相同）。而且Kylin集羣中只有一個Kylin實例運行任務引擎（kylin.server.mode＝all)，其它Kylin實例都是查詢引擎(kylin.server.mode=query)模式。一般可使用LDAP來管理用戶權限。

 

爲了實現負載均衡，即將不一樣用戶的訪問請求經過Load Balancer（負載均衡器）（好比lvs，nginx等）分發到每一個Kylin節點，保證Kylin集羣負載均衡。對於負載均衡器能夠啓用SSL加密，安裝防火牆，對外部用戶只用暴露負載均衡器的地址和端口號，這樣也保證Kylin系統對外部來講是隔離的。

 

咱們的生產環境中使用的LB是nginx，用戶經過LB的地址訪問Kylin時，LB將請求經過負載均衡調度算法分發到Kylin集羣的某一個節點，不會出現單點問題，同時若是某一個Kylin節點掛掉了，也不會影響用戶的分析。

 

這種方式也不是完美的，可是通常場景下是能夠知足的。

 

3. 第三種方式：

 

Kylin很是適合讀寫分離，緣由是Kylin的工做負載有兩種：

 

• Cube的計算，調用MapReduce進行批量計算，並且延時很長的計算，須要密集的CPU和IO資源
• 在線的實時查詢計算，就是Cube計算結束後進行查詢，並且都是隻讀的操做，要求響應快，延遲低。

 

經過分析，咱們發現第一種Cube的計算會對集羣帶來很大負載，從而會影響在線的實時查詢計算，全部須要作讀寫分離。若是你的環境，基本都是利用夜間執行Cube計算，白天上班時間進行查詢分析，那麼能夠考慮採用第二種部署方式。

 

其實Kylin也很容易部署這種組網方式。你須要單獨部署一套HBase集羣，在部署Kylin時，Hadoop配置項指向運算的集羣，HBase的配置項指向單獨部署的HBase集羣。說白了，就是Hadoop和HBase集羣的分離。

 

這種部署方式一般有如下步驟：

 

步驟一：分佈部署Hadoop（MapReduce計算集羣，如下簡稱計算）集羣和HBase（HDFS存儲，如下簡稱存儲）集羣；兩套集羣環境的Hadoop核心版本要一致，分別有各自的HDFS、Zookeeper等組件；

 

步驟二：在準備運行Kylin的服務器上，安裝和配置Hadoop（計算）集羣的客戶端；經過 hadoop , hdfs , hive , mapred 等命令，能夠訪問Hadoop集羣上的服務和資源；

 

步驟三：在準備運行Kylin的服務器上，安裝和配置HBase（存儲）集羣的HBase客戶端；經過 hbase 命令，能夠訪問和操做HBase集羣；

 

步驟四：確保Hadoop（計算）集羣和HBase（存儲）集羣的網絡互通，且無需額外驗證；能夠從Hadoop（計算）集羣的任一節點上，拷貝文件到HBase（存儲）集羣的任一節點；

 

步驟五：確保在準備運行Kylin的服務器上，經過hdfs命令行加上HBase集羣NameNode地址的方式（好比hdfs dfs -ls hdfs://pro-jsz800000:8020/），能夠訪問和操做存儲集羣的HDFS。

 

步驟六：爲了提高Kylin查詢響應效率，準備運行Kylin的服務器，在網絡上應靠近HBase集羣，以確保密集查詢時的網絡低延遲；

 

步驟七：編輯conf/kylin.properties，設置 kylin.hbase.cluster.fs 爲HBase集羣HDFS的url，例如：kylin.hbase.cluster.fs=hdfs://pro-jsz800000:8020

 

步驟八：重啓Kylin服務實例

 

4. 第四種方式：

 

前面三種方式，應該是絕大多數公司或我的研究採用的部署方式，其實還有一種更高級的部署是Staging和production多環境的部署。其實作開發的通常都會經歷這樣的環境，咱們一個需求完成後，首先會進行開發環境測試，而後部署到Staging（能夠理解爲Production生產環境的鏡像，或者測試環境），最後沒有問題後纔會發佈到Production生產環境，這樣作能夠避免不當的設計致使對生產環境的破壞。

 

使用這種方案的場景：

 

假如一個新用戶使用Kylin，可能他對Cube設計不是很熟悉，建立了一個很是很差的Cube，致使Cube計算時產生大量的沒必要要的運算，或者查詢花費的時間很長，會對其餘業務形成影響。咱們不但願這個有問題的Cube能進入生產環境，那麼就須要創建一個Staging環境，或則成爲QA的環境。

 

Kylin提供了一個工具，幾分鐘就能夠將一個Cube從Staging環境遷移到Production環境，不須要在新環境中從新build。由於在生產環境的Cube，將不容許修改，只能作增量的build。這樣作保證了Staging和Production的分離，保證發佈到Production上的Cube都是通過評審過的，因此對Production環境不會形成不可預料的影響，從而保證了Production環境的穩定。