1. MOB基本介绍
1.1使用MOB的背景&现状
MOB是Medium Object Storage，即中等大小的对象存储，一般指的是KeyValue所占字节数大于1MB，小与10MB的数据。系统部目前以HBase为底层存储所支持的XStore-S3大规模服务，就是采用这种方案实现的。主要支持了公司的视频云、IOT以及云盘等业务，其中超过1MB的存储需求又比较常见，例如图片，短视频以及文档等。但是对于HBase来说，存储MOB并不是最理想的情况。
- 由于HBase写流程需要先写Memstore，所以少量的MOB文件就会达到Flush的阈值，触发Flush操作。频繁的Flush操作又会生成大量的HFile文件，进而影响HBase的读性能。
- 产生大量的HFile文件后，就会更频繁的触发LSM的Compaction，合并没有改动的数据，这样也会消耗大量的IO。
- MOB数据的写入也会更加频繁的触发region的split操作，会产生写阻塞，影响写性能。
所以需要设计一个针对MOB数据的存储方案去优化上述问题。
1.2 MOB原理&如何避免上述问题
HBase MOB是将Meta数据和MOB数据分开存储。
MOB写原理
建表时，可以指定某个Family的MOB属性，设置MOB阈值，在Memstore进行Flush操作时，将其分开存到不同的位置，meta数据按照正常的StoreFile存，MOB的value写到MOBStoreFile文件中。
MOB读原理
正常先扫memstore，然后判断是否有refTag，进而选择读StoreFile还是MobStoreFile。相对应的，Hbase MOB为了降低Compaction的频率，也设计了特殊的Compaction策略：
- 按照文件所属分区以及日期两个维度进行分区，分区内的文件进行合并。
- 将默认每日合并的策略改为每周合并或者每月合并。
使用这种meta，cell分离的方式，将MOB的数据单独处理，将MOB移出普通region的管理来避免频繁的region split和compaction。但是读缓存一般是存不下MOB cell的，所以都是磁盘IO操作，虽然性能会比正常文件的读取差一些，但还是解决了大部分的读性能问题。
1.3 MOB Compaction
如果我们写入的数据中只有少数记录符合MOB的条件，那么会导致HDFS上存在许多MOB小文件，也可能会有被删除的单元格。常常我们需要删除单元格，并将小文件合并为大文件，以提高HDFS的利用率。MOB Compaction只对小文件进行压缩，而对大文件不进行严格的压缩，避免对大文件的无限压缩使写放大更具可预测性。我们需要知道在MOB压缩中删除了哪些单元格。因此，在每次HBase 进行major compaction中，删除标记在删除之前都被写到删除标记文件中。
下面看一下HBase中原生Mob Compaction的原理，如下图所示：
原生的Mob Compaction逻辑是有缺陷的，存在如下问题：
- Mob compaction首先会读取Mob Fille，将每条记录写入到hbase中后生成Reference File，最终将Reference bulkload到表中。
- 上述过程全部由Master来完成，所以在做Mob compaction时会导致master压力过大。
针对这些问题，我们进行了优化，将 Mob compaction阶段通过MapReduce的方式执行，从而减轻Master负担，优化后，Compact逻辑流程如下：
主要逻辑：
- MobMiniInputFormat
- getSplits方法将mob文件按mob region按照mob region进行分类
- MobMiniMapper
- 生成new mob files和reference files
- 按照date对mob hfile进行过滤
- 构建PartitionedMobCompactionRequest，构建del files列表和mob files partitions
- compactDelFiles：合并del files
- compactMobFiles：生成new mob files和reference files
- MobMiniReducer
- commit new mob files
- bulkload reference files
- delete old mob files
针对Mob Compaction的优化与bug修复:
我们在基于MOB Compaction做个性化开发过程中，发现一个严重的Bug，即进行mob compact后会有丢数据的情况，具体表象为读取Mob引用文件时候会读到失效的MobFile-Path，报错信息为FileNotFound Exception；
经过长时间的分析与排查后，发现导致此bug的原因有以下几个：
1. 引用文件被覆盖导致的丢数
当mob region下mob files个数大于一个batch(默认100)时，由于处理batch时会清空bulkload目录，所以最终只保留最后一个batch的ref files，
bulkload后导致除最后一个batch外其他batchs的ref files没有更新，读取时还是会找到老mob path。
解决方案：处理每个batch时不去清空bulkload目录。
2. Map后Reduce前新刷盘的mob文件被删除导致的丢数
当map后reduce前有新flush的mob files时，由于reduce时将当前目录下所有满足日期的mob files都删除，导致读取时找不到该mob文件路径。
解决方案：map时记录处理的老mob文件列表，reduce时只remove列表中的mob文件
3. 引用文件compaction导致的丢数
ref file compaction后，可能出现老mob files所在的ref file seqid大于新mob files所在ref file的seqid，由于新老mob cell信息完全相同，在mob cell完全相同情况下会去比较mob cell所在的ref file, 读取seqid大的ref file，从而读到老mob path。
解决方案：利用Mob TAG在mob cell上区分新老mob，HBase原始代码中mob tag始终为null，修改为map时记录当前系统时间为TAG value，在读取时进行TAG value比较，由于新mob的TAG value更大，从而能读取到新mob path。
2. EC–支持公司大容量存储服务的秘诀，降本利器
2.1 EC简介
Erasure coding：纠删码技术简称EC，一种编码容错技术。可以简单的将EC概括为利用源数据可以计算出相应的校验数据，利用源数据与校验数据之间的对应关系，可以恢复丢失的部分数据。它的一个很大的优势是在保证可靠性的前提下可以提高存储利用率
优势：
在保证可靠性的前提下，提高系统存储利用率。比如：一个文件有6个block，传统3副本存储策略，一共需要18个block；而使用RS(6,3) EC存储策略，只需要9个block，节省了50%的存储空间。
劣势：
当block丢失时，修复过程需要读多个DataNode，网络带宽、磁盘IO、CPU消耗过大。
限制：
不支持：append()、hflush()、hsync()等方法
所以综上所述，使用场景一般是存储冷数据。
2.1.1 EC原理介绍
Reed-Solomon（RS）码是存储系统较为常用的一种纠删码，它有两个参数k和m，记为RS(k，m)。如下图所示，k个数据块组成一个向量被乘上一个生成矩阵（Generator Matrix）GT从而得到一个码字（codeword）向量，该向量由k个数据块和m个校验块构成。如果一个数据块丢失，可以用(GT)-1乘以码字向量来恢复出丢失的数据块。RS(k，m)最多可容忍m个块（包括数据块和校验块）丢失。
如上图所示：7、8、9 代表三个原始数据块，通过EC算法计算出来两个校验码块50、122；其中7、8、9、50、122 可以任意丢两个，通过算法即可计算出来，达到找回的效果。
2.1.2 EC副本策略
（1）连续布局
连续布局策略下，数据被依次写入一个块中，一个块写满之后再写入下一个块，数据的这种分布方式被称为连续布局。
优点：
1. 一个逻辑块对应一个实际存储块，实现简单
2. 方便与多副本策略转换
缺点：
1.客户端缓存足够的数据块，内存压力大
2.不适合小文件
（2）条形布局
鉴于连续布局的不足，条形布局对齐进行了改进。但是条形布局在改进之后使客户端写数据逻辑变得复杂，也不能方便的进行副本策略的转换。
在条型布局下，如上图所示编码单元划分为多个cell。而若干个相同大小单元（cell）构成的序列构成一个Stripe。在条形布局下，数据被依次被复制到Stripe的各个cell中，然后不同cell里面的数据写到不同的存储节点中。当一条Stripe的数据单元被写满之后会进行编码得到校验数据。
不难看出，条形布局是连续布局的操作单元变小的一种情况。
优点：
- HDFS客户端缓存数据较少
- 无论文件Size大小都适用
缺点：
- 会影响一些对读取数据块位置敏感的任务的性能，因为原先在一个节点上的块被分散到了多个不同的节点上
- 当需要进行多副本存储策略转换比较复杂
2.2 EC相关改进与优化
EC策略下，HBase所依赖的HDFS集群块数较多，导致持锁时间较长，影响性能
解决方案：持续对集群进行MOB-Compaction操作，增大HDFS数据块大小为1GB，有效减少数据块数量。
总结
当前系统部HBase集群综合以上所述的MOB策略以及EC策略，配合高存储密度的机型的服务器，使得集群能够在高存储容量的情况下正常地提供服务，很好的达到了降本增效的目的。
当然这种架构也并不是完美的，在将成本压至极限的过程中对我们的工作也提出了很大的挑战，除了维护集群稳定性问题外，一大主要问题就是如何在高存储容量的HBase集群上进行更为有效的释放待删除数据的操作，由于HBase Compaction带来的读写放大与存储膨胀等问题，让这个问题更难以解决，故而接下来我们工作就将围绕如何更加有效释放存储资源的方向上进行。