Hbase 如何更新 HDFS 文件

一直疑惑Hbase怎么更新hdfs文件。因为HBase是一个支持高并发随机读写的数据库，而hdfs只适合于大批量数据处理，hdfs文件只能写一次，一旦关闭就再也不能修改了。而HBase却将数据存储在hdfs上！让人费解。
原来的猜想是Hbase每次将更新写入磁盘都会创建一个新的hdfs文件，存放该数据旧版本的文件需要合并并最终丢弃，如果是这样的话，其随机读写的性能如何保证？在网上找到了两篇文章很好的解释了这个问题。
一篇是hadoop论坛上2007年底的一个帖子：HBase-implementation-question
下面是对这个帖子的一个摘要：
----------------------
1. HBase用Hadoop MapFile(org.apache.hadoop.io.MapFile.java)存储数据，用SequenceFile存储Redo Log(后者当时是HBase的一个缺点，因为日志文件关闭前都不会持久化，随着hdfs引入append功能，现在这个问题已经得到解决)。
2. 每一次Hbase服务器收到写请求，都会先写redo log，然后更新内存中的缓存。缓存会定期的刷入hdfs的一个新创建的MapFile。文件基于列创建，因此任何一个MapFile只包含一个特定列的数据。
3. 当某一列的MapFile数量超过配置的阈值时，一个后台线程开始将现有的MapFile合并为一个文件。这个操作叫 Compaction。在合并的过程中，读写不会被阻塞。
4. 读操作会先检查缓存，若未命中，则从最新的MapFile开始，依次往最老的MapFile找数据。可以想象一次随机读可能需要扫描多个文件。
----------------------
上面处理过程最让人担心的是Compaction的性能问题。由于Hbase的数据是排好序的，文件合并本身是一个对内存和CPU都占用较少的过程，但产生的IO负担让人担忧。文中没有讲解Compaction的细节，在网上找到一篇非常好的博文：Visualizing HBase Flushes And Compactions
从这篇文章我们可以看到，Hbase把Compaction分为Major和Minor两类，而且通过参数可以限制MapFile文件的最大尺寸(默认为256MB)，和缓存块的尺寸。用很精巧的算法平衡了MapFile数量和Compaction的次数及其产生的IO负担，文中提供了多项测试的结果图例，一目了然。

这下问题就很清楚了。hdfs文件确实是只能写一次就不能修改了，通常hdfs只适合于数据大批量处理。Hbase的文件和日志确实都是存储在hdfs中，但通过精致设计的算法实现了对高并发数据随机读写的完美支持，让人叹服！当然，这依赖于Hbase数据排序后存储的特性。其他的基于Hash寻址的NoSQL数据库恐怕无法效仿HBase将数据存储在hdfs上。

文章出处：http://blog.sina.com.cn/s/blog_62c493b101010ehd.html

割。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

将HDFS和HBase的组合用于高效数据存储：http://book.51cto.com/art/201408/447943.htm