本篇博客重点介绍如何使用Kylin来构建大数据分析平台。根据官网介绍，其实部署Kylin非常简单，称为非侵入式安装，也就是不需要去修改已有的

Hadoop大数据平台。你只需要根据的环境下载适合的Kylin安装包，选择一个Hadoop节点部署即可，Kylin使用标准的Hadoop API跟各个组件进行通信，不需要对现有的Hadoop安装额外的Agent。

最底层是数据来源层，我们可以通过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环境的稳定。