`

Hbase万亿级存储性能优化总结

阅读更多
转:http://blog.csdn.net/odailidong/article/details/41794403

背景
      hbase主集群在生产环境已稳定运行有1年半时间,最大的单表region数已达7200多个,每天新增入库量就有百亿条,对hbase的认识经历了懵懂到熟的过程。为了应对业务数据的压力,hbase入库也由最初的单机多线程升级为有容灾机制的分布式入库,为及早发现集群中的问题,还开发了一套对hbase集群服务和应用全面监控的报警系统。总结下hbase优化(针对0.94版本)方面的一些经验也算对这两年hbase工作的一个描述。

服务端
1.hbase.regionserver.handler.count:rpc请求的线程数量,默认值是10,生产环境建议使用100,也不是越大越好,特别是当请求内容很大的时候,比如scan/put几M的数据,会占用过多的内存,有可能导致频繁的GC,甚至出现内存溢出。

2.hbase.master.distributed.log.splitting:默认值为true,建议设为false。关闭hbase的分布式日志切割,在log需要replay时,由master来负责重放

3.hbase.regionserver.hlog.splitlog.writer.threads:默认值是3,建议设为10,日志切割所用的线程数

4.hbase.snapshot.enabled:快照功能,默认是false(不开启),建议设为true,特别是对某些关键的表,定时用快照做备份是一个不错的选择。

5.hbase.hregion.max.filesize:默认是10G, 如果任何一个column familiy里的StoreFile超过这个值, 那么这个Region会一分为二,因为region分裂会有短暂的region下线时间(通常在5s以内),为减少对业务端的影响,建议手动定时分裂,可以设置为60G。

6.hbase.hregion.majorcompaction:hbase的region主合并的间隔时间,默认为1天,建议设置为0,禁止自动的major主合并,major合并会把一个store下所有的storefile重写为一个storefile文件,在合并过程中还会把有删除标识的数据删除,在生产集群中,主合并能持续数小时之久,为减少对业务的影响,建议在业务低峰期进行手动或者通过脚本或者api定期进行major合并。

7.hbase.hregion.memstore.flush.size:默认值128M,单位字节,一旦有memstore超过该值将被flush,如果regionserver的jvm内存比较充足(16G以上),可以调整为256M。

8.hbase.hregion.memstore.block.multiplier:默认值2,如果一个memstore的内存大小已经超过hbase.hregion.memstore.flush.size *  hbase.hregion.memstore.block.multiplier,则会阻塞该memstore的写操作,为避免阻塞,建议设置为5,如果太大,则会有OOM的风险。如果在regionserver日志中出现"Blocking updates for '<threadName>' on region <regionName> : memstore size <多少M> is >= than blocking <多少M> size"的信息时,说明这个值该调整了。

9.hbase.hstore.compaction.min:默认值为3,如果任何一个store里的storefile总数超过该值,会触发默认的合并操作,可以设置5~8,在手动的定期major compact中进行storefile文件的合并,减少合并的次数,不过这会延长合并的时间,以前的对应参数为hbase.hstore.compactionThreshold。

10.hbase.hstore.compaction.max:默认值为10,一次最多合并多少个storefile,避免OOM。

11.hbase.hstore.blockingStoreFiles:默认为7,如果任何一个store(非.META.表里的store)的storefile的文件数大于该值,则在flush memstore前先进行split或者compact,同时把该region添加到flushQueue,延时刷新,这期间会阻塞写操作直到compact完成或者超过hbase.hstore.blockingWaitTime(默认90s)配置的时间,可以设置为30,避免memstore不及时flush。当regionserver运行日志中出现大量的“Region <regionName> has too many store files; delaying flush up to 90000ms"时,说明这个值需要调整了

12.hbase.regionserver.global.memstore.upperLimit:默认值0.4,regionserver所有memstore占用内存在总内存中的upper比例,当达到该值,则会从整个regionserver中找出最需要flush的region进行flush,直到总内存比例降到该数以下,采用默认值即可。

13.hbase.regionserver.global.memstore.lowerLimit:默认值0.35,采用默认值即可。

14.hbase.regionserver.thread.compaction.small:默认值为1,regionserver做Minor Compaction时线程池里线程数目,可以设置为5。

15.hbase.regionserver.thread.compaction.large:默认值为1,regionserver做Major Compaction时线程池里线程数目,可以设置为8。

16.hbase.regionserver.lease.period:默认值60000(60s),客户端连接regionserver的租约超时时间,客户端必须在这个时间内汇报,否则则认为客户端已死掉。这个最好根据实际业务情况进行调整

17.hfile.block.cache.size:默认值0.25,regionserver的block cache的内存大小限制,在偏向读的业务中,可以适当调大该值,需要注意的是hbase.regionserver.global.memstore.upperLimit的值和hfile.block.cache.size的值之和必须小于0.8。

18.dfs.socket.timeout:默认值60000(60s),建议根据实际regionserver的日志监控发现了异常进行合理的设置,比如我们设为900000,这个参数的修改需要同时更改hdfs-site.xml

19.dfs.datanode.socket.write.timeout:默认480000(480s),有时regionserver做合并时,可能会出现datanode写超时的情况,480000 millis timeout while waiting for channel to be ready for write,这个参数的修改需要同时更改hdfs-site.xml

jvm和垃圾收集参数:
export HBASE_REGIONSERVER_OPTS="-Xms36g -Xmx36g -Xmn1g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=15 -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/data/logs/gc-$(hostname)-hbase.log"

由于我们服务器内存较大(96G),我们给一部分regionserver的jvm内存开到64G,到现在为止,还没有发生过一次full gc,hbase在内存使用控制方面确实下了不少功夫,比如各种blockcache的实现,细心的同学可以看源码。

Client端
1.hbase.client.write.buffer:默认为2M,写缓存大小,推荐设置为5M,单位是字节,当然越大占用的内存越多,此外测试过设为10M下的入库性能,反而没有5M好
2.hbase.client.pause:默认是1000(1s),如果你希望低延时的读或者写,建议设为200,这个值通常用于失败重试,region寻找等
3.hbase.client.retries.number:默认值是10,客户端最多重试次数,可以设为11,结合上面的参数,共重试时间71s
4.hbase.ipc.client.tcpnodelay:默认是false,建议设为true,关闭消息缓冲
5.hbase.client.scanner.caching:scan缓存,默认为1,避免占用过多的client和rs的内存,一般1000以内合理,如果一条数据太大,则应该设置一个较小的值,通常是设置业务需求的一次查询的数据条数
如果是扫描数据对下次查询没有帮助,则可以设置scan的setCacheBlocks为false,避免使用缓存;
6.table用完需关闭,关闭scanner
7.限定扫描范围:指定列簇或者指定要查询的列,指定startRow和endRow
8.使用Filter可大量减少网络消耗
9.通过Java多线程入库和查询,并控制超时时间。后面会共享下我的hbase单机多线程入库的代码
10.建表注意事项:
开启压缩
合理的设计rowkey
进行预分区
开启bloomfilter

zookeeper调优
1.zookeeper.session.timeout:默认值3分钟,不可配置太短,避免session超时,hbase停止服务,线上生产环境由于配置为1分钟,如果太长,当regionserver挂掉,zk还得等待这个超时时间(已有patch修复),从而导致master不能及时对region进行迁移。
2.zookeeper数量:建议5个或者7个节点。给每个zookeeper 4G左右的内存,最好有独立的磁盘。
3.hbase.zookeeper.property.maxClientCnxns:zk的最大连接数,默认为300,无需调整。
4.设置操作系统的swappiness为0,则在物理内存不够的情况下才会使用交换分区,避免GC回收时会花费更多的时间,当超过zk的session超时时间则会出现regionserver宕机的误报

hdfs调优
1.dfs.name.dir:namenode的数据存放地址,可以配置多个,位于不同的磁盘并配置一个nfs远程文件系统,这样namenode的数据可以有多个备份
2.dfs.namenode.handler.count:namenode节点RPC的处理线程数,默认为10,可以设置为60
3.dfs.datanode.handler.count:datanode节点RPC的处理线程数,默认为3,可以设置为30
4.dfs.datanode.max.xcievers:datanode同时处理文件的上限,默认为256,可以设置为8192

其它
列族名、column名、rowkey均会存储到hfile中,因此这几项在设计表结构时都尽量短些
regionserver的region数量不要过1000,过多的region会导致产生很多memstore,可能会导致内存溢出,也会增加major compact的耗时
分享到:
评论

相关推荐

    Hbase 二级索引方案

    Lily HBase Indexer 使用 SolrCloud 来存储 HBase 的索引数据,当 HBase 执行写 入、更新或删除操作时,Indexer 通过 HBase 的 replication 功能来把这些操作抽象成一系 列的 Event 事件,并用来保证写入 Solr 中的 ...

    论文研究-基于HBase的气象结构化数据查询优化.pdf

    首先,根据HBase存储特性设计表结构;然后,利用协处理器建立和维护辅助索引,将字段查询转化为对索引表的行键查询,使得HBase4M在具备HBase可扩展性、低延迟的特性上可以支持结构化气象数据的灵活查询。实验结果...

    HBase数据库检索性能优化策略

    HBase数据库是一个基于分布式的、面向列的、主要用于非结构化数据存储用途的开源数据库。其设计思路来源于Google的非开源数据库”BigTable”。HDFS为HBase提供底层存储支持,MapReduce为其提供计算能力,ZooKeeper为...

    面向HBase的大规模数据加载研究

    分布式数据库HBase在大规模数据加载中较传统关系型数据库有较大的优势但也存在很大的优化空间.基于Hadoop分布式平台搭建HBase环境,并优化自定义数据加载算法.首先,分析HBase底层数据存储,实验得出HBase自带数据加载...

    HBase性能优化案例分析

    HBase性能优化案例分析。HDFS设计的初衷是为了存储大文件(例如日志文件),面向批处理、顺序I/O的。然而架设在HDFS之上的HBase设计的初衷却是为了解决海量数据的随机读写的请求。把这两种设计初衷截然相反的组件怎么...

    HBase 数据库检索性能优化策略

     HBase 数据库是一个基于分布式的、面向列的、主要用于非结构化数据存储用途的开源数据库。其设计思路来源于 Google 的非开源数据库”BigTable”。  HDFS 为 HBase 提供底层存储支持,MapReduce 为其提供计算...

    HBase优化实战

    Datastream一直以来在使用HBase分流日志,每天的数据量很大,日均大概在80亿条,10TB的数据。对于像Datastream这种数据量巨大、对写入要求非常高,并且没有复杂查询需求的日志系统来说,选用HBase作为其数据存储平台...

    Kylin在贝壳的性能挑战和HBase优化实践

    Kylin从2017年开始作为贝壳公司级OLAP引擎对外提供...有两套HBase集群,30多个节点,Kylin每天的查询量最高2000+万。我们负责Kylin同事张如松在2018年KylinMeetup上分享过Kylin在贝壳的实践,当时每天最高请求量是 1

    基于HBase的海量GIS数据分布式处理实践

    系统优化了栅格数据的生成和存储过程,将海量栅格数据直接写入HBase存储、索引。同时,针对矢量空间数据的存储、索引与检索,提出了一种新的rowkey设计,既考虑经纬度,又考虑空间数据类型和属性,使得在按空间位置...

    Kudu分布式存储引擎

    课程分享——Kudu分布式存储引擎,完整版,附代码、课件。 课程亮点: 阐述了Kudu的产生背景和应用场景 ...总结性的阐述了Kudu的性能测试报告、报错解决方案、性能优化方案 帮助同学们掌握基础的Linux常用命令

    基于Hadoop的Apriori算法研究与优化

    为解决传统数据挖掘算法在大量数据处理时面临的内存占用、计算性能等方面的问题,基于Hadoop平台,应用HBase文件存储系统对海量数据分布式存储以及Map Reduce框架进行分布式计算,实现Apriori经典数据挖掘算法。...

    基于Hadoop的海量交易记录查询系统研究

    的存储特点,通过分析 HBase 的数据存储方式、Region 定位方式和写数据过程,提出了系统 设计的优化和改进建议。接着,对基于 Hadoop 的海量交易记录查询系统进行了设计和实现, 主要包括数据接入层、存储层和查询层...

    HBase在阿里搜索中的应用实践

    历史:阿里搜索于2010年开始使用HBase,从最早到目前已经有十余个版本。目前使用的版本是在社区版本的基础上经过大量优化而成。...角色:HBase是阿里搜索的核心存储系统,它和计算引擎紧密结合,主要服务搜索和推荐的业

    编程狂人第九期(2014-1-20)

    php性能优化 Java中的 equals() 和 hashCode() 契约 程序设计 IOS缓存机制详解 ios系类教程之用instruments来检验你的app Android 学习笔记之 SQLite基础用法 如何充分利用 Windows Phone 高清屏幕 【cocos2d-x 手...

    Doris:大型分布式KV存储系统

    多丽丝阿里巴巴的大型分布式云式KV存储系统。 发布日期:2013/5/21 Doris是阿里巴巴的技术产品之一多丽丝(Doris)的特征多租户像HBase一样可扩展。 支持大规模数据存储,并通过可扩展的服务器部署进行访问。 比...

    HadoopLearning:完整的大数据基础学习教程,包含最基础的centos,maven。大数据主要包含hdfs,mr,yarn,hbase,kafka,scala,sparkcore,sparkstreaming,sparksql。

    maven相关2,大数据教程2.1,hdfs教程2.1,mapreduce教程3,剩余编写HDFS入门,深入,Shell访问,Java API操作MapReduce入门,深入,编程基础,编程进阶,实战分析和训练Yarn入门,原理剖解和应用场景Hbase存储原理...

    大数据的存储管理技术.doc

    分布式文件系统的设计需要重点考虑可 扩展性、可靠性、性能优化、易用性及高效元数据管理等关键技术。 当前大数据领域中,分布式文件系统的使用主要以Hadoop HDFS为主。HDFS采用了冗余数据存储,增强了数据可靠性,...

Global site tag (gtag.js) - Google Analytics