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

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