如果发现区域级别的不一致，请使用-fix参数指示hbck尝试修复它们。遵循以下步骤顺序：

$ ./bin/hbase hbck -fix

-修复包括
运行不一致的标准检查。
如果需要，对table进行修理
如果需要，可以对区域进行维修。维修期间区域关闭。
所以在运行之前-fix如果想分别修复单个区域级别的不一致性
-fixassignments（相当于0.90-fix选项）修复未分配、错误分配或多重分配的区域。
-fixmeta，当相应的区域在hdfs中不存在时删除元行，如果这些区域在hdfs中存在而在meta中不存在，则添加新的元行。
-fix包括{-fixampassignments&-fixmeta}

$ ./bin/hbase hbck -fixAssignments
 $ ./bin/hbase hbck -fixAssignments -fixMeta

有几类表完整性问题属于低风险修复。前两个是退化区域（startkey==endkey）和向后区域（startkey>endkey）。通过将数据侧移到临时目录（/hbck/x）来自动处理这些数据。第三个低风险类别是hdfs区域空洞。可以使用以下方法进行修复：
-fixhdfsholes选项，用于在文件系统上创建新的空区域。如果检测到孔，可以使用-fixhdfsholes并应包括-fixmeta和-fixassignments以使新区域一致。

$ ./bin/hbase hbck -fixAssignments -fixMeta -fixHdfsHoles

-repairholes包括{fixassignments-fixmeta-fixhdfsholes}

$ ./bin/hbase hbck -repairHoles

我们遇到了类似的情况：一个hbase表有5个丢失的块，5个损坏的文件。
hbase版本：0.94.15
发行版：cdh 4.7
操作系统：centos 6.4
恢复说明：
切换到hbase用户：
su hbase hbase hbck -details 了解问题的范围 hbase hbck -fix 尝试从区域级别的不一致中恢复 hbase hbck -repair 试图自动修复，但实际上增加了1个不一致的数目
hbase hbck -fixMeta -fixAssignments hbase hbck -repair 这个时间表修好了 hbase hbck -details 确认修复
在这一点上，hbase是健康的，添加了额外的区域，并且取消了对损坏文件的引用。但是，hdfs仍然有5个损坏的文件。由于hbase不再引用它们，我们删除了它们：
切换到hdfs用户：
su hdfs hdfs fsck / 了解问题的范围 hdfs fsck / -delete 仅删除损坏的文件 hdfs fsck / 确认健康状态
注意：完全停止堆栈以重置缓存非常重要
（停止所有服务thrift、hbase、zoo keeper和hdfs，并按相反顺序重新启动它们）。
[1] hbck命令的cloudera页面：
http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/admin_hbck_poller.html

仅供参考：我决定咬紧牙关，用以下方法手动从hdfs中删除损坏的文件：

hdfs dfs -rm /user/hbase/table_foo_bar/295cff9c67379c1204a6dd....

( hdfs fsck -move 不适合我，不知道为什么）
在那之后，我和医生检查了hbase的健康状况 hbck ，但未检测到不一致

$ hbase hbck
...
0 inconsistencies detected.
Status: OK

所以在我们的例子中，手动删除区域文件并没有引入hbase损坏，如果我理解正确的话，这是很好的，但是令人困惑(我希望这不会适得其反，腐败不会在以后的某个时候显现出来）
问题已解决
您的里程数可能会有所不同。