HBase优化案例分析：Facebook Messages系统问题与解决方案

HDFS设计的初衷是为了存储大文件（例如日志文件），面向批处理、顺序I/O的。然而架设在HDFS之上的HBase设计的初衷却是为了解决海量数据的随机读写的请求。把这两种设计初衷截然相反的组件怎么揉在一起的呢？这种分层的结构设计主要是为了使架构更清晰，HBase层和HDFS层各司其职；但是却带来了潜在的性能下降。在很多业务场景中大家使用HBase抱怨最多的两个问题就是：Java GC相关的问题和随机读写性能的问题。Facebook Messages（以下简称FM系统）系统可以说是HBase在online storage场景下的第一个案例（《Apache Hadoop Goes Realtime at Facebook》, SIGMOD 2011），最近他们在存储领域顶级会议FAST2014上发表了一篇论文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》分析了他们在使用HBase中遇到的一些问题和解决方案，使用HBase做online storage的同学们可以参考下。

该论文首先讲了Facebook的分析方法包括tracing/analysis/simulation，FM系统的架构和文件与数据构成等，接下来开始分析FM系统在性能方面的一些问题，并提出了解决方案。

FM系统的主要读写I/O负载

《走出软件作坊》作者吕建伟（阿朱）出品QCon北京2014“构建高效能团队”专题

JavaOne Duke大奖得主郑晔确认参加QCon北京，分享《你应该更新的Java知识》

支付宝、天猫前端开发负责人玉伯、三七确认负责出品QCon北京2014长专题“移动时代的前端”

2013~2014年度InfoQ读者深度调查火热进行中，完成调研可以查看最新的统计结果。结果分享到微博或者微信朋友圈，有机会获得精美礼品。

《PM2.5的大数据分析》—— 英特尔中国研究院首席架构师姜小凡确认QCon分享

FM系统的主要文件类型和大小

FM系统的几种文件类型如Table 2所示，这个是纯业务的逻辑描述。在HBase的每个RegionServer上的每个column family对应一个或者多个HFile文件。FM系统中有8个column family，由于每个column family存储的数据的类型和大小不一样，使得每个column family的读写比是不一样的。而且很少数据是读写都会请求的，所以cache all writes可能作用不大（Figure 4）。

对于每个column family的文件，90%是小于15M的。但是少量的特别大的文件会拉高column family的平均文件大小。例如MessageMeta这个column family的平均文件大小是293M。从这些文件的生命周期来看，大部分FM的数据存储在large,long-lived files，然而大部分文件却是small, short-lived。这对HDFS的NameNode提出了很大的挑战，因为HDFS设计的初衷是为了存储少量、大文件准备的，所有的文件的元数据是存储在NameNode的内存中的，还有有NameNode federation。

FM系统的主要I/O访问类型

下面从temporal locality, spatial locality, sequentiality的角度来看。

73.7%的数据只被读取了一次，但是1.1%的数据被读取了至少64次。也就是说只有少部分的数据被重复读取了。但是从触发I/O的角度，只有19%的读操作读取的是只被读取一次的数据，而大部分I/O是读取那些热数据。

在HDFS这一层，FM读取数据没有表现出sequentiality，也就是说明high-bandwidth, high-latency的机械磁盘不是服务读请求的理想存储介质。而且对数据的读取也没有表现出spatial locality，也就是说I/O预读取也没啥作用。

解决方案

1. Flash/SSD作为cache使用。

下面就考虑怎么架构能够加速这个系统了。目前Facebook的HBase系统每个Node挂15块100MB/s带宽、10ms寻址时间的磁盘。Figure 9表明：a)增加磁盘块数有点用；b)增加磁盘带宽没啥大用；c)降低寻址时间非常有用。

由于少部分同样的数据会被经常读取，所以一个大的cache能够把80%左右的读取操作拦截而不用触发磁盘I/O，而且只有这少部分的hot data需要被cache。那么拿什么样的存储介质做cache呢？Figure 11说明如果拿足够大的Flash做二级缓存，cache命中率会明显提高，同时cache命中率跟内存大小关系并不大。

注：关于拿Flash/SSD做cache，可以参考HBase BucketBlockCache(HBASE-7404)

我们知道大家比较关心Flash/SSD寿命的问题，在内存和Flash中shuffling数据能够使得最热的数据被交换到内存中，从而提升读性能，但是会降低Flash的寿命,但是随着技术的发展这个问题带来的影响可能越来越小。

说完加速读的cache，接着讨论了Flash作为写buffer是否会带来性能上的提升。由于HDFS写操作只要数据被DataNode成功接收到内存中就保证了持久性（因为三台DataNode同时存储，所以认为从DataNode的内存flush到磁盘的操作不会三个DataNode都失败），所以拿Flash做写buffer不会提高性能。虽然加写buffer会使后台的compaction操作降低他与前台服务的I/O争用，但是会增加很大复杂度，所以还是不用了。最后他们给出了结论就是拿Flash做写buffer没用。

然后他们还计算了，在这个存储栈中加入Flash做二级缓存不但能提升性能达3倍之多，而且只需要增加5%的成本，比加内存性价比高很多（怎么感觉有点像SSD的广告贴）。

2.分层架构的缺点和改进方案

如Figure 16所示，一般分布式数据库系统分为三个层次：db layer/replication layer/local layer。这种分层架构的最大优点是简洁清晰，每层各司其职。例如db layer只需要处理DB相关的逻辑，底层的存储认为是available和reliable的。

HBase是图中a)的架构，数据的冗余replication由HDFS来负责。但是这个带来一个问题就是例如compaction操作会读取多个三备份的小文件到内存merge-sorting成一个三备份的大文件，这个操作只能在其中的一个RS/DN上完成，那么从其他RS/DN上的数据读写都会带来网络传输I/O。

图中b)的架构就是把replication层放到了DB层的上面，Facebook举的例子是Salus，不过我对这个东西不太熟悉。我认为Cassandra就是这个架构的。这个架构的缺点就是DB层需要处理底层文件系统的问题，还要保证和其他节点的DB层协调一致，太复杂了。

图中c)的架构是在a的基础上的一种改进，Spark使用的就是这个架构。HBase的compaction操作就可以简化成join和sort这样两个RDD变换。

Figure 17展示了local compaction的原理，原来的网络I/O的一半转化成了本地磁盘读I/O，而且可以利用读cache加速。我们都知道在数据密集型计算系统中网络交换机的I/O瓶颈非常大，例如MapReduce Job中Data Shuffle操作就是最耗时的操作，需要强大的网络I/O带宽。加州大学圣迭戈分校(UCSD)和微软亚洲研究院(MSRA)都曾经设计专门的数据中心网络拓扑来优化网络I/O负载，相关研究成果在计算机网络顶级会议SIGCOMM上发表了多篇论文，但是由于其对网络路由器的改动伤筋动骨，最后都没有成功推广开来。

Figure 19展示了combined logging的原理。现在HBase的多个RS会向同一个DataNode发送写log请求，而目前DataNode端会把来自这三个RS的log分别写到不同的文件/块中，会导致该DataNode磁盘seek操作较多（不再是磁盘顺序I/O，而是随机I/O）。Combined logging就是把来自不同RS的log写到同一个文件中，这样就把DataNode的随机I/O转化成了顺序I/O。

作者简介

梁堰波，北京航空航天大学计算机硕士，美团网资深工程师，曾在法国电信、百度和VMware工作和实习过，这几年一直在折腾Hadoop/HBase/Impala和数据挖掘相关的东西，新浪微博 @DataScientist 。