HDFS-Tiering 数据分层存储

1. 背景

随着小米业务迅猛发展，存储到 HDFS 集群的数据量不断增大，存储成本也不断攀升。尤其是海外 HDFS 集群每 GB 数据的成本是国内集群的 10 倍左右，如何优化海外集群的存储成本变得非常迫切。海外 HDFS 集群主要采用云主机挂载 EBS 的方式搭建，EBS 是成本的大头。但 EBS 可靠性高，性能优良，又是业务正常运行的保障。

经过我们对 HDFS 元数据信息的分析，以印度离线集群为例，发现半年以上没有访问的冷数据大约占 25% 左右。这些数据存储在高性能高成本的 EBS 上是一种浪费，是否可能把这部分冷数据存储到更便宜的存储介质上？答案是肯定的。

Amazon S3（0.021/GB.月）的单价不到EBS（0.051/GB.月）的单价不到 EBS（0.051/GB.月）的单价不到EBS（0.051/GB.月）的一半，可靠性高，但访问速度慢，在我们测试环境里，挂载 S3 的盘读写速度只有 40MB/s 左右，只有 EBS 的 1/5。但考虑到冷数据的读写频率比较低，存储到 S3 上是可行的，这样冷数据的存储成本可以下降一半多。依赖 S3 自身 11 个 9 的持久性，我们可以只保存一个副本，这样对原来三备份的冷数据的成本可降低到 1/6。同样，对于国内的集群，也有性能稍差但价格便宜的高密度机型可以选择，可以采用同样的方案来保存冷数据。

经过调研和分析，在上层应用无感知、HDFS 集群系统性能无明显下降的前提下，为降低存储成本，我们需要把数据按冷热进行分层管理，不同类型的数据存储到不同的存储介质上。

HDFS 社区版是支持数据分层存储的，可把不同的存储介质设置成不同的存储类型（Storage Types），支持的存储类型有5种：RAM_DISK、SSD、DISK、ARCHIVE、PROVIDED。把不同的数据设置成不同的存储策略（Storage Policies），支持的策略有7种：Hot、Warm、Cold、All_SSD、One_SSD、Lazy_Persist、Provided。默认 Storage Policies 是 Hot，可通过系统命令或者 API 改变数据的属性。

但 HDFS 社区版存在以下问题：

• 对存量数据处理的支持不好。设置数据的 Storage Policies 属性后，只对新写入的数据有效。对于存量数据，系统并不能将其自动移动到对应的存储介质上。HDFS 提供了一个外置工具 mover，可以把数据移动到正确的位置，但 mover 也不能确保调用后会把所有的数据都移动过去。

• 没有提供冷数据分析方案。

• 没有提供把远程存储设备（譬如 S3）mount 到 DataNode 上作为存储类型的方案。

2. 实现

小米 HDFS-Tiering 方案**简化**了 HDFS 社区版的存储类型和存储策略，实现了冷热数据的自动分层管理，不同类型的数据存储到不同存储介质上。主要解决了以下问题：

• 把远程的廉价存储介质挂载到 DataNode 作为 Archive 类型卷。

• 自动分析集群数据，获得冷数据列表，改变数据的 Storage Policies 属性。

• 自动循环调用 mover 工具，移动冷数据，并利用 fsck 命令判断数据是否迁移完成。

• 支持在可靠存储介质上实现文件级别的 Dedup。

• 支持灵活的存储配置方案，可切换 Archive 类型卷对应的存储介质。

小米 HDFS-Tiering 方案把存储介质分成两种类型：

1. DISK：普通存储介质，譬如 HDD/SSD 本地硬盘、EBS 网盘等。

2. ARCHIVE：低速廉价存储介质，譬如S3存储、高密度硬盘、磁带存储等。

又把数据分成三种存储策略，实现了数据在三种策略之间的自动转换（如图 2.1 所示）：

• HOT：三副本都在 DISK 上。

• WARM：一副本在 DISK，两副本在 ARCHIVE 上。

• COLD：三副本都在 ARCHIVE 上。

 

 

 

                                                   图 2.1 数据类型转换

以下介绍各主要模块的实现细节。

2.1 挂载远程存储设备到 HDFS 系统

<