Hbase­优化方案

1、预分区设计

    真正存储数据的是region要维护一个区间段的rowkey      startRow~endRowkey

    -》手动设置预分区
    create ‘user_p‘,‘info‘,‘partition‘,SPLITS => [‘101‘,‘102‘,‘103‘,‘104‘]
    存在-∞ +∞
    第一个分区 -∞ ~ 101
    第二个分区 101~102
    第三个分区 102~103
    第四个分区 103~104
    第五个分区 104 ~ +∞

    -》生成16进制序列预分区
    create ‘user_p2‘,‘info‘,‘partition‘,{NUMREGIONS => 15,SPLITALGO => ‘HexStringSplit‘}

    -》按照文件中设置的规则设置预分区
    create ‘user_p4‘,‘partition‘,SPLITS_FILE => ‘splits.txt‘

附:splits.txt

a1
b2
c3
d4

2、rowkey设计

    一条数据的唯一标识是rowkey,此rowkey存储在哪个分区取决于属于哪个预分区内。
    为什么要设计rowkey?数据倾斜
    为了防止出现数据倾斜
    (1)生成随机数/hash/散列值
    例如:rowkey是101 变成:dd21231dqwdqd123131d112131
    102 变成:wqdqdq212131dqdwqwdqdw1d21

    (2)字符串反转
    2018120800011 1100080218102
    2018120800012 2100080218102

    (3)字符串拼接
    2018120800011_a12e
    2018120800012_odd12c
    101~105 105~100000

3、HBase优化

    (1)内存优化
    一般分配70%内存给Hbase的java堆
    不建议分配非常大的堆内存
    一般设置为 16~48G内存即可
    设置:export HADOOP_PORTMAP_OPTS="-Xmx512m $HADOOP_PORTMAP_OPTS"
    注意:etc/hadoop下 hadoop-env.sh

    (2)基础优化
    -》优化DataNode
    最大文件打开数
    hdfs-site.xml
    属性:dfs.datanode.max.transfer.threads
    默认值:4096 设置大于4096

    -》优化延迟高的数据操作等待时间
    hdfs-site.xml
    属性:dfs.image.transfer.timeout
    默认:60000毫秒
    调大

    -》数据写入效率
    压缩
    属性:mapreduce.map.output.compress
    值:org.apache.hadoop.io.compress.GzipCodec

    -》优化Hstore的文件大小
    属性:hbase.hregion.max.filesize
    默认值:10GB
    调小

原文地址:https://www.cnblogs.com/areyouready/p/10125388.html

时间: 2024-10-09 23:52:11

Hbase­优化方案的相关文章

针对MySQL大表优化方案

详解MySQL大表优化方案 (1).字段 (2).索引 (3).规范查询SQL (4).存储引擎 (5).mysql配置参数优化 (6).mysql读写分离 (7).分区和分表 单表优化: 当单表的数据不是一直在暴增,不建议使用拆分,拆分会带来逻辑,部署,运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的.而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量 (1).字段 l 尽量使用TINYINT.SMALLINT

mysql 性能优化方案 (转)

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

网易视频云:HBase优化实战

网易视频云是网易倾力打造的一款基于云计算的分布式多媒体处理集群和专业音视频技术,提供稳定流畅.低时延.高并发的视频直播.录制.存储.转码及点播等音视频的PAAS服务,在线教育.远程医疗.娱乐秀场.在线金融等各行业及企业用户只需经过简单的开发即可打造在线音视频平台.现在,网易视频云的技术专家给大家分享一则技术文:HBase优化实战. 背景 Datastream一直以来在使用HBase分流日志,每天的数据量很大,日均大概在80亿条,10TB的数据.对于像Datastream这种数据量巨大.对写入要求

ES+Hbase对接方案概述

方案背景 Hbase的索引方案有很多,越来越多的人开始选择ES+Hbase的方案,其实该方案并没有想象中那么完美,ES并发低,同时查询速度相对Hbase也慢很多,那为什么会选择他呢,它的写入比较快,如果一个宽表需要建20个索引,在数据导入时,hbase每秒导入20W,那么ES压力就是每秒400W,solr和hindex都不能解决该问题. 所以对并发高的业务场景,还是使用华为HIndex这种方案,也可以混合使用 方案描述 ES+Hbase对接大致有两种方式,需要根据当前的业务场景做相应的选择, 方

然后我就去网上搜索“如何写网站SEO优化方案

这段时间属于网站的策划阶段,网站的定位.网站的布局以及关键词的选定 首先,需要确定自己建设一个什么样的网站.,我们当然是企业网站,然后,确定网站的关键词,确定关键词可以参考自己的竞争对手,也可以通过关键词挖掘工具选择合适的关键词,选出的关键词一定符合用户的搜索习惯,并且有一定的搜索量.最好是能够有明确转化意向的关键词. 关键词确定后,需要设计网站的整体布局,比如说首页应该放置哪些板块,你的客户最关心的是哪些内容?最想了解的是哪些信息?,这时就需要对你的客户进行分析了,比如我们做的是工业品,客户比

百度没出新算法之前这种最好的的优化方案

百度没出新算法之前这种最好的的优化方案:看到这个标题我相信大家很多人都会呲之以鼻的因为都自己心里感觉这人太装B了吧,谁敢说他的优化方案是最厉害的,首先这只是我感觉的. 自从绿萝算法更新以后咱们这个时候再去更新一篇文章,百度就不会去再从他原先有的数据库里面寻找了,因为这样的话太麻烦太坑爹了,就像一个我们的汶川大地震后的拯救工作太浩大了,就和研究中心里面说的一样,对一篇文章中,抓住10个中心重点就可以判断文章的原创性,伪原创需要的就是知道文章中心重点词,打个比方就像真猴子和假猴子一样万变不离其宗,伪

[转] 钉钉的H5性能优化方案

对于一个H5的产品,功能无疑很重要,但是性能同样是用户体验中不可或缺的一环.原本H5的渲染性能就不及native的app,如果不把性能优化做起来,将极大地影响用户使用产品的积极性. 用户感受 当用户能够在1-2秒内打开H5页面,看到信息的展示,或者能够开始进行下一步的操作,用户会感觉速度还好,可以接受:而页面如果在2-5秒后才进入可用的状态,用户的耐心会逐渐丧失:而如果一个界面超过5秒甚至更久才能显示出来,这对用户来说基本是无法忍受的,也许有一部分用户会退出重新进入,但更多的用户会直接放弃使用.

if-else嵌套过多时的优化方案

//if-else嵌套过多时的优化方案 在垒代码的时候经常会遇到 if-else 的嵌套判断,就是下一个判断依赖于上一个判断的结果,其基本的表现形式为if(){//first judge if(){//second //do something }else{ if(){//third //do something }else{ //do something } }}else{ //do something} 当嵌套的个数不是太多的时候,看上去也不是太乱,顺着每个判断写下来也不会太困难,但是当嵌套

MySQL大表优化方案总结

今天看了一篇mysql大表优化方案的文章( https://mp.weixin.qq.com/s/qM6MAd_ZcrHEapz0D4nSrA ),应该说是属于科普级别的,但是技术肯定是要先大概理解了才能再深入的,深入的话推荐看 MySQL技术内幕:InnoDB存储引擎(第2版) 总结一下大表的优化方案就是: 分库分表加分区 各个层级加缓存(mysql层是缓存调参) 字段索引要优化 SQL语句别复杂 读写分离大法好 升级硬件是王道