mapreduce.map.speculative、mapreduce.reduce.speculative默认是开启的，即为true
例如wordCount程序
hadoop jar wordCount.jar hdfs:///test/inputhdfs:///test/output
可以在hadoop 任务8088页面点击具体的job，查看job configuration，看到mapreduce.map.speculative为true，来源自mapred-default.xml
关闭map的speculative方法：
1.      在上面运行hadoop命令的机器上，修改hadoop配置文件，例如mapred-site.xml，增加mapreduce.map.speculative的property，设置为false。
这时观察8088页面上job configuration，可以看到mapreduce.map.speculative为false，来源mapred-site.xml。
2.      在wordCount程序代码中，conf.setBoolen(“mapreduce.map.speculative”,false);
这时观察8088页面上job configuration，可以看到mapreduce.map.speculative为false，来源自programatically，即通过程序设置。
 
但上面的第2步骤对于hbase通过TableMapReduceUtil类实现的mapreduce，不起效果，原因估计是TableMapReduceUtil实现里会重新读取配置文件而导致覆盖程序中动态设置的配置项（如有错误，欢迎指正），故对hbase的mapreduce，要关闭speculative机制，只能修改hadoop命令所关联的配置文件。

本文介绍HBase区域如何分配给区域服务器。
HBase区域分配启动
当HBase启动区域分配如下（简短版本）时：
主机在启动时调用AssignmentManager。
AssignmentManager查看hbase:meta中现有的区域分配。
如果区域分配仍然有效（即，如果RegionServer仍处于联机状态），则将保留分配。
如果分配无效，则调用LoadBalancerFactory来分配区域。负载均衡器（在HBase 1.0中默认StochasticLoadBalancer）将该区域分配给RegionServer。
hbase:meta使用RegionServer分配（如果需要）和RegionServer启动代码（RegionServer进程的开始时间）在RegionServer打开区域时进行更新。
故障转移
当RegionServer失败时：
区域立即变得不可用，因为RegionServer已关闭。
主机将检测到RegionServer失败。
区域分配将被视为无效，并将像启动序列一样被重新分配。
飞行中的查询被重新尝试，并且不会丢失。
操作在以下时间段内切换到新的RegionServer：
ZooKeeper session timeout + split time + assignment/replay time
区域负载平衡
区域可以由LoadBalancer定期移动。
区域状态转变
HBase维持每个区域的状态并在hbase:meta中保持状态。该hbase:meta地区本身的状态在ZooKeeper中保存。您可以在Master Web UI中查看转换中的区域状态。以下是可能的区域状态。
可能的区域状态：
OFFLINE：该区域处于离线状态，无法打开
OPENING：该区域正在被打开
OPEN：该区域已打开并且RegionServer已通知主机
FAILED_OPEN：RegionServer无法打开该区域
CLOSING：该区域正在关闭
CLOSED：RegionServer关闭了该区域并通知了主机
FAILED_CLOSE：RegionServer无法关闭该区域
SPLITTING：RegionServer通知主机该地区正在拆分
SPLIT：RegionServer通知主机该区域已完成拆分
SPLITTING_NEW：该区域正在建设中，正在进行中的拆分
MERGING：RegionServer通知主机这个区域正在与另一个区域合并
MERGED：RegionServer通知主机该区域已被合并
MERGING_NEW：这个区域是由两个区域合并创建的
区域状态转换图：
图表图例注释：
Brown：离线状态，一种特殊状态，可以是暂时的（打开之前关闭后），终端（已禁用表的区域）或初始（新创建表的区域）
Palegreen：区域可以满足请求的在线状态
Lightblue：瞬态状态
Red：需要OPS注意的失败状态
Gold：区域的终端国家拆分/合并
Grey：通过拆分/合并创建的区域的初始状态
过渡状态描述：
主机将区域从OFFLINE状态移动到OPENING状态并尝试将区域分配给RegionServer。RegionServer可能或可能未收到开放区域请求。主机会重试将开放区域请求发送到RegionServer，直到RPC通过或主机用尽重试。在RegionServer收到开放区域请求后，RegionServer开始打开该区域。
如果主服务器的重试耗尽，则即使RegionServer正在开始打开区域，主服务器也会通过将区域移至CLOSING状态并尝试关闭它来阻止RegionServer打开该区域。
RegionServer打开该区域后，它将继续尝试通知主服务器，直到主服务器将区域移至OPEN状态并通知RegionServer。该地区现在开放。
如果RegionServer无法打开区域，它会通知主人。主服务器将该区域移至CLOSED状态并尝试在不同的RegionServer上打开该区域。
如果主机无法在某个区域的任何区域打开该区域，则会将该区域移至FAILED_OPEN状态，并且在操作员从HBase shell进行干预或服务器死机之前不会采取进一步的行动。
主机将区域从OPEN状态移动到CLOSING状态。持有区域的RegionServer可能已经或可能未收到关闭区域请求。主服务器重试向服务器发送关闭请求，直到RPC通过或主服务器用尽重试。
如果RegionServer未联机或抛出NotServingRegionException，则主服务器将该区域移至OFFLINE状态并将其重新分配给不同的RegionServer。
如果RegionServer处于联机状态，但在主服务器用完重试之后无法访问，则主服务器会将该区域移至FAILED_CLOSE状态，并且不会采取进一步的操作，直到操作员从HBase shell进行干预或服务器已死亡。
如果RegionServer获得关闭区域请求，它会关闭该区域并通知主机。主机将区域移至CLOSED状态并将其重新分配给不同的RegionServer。
在分配区域之前，如果主区域处于OFFLINE状态，主区域会自动将区域移至CLOSED状态。
当一个RegionServer即将分割一个区域时，它通知主机。主机将要分割的区域从OPEN状态移动到SPLITTING状态，并将要创建的两个新区域添加到RegionServer。这两个区域最初都处于SPLITTING_NEW状态。
通知主机后，RegionServer开始拆分区域。一旦经过了不返回的点，RegionServer会再次通知主服务器，以便主服务器可以更新该hbase:meta表。但是，在服务器通知拆分完成之前，主服务器不会更新区域状态。如果拆分成功，拆分区域从SPLITTING状态移动到SPLIT状态，并且将两个新的区域从SPLITTING_NEW状态移动到OPEN状态。
如果拆分失败，则拆分区域从SPLITTING状态移动回OPEN状态，其中创建的两个新的区域将从SPLITTING_NEW状态移动到OFFLINE状态。
当一个RegionServer即将合并两个区域时，它首先通知主机。主机将两个区域合并为OPEN到MERGING状态，并将新的区域添加到RegionServer中，该区域将合并区域的内容保存起来。新区域最初处于MERGING_NEW状态。
通知主机后，RegionServer开始合并这两个区域。一旦经过不返回的点方，RegionServer再次通知主机，以便主机可以更新META。但是，主服务器不会更新区域状态，直到RegionServer通知合并已完成。如果合并成功，则两个合并的区域是从MERGING状态移动到MERGED状态，并且新的区域是从MERGING_NEW状态移动到OPEN状态。
如果合并失败，两个合并区域从MERGING状态返回到OPEN状态，这是为了保存合并的区域的内容的新的区域是从MERGING_NEW状态移动到OFFLINE状态。
对于处于FAILED_OPEN或FAILED_CLOSE状态的区域，当主机通过HBase Shell重新分配主区域时，主区域会尝试再次关闭它们。

