hbase 授权

回复

sun1985810 发起了问题 • 1 人关注 • 0 个回复 • 136 次浏览 • 2019-01-07 16:32 • 来自相关话题

HBASE针对spark的插件,有谁用过

回复

tong 发起了问题 • 1 人关注 • 0 个回复 • 132 次浏览 • 2019-01-07 13:54 • 来自相关话题

2018 HBase技术总结

hbasegroup 发表了文章 • 0 个评论 • 1282 次浏览 • 2019-01-05 13:02 • 来自相关话题

HBase 是一个高性能,并且支持无限水平扩展的在线数据库,其存储计算分离的特性非常好地适应了目前的趋势,并且在国内大公司内都被广泛地应用,具有非常好的生态,是构建大数据系统的不二选择。
 
HBase 是一个高性能,并且支持无限水平扩展的在线数据库,其存储计算分离的特性非常好地适应了目前的趋势,并且在国内大公司内都被广泛地应用,具有非常好的生态,是构建大数据系统的不二选择。
 

HBase Rowkey排序

hbasegroup 回复了问题 • 2 人关注 • 1 个回复 • 102 次浏览 • 2019-01-04 14:42 • 来自相关话题

hbase 集群的region 数量达到上限,该怎么处理呢?

zb 回复了问题 • 3 人关注 • 1 个回复 • 225 次浏览 • 2019-01-02 17:28 • 来自相关话题

2018年HBase生态社群画像 +最全资料汇总下载

过往记忆 发表了文章 • 0 个评论 • 275 次浏览 • 2019-01-02 16:39 • 来自相关话题

钉群直播全部资料下载:下载
 








9届Meetup视频和PPT下载:下载






《58HBase平台实践和应用 -平台建设篇》
何良均/张祥 58同城
查看
《HBase Rowkey 设计指南》
吴阳平 阿里巴巴HBase业务架 构师
查看
《HBase 2.0之修复工具HBCK2 运维指南》
田竞云 小米HBase Committer
查看
《从NoSQL到NewSQL,凤 凰涅槃成就Phoenix》
张赟 阿里巴巴 Phoenix Committer
查看
《消灭毛刺!HBase2.0全链路offheap效果拔群》
杨文龙 阿里巴巴技术专家 HBase Committer&HBase PMC
查看
《解读HBase2.0新功能 AssignmentManagerV2》
杨文龙 阿里巴巴技术专家 HBase Committer&Hbase PMC
查看
《深入解读HBase2.0新功能 高可用读Region Replica》
杨文龙 阿里巴巴技术专家 HBase Committer&Hbase PMC
查看
《HBase最佳实践-读性能 优化策略》
范欣欣 网易 HBase 资深开发工程师
查看
《HBase2.0新特性之In- Memory Compaction》
陆豪 阿里巴巴技术专家
查看
《HBase Coprocessor的实现与应用》
叶铿 烽火 大数据平台负责人
查看
《HBase实战之MOB使用指南》
查看
《HBase在新能源汽车监控系统中的应用》
颜禹 重庆博尼施CTO
查看
《HBase在爱奇艺的应用实践》
郑昊南 爱奇艺 资深研发工程师
查看
《HBase在滴滴出行的应用场景和最佳实践》
李扬 滴滴
查看
《HBase在人工智能场景的使用》
吴阳平 阿里HBase业务架构师
查看
《车纷享:基于阿里云 HBase构建车联网平台实践》
查看
《HBase基本知识介绍及典型 案例分析》
吴阳平 阿里HBase业务架构师
查看























HBase生态+Spark社区 云栖号:https://yq.aliyun.com/teams/382
中国 HBase 技术社区网站:http://hbase.group 查看全部
d31742f41fe14a640fcc4b3b527f04985e00dd2c.png

f77a3002db4fae240559d8cc3fe8b92c64ed4937.png

26e49202a039fe1e3eb1adf6470f07d87716769f.png

40cc47db9c4e7f674843066f3ec2633979d75a72.png

388942cd244f470b6f655d62d3f576757dbff8af.png

a65ddc521b8fadf40f57094b44a917a9179ef60f.png

0f1570d0d4240064e6de0815d4441e0c61d988b5.png

27d414dbdcbb2d680461513a5b255b417b3fc70c.png

钉群直播全部资料下载:下载
 
e774dbc14e69ff6895ec38b329b89a30650882ec.png

