浅谈数据平台迁移上云的经验教训

最新推荐文章于 2022-11-16 15:11:09 发布

北方~

最新推荐文章于 2022-11-16 15:11:09 发布

阅读量2.2k

点赞数 3

分类专栏：大数据迁移

本文链接：https://blog.csdn.net/strawhat2416/article/details/111861703

版权

大数据同时被 2 个专栏收录

34 篇文章 4 订阅

订阅专栏

迁移

1 篇文章 0 订阅

订阅专栏

在今年年中，本人有幸参与了公司数据平台迁移到云上的整个过程。整个过程历时半年多，我们作为一个顶级的二流互联网公司，数据平台的发展经历了几代人的努力，已经成长的比较完善，但是依然有很多问题需要借助云的能力去解决，在这次迁移过程中，经历了各种人事变迁，业务和技术的问题。不过也让我对数据平台的整体的业务和技术架构进行了一番梳理和学习，有了深层次的认识，在这个阶段也经历了心灵和肉体上的摧残，记录一下，给自己，后人留下一点东西。

为什么要进行迁移上云

这是个深奥的问题。

技术落后 当前技术体系已经相对落后，需要利用云上的一些服务，增强现有的体系架构。比如云原生，弹性扩容。
减少运维成本 开发人员短缺，对于一些公共的大数据套件，可以利用云上相对稳定的版本，和甲方提供的一些服务支持，减少系统的维护成本。另外一方面数据的存储成本和机器的成本，通过业务梳理和云化，可以降低很大的成本。
甩掉一些历史包袱 迁移的过程其实也是业务梳理的过程，下线掉不需要的应用和数据，并且对一些重复功能的应用进行合并。(spark三个版本需要进行升级成统一的高版本，历史遗留的异构数据源监控，创建表，数据源心跳等)，很多已经不再维护。

重点：省钱才是王道。否则没人愿意干这事。

数据平台迁移的黑历史

在我们的平台里面总共做了两次大规模的数据迁移，这两次迁移其实也是很多小公司成长的缩影。很多互联网公司其实应该和我们一样，从很小的数据平台发展开始，然后在公司业务迅速膨胀，开始组建自己的机房，数据平台，数据仓库，然后到系统稳定，系统开始臃肿，运维成本太高，需要降低运维成本，最后选择上云。

第一个阶段

公司规模很小，使用mysql就能满足业务的需求，随着业务的发展，需要做一些分析，开始手动搭建大数据的套件(hadoop, hive, hbase)，简单的DAG调度，数据交换，可视化报表。基本使用开源的就能满足需求。

第二个阶段

公司业务量爆发式增长，之前的架构和开发人员已经满足不了业务的需求，开始疯狂招人，数据平台开始背书大厂。人才是解决问题的关键。各种不同的系统拔地而起。大数据开始有自己的集群和机房。在这个阶段需要对第一个阶段的数据进行迁移，数据迁移的手段多种多样，distcp是一种手段，但是对于上p的数据，根据网络带宽和传输的速度，需要消耗很多天，而且面对每天的增量数据，如何进行验证也是一种很麻烦的问题。但是在这个阶段有个很重要的问题，自建机房，所以机器直接搬走。避免了增量的问题。

第三个阶段

公司业务偏于稳定，数据平台人员人员开始浮动，N手代码是常有的事情，数据冗余，之前的业务大多靠物理机进行构建。机器资源浪费严重。所以就有了降成本的需求。降成本第一件事情就是降低开发运维人员，但是盘子已经铺开，很多组件业务还是需要的，无人维护的问题凸显。所以开始走向上云的路子。使用云的能力和服务，把一些公共的组件(hadoop, hive, hbase等)交给云处理。在历史包袱和大数据量的场景下，这次迁移就比较困难。

困难点

异地机房搬迁 异地机房搬迁，测试节点带宽1G, 最后拉专线100G, 但是网络延迟巨大。
数据规模大 数据单拷贝接近4P, 文件3亿，集群每日数据增量50TB以上。4个CDM集群，规格64U128G, 每个CDM支持并发200个迁移任务，带宽40Gbit/s，数据迁移需要一个月左右，增量数据存在变数。
存储变更 从HDFS 迁移到对象存储OBS上，全部应用客户端需要升级适配，并且性能需要重新验证。
版本升级， hadoop, hive进行了版本升级，spark整合华为云hadoop,hive,并且做大版本的合并。
系统功能/链路复杂 调度任务3w+, 每天增量8w+, 整体链路复杂，数据的流入，流出，依赖，被依赖。应用之间的数据流转，难以梳理完全。
一次性割接 核心应用全部需要一次性割接完成。失败回滚数据难度大。

迁移的过程

事前

评估阶段

评估云厂商的能力和当前的业务适合哪个云厂商(主要是看服务能力报价)。
可行性调研 在云厂商的机器/网络上模拟一些场景是否match. (主要看一些核心的技术点是否能够match,或者有没有替代方案).
性能调研 测试云厂商的机器和网络以及其他的性能(一般都是根据厂商提供的一些指标，对比现有的机器。这个没有参与，不好说)。

