1.[知识讲解篇-155]HBase最佳实践－客户端超时机制
2.HBase scan setBatch和setCaching的区别
3.关于hbase的问题，开启hbase后一会hmaster和hregionserver就没了？

[知识讲解篇-155]HBase最佳实践－客户端超时机制

       客户端超时设置对整个系统的稳定性以及敏感性至关重要。不当的超时设置可能导致服务器端的长时间卡顿引起客户端阻塞等待，影响上层应用。HBase提供了多个客户端参数以设置超时，包括 hbase.rpc.timeout、猎魂+源码hbase.client.operation.timeout 和 hbase.client.scanner.timeout.period。尽管官方文档对此没有详细说明，本文将详细介绍这三个参数。

       其中，hbase.rpc.timeout 表示一次RPC请求的超时时间。如果请求耗时超过此时间，可可tv源码客户端将主动关闭socket，服务器端会捕获SocketTimeoutException异常。默认值为ms（1分钟）。

       hbase.client.operation.timeout 则表示HBase客户端发起数据操作直至得到响应的总超时时间，包括了多个可能的RPC请求。例如，在一次PUT请求中，如果因为服务器端Full GC导致RPC请求超时，则对应hbase.rpc.timeout。而如果请求过程中发生网络抖动导致网络异常，则对应hbase.client.operation.timeout。忻州溯源码

       至于hbase.client.scanner.timeout.period，它为扫描操作提供了一个单独的超时设置。由于扫描操作可能导致的服务器端IO利用率过高、网络带宽占用和客户端内存OOM等问题，HBase会将一次扫描操作拆分为多个RPC请求。该参数设置了一个RPC请求的超时时间，默认为ms，超时后会抛出SocketTimeoutException异常。

       在设置这些参数时，应根据实际情况选择合理的值。hbase.rpc.timeout与hbase.client.operation.timeout的源码运算程序值应综合考虑系统的并发量、服务器性能以及网络状况。而hbase.client.scanner.timeout.period的值则需要根据待检索数据量和客户端内存限制进行调整。

       需要额外注意的是，一次扫描操作实际上会拆分为多个RPC请求。具体拆分的数量由一次扫描的待检索条数和单次RPC请求的数据条数决定。在设置参数时，应平衡扫描效率和资源占用，避免一次扫描请求的数据量过大导致内存问题，同时也要避免拆分过多RPC请求增加网络成本。

       在实际使用中，如果在扫描过程中遇到RegionServer端抛出的tars 源码解析leaseException，这与HBase的租约机制有关。租约机制是为了防止在客户端意外宕机时，服务器端的资源得不到释放。RegionServer在接收到第一次RPC请求时，会生成全局唯一的scanId和超时时间的lease，如果在超时时间内后续请求未到达，则会认为客户端异常，释放相关资源。

       总结，合理设置客户端超时参数是保障系统稳定性和响应敏感性的关键。应避免盲目将超时时间设长，而是深入分析超时原因，确保系统在异常情况下能够快速响应，避免上层应用长时间卡顿。通过修改配置文件或代码设置参数时，应根据实际情况灵活调整，平衡资源利用与系统响应速度。

HBase scan setBatch和setCaching的区别

       HBase的查询实现只提供两种方式：

       1、按指定RowKey获取唯一一条记录，get方法（org.apache.hadoop.hbase.client.Get）

       2、按指定的条件获取一批记录，scan方法（org.apache.hadoop.hbase.client.Scan）

       å®žçŽ°æ¡ä»¶æŸ¥è¯¢åŠŸèƒ½ä½¿ç”¨çš„就是scan方式，scan在使用时有以下几点值得注意：

       1、scan可以通过setCaching与setBatch方法提高速度（以空间换时间）；

       2、scan可以通过setStartRow与setEndRow来限定范围（[start，end）start是闭区间，end是开区间）。范围越小，性能越高。

       é€šè¿‡å·§å¦™çš„RowKey设计使我们批量获取记录集合中的元素挨在一起（应该在同一个Region下），可以在遍历结果时获得很好的性能。

       3、scan可以通过setFilter方法添加过滤器，这也是分页、多条件查询的基础。

       scan中的setCaching与setBatch方法的区别是什么呢？

       setCaching设置的值为每次rpc的请求记录数，默认是1；cache大可以优化性能，但是太大了会花费很长的时间进行一次传输。

       setBatch设置每次取的column size；有些row特别大，所以需要分开传给client，就是一次传一个row的几个column。

       batch和caching和hbase table column size共同决意了rpc的次数。

关于hbase的问题，开启hbase后一会hmaster和hregionserver就没了？

       一、通常向HBase批量导入数据有三种常用方式

       1、使用HBase提供的TableOutputFormat，原理是通过一个Mapreduce作业将数据导入HBase

       2、还有一种方式就是使用HBase原生Client API（put）

       3、前两种方式因为须要频繁的与数据所存储的RegionServer通信。一次性入库大量数据时，特别占用资源，所以都不是很有效。因为HBase在HDFS中是以HFile文件结构存储的，所以高效便捷的方法就是直接生成HFile文件然后使用Bulk Load方法，即HBase提供的HFileOutputFormat类。

       二、Bulk Load基本原理

       Bulk Load处理由两个主要步骤组成：

       1、生成HFile文件

       Bulk Load的第一步会执行一个Mapreduce作业，其中使用到了HFileOutputFormat输出HBase数据文件：StoreFile。

       HFileOutputFormat的作用在于使得输出的HFile文件能够适应单个region。使用TotalOrderPartitioner类将map输出结果分区到各个不同的key区间中，每一个key区间都相应着HBase表的region。

       2、导入HBase表

       第二步使用completebulkload工具将第一步的结果文件依次交给负责文件相应region的RegionServer，并将文件move到region在HDFS上的存储文件夹中。一旦完毕。将数据开放给clients。

       假设在bulk load准备导入或在准备导入与完毕导入的临界点上发现region的边界已经改变，completebulkload工具会自己主动split数据文件到新的边界上。可是这个过程并非最佳实践，所以用户在使用时须要最小化准备导入与导入集群间的延时，特别是当其它client在同一时候使用其它工具向同一张表导入数据。

       Bulk Load常遇到的一个ERROR:”java.io.IOException: Retry attempted times without completing, bailing out”

       错误解析：

       我们使用的Hbase1.0.2版本下，如果Hfile文件 跨越多个region，bulkload会自动地将Hfile文件split，但是对于每次retry只会将指定的Hfile文件split一次。但是在hbase-site.xml配置文件里有个参数hbase.bulkload.retries.number控制了hbase对一个hfile最多plit多少次。这个参数默认是，如果某个hfile跨越的region数超过个就会报上述Exception。

       解决方案：

       将hbase.bulkload.retries.number这个参数设置为更大的值，比如目标表的region数量或者将这个参数设置成0，0表示不断重试直到成功。设置之后问题解决。