一、背景

现kylin作为数据源提供报表支撑的场景持续增多，经常出现查询慢的问题，为提高hbase支撑的稳定性，同时可以应对读写组合的情况，考虑一种方案即kylin的读写分离。

二、方案介绍

kylin部署的几种方式

单实例部署方式

• 即现阶段我们采用的部署方式，单节点kylin， 一般并发达到50时会出现瓶颈。

集群部署方式

• kylin机器采用集群部署方式， 只需要增加kylin的节点数，每个节点共用一份medadata表， 并且集群中只有一个kylin实例运行任务引擎（kylin.server.mode＝all 或 kylin.server.mode＝job）, 其他kylin实例都是查询引擎（kylin.server.mode＝query）.
• 为了负载均衡， 将不同的用户请求访问通过nginx进行负载均衡分发到每个kylin节点。

读写分离方式

• kylin的工作负载分为两类： 1. cube计算，需要密集的cpu和IO; 2. 在线的实时查询，要求快速想用。
• 适用场景：cube的计算和kylin的查询可能出现时间上冲突的情况, cube计算时可能会影响kylin的读取速度。
  一般的安装步骤如下：

1. 分别部署hadoop集群和hbase集群， 对我们来说可能是EMR集群和olap集群
2. 准备安装kylin的服务器上，安装和配置hadoop和hbase等组件的客户端（这里的hbase客户端需要能访问hbase集群， 其他如hdfs,hive,mr等客户端需要能访问hadoop集群， 这一步我们可以直接在目标集群上拷贝响应的配置实现）
3. hadoop集群与hbase集群需要能够网络间互通，且无需额外的验证（我们可以使用公共用户hdfs来解决cdh集群的验证问题）
4. 确保在kylin服务器上可以通过hdfs命令行 + HBase集群namenode地址访问和操作hbase集群的hdfs: 如 hdfs dfs -ls hdfs://<hbase>:8020/
5. 修改kylin.properties文件中的hbase集群配置： kylin.storage.hbase.cluster-fs=hdfs://<hbase>:8020 (其他配置同原kylin配置)
6. 重启kylin服务实例

staging和production多环境的部署

• 可以理解为是将测试和生产的kylin共用同一套hdfs集群，在测试上构建完kylin cube测试无问题后，使用kylin的迁移工具进行cube的迁移， 这里不再进一步说明。

./bin/kylin.sh org.apache.kylin.tool.CubeMigrationCLI <srcKylinConfigUri> <dstKylinConfigUri> <cubeName> <projectName> <copyAclOrNot> <purgeOrNot> <overwriteIfExists> <realExecute> <migrateSegmentOrNot>

kylin hbase迁移

• 因为kylin提供的cube迁移工具并不支持不同hadoop集群间的cube迁移， 这里详细说明一下kylin在不同集群间的迁移方法。

0. 迁移说明

0.1 hbase迁移采用hbase提供的snapshot工具
0.2 正在迁移的cube在迁移完成之前，需要保证cube不进行合并操作，可以通过临时修改cube属性，将7天合并和28天合并删除，以免迁移途中发现源表没了。。。
0.3 每次迁移最少一个cube,如果cube中的表未迁移完整，将导致kylin协处理器更新失败； 迁移完一个project后再迁移另一个， 如果能一次全部迁移的话最好

1. 准备工作

1.1 保证集群间的网络可以互通
1.2 目标集群（hbase集群）的服务器hosts文件中需要添加原集群的域名映射，已解决hbase snapshot复制后unknown host的问题。

2. 迁移步骤

2.1 备份kylin元数据

./bin/metastore.sh backup  -- 该命令会在当前目录下生成一个带日期后缀的元数据备份文件夹

2.2 拷贝元数据
拷贝文件到新的kylin服务器,并新建meta_new文件夹,目录结构与元数据保持一致; 按project进行迁移, 将元数据中 cube/cube_desc/cube_statistics/dict/model_desc/project/table/table_exd 子目录下对应 该cube的数据拷贝到cube_new文件夹下对应的相同名称的文件夹下（在2.7步将会用到）。
2.3 迁移hbase表
按照kylin cube对应的hbase table 做hbase 快照， 进入hadoop集群的hbase shell下

 snapshot 'table_name','table_name_snapshot'
list_snapshots --该命令可以查看快照文件列表

2.4 导出到目标集群

su hdfs   -- 切换为hdfs用户,具有目标集群的读写权限

hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot   -snapshot table_name_snapshot -copy-from hdfs://<计算>:8020/hbase    -copy-to hdfs://<hbase>:8020/hbase -mappers 5 -bandwidth  10  

