HBase性能优化案例分析

　　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系统的主要文件类型和大小

　　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是读取那些热数据。

原文转自：http://www.infoq.com/cn/articles/hbase-casestudy-facebook-messages