背景
xx公司属于最早一批使用TBDS（腾讯大数据处理平台）产品的老客户，从2016年开始将业务运行在TBDS。目前客户使用的是早期TBDS版本，与最新release版本在系统总体架构、组件版本等方面相差过大。因为客户需求越来越多，现在使用的老版本大数据集群因为功能较少，导致部分需求无法满足客户新增需求。由于历史遗留原因，老版本升级到新版本代价较高。考虑到客户的大数据集群规模不是很大（TB数据量级），因此做大数据迁移的代价比直接升级要低很多。因此，经过与客户讨论后决定，搭建新版本集群，直接将老集群数据全部迁移至新版本集群。
1.TBDS简介
1.1架构简介
TBDS 是基于腾讯多年海量数据处理经验，对政企客户提供的可靠、安全、易用的大数据处理平台。整个TBDS架构，上层主要是提供给用户使用的应用层，用户在上层通过页面进行用户管理，库表管理及全链路的应用开发。中间平台层主要提供各类大数据组件，供开发者运行各类大数据程序。用户将开发好的应用在全局工作流平台Lhotse上进行任务调度，通过任务把数据接入后再经过实时计算平台Oceanus或者离线MR任务处理，最后落地存储在HDFS上。更为详细的产品介绍参考官网链接：https://cloud.tencent.com/product/tbds
1.2平台数据类型
TBDS平台的数据我们可以划分为三类：平台元数据，用户业务数据，平台日志及监控数据。
元数据类主要包括：用户帐号、授权信息、项目信息、工作流配置等。
业务数据主要包括：API/客户端写入、工作流导入、页面上传、业务产生等。
日志及监控数据主要包括：审计日志，服务日志，组件监控数据，硬件监控数据等。
2.客户调研及前期工作
TBDS平台涵盖丰富的大数据相关组件。但是，每个客户的业务需求场景不同，有可能部分组件客户并未使用，所以首先了解清楚客户实际的使用场景，可以减少一些不必要的迁移工作。在这次迁移工作的前期，我们与客户及研发经过多次讨论，再根据下面制定的信息收集表，详细掌握了客户在TBDS平台上的使用方式，常用组件，业务数据类型等。
A）客户都是使用Hive进行离线的数据分析，只使用到平台中的Hive及HDFS组件，客户的业务逻辑并未有使用到诸如Hbase,Kafka等组件
B）客户的业务数据均存储在HDFS上，包括客户的程序脚本
C）客户要求老平台的帐号，权限，工作流等配置信息需要迁移，这部分数据存储在Mysql和Ldap上
D）Hermes和Kafka只有监控数据，无用户业务数据无需迁移
3、整体迁移方案
从前期的准备工作我们可以知道，这次客户TBDS需要迁移的数据类型有3种，Ldap数据，Mysql数据，HDFS数据。下面我们根据数据类型制定迁移步骤，详细的迁移步骤因为比较多（有另外详细的迁移操作指南文档），此处只讲迁移方法及关键步骤。下文中提到的Portal机器是TBDS平台最为重要的一个管理节点，我们称之为Portal。
3.1、Ldap数据迁移
Ldap数据主要为存储的用户帐号信息。
迁移方法：Ldap数据可通过命令将数据导出为文件，然后通过scp或rsync将文件拷贝到新集群上，再在新集群上用命令导入即可。
关键步骤：
1.旧集群导出
slapcat -n 2 -l /data/migration/old_bk/bk-ldap-from-old-tbds.ldif
2.清除新集群ldap数据
rm -rf /var/lib/ldap/*
3.拷贝ldap数据到新集群
scp /data/migration/old_bk/bk-ldap-from-old-tbds.ldif root@[new-Portal-IP]:/data/migration/old_bk/
4.新集群导入
slapadd -l /data/migration/old_bk/bk-ldap-from-old-tbds.ldif
5.修改文件权限
chown ldap:ldap -R /var/lib/ldap/
注意点：LDAP迁移完成后，还需要在新集群的TBDS页面上新建一个任意的测试用户，之后删掉即可。目的是为了刷新HDFS中的ACL文件，确保迁移后用户能够正常访问TBDS的各种服务
3.2、Mysql数据迁移
Mysql数据主要存储的Hive元数据，工作流配置等平台本身的必要数据。在TBDS平台中有两个Mysql服务，分别是管理节点上的mysql服务（未对外暴露）和MetaDB（实际为mysql），迁移的时候这两个Mysql的数据都需要迁移。
迁移方式：虽然平台中有两个Mysql服务，但是迁移方式都是一样。Mysql中存储的都是平台本身的数据，可用mysql自带的mysqldump命令进行导出，再用scp或rsync将数据文件拷贝到新集群，再在新集群上通过mysql命令进行导入
关键步骤：
1.梳理出Mysql中需要迁移的库表
2.根据梳理的库表信息，将旧集群数据导出，剔除不需要迁移的表
/usr/bin/mysqldump -uxxx -pxxx -h [old-Portal-IP] -t -c
--databases tbds --ignore-table=tbds.deployportal_case .....
> /data/migration/old_bk/bk-mysql-portalOld-tbds.sql
3.备份新集群mysql数据
mysqldump -uxxx -pxxx -h[new-Portal-IP] -d
--databases metadata lhotse_open ranger ranger_admin_dba_setup_lock ran_audit hive --ignore-table=lhotse_open.lb_error_desc ....
> /data/migration/new_bk/bk-mysql-metadb-metadata-lhotse-ranger-hive-nodata.sql
4.清空新集群数据
mysql -uxxx -pxxx -h [new-IP] < /data/migration/new_bk/bk-mysql-metadb-metadata-lhotse-ranger-hive-nodata.sql
5.拷贝旧集群数据到新集群
scp /data/migration/old_bk/bk-mysql-portalOld-tbds.sql root@[new-Portal-IP]:/data/migration/old_bk/
6.导入旧集群数据
mysql -uxxx -pxxx -h [new-IP] < /data/migration/old_bk/bk-mysql-portalOld-tbds.sql
注意点：
1.这次迁移的新老集群版本跨度过大，有可能表的字段名有改变，为了在将数据导入到新集群时不改变新表结构，所以在导出旧集群数据时加入了-t参数，只导数据不导表结构。
2.MetaDB有做主从服务，导入数据到MetaDB的Mysql主前，先要把主从状态停止，数据导入主mysql后再重新开启主从同步。
3.因为新集群的进程会缓存老的用户验证信息，所有Mysql的数据迁移完毕后，需要对HDFS服务（以及相关的服务如Gaia、Hive、HBase、MR、Hippo、FtpOnHDFS等），对其进行停止，再启动。
3.3、HDFS数据迁移
HDFS中的数据主要存储的为用户的业务数据，这次的迁移核心主要也在这块数据上。HDFS数据迁移一般使用Hadoop自带批量传输工具distcp，该工具通过MapReduce方式以并行方式完成数据的传输，并支持流控、断点续传(-update)、校验等功能，不过distcp的使用前提是需要两个集群的所有节点网络都能互通。
这次迁移的老集群在客户自有机房，新集群部署在腾讯云CVM上，属于腾讯云的机房，两套集群均只有私有网络不能互通，无法直接使用distcp工具迁移。我们在内部调研得知腾讯云有提供数据迁移工具CDM（可以理解为一个容量非常大的移动硬盘）,经过和客户及CDM侧讨论，决定采用腾讯云CDM COS distcp方案迁移HDFS数据，采用此方案的原因有以下几点：
（1）新集群使用的腾讯云CVM机器，CVM机器与腾讯云COS内网互通（最重要的因素）。
（2）TBDS平台与COS有打通，通过在TBDS上进行配置后，可直接使用distcp工具将COS的数据迁移到TBDS平台的HDFS上。
（3）CDM数据到COS过程由CDM侧负责保障，有成熟迁移经验，无需客户介入，迁移风险低。
（4）腾讯云机房只允许腾讯云的设备进出机房，不能使用客户的硬盘拷贝数据然后带到腾讯云机房挂载上去。
关键步骤：
1.客户在腾讯云官网申请CDM设备和COS存储
2.腾讯云CDM侧邮寄CDM设备至客户机房，客户根据CDM的指导文档将CDM设备挂载在旧集群
3.我们梳理HDFS上需要迁移的目录，客户侧根据迁移操作文档拷贝数据至CDM
Hadoop dfs -get /apps/hive /mnt/CDM/
....
4.客户侧将拷贝完毕的CDM设备邮寄回腾讯云CDM侧
5.腾讯云CDM侧将数据从CDM设备拷贝至腾讯云COS
6.通过配置将TBDS平台与COS打通
7.最后我们使用distcp工具将COS数据迁移到TBDS新集群
Hadoop distcp -i -m 100 cosn://cos-test-xxx/apps/hive /apps/
....
因为把数据从COS迁到HDFS上耗费的时间和精力最多，把迁移HDFS数据期间遇到的几个主要问题总结下。
（1）distcp从cos上迁移至新集群的HDFS时，yarn的nodemanager报错：
java.lang.OutOfMemoryError : unable to create new native Thread
排查：一开始我们以为内存不足，但是登录到服务器发现还有很多可用内存，不存在内存不够的问题。再经过深入调查发现提交distcp迁移任务至yarn上后，yarn的子进程启动了很多的线程数，通过日志也发现这些线程都是在做文件的拷贝动作，而系统默认配置的线程数不能超过32768，经过重现观察发现在程序报错的前几秒，系统的线程数基本已经达到32768这个数目。
解决：调整系统线程默认配置/proc/sys/kernel/pid_max的值为50000后，观察系统线程数并未超过此值
跑任务后系统的线程数：
从下图可以看到，日志中均是在做文件拷贝的动作
将/proc/sys/kernel/pid_max增大至5万后，并未超过此值
（2）执行distcp命令后报错退出call cos sdk failed
解决：经过联系COS侧排查得知，是由于COS侧有对用户的list操作进行频控，当对过多的文件进行list时会触发此动作，联系COS侧临时提高此用户的频控阀值。
4.总结
这次迁移算是TBDS集群的第一次完整迁移案例，包括用户的业务数据，平台应用，从项目启动到最后完成迁移差不多耗费了1个月的时间。我们从这次工作中也发现了不少可以优化的地方，比如mysql的数据导出，现在是人工比对库表再手动导出，部分文件权限在迁移后也发生了变化，目前也是人工调整，这些工作在后续都可以做成自动化工具以提高迁移的效率。虽然这次的迁移工作不能代表以后TBDS的所有迁移场景，但是借助这次迁移工作我们也彻底梳理清了平台组件与前端应用的关联，包括Mysql库表关系，监控逻辑，用户业务数据的落地逻辑等，并且我们整理了平台中各种数据组件的详细迁移操作指南，填补了TBDS的迁移文档库。最后对于这次迁移的总结，也给自己和其他同事在以后再次遇到TBDS的迁移需求时提供一个参考思路。