业务整体阶段

梳理现有业务系统，数据平台以及数据平台的下游。涉及多部门的合作(运维，数据库，数据平台，数据平台下游)
整理当前数据平台的业务架构，数据流向，以及迁移的范围(一般来说数据平台的下游应用不用迁移或者稍后迁移，与底层强相关的先迁移)
整理迁移后的目标架构。

评估阶段

评估应用迁移方案
评估数据迁移方案
评估整体的迁移方案

功能性测试阶段

搭建底层测试集群(一般都是小容量)
搭建应用测试集群
整合云上组件和应用进行兼容测试。
同步少量的数据进行功能性的测试。

计算阶段

根据当前的数据量，计算量评估上云之后的数据量和计算量(因为机器，存储介质会有所差异)
计算服务器/存储以及其他的的购买量。
计算每个集群的机器(内存，cpu,磁盘)。
计算数据流入流出网络带宽以及其他因素，

环境资源准备

专线建设和资源准备
网络施工
存储集群搭建

数据迁移阶段

测试集群数据同步一次
线上冷数据迁移
线上增量数据迁移
数据完整性/准确性校验

整体测试阶段

环境配置同步
客户端封装
整体功能性测试
整体性能测试
测试环境数据双跑

割接方案整理阶段

按照应用切分割接方案(包括应用的准备，重启，脚本，验收等)。
按照割接阶段割接方案分配。
割接模拟。
第二次割接模拟。

割接准备阶段

最后一次数据增量同步
最后一次数据库增量同步
割接脚本准备

事中

停旧服务
文件完整性校验
启动新服务
验证功能
第二天kpi任务处理。

事后

问题收集和解决
审批材料
数据缺失同步
最后一次文件完整性校验
历史数据备份
任务优化。
下线旧服务。

具体流程

迁移原始集群历史数据到新集群线上桶 以某一个时间点开始分离历史数据和未来会更新/新增的数据(历史数据是只会读取不会更新)，执行自定义传输脚本在网络专线中迁移到新的集群(因为迁移的是云厂商，这是唯一的方案，如果是自建集群可以考虑物理搬迁)。整个历史数据迁移大概耗时15~20天左右。
校验新集群线上桶历史数据 历史数据迁移完毕之后，就需要对历史数据进行数据校验(文件数，hive表记录数，文件的大小)。这个对比需要制定一个比较完整的流程和具体的校验口径，覆盖率统计。
搭建新集群服务和原始集群历史数据到新集群测试桶。测试桶数据只迁移一份历史数据。并且把原始集群的数据库数据同步到线上集群。新集群的服务建立在完善的网络，服务切换，数据库的前提下，基本上只需要更改以上服务和数据桶就能和正式环境保持一致，新集群访问域名和原始集群可以一键切换。
新集群功能测试 基于测试桶的数据在正式集群上面进行双跑。线上的数据双跑流入测试桶和原始集群。主要测试整体链路是否通畅，并且对新集群的问题进行修复。单任务和整体链路产出时间的对比。报错问题搜集。
校验新集群集群测试桶的增量数据 对每日任务双跑过程中核心链路的数据表进行增量数据的对比，排查问题，修复，并进行下一轮的双跑。直到增量数据保持一致，并且产出时间相差不大。建议系统稳定双跑时间在一周以上，才能进行下一个阶段。
迁移原始集群增量数据到新集群线上桶 按照一天50TB的量级，36天产生0.5p,预估需要5天，每次增量同步按照1/3缩短，总共需要18天，这个需要的时间= 校验增量数据的时间+ 新集群功能/性能测试的时间 + 割接方案确定/演练的时间 + 割接准备的时间。
校验新集群线上桶增量数据 主要校验文件数目是否一致，核心链路hive表数据是否一致，临时snapshot写文件是否排除。并且每做一次增量就做一次增量数据校验。
割接停服 在停服前两天，保证线上不做数据库ddl变更，以及核心链路数据表变更。割接当天原有集群停止服务，但是并不一定下线服务。域名，服务接口，数据库更新/切换保证最近的状态。启动正式数据桶和同步线上正式配置。
校验新集群 保证网络，服务调用，接口，数据库正常连接。调度系统开始调度数据。待系统稳定，放开域名，提供服务。并且下游系统开始正常依赖和调度。
其他。包括下游内部应用，线上应用，网络，域名，服务接口等这些就不展开来说了。因为这些已经包含在整体集群的功能性测试。和性能测试上。

一些具体的问题

无法进行线上数据双跑

原始在于：1，增量数据不能当天同步测试完毕。数据无法对齐，就没法进行双跑。2，资源使用上的压力，集群需要部署两份，测试和线上。所有下游业务集群也需要双跑，无法做到统一。
所以：割接过程只能是一次成功，如果失败的话，就需要在调度开始之前下线服务，恢复原始的配置，并且重启原始集群的服务，不过这个需要几个小时的时间。下一次的割接时间未定，可能浪费大量的人力物力。

