【HBase】06-HBase重要配置

1、推荐配置

1.1、ZooKeeper配置

zookeeper.session.timeout
默认超时为三分钟（毫秒指定）。这意味着，如果服务器崩溃，在主服务器发现崩溃并开始恢复之前需要三分钟。您可能需要将超时调整到一分钟或更短的时间，以便大师更快地发现故障。在更改此值之前，请确保JVM垃圾收集配置处于控制之下，否则，持续超过ZooKeeper会话超时的长垃圾收集将占用RegionServer。（如果RegionServer已经在GC中运行了很长时间，您可能希望恢复在服务器上启动）
要更改此配置，请编辑hbase-site.xml，跨集群复制更改的文件并重新启动。
我们把这个值设置得很高，这样就不必在邮件列表上列出问题，询问为什么一个RegionServer在大量导入期间出现故障。通常的原因是它们的JVM不调谐，它们正在运行长的GC暂停。我们的想法是，当用户对HBase越来越熟悉时，我们可以让他们不必知道它的所有复杂性。后来，当他们建立了一些信心，那么他们可以玩这样的配置。

1.2、HDFS配置

dfs.datanode.failed.volumes.tolerated
这是DataNode停止提供服务之前允许失败的卷数量。默认情况下，任何卷故障都会导致hdfs-default.xml描述中的“datanode”关闭。您可能希望将此设置为可用磁盘的大约一半。

hbase.regionserver.handler.count

此设置定义保持打开以响应对用户表的传入请求的线程数。经验法则是，当每个请求的有效负载接近MB（大put，使用大缓存进行扫描）时，保持该数值较低，而当有效负载较小（gets, small puts, ICVs, deletes）时，保持该数值较高。正在进行的查询的总大小受到设置hbase.ipc.server.max.callqueue.size的限制。

如果传入客户机的有效负载较小，则将该数量设置为最大数量是安全的，典型的示例是为网站服务的集群，因为put通常不被缓冲，并且大多数操作都是get。

保持这个设置高是危险的，因为当前在区域服务器中发生的所有put的总大小可能对其内存施加太大的压力，甚至触发OutOfMemoryError。在低内存上运行的RegionServer将触发其JVM的垃圾收集器更频繁地运行，直到GC暂停变得明显（原因在于，无论垃圾收集器如何努力，用于保存所有请求有效负载的所有内存都无法被丢弃）。一段时间之后，整个集群吞吐量受到影响，因为每个到达RegionServer的请求都将花费更长的时间，这更加恶化了问题。

通过rpc.logging到单个RegionServer上，然后跟踪它的日志（队列请求消耗内存），可以了解处理程序是否太少或太多。

1.3、大内存机的配置

HBase附带了一个合理、保守的配置，可以处理几乎所有人们想要测试的机器类型。如果您有更大的机器-HBase有8G和更大的堆-您可能会发现以下配置选项是有帮助的。

1.4、压缩

您应该考虑启用ColumnFamily 压缩。有几个选项几乎无摩擦，并且在大多数情况下通过减小StoreFiles的大小从而减少I/O来提高性能。更多参考https://hbase.apache.org/book.html#compression

1.5、配置WAL文件的大小和数量

HBase使用wal恢复在RS发生故障时没有刷新到磁盘的存储器数据。这些WAL文件应该配置成比HDFS块稍小（默认情况下，HDFS块是64Mb，WAL文件是~60Mb）。
HBase还限制了WAL文件的数量，旨在确保在恢复期间不会有太多的数据需要重播。这个限制需要根据内存库配置来设置，以便所有必需的数据都适合。建议分配足够的WAL文件来存储至少那么多的数据（当所有内存库接近满时）。例如，对于16GbRS堆、默认内存库设置（0.4）和默认WAL文件大小（~60Mb）、16Gb*0.4/60，WAL文件计数的起始点是~109。然而，由于所有的内存都不可能一直满，所以可以分配较少的WAL文件。

1.6、管理分片

HBase通常根据hbase-default.xml和hbase-site.xml配置文件中的设置来处理区域的分割。重要的设置包括hbase.regionserver.region.split.policy, hbase.hregion.max.filesize, hbase.regionserver.regionSplitLimit.分割的简单视图是，当一个区域增长到hbase.hregion.max.filesize时，它将被分割。对于大多数使用模式，您应该使用自动拆分。有关手动区域分割的更多信息，请参见手动区域分割决策。
您可以选择自己管理分区，而不是允许HBase自动分割您的区域。如果您非常了解密钥空间，那么手动管理拆分可以工作，否则让HBase为您确定在哪里进行拆分。手动分割可以减轻区域创建和负载下的运动。它也使得它的区域边界是已知的和不变的（如果你禁用区域分裂）。如果使用手动分割，则更容易进行交错的、基于时间的主要压缩，以分散网络IO负载。
禁用自动分割
要禁用自动分割，可以在集群配置或表配置中将区域分割策略设置为org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy
建议自动拆分
如果禁用自动拆分来诊断问题或在快速数据增长期间，建议在情况变得更稳定时重新启用它们。管理区域拆分的潜在好处并不是毫无争议的。
确定预裂区的最优数量
预分割区域的最佳数量取决于应用程序和环境。一个好的经验法则是从每个服务器10个预分割区域开始，并随着时间推移观察数据增长。最好是在太少的区域出错，然后执行滚动分割。区域的最佳数量取决于您所在区域的最大存储区。如果数据量增长，最大存储区的大小将随时间而增加。目标是使最大区域刚好足够大，以便压缩选择算法仅在定时主压缩期间对其进行压缩。否则，该团簇可能倾向于同时具有大量压实区域的压实风暴。理解数据增长导致压缩风暴而非手动拆分决策非常重要。
如果区域被分割成太多的大区域，则可以通过配置HConstants.MAJOR_COMPACTION_PERIOD来增加主压缩间隔。org.apache.hadoop.hbase.util.RegionSplitter实用程序还提供所有区域的网络IO安全滚动分割。

1.7、管理压缩

默认情况下，主要压缩操作计划在7天内运行一次。
如果需要精确地控制主要压缩运行的时间和频率，可以禁用托管的主要压缩。请参阅压缩参数表中的Hbas.HStutial.MyrRoad条目以获取详细信息。
不要禁用主要压缩
主要的压缩对于存储容器清理是绝对必要的。不要完全禁用它们。您可以通过HBASE shell或通过管理API手动运行主要的压缩操作。

1.8、推测执行

默认情况下，MapReduce任务的推测执行是打开的，对于HBase集群，通常建议在系统级别关闭推测执行，除非您在特定情况下需要它，其中可以按作业配置它。设置属性mapreduce.map.speculative和mapreduce.reduce.speculative 为false。