设为首页 加入收藏

TOP

HBase参数配置与优化
2019-02-09 01:52:18 】 浏览:40
Tags:HBase 参数 配置 优化

hbase.rootdir
  这个目录是region server的共享目录,用来持久化Hbase。URL需要是’完全正确’的,还要包含文件系统的scheme。例如,要表示hdfs中的/hbase目录,namenode运行在namenode.example.org的9090端口。则需要设置为hdfs://namenode.example.org:9000 /hbase。默认: file:///tmp/hbase-${user.name}/hbase

hbase.master.port
  Hbase的Master的端口。默认: 60000

hbase.cluster.distributed
  Hbase的运行模式。false是单机模式,true是分布式模式。若为false,Hbase和Zookeeper会运行在同一个JVM里面。默认: false

hbase.tmp.dir
  本地文件系统的临时文件夹。可以修改到一个更为持久的目录上。(/tmp会在重启时清除)默认: /tmp/hbase-${user.name}

hbase.master.info.port
  HBase Master web 界面端口. 设置为-1 意味着不运行。默认: 60010

hbase.master.info.bindAddress
  HBase Master web 界面绑定的端口。默认: 0.0.0.0

hbase.client.write.buffer
  HTable 客户端的写缓冲的默认大小。这个值越大,需要消耗的内存越大。因为缓冲在客户端和服务端都有实例,所以需要消耗客户端和服务端两个地方的内存。得到的好处是,可以减少RPC的次数。可以这样估算服务器端被占用的内存:hbase.client.write.buffer * hbase.regionserver.handler.count。默认: 2097152

hbase.regionserver.port
  HBase RegionServer绑定的端口。默认: 60020

hbase.regionserver.info.port
  HBase RegionServer web 界面绑定的端口,设置为-1表示不运行 RegionServer 界面。默认: 60030

hbase.regionserver.info.port.auto
  Master或RegionServer是否要动态搜一个可以用的端口来绑定界面。当hbase.regionserver.info.port已经被占用的时候,可以搜一个空闲的端口绑定。这个功能在测试的时候很有用。默认关闭。默认: false

hbase.regionserver.info.bindAddress
  HBase RegionServer web 界面的IP地址。默认: 0.0.0.0

hbase.client.pause
  通常的客户端暂停时间。最多的用法是客户端在重试前的等待时间。比如失败的get操作和region查询操作等都很可能用到。默认: 1000

hbase.client.retries.number
  最大重试次数。例如 region查询,Get操作,Update操作等等都可能发生错误,需要重试。这是最大重试错误的值。默认: 10

hbase.client.scanner.caching
  当调用Scanner的next方法,而值又不在缓存里的时候,从服务端一次获取的行数。越大的值意味着Scanner会快一些,但是会占用更多的内存。当缓冲被占满的时候,next方法调用会越来越慢。慢到一定程度,可能会导致超时。例如超过了hbase.regionserver.lease.period。默认: 1

hbase.client.keyvalue.maxsize
  一个KeyValue实例的最大size.这个是用来设置存储文件中的单个entry的大小上界。因为一个KeyValue是不能分割的,所以可以避免因为数据过大导致region不可分割。明智的做法是把它设为可以被最大region size整除的数。如果设置为0或者更小,就会禁用这个检查。默认10MB。

hbase.regionserver.lease.period
  客户端租用HRegion server 期限,即超时阀值。单位是毫秒。默认情况下,客户端必须在这个时间内发一条信息,否则视为死掉。默认: 60000

hbase.regionserver.handler.count
  RegionServers受理的RPC Server实例数量。对于Master来说,这个属性是Master受理的handler数量,默认: 10

hbase.regionserver.msginterval
  RegionServer 发消息给 Master 时间间隔,单位是毫秒。默认: 3000

hbase.regionserver.optionallogflushinterval
  将Hlog同步到HDFS的间隔。如果Hlog没有积累到一定的数量,到了时间,也会触发同步。单位毫秒,默认: 1000

hbase.regionserver.regionSplitLimit
  region的数量到了这个值后就不会在分裂了。这不是一个region数量的硬性限制。但是起到了一定指导性的作用,到了这个值就该停止分裂了。默认是MAX_INT,就是说不阻止分裂。

hbase.regionserver.logroll.period
  提交commit log的间隔,不管有没有写足够的值。默认: 3600000

hbase.regionserver.thread.splitcompactcheckfrequency
  region server 多久执行一次split/compaction 检查.默认: 20000

hbase.regionserver.nbreservationblocks
  储备的内存block的数量。当发生out of memory 异常的时候,我们可以用这些内存在RegionServer停止之前做清理操作。默认: 4

