vivo HDFS EC大规模落地实践

作者:Gu Ruinan - 互联网大数据团队- Zhao Yongxiang

Erasure Coding(简称EC),是一种纠删码。EC编码能够对部分缺失的数据进行数据恢复,广泛应用于存储与通信领域。在Hadoop3.0版本中,作为一种新的冗余存储的方式引入进来。使用EC编码的方式替代原来的三副本存储,保证数据可靠性的同时可以节约存储。相应地,付出的代价是读取性能的下降,对于访问频率不高的数据,使用EC编码很合适。

vivo目前HDFS集群节点达万台级别,数据规模接近EB级别,并且业务数据规模还在以较高速度持续增长中。在推进压缩算法缓解存储压力的同时,EC编码的推进也是存储降本的一大有力手段。

1分钟看图掌握核心观点👇

一、背景

Reed-Soloman编码(简称:RS码),是EC里一种经典的编码算法。下面简单介绍一下Reed-Soloman编码过程(不涉及数学原理的详细解析)。

假设我们的输入数据以D1,D2,...D5的向量来表示,矩阵B为编码矩阵,进行编码后得到D和C组成的矩阵,其中D为数据块(data block),C为校验块(parity block)。我们的数据写入都需要经过编码后才能进行存储。

假设我们抹除掉了D1,D4,C2。

我们能通过编码矩阵得到一个用于恢复的矩阵,将这个矩阵与剩余块相乘,可得到原来完整的输入数据,再次进行编码后可恢复C2。

二、存储布局的改变

EC编码对HDFS的应用,使数据块存储的结构发生了改变。

在传统三副本的策略中,一个文件被划分为不同的块(block)进行存储,一个数据块对应三个副本(replication),每个副本存储的内容完全一致,数据的存储时连续的,这种布局称为连续块存储布局(Contigous Block Layout)。

在EC策略中,一个文件被划分为不同的块组(Block Group)进行存储,一个块组内划分为多个内部块(Internal Block),其中,内部块又分为数据块(Data Block)和校验块(Parity Block)。数据块存储文件的数据,校验块存储由数据块生成的校验内容。一个块组内,可容忍的块丢失数量与校验块数量相同,如果丢失块的数量大于校验块数量,则数据不可被恢复。

在块组中,数据并不像三副本策略一样连续存储在一个块中,而是将连续的数据拆分为多个Cell,分散存储在不同的内部块中,形成一个个条带(Stripe)。这种布局称为条带存储布局(Striped Block Layout)。

我们集群目前采用EC策略RS6-3-1024k,其中6表示块组中数据块数量,3表示块组中校验块数量,1024k表示Cell大小。

三副本是HDFS默认的冗余存储方式,优点是当有机器宕机,数据丢失时,不会影响用户的读取,补块的方式也仅仅是副本的复制,简单高效。缺点也很明显,存储的冗余度高,三副本的存储冗余度达到200%。

EC编码通过编码的存储方式,来进行冗余存储。优点是存储的冗余度低(具体的冗余度取决于不同的存储策略),可靠性高。缺点是写入需要编码,造成性能的下降(大概3-4倍),补块时间长(校验块越多,补块时间越长),读取时如果遇到DN宕机,也需要额外的资源与时间进行解码恢复。

三、HDFS EC 码应用实践

3.1 兼容性问题

3.1.1 服务端

早在2020年,EC已经在vivo的HDFS集群中投入使用。EC是Hadoop3.0后推出的新特性,要想正常使用,服务端和客户端都需要升级到3.0或以上版本。

由于离线集群规模庞大,升级的调研和实施需要耗费比较长的时间。因此,我们临时搭建了一套基于3.1版本的冷备专用集群,使用EC来存储冷备数据,如下图:

冷备集群使用3.1版本的Yarn,可以同时访问热数据与冷数据,3.1版本的HDFS专门用来存储EC编码的冷数据。