此时目标集群hdfs:///hbase/.hbase-snapshot下会有对应的快照文件，当然也可以通过一下命令查看

list_snapshots

• mappers 表示并行度， bandwidth表示带宽，不要太高以免影响集群正常功能。

2.5 目标集群修改权限

• 因为以hdfs用户导出,所以目标集群的文件属于hdfs用户,而hbase默认使用hbase用户，权限不足

sudo -uhdfs hdfs dfs -chown -R hbase:hbase /hbase

2.6 在目标集群通过snapshot创建表
注意： 这里的表名要与源表保持一致

clone_snapshot 'table_name_snapshot','table_name'

2.7 导入元数据到新的kylin实例

./bin/metastore.sh restore meta_new

2.8 reload metadata

• 在kylin页面上进行点击System模块,点击reload MetaData
  2.9 更新协处理器

./kylin.sh org.apache.kylin.storage.hbase.util.DeployCoprocessorCLI $KYLIN_HOME/lib/kylin-coprocessor-*.jar all

2.10 至此，登录新的kylin实例web界面，即可看到我们刚刚导入的cube，并可进行查询，因为是按project进行导入的，所以其他的project是看不到的。

3. 可能出现的问题

3.1 目标集群hbase执行命令 clone_snapshot 'table_name_snapshot','table_name'后，一直不响应；

• 查看olap1 机器下 /var/log/hbase目录下的hbase-cmf-hbase-HBASERESTSERVER-olap1.log.out 及 hbase-cmf-hbase-MASTER-olap1.log.out
• 可能的原因是hosts文件没有配置，导致snapshot复制过来的表中携带的原集群的元信息不能被正确识别： 修改hosts文件解决

3.2 通过hbase shell可以查看表数据（可能是乱码哈）， 但是通过kylin查询会出错

• 未更新协处理器： ./kylin.sh org.apache.kylin.storage.hbase.util.DeployCoprocessorCLI $KYLIN_HOME/lib/kylin-coprocessor-*.jar all

3.3 更新协处理器报错

• 当前cube中包含的segment（表）未完全迁移，导致报错： 最小迁移单位为cube

3.4 Could not find or load main class org.apache.hadoop.hbase.util.GetJavaProperty

• 在hbase脚本中添加依赖，CLASSPATH=${CLASSPATH}:$JAVA_HOME/lib/tools.jar:/opt/cloudera/parcels/CDH/lib/hbase/lib/*

参考：http://92072234.wiz03.com/share/s/2i1O8Q1L1k042IDoOy3h7BgH2K4G6J2SoQv42Xc4b01xpCrj

4. 当真的解决不了的时候

注意： 以下操作只能在新集群上操作！！！

4.1 暴力删除hbase

• 4.1.1. 停止hbase服务
• 4.1.2. 删除zookeeper 下hbase文件夹
• 4.1.3. 删除hdfs /hbase目录

4.2 暴力删除kylin元数据

• 4.2.1. ./kylin.sh stop
• 4.2.2. 进入hbase shell, 删除kylin_metadata表
• 4.2.3. ./kylin.sh start

三、对当前情况下的适用性

优点：

1. 读写分离，可以应对更多样的环境
2. hbase集群拆分，由kylin查询引起的hbase问题，仅作用到hbase集群， 不会牵连到sparkstreaming任务（offset提交等）
3. hbase集群拆分，做配置方面的调整时，波及面小
4. 可以释放部分emr集群资源
5. 方便后续扩展

缺点：

1. hbase集群拆分后，需要占用olap集群的内存资源，可能导致实时数仓的资源紧张

风险点：

1. 方案最终需要单独的kylin服务器同时连两个集群，这个尚不具备环境实践测试，因为需要修改环境配置，可能导致原kylin不可用。
   • 解决方案： 另外单独申请机器， 与当前kylin机器隔离，带确认无误后切换kylin

适用性分析

• 针对当前使用情况来看，很多集群不稳定的情况是由于hbase内存不足导致regionserver经常性重启有关系, 可以通过调整现有hbase集群内存资源改善查询慢的问题；
• 与druid集群共用olap集群，同样需要较大量的内存，可能会影响实时数仓的服务稳定性，或者另加资源， 需要观察实时数仓的资源占用情况
• 现有集群虽然组件较多，但是资源方面相对olap集群可用资源更多，可以先观察一段时间。

参考

• https://blog.bcmeng.com/post/kylin-migrate.html （跨机房迁移）
• http://92072234.wiz03.com/share/s/2i1O8Q1L1k042IDoOy3h7BgH2K4G6J2SoQv42Xc4b01xpCrj （启动报错）
• https://blog.csdn.net/yangbosos/article/details/89438876 （kylin部署方式）