hbase.balancer.period
  Master执行region balancer的间隔。默认: 300000

hbase.regions.slop
  当任一regionserver有average + (average * slop)个region是会执行Rebalance。默认: 0

hbase.master.logcleaner.ttl
  Hlog存在于.oldlogdir 文件夹的最长时间, 超过了就会被 Master 的线程清理掉.默认: 600000

hbase.regionserver.global.memstore.upperLimit
  单个region server的全部memtores的最大值。超过这个值,一个新的update操作会被挂起,强制执行flush操作。默认: 0.4

hbase.regionserver.global.memstore.lowerLimit
  当强制执行flush操作的时候,当低于这个值的时候,flush会停止。默认是堆大小的 35% . 如果这个值和 hbase.regionserver.global.memstore.upperLimit相同就意味着当update操作因为内存限制被挂起时,会尽量少的执行flush(译者注:一旦执行flush,值就会比下限要低,不再执行)

hbase.server.thread.wakefrequency
  service工作的sleep间隔,单位毫秒。 可以作为service线程的sleep间隔,比如log roller.默认: 10000

hbase.hregion.memstore.flush.size
  当memstore的大小超过这个值的时候,会flush到磁盘。这个值被一个线程每隔hbase.server.thread.wakefrequency检查一下。默认: 67108864

hbase.hregion.preclose.flush.size
  当一个region中的memstore的大小大于这个值的时候,我们又触发了close.会先运行“pre-flush”操作,清理这个需要关闭的 memstore,然后将这个region下线。当一个region下线了,我们无法再进行任何写操作。如果一个memstore很大的时候,flush 操作会消耗很多时间。”pre-flush”操作意味着在region下线之前,会先把memstore清空。这样在最终执行close操作的时 候,flush操作会很快。默认: 5242880

hbase.hregion.memstore.block.multiplier
  如果memstore有hbase.hregion.memstore.block.multiplier倍数的 hbase.hregion.flush.size的大小,就会阻塞update操作。这是为了预防在update高峰期会导致的失控。如果不设上界,flush的时候会花很长的时间来合并或者分割,最坏的情况就是引发out of memory异常。默认: 2

hbase.hregion.max.filesize
  最大HStoreFile大小。若某个Column families的HStoreFile增长达到这个值,这个Hegion会被切割成两个。默认: 256M.

hbase.hstore.compactionThreshold
  当一个HStore含有多于这个值的HStoreFiles(每一个memstore flush产生一个HStoreFile)的时候,会执行一个合并操作,把这HStoreFiles写成一个。这个值越大,需要合并的时间就越长。默认: 3

hbase.hstore.blockingStoreFiles
  当一个HStore含有多于这个值的HStoreFiles(每一个memstore flush产生一个HStoreFile)的时候,会执行一个合并操作,update会阻塞直到合并完成,直到超过了hbase.hstore.blockingWaitTime的值。默认: 7

hbase.hstore.blockingWaitTime
  hbase.hstore.blockingStoreFiles所限制的StoreFile数量会导致update阻塞,这个时间是来限制阻塞时间的。当超过了这个时间,HRegion会停止阻塞update操作,不过合并还有没有完成。默认: 90000,单位ms。

hbase.hstore.compaction.max
  每个“小”合并的HStoreFiles最大数量。默认: 10

hbase.hregion.majorcompaction
  一个Region中的所有HStoreFile的major compactions的时间间隔。默认是1天。 设置为0就是禁用这个功能。默认: 86400000

hbase.mapreduce.hfileoutputformat.blocksize
  MapReduce 中HFileOutputFormat可以写 storefiles/hfiles. 这个值是hfile的blocksize的最小值。通常在Hbase写Hfile的时候,bloocksize是由table schema(HColumnDescriptor)决定的,但是在mapreduce写的时候,我们无法获取schema中blocksize。这个值 越小,你的索引就越大,你随机访问需要获取的数据就越小。如果你的cell都很小,而且你需要更快的随机访问,可以把这个值调低。默认: 65536

hfile.block.cache.size
  分配给HFile/StoreFile的block cache占最大堆(-Xmx setting)的比例。默认是20%,设置为0就是不分配。默认: 0.2

hbase.hash.type
  哈希函数使用的哈希算法。可以选择两个值:: murmur (MurmurHash) 和 jenkins (JenkinsHash). 这个哈希是给 bloom filters用的.默认: murmur