由于新增冷备集群的方案增加了集群运维的成本,架构也不够优雅,只是暂时的解决办法。在2021年,我们离线集群完成了HDFS从2.6到3.1的全面升级,正式支持EC编码,在2022年,我们完成绝大部分冷备集群的数据到离线集群的迁移,增量数据全部写到离线集群中。

3.1.2 客户端

我们没有对Client2.x客户端访问EC文件做兼容性的开发,更多是通过推动用户升级客户端来访问EC文件,例如Spark2任务切换至Spark3任务。该方案增加了用户迁移的成本,但同时也减少了HDFS侧的开发成本,用户任务逐步往Spark3迁移也更符合未来的规划。

3.2 EC 异步转换

由于EC编码会带来对文件读写性能的下降,对EC编码的定位主要应用在冷数据的存储,业务并不直接写EC数据,而是采用后台转储的方式,把三副本数据转储成EC数据。对不同业务而言,对"冷"的标准都不一致,不能用统一的标准来衡量数据的冷热。在推广EC编码的过程中,平台并不用统一的标准来"强制"把用户数据转为EC,是否转为EC的最终决定权在用户。我们向用户提供分区访问频率的数据作为参考,帮助用户来了解不同分区路径的访问频次,让用户更好地选择哪些分区转为EC编码。用户可以通过大数据开发者平台(Big data developer platform)设置x天前的数据转为EC存储,后台程序会将相应分区通过Hadoop distcp,将三副本写入到已设置EC策略的目录中,再用新目录替换掉原目录,其中目录名称不变,保证了元数据一致,用户无需修改代码。

3.3 Distcp 数据校验

先来介绍一下HDFS两种校验和的方式。

3.3.1 MD5MD5CRC

此方式为HDFS默认的校验方式,这种校验方式会进行两次MD5计算一次CRC计算,从名字就可以反映出来。

  • 块级校验和:所有chunk CRC的级联的MD5值。(an MD5 of a concatenation of chunk CRCs)

  • 文件级校验和:所有块校验和的级联的MD5值。(the MD5 of the concatenation of all the block checksums)

由定义可知,这种方式对于HDFS分块大小敏感,不同的分块大小块级校验和不一样,导致文件校验和也会不一样。

3.3.2 Composite CRC

Composite CRC一个新的校验和计算方式。

当计算块校验和不是简单地将chunk CRC进行级联(concatenation),而是将chunk CRC进行数学式的组合(mathematically compose),计算文件校验和时对文件所有的chunk CRC进行数学式组合。因此,对于文件校验和,该计算方式对于分块大小并不敏感。 CRC算法相关论文。

在数据进行distcp的过程中,HDFS会进行校验和校验,确保distcp的源数据与新数据一致,但正如前文所说,EC编码会带来存储布局的改变,相同的文件三副本与EC数据存储的块大小,块数量都不一致,这让HDFS默认的MD5MD5CRC的方式变得不再适用。

需要将校验方式改为COMPOSITE CRC。

可通过 dfs.checksum.combine.mode 改变校验和校验的方式(MD5MD5CRC(默认值) or COMPOSITE_CRC)。

即使distcp过程中会进行校验,为了确保万无一失,我们还会对前后的分区目录的校验和校验。(目录校验和计算方式为将目录下文件MD5值排序,再进行MD5计算)为了保证转EC前后文件的一致性,多加一道校验的"工序"是值得的。

3.4 文件损坏与修复

文件损坏与丢块是HDFS EC应用绕不开的一个话题,原因是在Hadoop EC特性新推出的过程中,有若干与文件损坏相关的bug。EC文件损坏的过程主要发生在补块阶段,计算结果的不准确导致了新补的块与原来的块内容不一致。我们在EC推广的过程中,也狠狠地踩过文件损坏的"坑"。如何避免文件损坏,如何对补块的结果进行校验,如何修复损坏文件是三个重要的需要解决的问题。

3.4.1 如何避免文件损坏

通过对社区的调研,我们打了若干的patch来解决文件损坏与丢块的问题。

3.4.2 对补块结果的校验

