kylin 在部署的时候需要考虑的几点：
1，不能污染现有的大数据环境，通过大数据客户端的方式提供部署的机器。
2，读的负载均衡问题，需要有session，权限等粘滞的功能。选择好负载均衡工具，haproxy，nginx，lvs。
3，kylin集群中只能有一个job节点（也就是写的节点），如何保证高可用？
4，kylin的元数据，cube数据都是存储在hbase中的，对hbase的读写性能要求高，需要找到平衡点。
一下是转自：http://www.cnblogs.com/brucexia/p/6221528.html， 分析不同部署方式的优缺点。
根据官网介绍，其实部署Kylin非常简单，称为非侵入式安装，也就是不需要去修改已有的Hadoop大数据平台。你只需要根据的环境下载适合的Kylin安装包，选择一个Hadoop节点部署即可，Kylin使用标准的Hadoop API跟各个组件进行通信，不需要对现有的Hadoop安装额外的Agent。
Kylin部署的架构是一个分层的结构，最底层是数据来源层，我们可以通过Sqoop等工具将数据迁移到HDFS分布式文件系统。Kylin依赖Hadoop平台，包括组件HBase，Hive，MapReduce等，即Kylin运行在Hadoop构建的大数据层之上，Kylin平台部署好之后，业务系统连接Kylin，Kylin就把压力发布到Hadoop上做并行计算和查询。
对于Kylin的部署架构，一般都四种典型部署方式，从简单到复杂。
- 第一种方式：
单实例部署方式（Single instance）。在Hadoop集群的一个节点上部署，然后启动即可。建模人员通过Kylin Web登录，进行建模和创建Cube。业务分析系统等发送SQL到Kylin，Kylin查询Cube并返回结果。
这种部署最大特点是简单快捷，而是单点，如果并发请求比较多（QPS > 50），单台Kylin节点将成为瓶颈，所以推荐使用集群（Cluster）部署方式。
- 第二种方式：
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节点挂掉了，也不会影响用户的分析。
这种方式也不是完美的，但是一般场景下是可以满足的。
- 第三种方式：
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服务实例
- 第四种方式：
前面三种方式，应该是绝大多数公司或个人研究采用的部署方式，其实还有一种更高级的部署是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环境的稳定。