zookeeper.session.timeout
  ZooKeeper 会话超时.Hbase把这个值传递改zk集群,向他推荐一个会话的最大超时时间。单位是毫秒,默认: 180000

zookeeper.znode.parent
  ZooKeeper中的Hbase的根ZNode。所有的Hbase的ZooKeeper会用这个目录配置相对路径。默认情况下,所有的Hbase的ZooKeeper文件路径是用相对路径,所以他们会都去这个目录下面。默认: /hbase

zookeeper.znode.rootserver
  ZNode 保存的根region的路径. 这个值是由Master来写,client和regionserver 来读的。如果设为一个相对地址,父目录就是 ${zookeeper.znode.parent}.默认情形下,意味着根region的路径存储在/hbase/root-region- server.默认: root-region-server

hbase.zookeeper.quorum
  Zookeeper 集群的地址列表,用逗号分割。例 如:"host1.mydomain.com,host2.mydomain.com,host3.mydomain.com".默认是 localhost,是给伪分布式用的。要修改才能在完全分布式的情况下使用。如果在hbase-env.sh设置了HBASE_MANAGES_ZK, 这些ZooKeeper节点就会和Hbase一起启动。默认: localhost

hbase.zookeeper.peerport
  ZooKeeper节点使用的端口。默认: 2888

hbase.zookeeper.leaderport
  ZooKeeper用来选择Leader的端口,默认: 3888

hbase.zookeeper.property.initLimit
  ZooKeeper的zoo.conf中的配置。 初始化synchronization阶段的ticks数量限制。默认: 10

hbase.zookeeper.property.syncLimit
  ZooKeeper的zoo.conf中的配置。 发送一个请求到获得承认之间的ticks的数量限制,默认: 5

hbase.zookeeper.property.dataDir
  ZooKeeper的zoo.conf中的配置。 快照的存储位置,默认: ${hbase.tmp.dir}/zookeeper

hbase.zookeeper.property.clientPort
  ZooKeeper的zoo.conf中的配置。 客户端连接的端口,默认: 2181

hbase.zookeeper.property.maxClientCnxns
  ZooKeeper的zoo.conf中的配置。 ZooKeeper集群中的单个节点接受的单个Client(以IP区分)的请求的并发数。这个值可以调高一点,防止在单机和伪分布式模式中出问题。默认: 2000

hbase.rest.port
  HBase REST server的端口,默认: 8080

hbase.rest.readonly
  定义REST server的运行模式。可以设置成如下的值: false: 所有的HTTP请求都是被允许的 - GET/PUT/POST/DELETE. true:只有GET请求是被允许的。默认: false


zookeeper.session.timeout
  默认值3分钟(180000ms)。RegionServer与Zookeeper间的连接超时时间。当超时时间到后,ReigonServer会 被Zookeeper从RS集群清单中移除,HMaster收到移除通知后,会对这台server负责的regions重新balance,让其他存活的 RegionServer接管.
  调优:这个timeout决定了RegionServer是否能够及时的failover。设置成1分钟或更低,可以减少因等待超时而被延长的failover时间。
  不过需要注意的是,对于一些Online应用,RegionServer的宕机到恢复时间本身就很短的(网络闪断,crash等故障,运维可快速介入), 如果调低timeout时间,会得不偿失。因为当ReigonServer被正式从RS集群中移除时,HMaster就开始做balance了,当故障的 RS快速恢复后,这个balance动作是毫无意义的,反而会使负载不均匀,给RS带来更多负担。

hbase.regionserver.handler.count
  默认值10。RegionServer的请求处理IO线程数。
  调优:这个参数的调优与内存息息相关。较少的IO线程,适用于处理单次请求内存消耗较高的Big PUT场景(大容量单次PUT或设置了较大cache的scan,均属于Big PUT)或ReigonServer的内存比较紧张的场景。
  较多的IO线程,适用于单次请求内存消耗低,TPS要求非常高的场景。这里需要注意的是如果server的region数量很少,大量的请求都落在一个region上,因快速充满memstore触发flush导致的读写锁会影响全局TPS,不是IO线程数越高越好。

hbase.hregion.max.filesize
  默认值256M。在当前ReigonServer上单个Reigon的大小,单个Region超过指定值时,这个Region会被自动split成更小的region。
  调优:小region对split和compaction友好,因为拆分region或compact小region里的storefile速度很快,内存占用低。缺点是split和compaction会很频繁。
  特别是数量较多的小region不停地split, compaction,会使响应时间波动很大,region数量太多不仅给管理上带来麻烦,甚至引发一些Hbase的bug。
