Kylin云端跨集群迁移实践

2022-04-18 18:44:24 浏览数 (1)

本文介绍在云端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的元数据,包含projectmodelcube以及构建信息. 另一部分是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自带的命令,备份元数据信息

代码语言:javascript复制
${KYLIN_HOME}/bin/metastore.sh backup

之后会在

代码语言:javascript复制
${KYLIN_HOME}/metadata_backps 

生成一个meta_xx_xx 以当前日期标注的备份文件夹.

然后将文件复制到另外一个集群中,

使用kylin自带的命令,将备份内容进行恢复

代码语言:javascript复制
$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 打一个快照

代码语言:javascript复制
snapshot ‘kylin_metadata’,’snapshot-kylin_metadata’

然后从目标集群中将快照进行导入

代码语言:javascript复制
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操作

快照恢复操作

代码语言:javascript复制
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挂掉!

异常:

代码语言:javascript复制
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的处理过程和解决方法一中一样.

问题二:执行恢复语句报错

代码语言:javascript复制
restore_snapshot 'snapshot-KYLIN_ZZUCFPPZY4-20191220'

报错:

代码语言:javascript复制
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

解决方法:

代码语言:javascript复制
hadoop fs -rm -r /apps/hbase/data/.tmp/*

问题三:

代码语言:javascript复制
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/下面有没有对应的表.如果有则删除

问题四:

代码语言:javascript复制
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异常

解决方法:

在源集群中迁移过来的目录和文件,需要在目标集群中修改用户以及用户的权限

0 人点赞