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负载
Figure 2描述了每一层的I/O构成，解释了在FM系统对外请求中读占主导，但是由于logging/compaction/replication/caching导致写被严重放大。
HBase的设计是分层结构的，依次是DB逻辑层、FS逻辑层、底层系统逻辑层。DB逻辑层提供的对外使用的接口主要操作是put()和get()请求，这两个操作的数据都要写到HDFS上，其中读写比99/1（Figure 2中第一条）。
由于DB逻辑层内部为了保证数据的持久性会做logging，为了读取的高效率会做compaction，而且这两个操作都是写占主导的，所以把这两个操作（overheads）加上之后读写比为79/21（Figure 2中第二条）。
相当于调用put()操作向HBase写入的数据都是写入了两份：一份写入内存Memstore然后flush到HFile/HDFS，另一份通过logging直接写HLog/HDFS。Memstore中积累一定量的数据才会写HFile，这使得压缩比会比较高，而写HLog要求实时append record导致压缩比（HBASE-8155）相对较低，导致写被放大4倍以上。
Compaction操作就是读取小的HFile到内存merge-sorting成大的HFile然后输出，加速HBase读操作。Compaction操作导致写被放大17倍以上，说明每部分数据平均被重复读写了17次，所以对于内容不变的大附件是不适合存储在HBase中的。由于读操作在FM业务中占主要比例，所以加速读操作对业务非常有帮助，所以compaction策略会比较激进。
HBase的数据reliable是靠HDFS层保证的，即HDFS的三备份策略。那么也就是上述对HDFS的写操作都会被转化成三倍的local file I/O和两倍的网络I/O。这样使得在本地磁盘I/O中衡量读写比变成了55/45。
然而由于对本地磁盘的读操作请求的数据会被本地OS的cache缓存，那么真正的读操作是由于cache miss引起的读操作的I/O量，这样使得读写比变成了36/64，写被进一步放大。
另外Figure 3从I/O数据传输中真正业务需求的数据大小来看各个层次、各个操作引起的I/O变化。除了上面说的，还发现了整个系统最终存储在磁盘上有大量的cold data（占2/3），所以需要支持hot/cold数据分开存储。
总的来说，HBase stack的logging/compaction/replication/caching会放大写I/O，导致业务逻辑上读为主导的HBase系统在地层实际磁盘I/O中写占据了主导。
FM系统的主要文件类型和大小