一直疑惑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

HBase 版本：1.2.0-cdh5.7.0
一、客户端的长短连接
java 远程连接 HBase 客户端，大体分为两种方式。一种是长连接，一种是短连接。
短链接，顾名思义，就是客户端执行完某个操作之后，就关闭连接的这种方式，就是短链接。
而长连接就是有且连接一次，后续的所有操作都是基于这次连接做的操作，操作完成后，不关闭连接。长连接适用于频繁交互的场景，今天我们就来着重说一下它。
二、使用单例模式来初始化 HBase 客户端
以 HBase 为例，如果使用长连接，那就得需要确保 connection 唯一(不唯一的话，有可能造成资源浪费或者连接数过多报错)，所有的操作都使用这一个 connection 。实现方法有很多，比如双重校验，加锁等方法。
但我们也可以使用静态内部类的形式实现上述场景。静态内部类也是实现单例模式的一种，保证只加载一次，懒加载并且线程安全。
/**
* HBase客户端操作(长连接)
*/
public class HBaseUtil{
private static final Logger log = LoggerFactory.getLogger(HBaseUtil.class);
private Connection connection;
private static Configuration configuration;
/**
* 私有构造器
* 初始化 HBase Connection
*/
private HBaseUtil(){
configuration = initHBaseEnv();
try {
connection = ConnectionFactory.createConnection(configuration);
} catch (IOException e) {
log.error("HBase Client connect abnormal: ", e);
System.exit(-1);
}
}
/**
* 静态内部类
*/
private static class InstanceHolder{
// 不会在外部类初始化时就直接加载，只有当调用了getInstance方法时才会静态加载，线程安全。
private static final HBaseUtil instance = new HBaseUtil();
}
/**
* 单例模式，获取HBase实例
*/
public static HBaseUtil getInstance(){
return InstanceHolder.instance;
}
/**
* 初始化 HBase 配置
*/
public static Configuration initHBaseEnv(){
try {
configuration = HBaseConfiguration.create();
configuration.set("hbase.zookeeper.quorum", "cdh-worker-1,cdh-worker-2,cdh-worker-3");
configuration.set("hbase.zookeeper.property.clientPort", 2181);
configuration.set("zookeeper.znode.parent", "/hbase");
} catch (Exception e) {
log.error("HBase Client Configuration Initialization exception: ", e);
}
return configuration;
}
/**
* 获取namespace中所有的表名
*
* @param namespace
*/
public List listTables(String namespace) throws IOException{
List tableNameList = new ArrayList<>();
// 获取namespace中所有的表名
TableName[] tbs = connection.getAdmin().listTableNamesByNamespace(namespace);
for (TableName tableName : tbs) {
tableNameList.add(tableName.toString());
}
return tableNameList;
}
}
上述代码，只有当触发 getInstance() 方法时，才会初始化 connection ，且 connection 只会被加载一次。
比如我们要执行 HBase 客户端操作的话，可以执行：HBaseUtil.getInstance().listTables("xxx") 。
三、总结
1、为什么这样实现就是单例的？
因为 HBaseUtil.java 的实例化是靠静态内部类的静态常量 instance 实例化的。instance 是常量，因此只能赋值一次；它还是静态的，因此随着内部类一起加载。
2、这样实现有什么好处？
我记得以前接触的懒汉式的代码好像有线程安全问题，需要加同步锁才能解决。采用静态内部类实现的代码也是懒加载的，只有触发静态内部类的静态常量 instance 的时候才加载；同时也不会有线程安全问题。
3、不只是 HBase 可以这样初始化客户端，Elasticsearch 等等的长连接也都可以，这样，你学会了吗？