2200687ad1a586fd54358ae539511f8c0ea8c15c.png

9届Meetup视频和PPT下载:下载

0ae287f151e65e060e273905f916f76805e6f5b4.png


《58HBase平台实践和应用 -平台建设篇》
何良均/张祥 58同城
查看
《HBase Rowkey 设计指南》
吴阳平 阿里巴巴HBase业务架 构师
查看
《HBase 2.0之修复工具HBCK2 运维指南》
田竞云 小米HBase Committer
查看
《从NoSQL到NewSQL,凤 凰涅槃成就Phoenix》
张赟 阿里巴巴 Phoenix Committer
查看
《消灭毛刺!HBase2.0全链路offheap效果拔群》
杨文龙 阿里巴巴技术专家 HBase Committer&HBase PMC
查看
《解读HBase2.0新功能 AssignmentManagerV2》
杨文龙 阿里巴巴技术专家 HBase Committer&Hbase PMC
查看
《深入解读HBase2.0新功能 高可用读Region Replica》
杨文龙 阿里巴巴技术专家 HBase Committer&Hbase PMC
查看
《HBase最佳实践-读性能 优化策略》
范欣欣 网易 HBase 资深开发工程师
查看
《HBase2.0新特性之In- Memory Compaction》
陆豪 阿里巴巴技术专家
查看
《HBase Coprocessor的实现与应用》
叶铿 烽火 大数据平台负责人
查看
《HBase实战之MOB使用指南》
查看
《HBase在新能源汽车监控系统中的应用》
颜禹 重庆博尼施CTO
查看
《HBase在爱奇艺的应用实践》
郑昊南 爱奇艺 资深研发工程师
查看
《HBase在滴滴出行的应用场景和最佳实践》
李扬 滴滴
查看
《HBase在人工智能场景的使用》
吴阳平 阿里HBase业务架构师
查看
《车纷享:基于阿里云 HBase构建车联网平台实践》
查看
《HBase基本知识介绍及典型 案例分析》
吴阳平 阿里HBase业务架构师
查看

9daceab1cd0cfec37d5122c10d424251cddaea94.png

89d798bac2565ae1ea89845a5f2b34f2b4555443.png

4a5346ef14879ecd66262f0f6bfbf9d178a1e6da.png

5a613c85a5a65c4777f339ad0a2a6700c3cced98.png


5d6d269caa4deb5ea85092c36ac5aa461ae8d6b2.png


HBase生态+Spark社区 云栖号:https://yq.aliyun.com/teams/382
中国 HBase 技术社区网站:http://hbase.group

hbase 启动rs group后balance失败

过往记忆 回复了问题 • 2 人关注 • 1 个回复 • 249 次浏览 • 2018-12-29 17:48 • 来自相关话题

snapshot 做hbase表迁移,报错A clone should not have regions to restore

匿名用户 回复了问题 • 4 人关注 • 3 个回复 • 385 次浏览 • 2018-12-29 15:22 • 来自相关话题

HBase疑难杂症填坑指南

hbasegroup 发表了文章 • 1 个评论 • 633 次浏览 • 2018-12-28 18:06 • 来自相关话题

1.如何避免HBase写入过快引起的各种问题?
首先我们简单回顾下整个写入流程client api ==> RPC ==> server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to filesystem