一般512以下的都算小region。
  大region,则不太适合经常split和compaction,因为做一次compact和split会产生较长时间的停顿,对应用的读写性能冲击非常大。此外,大region意味着较大的storefile,compaction时对内存也是一个挑战。
  当然,大region还是有其用武之地,你只要在某个访问量低峰的时间点统一做compact和split,大region就可以发挥优势了,毕竟它能保证绝大多数时间平稳的读写性能。
  compaction是无法避免的,split倒是可以从自动调整为手动。只要通过将这个参数值调大到某个很难达到的值,比如100G,就可以间接禁用自动split(RegionServer不会对未到达100G的region做split)。
  内存方面,小region在设置memstore的大小值上比较灵活,大region则过大过小都不行,过大会导致flush时app的IO wait增高,过小则因store file过多读性能降低。

hbase.regionserver.global.memstore.upperLimit/lowerLimit
  默认值。0.4/0.35
  upperlimit说明:hbase.hregion.memstore.flush.size这个参数的作用是 当单个memstore达到指定值时,flush该memstore。但是,一台ReigonServer可能有成百上千个memstore,每个 memstore也许未达到flush.size,jvm的heap就不够用了。该参数就是为了限制memstores占用的总内存。
  当ReigonServer内所有的memstore所占用的内存综合达到heap的40%时,HBase会强制block所有的更新并flush这些memstore以释放所有memstore占用的内存。
  lowerLimit说明: 同upperLimit,只不过当全局memstore的内存达到35%时,它不会flush所有的memstore,它会找一些内存占用较大的 memstore,个别flush,当然更新还是会被block。lowerLimit算是一个在全局flush前的补救措施。可以想象一下,如果 memstore需要在一段时间内全部flush,且这段时间内无法接受写请求,对HBase集群的性能影响是很大的。
  这是一个Heap内存保护参数,默认值已经能适用大多数场景。它的调整一般是为了配合某些专属优化,比如读密集型应用,将读缓存开大,降低该值,腾出更多内存给其他模块使用。
  这个参数会给使用者带来什么影响?比如,10G内存,100个region,每个memstore 64M,假设每个region只有一个memstore,那么当100个memstore平均占用到50%左右时,就会达到lowerLimit的限制。 假设此时,其他memstore同样有很多的写请求进来。在那些大的region未flush完,就可能又超过了upperlimit,则所有 region都会被block,开始触发全局flush。

hfile.block.cache.size
  默认值0.2。storefile的读缓存占用Heap的大小百分比,0.2表示20%。该值直接影响数据读的性能。
  该值当然是越大越好,如果读比写少,开到0.4-0.5也没问题。如果读写较均衡,0.3左右。如果写比读多,果断 默认吧。设置这个值的时候,你同时要参考 hbase.regionserver.global.memstore.upperLimit ,该值是 memstore占heap的最大百分比,两个参数一个影响读,一个影响写。如果两值加起来超过80-90%,会有OOM的风险,谨慎设置。

hbase.hstore.blockingStoreFiles
  默认值7。在compaction时,如果一个Store(Coulmn Family)内有超过7个storefile需要合并,则block所有的写请求,进行flush,限制storefile数量增长过快。
  block请求会影响当前region的读写性能,将值设为单个region可以支撑的最大store file数量会是个不错的选择。最大storefile数量可通过region size/memstore size来计算。如果你将region size设为无限大,那么你需要预估一个region可能产生的最大storefile数。

hbase.hregion.memstore.flush.size
  每次update之后会检查此region memstore是否达到这个大小,达到之后就会请求flush。默认值为64MB

hbase.hregion.memstore.block.multiplier
  默认值2。当一个region里的memstore超过hbase.hregion.memstore.flush.size*hbase.hregion.memstore.block.multiplier的大小时,block该 region的所有请求,进行flush,释放内存。虽然我们设置了memstore的总大小,比如64M,但想象一下,在最后63.9M的时候,我 Put了一个100M的数据或写请求量暴增,最后一秒钟put了1万次,此时memstore的大小会瞬间暴涨到超过预期的memstore.size。 这个参数的作用是当memstore的大小增至超过memstore.size时,block所有请求,遏制风险进一步扩大。
  这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景(不包括异常)不会出现突发写或写的量可控,那么保持默认值即可。如果正常情况下,你的写量 就会经常暴增,那么你应该调大这个倍数并调整其他参数值,比如hfile.block.cache.sizehbase.regionserver.global.memstore.upperLimit/lowerLimit,以预留更多内存,防止HBase server OOM。

】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇【Hbase】hbase入门使用教程 下一篇单机模式启动Hbase失败

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目