写点什么

基于 ZFS 的 Hadoop 透明压缩

  • 2019-09-22
  • 本文字数:4212 字

    阅读完需:约 14 分钟

基于ZFS的Hadoop透明压缩

随着公司业务规模的不断增加,hadoop 集群接入的数据量不断增加。对集群的计算资源和存储资源都提出了更大的需求。相比之下,对存储资源的需求更加迫切。对集群数据进行合理的操作,能够节省集群的存储资源,提高存储资源利用率。

技术背景

Hadoop 是当前广泛采用的大数据处理平台,其对数据采用三备份方案,如下图所示:



这种三备份机制极大的提高了存储数据的冗余性,保障集群数据的安全。但是三备份措施也极大的提高了存储成本。以当前集群看,需要存储数据约 3.2PB,三备份后,至少需要 10PB 的存储空间。目前集群提供的总空间约 7PB,不能满足业务的存储需求。


目前提升集群存储能力可以从下述两个方面入手:


(1)集群数据治理


HDFS 作为数据存储平台,存放所有业务数据。使用比较频繁的业务数据,大都在 3 个月之内,是热数据;3 月以外的数据使用较少,为冷数据。对冷数据进行压缩、周期删除管理、迁移到廉价存储等是节省集群存储资源的有效手段。


(2)Hadoop 三备份策略优化


Hadoop 的三备份机制保障了数据的安全性,但是也带来了存储成本的增加。尤其对冷数据的三备份,造成了存储资源的浪费。在 hadoop3.0 版本中,引入了 EC 码的机制,利用纠删码的特性改造了三备份机制。使用 1.5 备份实现了三备份的功能,同样能够保障数据安全性。这会极大减少集群存储资源的使用。


当前 Hadoop3.0 仍然没有发布 release 版本,且版本升级对集群的影响比较大。因此更为现实的方案是采用数据治理。综合集群的情现实况,以及业务需求,我们优先选用对冷数据进行压缩的方式,来降低集群的磁盘存储占用。


当前比较成熟的压缩方案有两种:


(1)用户写入数据时压缩


此种方案成本较低,在客户端开启压缩即可。但是对于集群管理来说,带来了挑战。同时无法有效的区分集群中的冷热数据。


(2)后台透明压缩


后台透明压缩,通过 hadoop 本身的存储策略,以及 linux 特定存储系统实现。能够对前台用户透明的进行数据压缩,同时可以较好的定量冷热数据,方便集群管理控制。同时,方案技术难度相对更高。


基于集群自身情况,减少对上层用户的影响,决定选用后台透明压缩的方案。透明压缩技术使用到了 HDFS 异构存和 ZFS 文件系统级压缩技术。


(1)HDFS 分层异构存储策略


HDFS 的分层异构存储是 hadoop2.6+中引入的新技术,支持将不同使用频度的数据放入不同的存储介质,以更合理的使用集群资源。如,冷数据放在磁盘或者介质密度更大的文件系统。热数据放在 SSD 等。异构存储使得一套 Hadoop 可以分类存储冷热数据。



在 hadoop 中,将存储类型分为 RAM_DISK,SSD,DISK,ARCHIVE 等几种类型,其存储速度顺次降低,存储成本也相应顺次降低。同时,hadoop 提供了针对不同存储介质的存储策略。



Lazy_Persist: 基于内存的存储策略。将多备份中的一块放入内存,其余放在磁盘

All_SSD: 所有数据块均放在 SSD 中。

ONE_SSD:一块放入 SSD 中,其余放在磁盘中,这是对 All_SSD 的折中。

Hot:Hdfs 默认的存储策略,当前集群使用的也是此种策略。

Warm:一块放在磁盘,其余放入 ARCHIVE 高密度存储中。此种策略比较适合对仍有使用的冷数据。

Cold:所有数据块均放入 ARCHIVE 中,实现冷数据的高密度存储。但是在读取时,需要花费一定的时间。