整个写入流程从客户端调用API开始,数据会通过protobuf编码成一个请求,通过socket实现的IPC模块被送达server的RPC队列中。最后由负责处理RPC的handler取出请求完成写入操作。写入会先写WAL文件,然后再写一份到内存中,也就是memstore模块,当满足条件时,memstore才会被flush到底层文件系统,形成HFile。
当写入过快时会遇见什么问题?
写入过快时,memstore的水位会马上被推高。
你可能会看到以下类似日志:RegionTooBusyException: Above memstore limit, regionName=xxxxx ...这个是Region的memstore占用内存大小超过正常的4倍,这时候会抛异常,写入请求会被拒绝,客户端开始重试请求。当达到128M的时候会触发flush memstore,当达到128M * 4还没法触发flush时候会抛异常来拒绝写入。两个相关参数的默认值如下:hbase.hregion.memstore.flush.size=128M
hbase.hregion.memstore.block.multiplier=4或者这样的日志:regionserver.MemStoreFlusher: Blocking updates on hbase.example.host.com,16020,1522286703886: the global memstore size 1.3 G is >= than blocking 1.3 G size
regionserver.MemStoreFlusher: Memstore is above high water mark and block 528ms这是所有region的memstore内存总和开销超过配置上限,默认是配置heap的40%,这会导致写入被阻塞。目的是等待flush的线程把内存里的数据flush下去,否则继续允许写入memestore会把内存写爆hbase.regionserver.global.memstore.upperLimit=0.4 # 较旧版本,新版本兼容
hbase.regionserver.global.memstore.size=0.4 # 新版本当写入请求由于达到memstore上限而被阻塞,队列会开始积压,如果运气不好最后会导致OOM,你可能会发现JVM由于OOM crash或者看到如下类似日志:ipc.RpcServer: /192.168.x.x:16020 is unable to read call parameter from client 10.47.x.x
java.lang.OutOfMemoryError: Java heap spaceHBase这里我认为有个很不好的设计,捕获了OOM异常却没有终止进程。这时候进程可能已经没法正常运行下去了,你还会在日志里发现很多其它线程也抛OOM异常。比如stop可能根本stop不了,RS可能会处于一种僵死状态。
如何避免RS OOM?
一种是加快flush速度:hbase.hstore.blockingWaitTime = 90000 ms
hbase.hstore.flusher.count = 2
hbase.hstore.blockingStoreFiles = 10当达到hbase.hstore.blockingStoreFiles配置上限时,会导致flush阻塞等到compaction工作完成。阻塞时间是hbase.hstore.blockingWaitTime,可以改小这个时间。hbase.hstore.flusher.count可以根据机器型号去配置,可惜这个数量不会根据写压力去动态调整,配多了,非导入数据多场景也没用,改配置还得重启。
同样的道理,如果flush加快,意味这compaction也要跟上,不然文件会越来越多,这样scan性能会下降,开销也会增大。hbase.regionserver.thread.compaction.small = 1
hbase.regionserver.thread.compaction.large = 1增加compaction线程会增加CPU和带宽开销,可能会影响正常的请求。如果不是导入数据,一般而言是够了。好在这个配置在云HBase内是可以动态调整的,不需要重启。
上述配置都需要人工干预,如果干预不及时server可能已经OOM了,这时候有没有更好的控制方法?hbase.ipc.server.max.callqueue.size = 1024 * 1024 * 1024 # 1G直接限制队列堆积的大小。当堆积到一定程度后,事实上后面的请求等不到server端处理完,可能客户端先超时了。并且一直堆积下去会导致OOM,1G的默认配置需要相对大内存的型号。当达到queue上限,客户端会收到CallQueueTooBigException 然后自动重试。通过这个可以防止写入过快时候把server端写爆,有一定反压作用。线上使用这个在一些小型号稳定性控制上效果不错。
填坑链接:如何避免HBase写入过快引起的各种问题 查看全部
1.如何避免HBase写入过快引起的各种问题?
首先我们简单回顾下整个写入流程
client api ==> RPC ==> server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to filesystem
1.png

