hbase的mttr怎么样，阿里云有特殊的优化么？

Hbase 是一个always-available的服务，在机器故障的时候保持可用性，集群中的机器都运行regionserver daemons。但一个regionserver出现故障，或者机器掉线，那么保存在上面的regions也同样掉线。Hbase中MTTR的能够检测异常，尽可能早的恢复对掉线region的访问。
文章解释了hbase如何管理MTTR，并且介绍了一些hbase和hdfs的设置。

Hbase是一致性时对故障的如何保持弹性

Hbase通过让一个单独的server负责数据的子集，也就是说，一个region在同一时刻只能被一个region server进行管理。

Hbase对失败的弹性，归功于hdfs，因为在写数据的时候，数据会被复制到到不通的节点。
Hbase将数据写入到hfiles中，hfile保存在hdfs上面，hdfs完成对hfiles的block的副本（replica）。默认情况下是副本数是3.
Hbase使用commit log（或者称之为Write-Ahead-log，WAL），提交日志也同样写在HDFS上面，默认副本数为3.

Hbase在故障检测以及访问恢复的步骤：
识别宕机的节点（Identifying that a node is down）：由于过载或者直接死掉，节点会不再响应。
在write操作进行中的时候进行恢复（Recovering the writes in progress):通过读取commit log，恢复还没有被flush的edit。
重新分配region：失败的regionserver之前在正在处理一些region，这些region需要被重新分配给其他的RS（regionSever），这个分配过程要根据每台RS不通的workload的情况
那上面三个过程中哪一个步骤最痛苦？在检测以及恢复步骤发生的时候，客户端会被阻塞。MTTR的作用就是加速这个处理过程，让客户端对数据downtime的感知时间尽可能的短。

检测失败节点：
一个RS的失败原因很多：正常的情况下，可能是由于clean stop，比如管理员关闭了某个节点，这就允许RS能安全适当的关闭region，然后告诉HMaster，正在关闭。这种情况下，commit log会被清除，然后HMaster会立刻安排region的重新分配。
另外的regionserver关闭的的情况：比如运行RS的计算机静默死亡（silent death），比如网络原因。导致region server不能够发出告警，这种情况有Zookeeper进行处理。 每一个RS都会连接到Zookeeper上面，而Master监测这些连接，Zookeeper自己管理heartbeat。所以timeout出现的时候，Hmaster会申明region server 已经死亡，启动一个恢复处理过程

恢复正在进行中的写操作。
当一个RS 出现了宕机，那么commit logs的恢复工作就发生了。这个恢复工作是并行开始的。
第一步：随机的RS会提取commit logs（从设置好的commit log 目录中），并且按照region来分割日志成多个文件，保存在HDFS上面，然后region会被重新分配给其他任意的RS，
然后每一个被分配的RS的都会去读取已经前面分割好的对应的region 日志文件，并且进行将该region恢复到正确状态。

当出问题的是一个node 失败了，而不是一个进程崩溃了，那么问题就会出现了。
出现进程崩溃的的regionserver，会将数据写入到处于同一台机上面的datanode上面。假设副本因素为3，那么当一个node丢失的时候，你丢失的不仅仅是一个region server，并且还有这个数据的一个副本。 进行split，就意味着要读取block，而1/3的副本已经死了，那么对于每一个block，你会有三分之一的几率被引导到错误的副本上面。还有，split操作需要创建新的文件。每一个文件都会有3个副本，这些副本可能会被指派给已经丢失的datanode，而这个write数据的过程由于datanode已经死亡，会在经过一个timeout之后失败，而重新回转到另外一个datanode上面，这就延缓了数据的恢复的过程。

重新分配region
分配region的工作会进行的很快，这依赖于Zookeeper，需要通过Zookeeper完成master和region server的异步工作。

MTTR带来的提升（The MTTR improvements）
检测失败节点：
首先，可以减小默认的timeout时间。Hbase 被配置成3分钟的Zookeepertimeout时间，这就保证了GC不会介入进来（GC parse会导致ZK的timeout，会导致错误的failure检测。）
对于生产系统，关注MTTR的话，设置timeout时间为1分钟，或者30秒，是很有必要的。
一个合理的最小设置时20秒。所以你可以设置hbase.zookeeper.timeout=60000
你同样设置你GC(incremental, generational GC with good figures for the young and old generations, etc., this is a topic by itself) ，这样使GC的暂停时间不要超过ZK timeout。

恢复正在进行中的写操作。
在正常情况下，会有足够的活跃的RS来并行的完成commit log files的split工作，所以问题的就转到能否直接找到HDFS上面仅存的副本。该问题的解决方案是，配置HDFS，是hdfs对于故障的检测快于hbase的检测。那就是说，如果hbase的timeout为60s，HDFS应该设置成20s（就是设置成20s之后就认为node已经死亡）。在这里我们要描述一下HDFS是如何处理dead node。HDFS的故障检测也同样是依赖于heartbeat和timeout，在HDFS中，如果一个node被申明为dead，那么保存在该datanode上面的replicas将会被复制到其他活跃的datanode上面去，而这个是一个消耗很大的过程，并且，如果多个datanode同事死亡，那么这就会引发“replication storms”，replication storms指所有的副本被重新拷贝，这会加剧系统负载，从而导致某些节点不响应，进而导致这些节点被NN视为已经死亡，而这些节点上面block又要重新被复制，周而复始，这样的replication storms实在是可怕了。
因此，HDFS在开始恢复过程之前会等待一段时间，会比10分钟长一点。而这一点，对于低延时系统来说就是一个问题:访问dead datanode就会促发timeout。在HDFS versions 1.0.4 or 1.2, and branches 2 and 3中，引入一个新的状态：stale。当一个datanode不再发送hearbeat，并且这个时间持续到一个指定的时间，那么datanode处于stale状态。 处于stale状态的节点就是在读写过程中最后一个选择（a last resort for reads），所以启用这种性质，会是恢复更加快。
设置启用stale的方法：修改hdfs-site.xml


dfs.namenode.avoid.read.stale.datanode
true


dfs.namenode.avoid.write.stale.datanode
true

dfs.namenode.write.stale.datanode.ratio
1.0f



dfs.namenode.check.stale.datanode
true

注：我在cloudera cdh-4.1.2 提供的doc的配置项目文档中没有找到该参数，看了源码才找到这些参数。
具体参考HDFS-3912, HDFS-4350:

重新分配region
Region分配的是纯粹hbase的内部实现，在Hbase 0.94+的版本中，region 分配过程的处理被优化了，允许在很短的时间异步分贝更多的region。
具体可以参考[example - Apache jira HBASE-7247].

结论。
在Hbase中没有global failure，如果一个region server 失败了，其他的region server 仍然可用，对于给定的一个数据集，MTTR 通常是 10分钟左右。
该经验数值是从是从比较普遍的情况是中得到的，因为需要使用dead datanode的节点上面副本数，恢复就需要时间。HDFS需要花费10分钟的时间来申明datanode死亡了。 当引入了stale状态的时候，这就不再是一个问题了。这个时候恢复时间就变成Hbase本身的问题，如果你需要考虑MTTR，那么你采用这里的设置，从节点真的出现失败，到数据在其他RS上面又重新变得可用，这个过程只需要2分钟，或者更少。