当前集群使用的是默认 HOT 策略,即所有冷热块都放在 DISK 上。


(2)Linux ZFS 文件系统


ZFS 文件系统(的英文名称为 ZettabyteFileSystem),也叫动态文件系统(DynamicFileSystem),是第一个 128 位文件系统。最初是由 Sun 公司为 Solaris10 操作系统开发的文件系统。作为 OpenSolaris 开源计划的一部分,ZFS 于 2005 年 11 月发布,被 Sun 称为是终极文件系统,经历了 10 年的活跃开发,而最新的开发将全面开放,并重新命名为 OpenZFS。


ZFS 文件系统具有如下的特点:


  1. 存储池

  2. Zfs 摒弃了传统的卷管理等复杂方式,用存储池的概念统一管理所有存储空间。


  1. 自我修复功能数据保护-软 raid

  2. ZFS 文件系统通过 ZFS Mirror 和 RAID-Z,在读取文件时进行校验。如果有错误则向上层汇报并自动修复错误。

  3. 压缩与可变块大小

  4. ZFS 支持压缩功能,能够在数据写入和读取时,进行压缩和解压缩操作。可变块大小则会在文件存储时,自动设置其块大小。

  5. 写时拷贝/校验和/快照

  6. ARC(自适应内存缓存)与 L2ARC(SSD 做二级缓存)

设计方案与实现

基于 ZFS 的 Hadoop 透明压缩技术的 Hadoop 透明压缩的核心是利用 Hadoop 异构存储特性,将特定的数据写入到支持写入和读取压缩的文件系统中。以实现特定类型数据的透明压缩,透明解压缩。这其中的其关键部分是异构存储数据的快速界定,压缩文件系统的性能最优调整。


下图是该技术的主要实现流程:



首先,界定需要做冷热数据隔离的主要内容;其次,上图是 Hadoop 透明压缩的设计思路。生成特定的通过获取特定的冷数据列表,并标记其冷数据率;然后,定期从冷数据表中取出为完成冷数据迁移的行,进行移动。


在此过程中,我们做了如下的优化工作:


(1)Hadoop 冷热数据分离优化


1)异构存储策略选择


Hadoop 提供了多种存储策略。基于集群的实际情况。决定采用了 WARM 策略来存储冷数据。即利用 WARM 策略,一块备份仍存放于磁盘,其他两个备份被分块会被写入支持压缩的 ZFS 文件系统。这既较大程度的对冷数据进行了压缩,又在需要读取冷数据时,直接提供了一份未压缩数据进行读取。


2)HDFS 冷热数据移动优化


完成存储策略设定后,启动 hdfs mover,hadoop 会自动移动冷热数据到目的空间。但是此时会出现一个问题。默认情况下,Hadoop 会扫描所有 HDFS 数据块,以判定其是否处于合适的位置空间。这在集群规模较大时,该操作会耗费较多的时间。且每一次扫描,均会进行全块扫描。为了解决此问题,我们通过建立冷数据表来提高扫描效率。基于此种情况。我们做了一些优化:


1> 基于 hive 元数据,选择创建超过三月的分区目录,加入待移动列表。根据 hive 库信息/表/分区的形式,建立扫描空间,避免全集群扫描

2> 定期更新待移动列表中每个目录的完成率,对于完成率统计每个分区的移动率,对于移动率 100%的目录路径,不再进行扫描。

3> 定期取出完成率小于移动率不为 100%的目录。路径,形成一个移动数据文件。执行 hdfs mover –f path.txt 以此限定 mover 的扫描范围仅限在指定的路径中

采取上述措施后,极大的减少了每次 mover 扫描的数据量,大幅提升移动速度。


(2)ZFS 文件系统优化


1)ZFS 文件系统压缩效率


ZFS 文件系统本身内在支持多种压缩算法,数据写入时压缩,读取时解压。常用的压缩算法有 GZ,LZ4 等。合理选择压缩算法,有助于最大限度的提升透明压缩的效率。


