惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - Franky
博客园 - 司徒正美
Microsoft Azure Blog
Microsoft Azure Blog
J
Java Code Geeks
The Cloudflare Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
The GitHub Blog
The GitHub Blog
Recent Announcements
Recent Announcements
Blog — PlanetScale
Blog — PlanetScale
G
Google Developers Blog
WordPress大学
WordPress大学
A
About on SuperTechFans
Hugging Face - Blog
Hugging Face - Blog
T
Tor Project blog
阮一峰的网络日志
阮一峰的网络日志
Recent Commits to openclaw:main
Recent Commits to openclaw:main
The Hacker News
The Hacker News
F
Full Disclosure
有赞技术团队
有赞技术团队
H
Help Net Security
Security Latest
Security Latest
P
Palo Alto Networks Blog
MyScale Blog
MyScale Blog
Simon Willison's Weblog
Simon Willison's Weblog
G
GRAHAM CLULEY
P
Privacy International News Feed
P
Proofpoint News Feed
Scott Helme
Scott Helme
V
Vulnerabilities – Threatpost
罗磊的独立博客
Y
Y Combinator Blog
云风的 BLOG
云风的 BLOG
aimingoo的专栏
aimingoo的专栏
Latest news
Latest news
Jina AI
Jina AI
Stack Overflow Blog
Stack Overflow Blog
C
Cyber Attacks, Cyber Crime and Cyber Security
Hacker News: Ask HN
Hacker News: Ask HN
爱范儿
爱范儿
T
Threat Research - Cisco Blogs
Last Week in AI
Last Week in AI
The Last Watchdog
The Last Watchdog
N
Netflix TechBlog - Medium
D
DataBreaches.Net
L
LINUX DO - 热门话题
Application and Cybersecurity Blog
Application and Cybersecurity Blog
L
Lohrmann on Cybersecurity
O
OpenAI News
S
SegmentFault 最新的问题
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC

博客园 - LixingTie

Git添加排除文件规则 [RabbitMQ+Python入门经典] 兔子和兔子窝 Win7强制删除文件 vim配置 Ubuntu部署HBase Ubuntu部署Zookeeper Ubuntu 12.04 Hadoop自动安装脚本 Ubuntu 12.04下安装Extmail 白话MongoDB(三) 白话MongoDB(二) 白话MongoDB(一) Paxos在大型系统中常见的应用场景 某分布式应用实践一致性哈希的一些问题 多IDC的数据分布设计(二) 多IDC的数据分布设计(一) Redis新的存储模式diskstore Redis容量及使用规划 Redis几个认识误区 一致性哈希(Consistent Hashing)
关于HBase的一些零碎事
LixingTie · 2011-07-27 · via 博客园 - LixingTie

随着Facebook使用HBase来构建实时消息系统,基于Hadoop的面向列存储的HBase持续升温。

目前稳定版本的HBase0.90.2只能基于Hadoop0.20.x系列版本,暂不支持最新的0.21.x。而且官方版本的Hadoop0.20.2(或者0.203.0)缺少一个重要的特性,HDFS不支持sync模式的持久,这样HBase就有较大的丢失数据的风险。要在生产环境使用HBase,有两个选择,一是使用Cloudera的CDH3版本,Cloudera就类似MySQL的Percona,对官方版本的Hadoop做了很多改进工作,而且经典的《Hadoop:The Definitive Guide》一书的作者Tom White就是Cloudera的一员,这也和《High performance MySQL》一书的作者主要来是Percona一样。另外一种选择,就是自行编译Hadoop branch-0.20-append源码分支,这里有详细的说明

对于HBase这种类似BigTable的系统,其优化之一是消除了磁盘的随机写。付出的代价是将最新的数据保存在内存表中,对内存有较大的需求。如果内存表的数量较多,则每个内存表就会在较小的时候刷到磁盘,导致磁盘文件多而且小。范围读取数据的时候就会跨多个数据文件甚至多个节点。为提升读性能,系统都会设计有compaction操作。另外为了防止某些情况下数据文件过大(hbase.hregion.max.filesize,默认256M,太大的数据文件在compaction等操作是对内存的消耗更大),HBase也设计了split操作。Compaction和Split操作,对于在线应用的响应时间都容易造成波动,他们的策略需要根据应用的特性进行调整。建议在业务低峰期手工调整。

HBase的regionserver宕机超过一定时间后,HMaster会将其所管理的region重新分布到其他存活的regionserver,由于数据和日志都持久在HDFS中,因此该操作不会导致数据丢失。但是重新分配的region需要根据日志恢复原regionserver中的内存表,这会导致宕机的region在这段时间内无法对外提供服务。而一旦重分布,宕机的节点起来后就相当于一个新的regionserver加入集群,为了平衡,需要再次将某些region分布到该server。 因此这个超时建议根据情况进行调整,一般情况下,宕机重启后即可恢复,如果重启需要10分钟,region重分布加恢复的时间要超过5分钟,那么还不如等节点重启。Region Server的内存表memstore如何在节点间做到更高的可用,是HBase的一个较大的挑战。Oceanbase也是采用内存表保持最新的更新数据,和HBase不同的是,Oceanbase使用的是集中的UpdateServer,只需要全力做好UpdateServer的容灾切换即可对业务连续性做到最小影响。分布还是集中,哪些功能分布,哪些功能集中,各自取不同平衡,是目前大部分分布式数据库或者存储的一个主要区别。当然,像Cassandra这种全分布的,架构上看起来很完美,实际应用起来反而问题更多。

对于java应用,线上运维最大的挑战之一就是heap内存管理。GC的不同方式,以及使用内存表和cache对内存的消耗,可能导致局部阻塞应用或者stop the world全局阻塞或者OOM。因此HBase的很多参数设置都是针对这两种情况。HBase使用了较新的CMS GC(-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode)。

默认触发GC的时机是当年老代内存达到90%的时候,这个百分比由 -XX:CMSInitiatingOccupancyFraction=N 这个参数来设置。concurrent mode failed发生在这样一个场景:
当年老代内存达到90%的时候,CMS开始进行并发垃圾收集,于此同时,新生代还在迅速不断地晋升对象到年老代。当年老代CMS还未完成并发标记时,年老代满了,悲剧就发生了。CMS因为没内存可用不得不暂停mark,并触发一次全jvm的stop the world(挂起所有线程),然后采用单线程拷贝方式清理所有垃圾对象。这个过程会非常漫长。为了避免出现concurrent mode failed,我们应该让GC在未到90%时,就触发。

通过设置 -XX:CMSInitiatingOccupancyFraction=N

这个百分比, 可以简单的这么计算。如果你的 hfile.block.cache.size 和 hbase.regionserver.global.memstore.upperLimit 加起来有60%(默认),那么你可以设置 70-80,一般高10%左右差不多。

(以上CMS GC的说明引自HBase性能调优

目前关于HBase的书不多,《Hadoop: The Definitive Guide》第二版有一章,另外最权威的要算官方的这本电子书了。

这篇是最近看HBase过程中的一些零碎的东西,记录于此备忘。