共计 4126 个字符，预计需要花费 11 分钟才能阅读完成。
主题简介：
随着大数据技术相关技术的发展和普及，越来越多的公司开始使用基于开源 Hadoop 的平台系统，同时，越来越多的业务和应用也在从传统的技术架构迁移到大数据平台上。在典型的 Hadoop 大数据平台中，人们使用 HDFS 作为存储服务的核心。
而在大数据发展之初，最主要的应用场景仍然是离线批处理场景，对存储的需求追求的是吞吐量，HDFS 正是针对这样的场景而设计的，而随着技术不断的发展，越来越多的场景会对存储提出新的需求，HDFS 也面临着新的挑战。主要包括几个方面：
一方面随着业务的增长和新的应用接入，会给 HDFS 带来更多的数据，另一方面随着深度学习，人工智能等技术的发展，用户通常希望能保存更长时间的数据，以提升深度学习的效果。数据量的快速增加会使集群不断面临扩容需求，从而导致存储成本不断增加。
众所周知，HDFS 的设计是针对离线批处理大文件的，处理小文件并非传统 HDFS 擅长的场景。HDFS 小文件问题的根源在于文件的元数据信息都是维护在单点 Namenode 的内存中，单台机器的内存空间始终是有限的。据估算，单台 namenode 集群能容纳系统文件数量极限大约在 1.5 亿左右。实际上，HDFS 平台通常作为底层存储平台服务于上层多种计算框架，多个业务场景，所以小文件问题从业务的角度也难以避免。目前也有方案例如 HDFS-Federation 解决 Namenode 单点扩展性问题，但同时也会带来巨大的运维管理难度。
随着数据量的不断增长积累，数据也会呈现出访问热度不同的巨大差异。例如一个平台会不断地写入最新的数据，但通常情况下最近写入的数据访问频率会比很久之前的数据高很多。如果无论数据冷热情况，都采用同样的存储策略，是对集群资源的一种浪费。 如何根据数据冷热程度对 HDFS 存储系统进行优化是一个亟待解决的问题。
从 Hadoop 诞生到今天也有超过 10 年的时间，在此期间 HDFS 技术本身也在不断优化演进。HDFS 现有一些技术能够一定程度上解决上述一些问题。这里简要介绍一下 HDFS 异构存储和 HDFS 纠删码技术。
Hadoop 从 2.6.0 版本开始支持异构存储功能。我们知道 HDFS 默认的存储策略，对于每个数据块，采用三个副本的存储方式，保存在不同节点的磁盘上。异构存储的作用在于利用服务器不同类型的存储介质（包括 HDD 硬盘、SSD、内存等）提供更多的存储策略（例如三个副本一个保存在 SSD 介质，剩下两个仍然保存在 HDD 硬盘），从而使得 HDFS 的存储能够更灵活高效地应对各种应用场景。
HDFS 中预定义支持的各种存储包括：
ARCHIVE：高存储密度但耗电较少的存储介质，例如磁带，通常用来存储冷数据
DISK：磁盘介质，这是 HDFS 最早支持的存储介质
SSD：固态硬盘，是一种新型存储介质，目前被不少互联网公司使用
RAM_DISK：数据被写入内存中，同时会往该存储介质中再（异步）写一份
HDFS 中支持的存储策略包括：
Lazy_persist：一个副本保存在内存 RAM_DISK 中，其余副本保存在磁盘中
ALL_SSD：所有副本都保存在 SSD 中
One_SSD：一个副本保存在 SSD 中，其余副本保存在磁盘中
Hot：所有副本保存在磁盘中，这也是默认的存储策略
Warm：一个副本保存在磁盘上，其余副本保存在归档存储上
Cold：所有副本都保存在归档存储上
总体上 HDFS 异构存储的价值在于，根据数据热度采用不同策略从而提升集群整体资源使用效率。对于频繁访问的数据，将其全部或部分保存在更高访问性能的存储介质（内存或 SSD）上，提升其读写性能；对于几乎不会访问的数据，保存在归档存储介质上，降低其存储成本。但是 HDFS 异构存储的配置需要用户对目录指定相应的策略，即用户需要预先知道每个目录下的文件的访问热度，在实际大数据平台的应用中，这是比较困难的一点。
传统 HDFS 数据采用三副本机制保证数据的可靠性，即每存储 1TB 数据，实际在集群各节点上占用的数据达到 3TB，额外开销为 200%。这给节点磁盘存储和网络传输带来了很大的压力。
在 Hadoop3.0 开始引入支持 HDFS 文件块级别的纠删码，底层采用 Reed-Solomon（k,m）算法。RS 是一种常用的纠删码算法，通过矩阵运算，可以为 k 位数据生成 m 位校验位，根据 k 和 m 的取值不同，可以实现不同程度的容错能力，是一种比较灵活的纠删码算法。
常见的算法为 RS(3,2)、RS(6,3)、RS(10,4)，k 个文件块和 m 个校验块构成一个组，这个组内可以容忍任意 m 个数据块的丢失。
HDFS 纠删码技术能够降低数据存储的冗余度，以 RS(3,2) 为例，其数据冗余度为 67%，相比 Hadoop 默认的 200% 大为减少。但是纠删码技术存储数据和数据恢复都需要消耗 cpu 进行计算， 实际上是一种以时间换空间的选择 ，因此比较适用的场景是对冷数据的存储。冷数据存储的数据往往一次写入之后长时间没有访问，这种情况下可以通过纠删码技术减少副本数。
前面介绍的无论 HDFS 异构存储还是纠删码技术，前提都是需要用户对特定的数据指定存储的行为，就是说用户需要知道哪些数据是热点数据，哪些是冷数据。那有没有一种方法可以自动对存储进行优化呢？
答案是有的，这里介绍的 SSM(Smart Storage Management) 系统，它从底层存储（通常是 HDFS）中获取元数据信息，并通过数据读写访问信息分析获取数据热度情况，针对不同热度的数据，按照预先制定的一系列规则，采用相应的存储优化策略，从而提升整个存储系统的效率。SSM 是一个由 Intel 主导的开源的项目，中国移动也参与其中的研发， 项目可以在 Github 中获取到：https://github.com/Intel-bigdata/SSM。
SSM 定位是一个存储外围优化的系统，整体上采用 Server-Agent-Client 的架构，其中 Server 负责 SSM 整体逻辑的实现，Agent 用于对存储集群执行各种操作，Client 是提供给用户的数据访问接口，通常其中包含了原生 HDFS 的接口。
SSM-Server 的主要框架如上图所示，从上到下，StatesManager 与 HDFS 集群进行交互，用于获取 HDFS 元数据信息，并维护每个文件的访问热度信息。StatesManager 中的信息会持久化到关系型数据库中。在 SSM 中采用 TiDB 作为底层存储的数据库。RuleManager 维护和管理规则相关信息，用户通过前台界面为 SSM 定义一系列存储规则，RuleManger 负责规则的解析和执行。CacheManager/StorageManager 根据热度和规则，生成具体的 action 任务。ActionExecutor 负责具体的 action 任务，把任务分配给 Agent，并在 Agent 节点执行。
SSM-Server 内部逻辑实现依赖于规则的定义，需要管理员通过前台 web 页面为 SSM 系统制定一系列规则。一条规则包括几部分组成：
- 操作对象，通常是指符合特定条件的文件。
- 触发器，指规则触发的时间点，例如每天定时触发。
- 执行条件，定义一系列基于热度的条件，例如文件在一段时间访问次数计数要求。
- 执行操作，对符合执行条件的数据进行相关操作，通常是指定其存储策略等。
一个实际的规则示例：
file.path matchs”/foo/*”: accessCount(10min) >= 3 | one-ssd
这条规则表示对于在 /foo 目录下的文件，满足 10 分钟内被访问次数不低于三次，则对其采用 One-SSD 的存储策略，即数据一个副本保存在 SSD 上，剩余 2 个副本保存在普通磁盘上。
SSM 能够针对数据的冷热程度，采用不同存储策略进行优化，以下是一些典型的应用场景：
最典型的场景就是针对冷数据，如上图所示，定义相关规则，将较长时间为没有访问的数据采用更低成本的存储。例如原先的数据块，从 SSD 存储退化到 HDD 存储。
与此类似，对于热点的数据，同样可以根据不同的规则，对其采用更快速的存储策略，如上图所示，短时间内访问此处较多的热点数据，会从 HDD 存储上升至 SSD 存储，更热点的数据会采用内存存储的策略。
针对冷数据的场景，SSM 也可以采用纠删码的优化，通过定义相应规则，对于访问次数很少的冷数据，对其执行 erasure code 操作，降低数据副本冗余。
另外值得一提的是 SSM 针对小文件也有相应优化手段，这个功能仍然处于开发过程中。大体逻辑是 SSM 会对 HDFS 上一系列小文件执行合并成大文件的操作，同时，在 SSM 的元数据中记录下原始小文件和合并后大文件的映射关系以及每个小文件在大文件中的偏移量。当用户需要访问小文件时，通过 SSM 特定的客户端（SmartClient），根据 SSM 元数据中的小文件映射信息，从合并后的文件中获取到原始小文件。
最后 SSM 是个开源的项目，目前仍然在非常快速的迭代演进过程中，欢迎任何感兴趣的朋友参与项目的开发贡献。
Q1：HDFS 自行搭建应该从多大规模开始？
A1：HDFS 支持伪分布模式，即使只有一个节点，也能搭建一个 HDFS 系统。如果希望更好体验和理解 HDFS 的分布式架构，建议有 3 到 5 个节点的环境来搭建。
Q2： 苏研在实际各省的大数据平台用 SSM 了吗？
A2： 目前还没有，这个项目还在快速发展中，需要等到测试稳定后才会逐步用到生产上。
Q3：HDFS 和 Spark 区别是什么？优缺点呢？
A3：HDFS 和 Spark 并不是同一个层面上的技术，HDFS 是存储系统，而 Spark 是一种计算引擎。我们经常拿来和 Spark 对标的是 Hadoop 中的 Mapreduce 计算框架而非 HDFS 存储系统。在实际项目建设中，通常 HDFS 和 Spark 是协作的关系，底层存储使用 HDFS，上层计算使用 Spark。