性能问题

上云不仅是数据上云，还有服务上云，hadoop, hive, zk这些基础的底层组件都需要依赖云的能力。在涉及到版本更改的时候，需要重新封装客户端，在使用云厂商的配置下，根据环境的不同，更新原始集群的配置到新的集群。如果使用了云厂商的服务，一定要对方提供一份配置的最佳实践。比如我们使用了华为云的对象存储obs替换掉了之前的HDFS存储，遇到了很多功能和性能上的问题，怎么排查？以一个spark的任务为例

保留原始集群的yarn-history.spark-history的历史记录。对比应用的配置信息，stage的执行时间，task流入/流出数据量统计。去分析具体的性能上的问题。

一致性保证

系统全程开启MD5校验
失败重试文件列表重新迁移
脚本工具，对HDFS下的文件个数，文件大小进行对比。
hive数据集对比工具对具体hive表数据量对比
业务层面数据分析抽样结果比较

性能检测

对比的指标都是原始集群，包含：单任务的性能测试，整体链路的性能测试。主要有两个方面流入和流出。

网络问题，涉及到跨机房和网络访问，虽然通过专线，但是延迟依旧很大。特别需要关注的是数据的读取，最主要的数据来源就是dump任务和output任务，这些任务一般都需要进行跨网络读取和写入。比如数据写入和读取超时等等。一般都需要更改数据库的配置和增大并发。

数据库同步

包括数据库全量同步和增量补数据。在割接前两天，保证线上数据库无表变更，只有数据的更新。增量补数据通过数据库中间件完成。增量补数据的截止时间为原始集群停机。

割接时间选定

避免与公司促销相关活动冲突或者邻近。
增量数据同步的次数，增量次数越多，出现问题的可能性就越大。
整体集群功能/性能测试完成度，数据校验的覆盖率
领导的意见，这个都懂的。

环境问题

客户机和服务机机型不一致会导致一些依赖native的jar包出现一些莫名其妙的问题，比如snappy压缩。
鉴权问题，云厂商提供的机器和服务大多有复杂的鉴权，这些鉴权在测试过程中很容易造成一些小问题但是难以排查。

心得

保留历史数据的现场 在数据迁移的过程中，尽量增大旧历史数据保存天数，比如:yarn-history, spark-history.以及备份数据，日志。在割接后任务的性能问题是一个大问题，不只是堆机器这么简单，如何能快速的找到数据问题的根源，一般就是要和历史数据/执行计划进行对比。
不做任何不可逆的操作 任何不可逆的操作都存在风险，无论是下应用，还是删数据。尤其是一些有状态的或手工部署的应用，以及一些看似没用的数据和脚本。宁可麻烦一些，给自己留下退路。
数据校验尽量双跑 数据校验是整个迁移的重中之重，一般有三个方面：1. 对比测试集群和原始集群双跑对比相同任务脚本产出数据。2. 对比原始集群和线上集群历史数据。3.对比原始集群和线上集群经过增量同步的数据。一般历史数据迁移并没有太大问题，出现问题多的一般是增量同步数据导致，在增量同步过程一般根据文件更新时间进行同步，但是需要注意的是对于临时snapshot的问题不能进行同步，否则新集群读取会有问题。双跑是必须要做的，并且务必对核心链路的数据进行对比，从性能和数据完整性两方面。
开源组件 对于一些底层组件，hadoop,hive, spark等，拥抱开源是很重要的第一点，尤其是对于一些想要上云的企业，对于修改了一些自定义代码的组件，原始集群运行稳定，但是新集群可能就水土不服，一些很小的问题都需要做大量的排查。对于一些有规模的企业来说，如果有底层更改的需求，尽量同步到社区，然更新到线上，拥抱开源是一种责任，也是给自己未来铺路。
历史包袱 基本上每个集群都有很多历史包袱，包括不同语言差异导致，业务导致，依赖导致，人员流动导致。而且很多历史包袱还是核心功能，牵一发而动全身。所以一个平台想要做的更加长远，不能只是追求新技术，对业务方服务，更要去做历史系统的整合，梳理，优化。这样不仅是成本优化，更是对后来人负责。
信息对称 迁移的过程中，尽量能保证每一两天同步一下任务的进度和做出的修改，保证后端和底层的配置信息以及其他保持一致。这个非常重要，因为在测试阶段配置修改是常有的事情，尤其是hadoop, hive, spark,yarn等配置和调优信息。一次修改全局可见。并且能通知到每个人。迁移毕竟是相互配合的过程。
亲力亲为，业务方为辅 数据校验和业务校验，务必指定一个完整的校验流程和校验口径。核心链路务必100%覆盖。一步一个脚印。不要依赖业务方去做数据校验，业务方对业务敏感，但是前提是线上应用，而不是测试阶段。业务方更多要放到割接完成之后，做问题排查。