有很多关于它的好书（见文章末尾），但我会试着用我自己的话来解释；）
hbase不负责数据复制，hadoop hdfs负责，默认情况下配置为复制因子3，这意味着所有数据将至少存储在3个节点中。
数据局部性是获得良好性能的一个关键方面，但实现最大的数据局部性很容易：您只需要将hbase regionserver（rs）与hadoop datanodes（dn）合并，因此，您的所有dn也应该具有rs角色。一旦你有了它，hbase会自动将数据移动到需要的地方（在主要压缩上），以实现数据的局部性，也就是说，只要每个rs都有它在本地服务的区域的数据，你就有了数据的局部性。
即使将数据复制到多个dn，每个区域（以及它们包含的行）也只由一个rs提供服务，复制因子为3、10或100并不重要。。。读取属于区域#1的行将始终命中相同的rs，并且该rs将是承载该区域的rs（由于数据局部性，该rs将从hdfs本地读取数据）。如果承载该区域的rs宕机，该区域将自动分配给另一个rs（因为数据也被复制到其他dn）
您所能做的是以一种方式拆分表，每个rs甚至都有分配给它的行（区域）桶，这样在您读写数据时，尽可能多的不同rs同时工作，只要您不总是命中相同的区域（称为regionserver hotspotting**），就可以提高总体吞吐量。
因此，您应该始终从确保表的所有区域都分配给不同的r开始，并且它们接收相同数量的r/w请求。完成后，可以将表拆分为多个区域一次，直到集群的所有r上都有偶数个区域（如果对负载均衡器不满意，则可能需要手动分配这些区域）。
只需提醒一下，即使您的区域分布看起来很完美，但如果您的数据访问模式不正确（或不均匀），并且不能均匀地到达所有区域，那么您的性能仍然很差，最终这一切都取决于您的应用程序。
（*）建议内容：
http://www.larsgeorge.com/2009/10/hbase-architecture-101-storage.html
http://www.larsgeorge.com/2010/05/hbase-file-locality-in-hdfs.html
（**）为了避免rs热点，我们总是将表设计为具有非单调递增的行键，因此行1、2、3。。。n托管不同的区域，常用的方法是使用md5（id）+id作为rowkey。这种方法有自己的一系列缺点：不能扫描前10行，因为它们是咸的。