本篇博客重點介紹如何使用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環境的穩定。