我们引入了HDFS-15759,Patch提供了一个对EC补块的校验功能,在DN执行补块任务时,对补块结果进行校验。如果校验失败会抛出异常,并且补块任务会进行重试。

3.4.3 EC批量校验工具

我们对开源的EC批量校验工具进行了定制化的改造,工具能够对EC目录进行批量扫描,扫描出目录中的损坏的EC文件,在此感谢Stephen O'Donnell对工具的开源。

原理大致如下,对数据块进行EC编码,通过比对新生成的校验块和原来的校验块,来验证是否存在文件损坏。如果比对通过,则没有文件损坏,如果比对不通过,则存在文件损坏。

工具支持MR,可以分布式执行,此外,也可只对一个条带进行比对,只生成校验块的第一个条带,比对与原校验块第一个条带是否一致,这些都大大提高了批量校验EC文件的效率。

工具地址:

https://github.com/sodonnel/hdfs-ec-validator

3.4.4 修复损坏文件

在我们的集群,绝大部分损坏的文件都是ORC文件,ORC文件发生损坏时,由于其元数据分布的方式,会出现元数据的损坏,ORC无法解析。

假设一个块组内,数据块编号为1~6,校验块编号为7~9,数据块1损坏,我们可以通过读取数据块2~6加上任一一个校验块,得到"完好"的文件,对于ORC文件而言,判断是否完好取决于能否正常解析。

HDFS客户端get文件的时候默认只会读取数据块,我们通过改造HDFS客户端,使我们能够读取块组内指定编号的块,通过各种排列组合,得到一个"完好"的文件,之后将"完好"的文件覆盖掉HDFS上的损坏文件,来达到文件修复的目的。

3.5 机器异构&存储策略

由于EC数据访问频率低,将EC数据存储到大存储的机器上,利用机器异构降低我们的单位存储成本。

在HDFS中,如果文件写入的路径设置了hot存储策略的目录,则会优先把文件存储到disk存储介质当中,如果设置了cold存储策略的目录,则会优先把文件存储到archive存储介质当中。

因此,当我们将大存储机器的盘都设置为Archive,并且将EC目录设置为Cold存储策略,即可将EC数据存放到大存储机器上,使TCO降低,进一步实现存储降本。

四、总结与展望

vivo的HDFS集群已存有几百PB的数据采用EC-RS6-3-1024k策略存储,相比三副本EC-RS6-3-1024k方式能带来50%的存储收益,节省了数百PB的存储空间,为公司带来了巨大的收益。目前我们推荐用户将访问频次较少的数据转为EC,因为EC会带来读取性能的下降,如何减少EC带来的读取性能下降?以及后续细化对用户数据的冷热分层,对越冷的数据采用冗余度越低的EC策略,EC补块速度优化等,都是后续继续大规模推进EC需要解决的重要难题。

相关推荐
江苏汉软19 小时前
mes现场管理系统
大数据
tanglinS19 小时前
工业陶瓷在半导体设备里都用哪里?氮化铝基板与氮化硅结构件的静电无尘角色
大数据·运维·人工智能·自动化·材质
慧新软件20 小时前
Google算法更新后,外贸SEO优化策略如何调整
大数据
xushichang123_20 小时前
如何观看 2026 亚马逊云科技中国峰会全场主题演讲与技术分论坛内容?
大数据·人工智能
招财小梗21 小时前
AI矩阵获客,品牌连锁落地有啥方案?
大数据·人工智能·矩阵
黎子越21 小时前
大模型基础名词概念
大数据
zandy101121 小时前
主流 AI Agent搜索Skill推荐及高阶选型指南
大数据·人工智能
跨境卫士苏苏21 小时前
2026年做跨境电商,TikTok美区半托管这3个品类正在严查,第2个很多新手还在铺货
大数据·人工智能·跨境电商·营销策略
GIS数据转换器21 小时前
村镇无人机物流配送与跨域监测一体化平台
大数据·运维·人工智能·科技·无人机
知识燃料1 天前
企业技术决策者落地 AI Agent 体系,AWS 中国峰会有哪些战略与工程内容可看?
大数据·人工智能