Hadoop集群存储空间治理

前言：

作为支撑部门，体现自身价值的重要一点就是节约成本，省钱就是赚钱，体现在公司收支上效果是差不多的。在计算资源可复用、可灵活调度的情况下，存储空间往往是带来成本的最重要的原因。下面主要介绍对hadoop集群存储空间的一些治理方法。

 

治理方法：

1.降低备份数

为保证数据的高可用，hdfs集群使用三副本策略，一份数据会占用三份大小的存储空间。降低副本数可以直接降低存储，但是这种方式不适用所有的数据，且会牺牲一定高可用的风险，不是解决问题的根本办法。

考虑到丢数据风险加大，临时降低副本数可以用在临时文件目录和一些超冷数据目录上，或者线上业务不会直接用到的数据目录上。即使同时坏盘导致数据丢失，也不会直接影响到业务， 但是执行降幅本操作要保证这些数据确实不是很重要的情况下去执行。

 

2.使用压缩

几种压缩方式对比：

性能测试结果：

如图所示：bzip2不支持native，且压缩速率太慢，所以不考虑这种方式；其余gzip压缩比比较高，节省空间，处理速率慢一些。lzo和snappy无论压缩比还是处理速度，都不错，考虑到splitable，lzo最合适。

但实际上，lzo 有个不可忽视的特性。lzo 的 splitable 是需要额外的索引文件来支持的，每个文件都需要有一个同名的索引文件。并且这个索引文件需要单独去生成。这还不算，索引文件会导致实际文件数多出一倍，这对于大规模集群的 NameNode 会造成巨大的压力。

综合上面这些情况，实际生产环境，我们采用的是这样的方式：

• 原始日志采集落地的时候使用 snappy 压缩，兼顾存储空间和处理速度。
• 周期性的对清洗完的日志文件做 archive，并把 snappy 文件转换为 gzip，以节省空间。
• 对结构化的数据，主要是 Hive 表，采用 parquet+gzip 的方式，gzip 节省空间，而相对于 snappy 的性能劣势，则由 parquet 的性能优势来弥补。

3. 冷热分层

在存储领域有个很流行的词，叫异构存储（heterogeneous storage），大白话讲就是不同类型的存储放在一个系统里，比如 RAM、SSD、DISK 等等。不少类似 Spark 这样的框架都对异构存储做了广泛的支持。

异构存储通常用来解决访问性能问题，这很容易理解，不同的存储介质访问速度普遍差了数量级。但同时，空间大小和成本也差了数量级，因此也能被用来节省成本。

HDFS 定义了两个概念来支持异构存储。

第一个概念：Storage Type

用来表示不同类型的存储，包括：

• ARCHIVE，其实就是更大更便宜的硬盘，花同样多的 RMB 能存下更多的数据。我们生产环境单台 128 TB。
• DISK，常见的普通硬盘，我们生产环境单台空间 48TB。
• SSD，常见的固态硬盘。
• RAM_DISK，其实就是内存，一般不会这么奢侈。

很显然，从上到下越来越快但也越来越贵。

第二个概念：Storage Policy

用来表示不同的存储策略，可以对应数据的冷热程度，也就是使用频次。包括：

• Hot，热数据，经常被访问到的数据，所有副本都保存到 DISK
• Cold，冷数据，很少访问的数据，所有副本都保存到 ARCHIVE
• Warm，温数据，介于冷热之间的数据，一个副本保存在 DISK，其他全部在 ARCHIVE
• All_SSD，没有冷热对应，所有副本保存在 SSD
• One_SSD，没有冷热对应，一个副本保存在 SSD，其他都在 DISK

不同版本对以上两个概念的支持可能略有差异。既然是要节省成本，那 SSD 自然就排除掉，离线大数据处理的场景也确实不太有需要 SSD 的情况。

通常按这个思路去划分数据冷热，然后设置 Storage Policy 做就能解决大部分问题了。至于怎样定义和衡量数据冷热，就又是一个可以另开一篇的话题了。简单提点思路，可以按照数据时间和访问次数两个维度去划分区间，从 HDFS 审计日志统计结果。

除了社区的默认支持外，我们在 hot warm cold 的基础上，又加了一层 frozen 层，用来保存最冷的数据。

考虑到 ARCHIVE 已经是最便宜的存储介质了，具体 frozen 的效果并没有也没办法再在 Storage Type 上做文章。我们把目光转移到了第一节提到的降低备份数上。

当然不能是简单的设置 repica，不然这部分就直接放第一节讲了。我们使用的是 HDFS 的纠删码（erasure code）。

通俗点说就是 HDFS 上的 RAID。RAID 这个思路其实早就被 Facebook 和腾讯这样的公司在生产环境大规模实践过，毕竟他们肯定是最先遇到也最有动力解决存储成本问题的公司。可惜要么版本古老不再更新维护，要么闭源没有回馈社区。

好在 Hadoop 3.0 正式支持了这个功能。当然，缺点也是有的。首先，代码稳定性有待考验，毕竟业界还没有大规模的 3.0 踩坑经验；其次，CDH 目前还没有发布 Hadoop 3.0 的正式版，因此部署维护就没那么方便和统一了。

所以，只有真的非常老和很长时间都不用的数据才适合设置为 frozen 放在启用了纠删码的 3.0 集群上。

按我们生产环境 archive 机器成本占 disk 机器大概 1/3 算，分层存储的空间和成本开销对比如下：

看到这个表格，相信大家都有足够的动力去做分层存储了。

4.大存储机器

但是，最近几年，有个说法开始逐渐颠覆大家的传统认知，说没有必要再分 DISK、ARCHIVE 两种机型，直接全部上大存储机器。

考虑到随着万兆网卡的普及，再加上网卡绑定、交换机性能的提升等，网络 IO 已经不再是瓶颈。同时考虑到数据规模，DISK/Memory 比也没有意义，因此也不用顾及计算资源相对少的问题。更何况还有相当数量的冷数据躺在哪里，根本不需要为它们预留计算资源。

 

转载地址：http://www.sohu.com/a/312030240_315839