HBase数据存储状况
1、2PB+ of online data in HBase (6PB+ with replication; excludes backups),存储了message data, metadata, search index 等信息。
2、每天大概有8B+Messages，增长到每月大概产生250TB的数据。
3、Traffic to HBase ▪ 75+ Billion R+W ops/day ▪ At peak: 1.5M ops/sec ▪ ~ 55% Read vs. 45% Write ops 。
Facebook选择HBase的原因
▪ High write throughput
▪ Good random read performance
▪ Horizontal scalability
▪ Automatic Failover
▪ Strong consistency
▪ Benefits of HDFS
Fault tolerant, scalable, checksums, MapReduce
internal dev & ops expertise
Facebook的HBase架构
Multiple clusters/cells for messaging
▪ 20 servers/rack; 5 or more racks per cluster Controllers (master/Zookeeper) spread across racks
Facebook将消息的存储分成多个HBase集群，每个HBase集群由多个Rack上的节点组成，这样可以减小故障对服务影响的范围。
Facebook消息的schema
1、RowKey：md5sum(userid)+userid。结合preSplit，可以避免HotSpot。
2、借助HBase单行操作的原子性。一个用户的所有信息存储成一行,这包括消息本身、Message Index、Search Index、以及相关Meta Data(Actions:addMessage、markAsRead,etc)。
Example：Facebook如何存储Message Index的结构。
HBase Enhancement
1、HFile V2的架构
- Open HFile操作
1) 提供对于V1、V2两种格式的HFile的兼容。这分别对应于org.apache.hadoop.hbase.io.hfile.HFileReaderV1和org.apache.hadoop.hbase.io.hfile.HFileReaderV2
2) 加载Opening-time Data Section区域的数据。这些操作位于HFileReaderV2或者HFileReaderV1的构造函数中。 - Write操作
1）写数据到Data Block。 HFileBlock //本操作暂时忽略MemStore的过程，只是对于HFile文件的操作。
2）写bloom block和Leaf index block - Read操作
1) 从Root Data Index和Bloom Index检索。
2）进入Leaf level index ，然后查找Block Cache，如果dismiss,就从hfile把对应DataBlock加载到Cache中。
2、Compaction 优化
- Major Compaction与Minor Compaction采用不同的队列。
- 在off-peak负载下预先进行Compactions
- Compaction多线程执行
- 算法优化，如下图。
ps(将满足要求的小文件合并，过去was,修改之后的算法，现在Now)
3、监控与Metrics
- Metrics收集HBase状态信息。▪ block cache usage & hit ratio
▪ memstore usage
▪ on-disk file sizes
▪ file counts
▪ bytes returned, bytes flushed, compaction statistics
▪ stats by block type (data block vs. index blocks vs. bloom blocks, etc.)
▪ bloom filter stats - 增加了对于Region、CF statistics的收集和应用。
- 所有收集的stats数据会单独存储在Data Store中。
From Binospace, post HBase在Facebook Message存储的使用经验总结
文章的脚注信息由WordPress的wp-posturl插件自动生成