Kylin云端跨集群迁移实践
“ 本文介绍在云端kylin数据迁移的实现方案以及在迁移过程中的遇到哪些问题,并给出了问题解决方案.本次迁移中涉及到的hbase cube表1600+,model数量80+,project 10+”
01
—
目录
- 迁移前准备
- Kylin迁移概述与方案制定
- 不同方案的实现与问题
- 迁移前的前置依赖
- 迁移过程中的问题以及解决方法
- 迁移完成后的checklist都有哪些?
02
—
迁移前准备
- 在目标集群中创建好hadoop大数据环境(hive/hbase/hadoop)
- 在目前集群中安装部署好kylin环境,确保kylin可以正常启动并build cube任务
- 双方网络互通,大数据拉取数据端口开放,可以正常拉取到源集群中的hdfs文件
- 目前集群的kylin版本与源集群版本保持一致
- 确保在目标集群中hive表已经构建且数据已经迁移完成
- 提前准备好数据迁移的脚本,hdfs数据迁移/hbase打快照快照/hbase快照恢复等脚本
- 确保脚本在测试环境可以正常执行
- 检查源端的kylin配置是否与目标端一致
- 确认客户使用Kylin版本以及是否按照源版本安装
03
—
Kylin迁移概述与方案制定
Kylin数据迁移主要包含两部分,一部分是kylin的元数据,包含project\model\cube以及构建信息. 另一部分是cube的预计算数据,也就是存储在hbase的kylin的数据集结果.
Kylin元数据迁移的方案制定
一、方案一
通过元数据备份/还原的方式实现两个集群的元数据同步
二、方案二
通过kylin自己的工具将cube导出然后在另外集群导入方式进行元数据同步
三、方案三
将kylin在hbase上存储的metadata表数据迁移,实现元数据同步
Kylin cube预计算数据迁移方案:
通过hbase的snapshot方式在另外一个集群恢复实现
04
—
迁移前的前置依赖
在进行kylin迁移之前首先要确保在新环境中要具备大数据的组件的安装配置,kylin在启动时,会check hive/hive/hadoop的依赖配置,也可以通过export的方式制定.
其次kylin的数据源要和源集群中的一致,hive的表结构和数据前期需要先导入过来.
具体的kylin安装配置可以参考
http://kylin.apache.org/docs23/install/index.html
下面来分别说一下三个方案的实现,以及中间会遇到哪些问题.
首先,方案一和方案三亲测都可以实现元数据迁移,方案二在实现的时候会有异常问题,查询kylin源代码加载cube基础信息空指针异常,同时因为使用这种方式也会有大量的手工操作,所以就放弃了使用这种方式.
方案一实现
使用kylin自带的命令,备份元数据信息
${KYLIN_HOME}/bin/metastore.sh backup之后会在
${KYLIN_HOME}/metadata_backps 生成一个meta_xx_xx 以当前日期标注的备份文件夹.
然后将文件复制到另外一个集群中,
使用kylin自带的命令,将备份内容进行恢复
$KYLIN_HOME/bin/metastore.sh restore $KYLIN_HOME/meta_backups/meta_xxxx_xx_xx_xx_xx_xx更多的实用命令可以参考kylin官网
http://kylin.apache.org/docs23/howto/howto_backup_metadata.html
在另一个集群恢复之后,进入kylin的web ui可以查看到在源kylin环境的一些project/model/cube的信息,然后点击build能够正常的将cube build成功
在kyin这里备份恢复的方式内部其实就是将文件以upload的方式导入到hbase中,也就是metadata表,但是这种方式有一个问题就是无法解决增量数据的问题,客户的数据是每天在不断增量增长的,即便我们这次测试完成之后在正式迁移的时候还需要重新的backup,restore一次. 那么这个时间会很长,因为本身kylin的元数据还是挺大的,大约在260GB+(主要是kylin的snapshot会比较大)
所以方案一比较适用于cube数量比较少,数据量小的kylin迁移比较适用,对于大数据量,cube数量比较多的情况并不是很合适.
最终我们采取的是方案三的方式进行迁移.
在这里方案三实施的一个前期是kylin的元数据存储是基于hbase的,因为kylin的存储介质也可以使用mysql或者本地文件,当然如果是这两种存储介质的话,可能会更方便一些.
这里kylin默认的元数据存储介质是hbase,在hbase中表kylin_metadata存储的就是kylin的元数据信息.
首先,通过hbase snapshot方式将kylin_metadata 打一个快照
snapshot ‘kylin_metadata’,’snapshot-kylin_metadata’然后从目标集群中将快照进行导入
hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot ${snapshotname} -copy-from hdfs://hostname:8020/apps/hbase/data -copy-to /apps/hbase/data然后在目标集群中查看hbase的snapshot是否已经导入过来.
可以通过list_snapshot查看hbase中的快照.确保快照导入过来之后,接下来进行快照的restore操作
快照恢复操作
restore_snapshot ’snapshot-kylin_metadata’恢复完成之后需要enable 'snapshot-kylin_metadata’ 表, 之后验证kylin_metadata表是否可以正常查询.
元数据已经完成迁移并恢复到目标集群中,通过kylin web ui可以查看是否源集群中的project/model/cube已经加载进来,如果没有加载,需要在kylin web 中 system->reload config.
元数据迁移完成之后,接下来需要迁移kylin的cube 预计算的数据.
这里,和迁移元数据的方式一样,kylin的cube 预计算的数据也是存储在hbase中的,表的名称都是以KYLIN_ 开头,这里需要将hbase中所有以KYLIN_开头的表打快照处理.
然后通过同样的方式进行拉取和恢复.
在方案三种元数据的恢复是没有问题的,在恢复cube 预计算数据时,导致了regionserver全部挂掉, 原因在于kylin中使用了coprocessor,每个hbase表都有一个coprocessor,用于更高效的处理数据查询和写入操作,但是在hbase 表desc之后查看coprocessor指定的地址为源集群中的namenode:8020端口,所以加载不到coprocessor的jar包,导致regionserver挂掉,region一直在重新连接加载.
那么在这里需要修改hbase desc的信息,但是一旦恢复数据表snapshot,regionserver就会挂掉,无法通过hbase自身的方式进行恢复.
05
—
迁移过程中的问题以及解决方法
问题一. hbase快照恢复之后，regionserver挂掉！
异常：
FATAL regionserver.HRegionServer: RegionServer abort: loaded coprocessors are: [org.apache.hadoop.hbase.backup.BackupObserver, org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint, org.apache.hadoop.hbase.coprocessor.MultiRowMutationEndpoint]
org.apache.kylin.storage.hbase.cube.v2.coprocessor.endpoint.CubeVisitService threw java.lang.IllegalArgumentException: java.net.UnknownHostException: xxxxxx原因：
kylin使用了hbase的coprocessor ，指定的hdfs namenode的地址还是源集群nn的地址
解决方法:
首先为了防止因为加载coprocessor原因导致regionserver挂掉的问题,可以增加下面的配置
hbase.coprocessor.abortonerror=false
这样即便卸处理器加载不成功，也不会影响regionserver挂掉
因为在snapshot在restore之后,regionserver会一直的加载coprocessor,所以需要先更新hbase表的coprocessor
解决方法一:
可以通过在新集群中绑定源集群的host ,让hbase restore之后,可以访问到对应源集群的hdfs文件. 从而可以保证在restore之后,regionserver不会挂掉
然后,再执行hbase coprocessor的alter的操作
首先删除掉coprocessor
alter 'tablename', METHOD => 'table_att_unset',NAME => 'coprocessor
然后加入新的coprocessor
"alter 'tablename', 'coprocessor'=>‘绑定目标hdfs集群kylin的coprocessor.jar地址’
解决方法二:
可以在目标集群中伪造源端的host名称,使hbase coprocessor实际访问的依旧是目标端的hdfs地址,然后hbase的处理过程和解决方法一中一样.
问题二:执行恢复语句报错
restore_snapshot 'snapshot-KYLIN_ZZUCFPPZY4-20191220'报错：
ERROR: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: clone snapshot={ ss=snapshot-KYLIN_XXXX table=KYLIN_XXXXX type=FLUSH } failed because A clone should not have regions to restore
at org.apache.hadoop.hbase.master.snapshot.CloneSnapshotHandler.handleCreateHdfsRegions(CloneSnapshotHandler.java:132)
at org.apache.hadoop.hbase.master.handler.CreateTableHandler.handleCreateTable(CreateTableHandler.java:269)
at org.apache.hadoop.hbase.master.handler.CreateTableHandler.process(CreateTableHandler.java:205)
at org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: A clone should not have regions to restore解决方法:
hadoop fs -rm -r /apps/hbase/data/.tmp/*问题三:
ERROR: org.apache.hadoop.hbase.snapshot.RestoreSnapshotException: Couldn't clone the snapshot={ ss=snapshot-KYLIN_XXXXX table=KYLIN_XXXX type=FLUSH } on table=KYLIN_00HWTHGZCV
**********
Caused by: org.apache.hadoop.hbase.TableExistsException: KYLIN_XXXX解决方法:
1、list查看hbase中是否有相应表,有则删除
2、清理hbase元数据
如果上面都不行,则进去zkCli.sh 查看hbase/table/下面有没有对应的表.如果有则删除
问题四:
ERROR: org.apache.hadoop.hbase.DoNotRetryIOException: java.net.UnknownHostException: xxxxx Set hbase.table.sanity.checks to false at conf or table descriptor if you want to bypass sanity checks
将hbase.table.sanity.checks=false问题五:
使用distcp再拉取/kylin/kylin_metadata目录时,会缺少一些文件,会导致kylin在step5的时候build异常
原因:
在/kylin/kylin_metadata 目录下面主要存储的是kylin的元数据文件以及中间结果数据文件,基本上都是一些小文件居多,在测试中发现使用distcp拉取小文件比较多的目录时,会缺少一些文件.
解决方法
可以先使用hdfs的archive,将目录进行归档.然后在使用distcp将har文件拉取过来,进行解压.
问题六:
在使用hdfs倒过来的目录和文件的用户权限依旧是源集群中的用户权限.会导致kylin 在step1的时候build异常
解决方法:
在源集群中迁移过来的目录和文件,需要在目标集群中修改用户以及用户的权限