整个写入流程从客户端调用API开始,数据会通过protobuf编码成一个请求,通过socket实现的IPC模块被送达server的RPC队列中。最后由负责处理RPC的handler取出请求完成写入操作。写入会先写WAL文件,然后再写一份到内存中,也就是memstore模块,当满足条件时,memstore才会被flush到底层文件系统,形成HFile。
当写入过快时会遇见什么问题?
写入过快时,memstore的水位会马上被推高。
你可能会看到以下类似日志:
RegionTooBusyException: Above memstore limit, regionName=xxxxx ...
这个是Region的memstore占用内存大小超过正常的4倍,这时候会抛异常,写入请求会被拒绝,客户端开始重试请求。当达到128M的时候会触发flush memstore,当达到128M * 4还没法触发flush时候会抛异常来拒绝写入。两个相关参数的默认值如下:
hbase.hregion.memstore.flush.size=128M 
hbase.hregion.memstore.block.multiplier=4
或者这样的日志:
regionserver.MemStoreFlusher: Blocking updates on hbase.example.host.com,16020,1522286703886: the global memstore size 1.3 G is >= than blocking 1.3 G size 
regionserver.MemStoreFlusher: Memstore is above high water mark and block 528ms
这是所有region的memstore内存总和开销超过配置上限,默认是配置heap的40%,这会导致写入被阻塞。目的是等待flush的线程把内存里的数据flush下去,否则继续允许写入memestore会把内存写爆
hbase.regionserver.global.memstore.upperLimit=0.4 # 较旧版本,新版本兼容 
hbase.regionserver.global.memstore.size=0.4 # 新版本
当写入请求由于达到memstore上限而被阻塞,队列会开始积压,如果运气不好最后会导致OOM,你可能会发现JVM由于OOM crash或者看到如下类似日志:
ipc.RpcServer: /192.168.x.x:16020 is unable to read call parameter from client 10.47.x.x 
java.lang.OutOfMemoryError: Java heap space
HBase这里我认为有个很不好的设计,捕获了OOM异常却没有终止进程。这时候进程可能已经没法正常运行下去了,你还会在日志里发现很多其它线程也抛OOM异常。比如stop可能根本stop不了,RS可能会处于一种僵死状态。
如何避免RS OOM?
一种是加快flush速度
hbase.hstore.blockingWaitTime = 90000 ms 
hbase.hstore.flusher.count = 2
hbase.hstore.blockingStoreFiles = 10
当达到hbase.hstore.blockingStoreFiles配置上限时,会导致flush阻塞等到compaction工作完成。阻塞时间是hbase.hstore.blockingWaitTime,可以改小这个时间。hbase.hstore.flusher.count可以根据机器型号去配置,可惜这个数量不会根据写压力去动态调整,配多了,非导入数据多场景也没用,改配置还得重启。
同样的道理,如果flush加快,意味这compaction也要跟上,不然文件会越来越多,这样scan性能会下降,开销也会增大。
hbase.regionserver.thread.compaction.small = 1 
hbase.regionserver.thread.compaction.large = 1
增加compaction线程会增加CPU和带宽开销,可能会影响正常的请求。如果不是导入数据,一般而言是够了。好在这个配置在云HBase内是可以动态调整的,不需要重启。
上述配置都需要人工干预,如果干预不及时server可能已经OOM了,这时候有没有更好的控制方法?
hbase.ipc.server.max.callqueue.size = 1024 * 1024 * 1024 # 1G
直接限制队列堆积的大小。当堆积到一定程度后,事实上后面的请求等不到server端处理完,可能客户端先超时了。并且一直堆积下去会导致OOM,1G的默认配置需要相对大内存的型号。当达到queue上限,客户端会收到CallQueueTooBigException 然后自动重试。通过这个可以防止写入过快时候把server端写爆,有一定反压作用。线上使用这个在一些小型号稳定性控制上效果不错。
填坑链接:如何避免HBase写入过快引起的各种问题

Hbase 写入过快OOM, 导致整个hbase挂掉.

回复

Nick 回复了问题 • 1 人关注 • 1 个回复 • 239 次浏览 • 2018-12-27 14:41 • 来自相关话题

hbase replication

回复

zhangleiHbase 发起了问题 • 1 人关注 • 0 个回复 • 122 次浏览 • 2018-12-26 19:42 • 来自相关话题

获取hbase表结构

beyond 回复了问题 • 2 人关注 • 1 个回复 • 186 次浏览 • 2018-12-26 12:28 • 来自相关话题

hbase 2.0 procedure卡住了

回复

zxpns18 发起了问题 • 1 人关注 • 0 个回复 • 116 次浏览 • 2018-12-21 10:56 • 来自相关话题

如何有效防止hbase被攻击

anbbrr 回复了问题 • 2 人关注 • 2 个回复 • 249 次浏览 • 2018-12-20 11:26 • 来自相关话题

多线程写入hbase

陈坤 回复了问题 • 3 人关注 • 3 个回复 • 289 次浏览 • 2018-12-18 16:54 • 来自相关话题

SnapshotScanMR的用法

回复

小勇 发起了问题 • 1 人关注 • 0 个回复 • 165 次浏览 • 2018-12-16 00:03 • 来自相关话题

hbase 日志洪灾 滚动报“requested wrong row”

回复

xint1ao 发起了问题 • 1 人关注 • 0 个回复 • 157 次浏览 • 2018-12-15 22:29 • 来自相关话题

hbase 2.0 启用MOB特性 regionserver出现卡住

WangYQ 回复了问题 • 2 人关注 • 1 个回复 • 258 次浏览 • 2018-12-14 13:26 • 来自相关话题


中国HBase技术社区微信公众号:
hbasegroup

欢迎加入HBase生态+Spark社区钉钉大群