主题简介：
HDFS优化存储功能讲解
SSM系统架构设计
SSM系统应用场景分析
一、背景
随着大数据技术相关技术的发展和普及，越来越多的公司开始使用基于开源Hadoop的平台系统，同时，越来越多的业务和应用也在从传统的技术架构迁移到大数据平台上。在典型的Hadoop大数据平台中，人们使用HDFS作为存储服务的核心。
而在大数据发展之初，最主要的应用场景仍然是离线批处理场景，对存储的需求追求的是吞吐量，HDFS正是针对这样的场景而设计的，而随着技术不断的发展，越来越多的场景会对存储提出新的需求，HDFS也面临着新的挑战。主要包括几个方面：
1、数据量问题
一方面随着业务的增长和新的应用接入，会给HDFS带来更多的数据，另一方面随着深度学习，人工智能等技术的发展，用户通常希望能保存更长时间的数据，以提升深度学习的效果。数据量的快速增加会使集群不断面临扩容需求，从而导致存储成本不断增加。
2、小文件问题
众所周知，HDFS的设计是针对离线批处理大文件的，处理小文件并非传统HDFS擅长的场景。HDFS小文件问题的根源在于文件的元数据信息都是维护在单点Namenode的内存中，单台机器的内存空间始终是有限的。据估算，单台namenode集群能容纳系统文件数量极限大约在1.5亿左右。实际上，HDFS平台通常作为底层存储平台服务于上层多种计算框架，多个业务场景，所以小文件问题从业务的角度也难以避免。目前也有方案例如HDFS-Federation解决Namenode单点扩展性问题，但同时也会带来巨大的运维管理难度。
3、冷热数据问题
随着数据量的不断增长积累，数据也会呈现出访问热度不同的巨大差异。例如一个平台会不断地写入***的数据，但通常情况下最近写入的数据访问频率会比很久之前的数据高很多。如果无论数据冷热情况，都采用同样的存储策略，是对集群资源的一种浪费。如何根据数据冷热程度对HDFS存储系统进行优化是一个亟待解决的问题。
二、现有HDFS优化技术
从Hadoop诞生到今天也有超过10年的时间，在此期间HDFS技术本身也在不断优化演进。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纠删码：
传统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进行计算，实际上是一种以时间换空间的选择，因此比较适用的场景是对冷数据的存储。冷数据存储的数据往往一次写入之后长时间没有访问，这种情况下可以通过纠删码技术减少副本数。
三、大数据存储优化：SSM
前面介绍的无论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应用场景
SSM能够针对数据的冷热程度，采用不同存储策略进行优化，以下是一些典型的应用场景：
最典型的场景就是针对冷数据，如上图所示，定义相关规则，将较长时间为没有访问的数据采用更低成本的存储。例如原先的数据块，从SSD存储退化到HDD存储。
与此类似，对于热点的数据，同样可以根据不同的规则，对其采用更快速的存储策略，如上图所示，短时间内访问此处较多的热点数据，会从HDD存储上升至SSD存储，更热点的数据会采用内存存储的策略。
针对冷数据的场景，SSM也可以采用纠删码的优化，通过定义相应规则，对于访问次数很少的冷数据，对其执行erasure code操作，降低数据副本冗余。
另外值得一提的是SSM针对小文件也有相应优化手段，这个功能仍然处于开发过程中。大体逻辑是SSM会对HDFS上一系列小文件执行合并成大文件的操作，同时，在SSM的元数据中记录下原始小文件和合并后大文件的映射关系以及每个小文件在大文件中的偏移量。当用户需要访问小文件时，通过SSM特定的客户端(SmartClient)，根据SSM元数据中的小文件映射信息，从合并后的文件中获取到原始小文件。
***SSM是个开源的项目，目前仍然在非常快速的迭代演进过程中，欢迎任何感兴趣的朋友参与项目的开发贡献。
Q&A
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。