1> ZFS-gz,ZFS-lz4,ext4 下压缩效率及 CPU 占用。从下方表格可以看出,GZ 的压缩效率最好,CPU 占用也最高。



2> 读取效率对比



由上图可知,zfs 文件系统下,gz 和 lz4 的读取和写入效率均高于 ext4 文件系统。gz 与 lz4 在读取,写入速度多上各有优劣。Lz4 稍微占优。


3> datanode 加载速度对比


DataNode 对压缩数据的加载时间,直接关系到访问此部分数据时的效率。



从上表可知,ZFS 的 gz 压缩在 DataNode 加载数据上对 LZ4 有部分优势。较为接近 EXT4。


综合考虑压缩率,读取、写入速度、datanode 加载速度等,选定 gz 作为 ZFS 文件系统的压缩算法。


2)ZFS 文件系统 ARC 缓存调整


ZFS 文件系统的 ARC 缓存系统是一种同时缓存数据块请求和数据块使用频度的新型缓存系统,设置合适的大小,有利于有效的发挥 ZFS 文件系统的性能。



测试发现,在将缓存由 10GB 调整为 100GB 时,ZFS 文件系统并无显著提升,因此将 ZFS 文件系统的 ARC 缓存设定为 10GB


3)关闭 atime


Atime 是一个文件或目录的最后访问时间,如果文件被频繁访问,那么 atime 就会被频繁更新。这会影响到磁盘的性能瓶颈,其影响范围会包含 ext4,zfs 等文件系统。关闭 atime 对 hadoop 磁盘性能提升较大。


4)DataNode 使用 Jbod 而不是 Raid


在 Hadoop 中,可以通过对磁盘 raid 来提升数据的安全性,在 namenode 节点,我们可以如此配置。保障 namenode 数据的安全。对于 DataNode,hadoop 的 Jbod 机制已经能够保障数据安全,对 datanode 使用 raid 会降低存储性能。在相关测试中,raid 相比 jbod 有 10%-30%的性能损失。

透明压缩成效

在 Hadoop 集群透明压缩上线后,集群的存储资源明显下降,以相对少的服务器,满足了当前线上业务对空间的需求,同时上线后,未对上层业务作出变动,实现了透明压缩。


(1)集群存储情况


当前集群存储数据逻辑占用约 3.1PB,依据 hadoop 的 3 备份原则,需要至少 9.3PB 的空间来存储这些数据。当前 总空间约 7PB,远不能满足需求。在上线 Hadoop 的透明压缩后,目前存储空间以使用约 6PB,约占 85%。节省了月 3PB+的存储资源。以单台服务器 80TB 存储空间计算,节省了约 40 台服务器。数百万成本。


同时,在该项目上线的前三天,日均压缩数据 180TB,压缩比 22%。在上线前,集群数据急剧增加(3 天内):



上线透明压缩后:



在数据量持续增加的情况下,实现了集群存储占用的不断下降。


(2)用户影响


透明压缩针对的是文件系统级的压缩,用户在使用时,完全无感知。实现了对用户的透明。

未来展望

(1)QAT 加速与全数据压缩


QAT 加速卡是 intel 推出的用于协助完成数据压缩和解压缩的硬件工具,其将 cpu 从这项工作中解放。


目前集群中采取了将单台服务器上的部分磁盘更改为 ZFS 文件系统的策略存压缩存储数据。如果能将所有磁盘均设置为 ZFS 文件系统,则会实现全数据压缩,进一步减小集群的存储使用。


目前,已经向 intel 申请了几块 QAT 加速卡进行测试,未来会给出测试情况分析。


(2)EC 码与透明压缩结合


EC 码是针对 Hadoop 三备份策略的优化,能够从根本上减少对存储量。如果与 ZFS 文件系统压缩结合,会取得比较好的效果。目前只有 Haodop3.0+系统才支持该特性,且官方还未提供 Release 版本,因此该方案更多的是在测试中。具体的需要待官方 Release 版本发布后,测试其效果。


