请选择 进入手机版 | 继续访问电脑版

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

[复制链接]
小小海 发表于 2021-1-2 19:02:19 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
  在本年年中,本人有幸到场了公司数据平台迁移到云上的整个过程。整个过程历时半年多,我们作为一个顶级的二流互联网公司,数据平台的发展履历了几代人的积极,已经发展的比力完善,但是依然有许多问题需要借助云的本领去办理,在这次迁移过程中,履历了各种人事变迁,业务和技能的问题。不外也让我对数据平台的整体的业务和技能架构举行了一番梳理和学习,有了深条理的认识,在这个阶段也履历了心灵和肉体上的摧残,记载一下,给自己,后人留下一点东西。
目次



  • 为什么要举行迁移上云
  • 数据平台迁移的黑汗青
  • 困难点
  • 迁移的过程
  • 详细流程
  • 一些详细的问题
  • 心得
  • 感谢
为什么要举行迁移上云

这是个深奥的问题。


  • 技能掉队 当前技能体系已经相对掉队,需要使用云上的一些服务,增强现有的体系架构。好比云原生,弹性扩容。
  • 淘汰运维资本 开辟人员短缺,对于一些公共的大数据套件,可以使用云上相对稳定的版本,和甲方提供的一些服务支持,淘汰系统的维护资本。别的一方面数据的存储资本和呆板的资本,通过业务梳理和云化,可以低沉很大的资本。
  • 甩掉一些汗青包袱 迁移的过程实在也是业务梳理的过程,下线掉不需要的应用和数据,而且对一些重复功能的应用举行归并。(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%覆盖。一步一个脚迹。不要依赖业务方去做数据校验,业务方对业务敏感,但是前提是线上应用,而不是测试阶段。业务方更多要放到割接完成之后,做问题排查。
感谢

整个上云过程大概连续了2个季度,从最初的方案论证,到最后上云乐成,现在想起来,满是感慨。脑海中依然浮现着一起加班的兄弟们,@海风,@敖丙,@明枫,@申屠。这种履历,一次足够了。
那些48小时连轴转,带着妹子加班到破晓2点,楼道里抽过的烟把塞满了垃圾箱,晚上做梦都是在改bug的情景(突然想起割接的第一个破晓,各种报错, @海风一直在说,怎么办?怎么办?)。
在这个时候,感谢一下华为的老哥哥们,多少个日夜的服从和伴随。才有了最后的上云乐成。华为的大保健式服务,真的名不虚传(反正我是真心的敬佩和感激)。

来源:https://blog.csdn.net/chenfeng0829/article/details/111861703
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )