手上的一个HBase相关的服务在重启后开始报错（重启前运行良好），错误信息如下： 错误信息提示连接zookeeper时间超长。经检查是因为有一个zookeeper节点已经停止运行（zk3.com），和运维商量后将zookeeper故障节点删除，并移掉了另一个节点，剩下了3个节点。修改配置文件并重启后服务恢复。 #######

org.apache.hadoop.hbase.client.BufferedMutator主要用来对HBase的单个表进行操作。它和Put类的作用差不多，但是主要用来实现批量的异步写操作。 BufferedMutator替换了HTable的setAutoFlush(false)的作用。 可以从Connection的实例中获取BufferedMutator的实例。在使用完成后需要调用close()方法关闭连接。对BufferedMutator进行配置需要通过BufferedMutatorParams完成。 MapReduce Job的是BufferedMutator使用的典型场景。MapReduce作业需要批量写入，但是无法找到恰当的点执行flush。BufferedMutator接收MapReduce作业发送来的Put数据后，会根据某些因素（比如接收的Put数据的总量）启发式地执行Batch Put操作，且会异步的提交Batch Put请求，这样MapReduce作业的执行也不会被打断。 BufferedMutator也可以用在一些特殊的情况上。MapReduce作业的每个线程将会拥有一个独立的BufferedMutator对象。一个独立的BufferedMutator也可以用在大容量的在线系统上来执行批量Put操作，但是这时需要注意一些极端情况比如JVM异常或机器故障，此时有可能造成数据丢失。 如下是几个使用BufferedMutator的实例。 实例一： 这段代码演示了创建BufferedMutator的一般过程。如前文所说，BufferedMutator的配置通常通过BufferedMutatorParams完成。获取BufferedMutator实例则是通过Connection对象。在这里还调整了一个writeBuffer的设置，这里等于是覆盖了HBase配置文件中的“hbase.client.write.buffer”设置。 实例二： 这段代码只看前半部分即可。与实例一的不同在于这里新建了一个ExceptionListener接口实现，并添加到BufferedMutatorParams中替换了BufferedMutatorParams的默认ExceptionListener实现。 实例三： 这里是一段BufferedMutator测试代码。 实例四： 实例五： 如有必要，稍后抽时间对代码做些简单说明。 ######

Hadoop中一个不明确的内容就是Block复制：它自动完成，通常不需要用户关心。HBase将数据保存到HDFS，并完全相信它的安全性。正是因为HDFS的Block复制对HBase来说是完全透明的，就产生了一个问题：HBase的效率会受到多大的影响？当我们开始写MapReduce作业访问HBase和Hadoop的时候，就难免会想到这个问题。尤为关键的是，当HBase中存储的数据很多的时候，它怎样使数据距离需要的地方更近一些？这就涉及到HBase的数据是怎样在HDFS上存储了。 首先，我们看看Hadoop是如何处理这个问题的。在MapReduce文档中说明了task通常运行在距离其处理的数据比较近的位置。这主要是通过将HDFS中的数据拆分成小块实现的，这些小块的数据被称为Block。HDFS中的Block的大小要比文件系统的Block大得多：默认是64M，但是通常会被设置为128M（这个值还可以设置得更大一些——如果确认所有文件的size都大于单个Block）。每个Block对应一个map task。这也就意味着Block的size设置得越大，Block的数量就越少，需要的map task的数量就越少。Hadoop知道每个Block的存储位置，它会在存储Block的节点上直接运行map task。每个Block都有两到三个副本。事实上，hadoop选择的节点通常是存储Block副本的节点。这样Hadoop保证了MapReduce作业总是在本地处理数据。 现在回到HBase。既然已经知道Hadoop是如何让它的每个map task处理本地数据的，就可以再进一步思考下HBase是如何做到Data Locality的。要是读过关于HBase存储结构的文章的话，就知道HBase是将相关的文件保存在HDFS上。这些文件包括数据文件（HFile）和日志文件（WAL）。在源码里也能看到HBase是调用了FileSystem.create(Path path)方法来创建这些文件的。现在可以想想两种常见的访问模型：1.直接随机访问；2.使用MapReduce扫描全表。我们会很好奇HBase是怎样就近读取HDFS上的Block，从而提升这两种访问方式的效率的。 话说回来，如果Hadoop和Hbase没有在同一个集群上，而是分隔开的，就不要再想Data Locality了——这根本不可能做到。这就如同运行一个独立的MapReduce集群，而它根本无法在DataNode上执行task。所以要实现Data Locality就必须让相关的服务在一个同一个集群上，包括Hadoop（或者说是HDFS）、MapReduce和HBase。就是这样。 好了，是不是弄清了所有的服务都在同一个集群（希望是一个比较大的集群）上？弄清了，那就继续。在HBase访问数据的时候，Hadoop是怎样找到数据在哪儿呢？这样又回到了前面提到的两种访问模型上。这涉及到一个概念：RegionServer。不管是直接随机访问还是扫描全表，都是通过相同的API实现的。正如之前所提到的，HBase仅仅是执行文件的保存，而文件的分布和Block的复制是通过HDFS的DatNode来实现的。假设一个场景：在向HBase中存储了大量的数据后停止HBase服务并连续地对其进行重启。RegionServer在重启后会被分配随机数量的Regions。在这个时候，HBase的Data Locality是无法保证的。为什么呢？ 最重要的是HBase不会频繁重启，并且会定期进行内部维护。随着时间的推移，数据不停地增加，HBase会执行compact来重写文件。由于各种原因，文件一旦写入HDFS就是不可变的。因此，数据会不停地写入新的文件。随着数据文件越来越多，HBase会将这些数据文件压缩（compact）合并成另一组新的文件。这里是最让人惊奇的地方：HDFS足够聪明，它知道将数据放到被需要的地方。这是怎么做到的呢？我们需要深入Hadoop的源码来看看HBase调用的FileSystem.create(Path path)方法是怎么工作的。因为我们选择的HBase存储方案是HDFS，所以我们实际上调用的是DistributedFileSystem.create(Path path)方法，该方法的代码如下： 这个方法返回了一个FSDataOutputStream类型的实例。create这个实例的方法如下： 这个方法中使用了一个DFSClient实例作为纽带来连接client和NameNode： 最终返回的是一个DFSClient.DFSOutputStream实例。数据不停地写入到DFSOutputStream，DFSClient会将之收集起来打成包作为一个Block写入到DataNode。这个过程是由DFSClient.DFSOutputStream.DataStreamer实现的，它以守护进程的形式在后台运行。接下来我们一步一步的推断出这个过程具体是怎么实现的。首先我们看一下DataStreamer后台线程的run()方法，它获取了存储数据的DataNode的列表： 而这个方法又调用了如下的代码： 接下来看看locateFollowingBlocks()又调用了哪个方法： 这里就是关键了。这里使用namenode对象添加了一个新的Block，方法中使用的src参数表示要写入的文件，clientName表示DFSClient实例的名称。接下来跳过部分不太重要的内容，直接看看稍后一些关键的步骤： 最后也是最为核心的代码，就是replicator.chooseTarget() 方法的详情了： 接回上面的内容，我们已经启动了一个DFSClient实例并创建了一个写满数据的序列化文件。当要将数据文件存储为Block的时候，上面的代码首先检查是否可以将Block保存在client所在的本地主机（代码中的“writer”）——这是程序中“case 0”的内容。而“case 1”的部分表示程序尝试在另一个机架上保存一个远程备份。后面“case 2”优先选择一个与“case 0”中相同的机架，然后才考虑选择不同的机架。如果还需要更多的备份，则会随机选择一个机架的任意节点保存。 这就表示，在完成一次对所有表的major compaction（可以是手动触发也可以在配置文件中配置）以后，RegionServer运行的时间越长，它将数据保存在本地节点的概率就越大。和RegionServer在相同物理主机上的DataNode会保留一份这个RegionServer需要的所有数据的拷贝。这样可以保证在执行scan、get或其他任何操作时有最好的性能。 最后，要想全面地了解HDFS的设计和数据冗余备份的内容请移步Hadoop官网：HDFS Architecture。也请注意到HBase团队一直在重新设计HMaster分配Region给RegionServer的方案。新的方案将会把Regions分配给拥有Block最多的RegionServer。这调整对改善HBase重启后的DataLocality特别有用。 原文： HBase File Locality in HDFS：http://www.larsgeorge.com/2010/05/hbase-file-locality-in-hdfs.html #####

热点现象 HBase中的记录行按行键的字典顺序进行排序。这种设计有利于扫描（scan）记录。因此我们可以合理的设计行键，将相关的行或者需要一起读取的行放得靠近一些。不过设计得不好的行键也是热点现象的常见来源。当大量客户端流量指向集群中一个或少数几个节点时就容易产生热点现象。这里说的流量指的是读、写或其他操作。这些客户端流量可能会压倒负责托管某个区域（region）的机器，并因此导致性能下降甚至该区域的不可用。因为无法响应请求，这台主机上托管的其他region也可能会受到不良影响。因此如何设计数据访问模式以使集群全面均衡地发挥作用就很重要了。 为防止写数据的热点出现，就需要调整行键设计。原本有些数据非常需要写入同一个region，但是从更高的角度上来看，这些数据就应该分发到集群的多个region上，而非是一次性写入某一个region。下面会介绍一些常用的避免热点的方案，以及这些方案的优点和缺点。 盐化 这里说的盐与加密盐并无关系，只是将一串随机数添加到行键的头部。这里说的盐化指的是将一串随机分配的前缀添加到行键以使其按与原本不同的方式进行排序。不同前缀的数量应该和设计的region的数量一致。如果在均匀分布的行模式中反复出现了少量热点行模式，此时使用盐化的方式是很有用的。看一下下面的实例，在实例中演示了是如何使用盐化将数据分散到不同的regionServer中的，以及盐化对读取数据的影响。 假设我们有如下行键列表。存储记录的表按字母表给每个字母分配一个region，比如前缀“a”是一个region，前缀“b”就是另一个region。在表中所有以“f”开头的行键的记录就会被写入到相同的region中。在这个例子中我们有如下这样的一批行键： 现在我们想把这些行键对应的记录分发到不同的region中。我们将使用4个不同的盐a、b、c和d作为前缀。这样，包含盐前缀的记录就会被写到对应的region上。使用盐以后，我们会得到下面这样的行键。因为现在是将记录写到四个不同的region，相比只写入到一个region理论上会有四倍的吞吐量。 如果要添加一行新的记录，在现有的行键上随机填上四个盐中的一个作为前缀。 因为这种分配是随机的，同一条记录有可能会分配到不同的前缀，这样要想按字典顺序检索出记录就得做更多的工作。 使用盐化的方式扩大了写入的吞吐量，却也增加了读取数据的开销。 哈希 要替代随机分配盐的方案，可以使用单向哈希。这使用单向哈希每个行都会分配到一个固定的前缀。这样记录仍可以被写到不同的region上，不过在读的时候可以保证做到精确读取。使用确定性哈希允许客户端重建完整的行键并使用Get操作准确检索到记录。 仍然是前面盐化方案中的例子，可以使用单向哈希给“foo0003”这条记录始终分配一个可以预知的前缀“a”。这样在检索这一行记录的时候就可以就可以准确计算出行键。基于这个方案我们可以对行键做一些优化，比如让特定的一对行键总是被分配到相同的region中。 反转行键 第三个常见的防止热点的技巧是反转行键。也就是将固定宽度或数值类型的行键反转，这样行键中变化最频繁的部分（最低有效位）就会排到第一位。这有效地对行键进行了随机化，不过却牺牲了行排序属性。 单调递增行键或时间序列数据 在使用HBase时要警惕一个现象：所有的客户端集中锁定访问表的一个region（也就是hbase的一个节点），然后又全部移动向下一个region，就这样推进并形成循环。在使用单调递增的行键（比如使用时间戳）时就容易发生这样的情况。在BigTable类的数据存储中使用单调递增的行键是一个坏的选择。这里有一幅漫画描述了为什么单调递增是不好的。虽然可以采用随机化的方式打乱输入记录的排序顺序来减轻单调递增行键造成的单个region的访问热点的问题，但是通常也应尽量避免使用时间戳或者一个自增序列（比如1、2、3）作为行键。 如果确实需要上传时间序列数据到HBase，可以学习一个成功案例：OpenTSDB。这个项目有一个页面专门描述了它在HBase中使用的schema。OpenTSDB实际上使用的行键格式是：[metric_type][event_timestamp]。乍一看这和我们前面说的不建议使用时间戳作为行键是冲突的。差别就在于这里没有将时间戳置于行键的前导位置，并且在设计中假设存在几十几百个（或者更多）不同的metric_type。因此，尽管有不间断的输入数据流，相关的Puts操作也会被分发向不同的region。 尝试最小化行键和列的大小 在HBase中，每一个值都有与其对应的坐标。比如HBase系统中的一个cell value，它的坐标就是行键名、列名还有时间戳。如果行键名和列名很大——尤其是与cell value一起比较的时候——就可能会遇到一些有趣得情况。在HBASE-3551中Marc Limotte就描述了这样的一种情形。这里描述的问题是保存在HBase存储文件（HFile）上以便于随机访问的索引占用了大部分分配给HBase的RAM，原因就是cell value的坐标太大了。刚才引用的这个问题，在评论中有人建议调大blocksize，这样为HBase存储记录新建索引的时间间隔就会大一些，或者是修改表设计使用更小的列名和行键名。此外，压缩也能导致索引变大，在这里提到了一个相关的案例。 大多数时候这种小的低效率并没有大的影响。不幸的是它们确实有发生的契机，尤其是在需要访问几十亿条数据的时候。 行键长度 行键长度固然是越短越好，但是应尽量保证行键有意义，以便于对数据进行访问（包括Get和scan）。一个短的行键并不比一个虽然长却有利于scan或get的行键更好。因此在设计行键时需要反复权衡。 关于列族 列族名称应该尽量的小，最好是1个字母，比如使用d来替换default或data。 关于属性名称 尽管冗长的属性名称（比如：myVeryImportantAttribute）更容易理解，但是保存在HBase中的属性名称应该是越短越好（比如使用via）。 字节模式 一个长整型值的长度是8个字节。在这8个字节里我们可以保存一个最大为18,446,744,073,709,551,615的整数值。如果我们将这个整数值保存在字符串里——假设使用一个单词代表一个字节——我们将需要3倍的字节数。 不相信？下面是一段示例代码，可以自己运行一下试试看。 使用字节代表一个类型有一个缺点：将会使数据在代码以外的地方很难阅读。下面这个例子演示了在hbase shell中对一个值执行increase操作的结果： hbase shell会尽最大努力打印一个字符串。在这种情况下，它只会打印16进制的值。同样的情况也会发生在region内的行键上。通常如果知道正在写入的数据是什么是最好的，不过写入cell内的可以是任何内容，包括可读的和不可读的。这点在设计时需要仔细衡量。 反向时间戳 数据库中一个常见的问题是如何快速的找到一个值的最新版本。在某些特殊情况下使用反向时间戳技术作为行键的一部分可以很好地处理这个问题。反向时间戳即（Long.MAX_VALUE – timestamp）。通常是将反向时间戳追加在行键末尾，即[行键][reverse_timestamp]。这样，在通过一个原始的行键执行scan搜索时检索到的第一个值就是这个原始行键所对应的最新的值。 使用反向时间戳替换HBase的Versions管理的目的是永久保留一些值的所有版本，并在使用相同的Scan方案的时候仍然能够保持快速访问其它任何版本的能力。 行键和列族 行键的作用域是列族。因此一个表中的列族可以有相同的行键而不冲突。 行键的不变性 行键是不可变的。一个表中的行键可以被“改变”的方式就是将记录删除后再重新插入。 行键和region split的关系 如果要对表进行预分区，那么弄清楚region边界处的行键分布就很重要了。下面的例子说明了为什么这很重要，在实例中使用了可视化十六进制字符作为行键（比如”0000000000000000″ 到 “ffffffffffffffff”）。使用Bytes.split（这也是用Admin.createTable(byte[] startKey, byte[] endKey, numRegions)方法创建分区时使用的split策略）处理这个范围内的行键，计划创建10个分区，目前有如下的splits数组作为splitKey： （注意：右侧的注释说明了前导字节的值）。如上面所示的，第一个split字节是字符‘0’，最后一个split字节是字符‘f’。看起来就是这样，没毛病，是不是？先别着急下定论。 问题是所有的数据将会堆积在前两个region以及最后一个region处，并因此产生lumpy region（也有可能是hot region）问题。要理解为什么，可以先参考ASCII表。字符‘0’的byte值是48，字符‘f’的byte值是102。但是在字节值中有一个巨大的间隙（字节58 到 96）永远不会出现在行键空间中，因为有效值是[0-9]和[a-f]。因此中间部分的region将永远不会出现。要使示例的行键设计在预分区工作中生效，需要使用一个自定义的split策略（而不仅仅是依赖内置的split方法）。 从刚才描述的问题，我们能够获得如下两条经验： 经验一：预分区通常是一个不错的方案，但是需要确保预分区得到的所有regions是对行键可达的。在这个例子里演示了使用十六进制字符作为行键前缀造成的问题，类似的问题也可能发生在其他类型的行键设计上。因此首先要做的一件事情就是充分了解要写入HBase的数据。 经验二：尽管通常不建议，使用十六进制字节（通常建议使用可视化数据）作为预分区表的行键前缀也是可行的——只要创建的所有分区对于设计的行键是可达的即可。 为了好好结束这个例子，下面提供了一种适合十六进制行键的预分区split生成方案： 参考文档 Configuring The Blocksize For HBase ##################