(3)数据回暖


目前基于分区的创建时间策略,后续可以根据 hdfs 审计日志,智能分析一段时间不访问的冷数据进行压缩,同时如果冷数据最近发生一定访问规则,可以自动回暖,解除压缩。


作者介绍:


大数据架构团队,负责公司大数据存储平台、计算平台、实时数据流平台的架构、性能优化、研发等,提供高效的大数据 olap 引擎、以及大数据工具链组件研发,为公司提供稳定、高效、开放的大数据基础组件与基础平台。


本文转载自公众号贝壳产品技术(ID:gh_9afeb423f390)。


原文链接:


https://mp.weixin.qq.com/s/fSrWF4PFZkvky7rkeCf46w


2019-09-22 21:421044

评论

发布
暂无评论
发现更多内容

CSS07 - 伪类

Mr.Cactus

html/css

不愧是Alibaba技术官:程序员必会的架构知识清单,如何让你技术上的提升面试时的丰收

Java架构之路

Java 程序员 架构 面试 编程语言

数据中心“容灾”和“备份”的区别

如何使用Eclipse内存分析工具定位内存泄露

Java老k

Java 内存泄露

如果你听说过 Elastic Certified Engineer

escray

七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

深入理解Nginx的四级指针

赖猫

c++ nginx Linux

CSS09 - 文本&背景属性

Mr.Cactus

html/css

俯瞰Dubbo全局,阅读源码前必须掌握这些!!

冰河

架构 分布式 微服务 dubbo 服务治理

还在手动写数据库文档吗?试试这个工具,划水干活儿两不误!

我爱娃哈哈😍

数据库 文档生成

要想软件“一想之美”,UI测试少不了

华为云开发者联盟

软件 测试 华为云

volatile 关键字精讲

伯阳

Java volatile 后端 关键字 多线程与高并发

天天CRUD,被领导怼,我是如何从小公司菜鸡到阿里P8架构师?,首次分享Java程序员黄金五年进阶心得

Java架构之路

Java 程序员 架构 面试 编程语言

在onelogin中使用OpenId Connect Implicit Flow

程序那些事

权限系统 程序那些事 openid 权限架构 onelogin

CSS08 - CSS特性

Mr.Cactus

html/css

边缘计算安全技术研究

华为云原生团队

云计算 大数据 云原生 边缘计算 华为云

数据库表数据量大读写缓慢如何优化(1)【冷热分离】

我爱娃哈哈😍

大数据 架构 海量数据库的设计与实践 优化 数据库优化

【Mysql-InnoDB系列】InnoDB架构

程序员架构进阶

MySQL 架构 innodb 28天写作

Spark HistoryServer日志解析&清理异常

kwang

大数据 spark hdfs

甲方日常 81

句子

随笔杂谈

甲方日常 82

句子

随笔杂谈

一次系统调用时间过长追踪完整教程案例

AI乔治

Java Linux 架构

LeetCode题解:111. 二叉树的最小深度,BFS,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

一个正确的编程思维

程序员吴师兄

28天写作

从七日更,到28天写作挑战,我无法拒绝的原因

梁龙先森

大前端 编程语言 28天写作

文档驱动开发模式在 AIMS 中的应用与实践

华为云开发者联盟

Web 代码 API 文档

CSS06 - 标签的显示模式与转换

Mr.Cactus

html/css

【CSS】CSS对大小写敏感吗?

德育处主任

28天写作

开始的开始-可能是最早提交的28天写作活动作品

石君

28天写作

VUE项目性能优化实践——通过懒加载提升页面响应速度

葡萄城技术团队

Vue

如何使用Eclipse内存分析工具定位内存泄露

AI乔治

Java eclipse 架构

杜绝标题党,好的标题是成功的99%

xcbeyond

方法论 28天写作 写作技巧

基于ZFS的Hadoop透明压缩_文化 & 方法_大数据架构_InfoQ精选文章