hbase 性能测试（hbase性能优化包含哪些）

本篇文章给大家谈谈hbase 性能测试，以及hbase性能优化包含哪些对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享hbase 性能测试的知识，其中也会对hbase性能优化包含哪些进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、hbase 如何 做性能测试
• 2、HBase探索篇 _ 单节点多RegionServer部署与性能测试
• 3、hbase 如何进行测试并发性能
• 4、淘宝为什么使用HBase及如何优化的
• 5、(课程)基于HBase做Storm 实时计算指标存储

hbase 如何 做性能测试

1 测试环境
1.1 硬件环境
●五个HP Z210： 8G内存；4个型号为i7-2600的CPU，4核；千兆网卡
●Cisco Catalyst 3670交换机
1.2 软件环境
OS：Red Hat 64bit；hadoop-1.0.3；HBase0.94.0
1.3 组网

2 写性能测试
●黑色曲线
4个客户端，分别部署在SM21、SM22、SM23和SM24。每个客户端有两个不共用连接的线程，表是非AutoFlush模式，数据满2M后，才向HRegionServer提交。8个线程不断向表的同一个列族插入value大小为1K的cell， rowkey为long类型的随机数。表的定义：create 'test0', 'profile'。
测试880分钟。测试完成后，插入的数据共有548M个cell，数据量有548G。平均吞吐量为10000cells/s。
●蓝色曲线
4个客户端，分别部署在SM21、SM22、SM23和SM24。每个客户端有两个不共用连接的线程，表是非AutoFlush模式，数据满2M后，才向HRegionServer提交。8个线程不断向8个表的插入value大小为1K的cell， rowkey为long类型的随机数。
测试880分钟后，插入的数据共有467M个记录，数据量有467Gbyte。平均吞吐量为8000cell/s。
●红色曲线
1个客户端，部署在SM21。客户端有1个线程，表是非AutoFlush模式，数据满2M后，才向HRegionServer提交。线程不断向1个表的插入value大小为1K的cell， rowkey为long类型的随机数。 表的定义：create 'test0', 'profile'。
测试880分钟后，插入的数据共有299M个记录，数据量有299Gbyte。平均吞吐量为5000cell/s。
3 读性能测试
3.1 随机查找测试1
表的定义如下：
create 'test0',{NAME = 'profile',BLOOMFILTER = 'ROWCOL'}
test0中有94M记录， value大小为1K。可以计算出表test0中共94GB数据。从test0中随机查找存在的数据。测试得出：每秒可以查询50次，时延为1000ms/50=20ms。
测试结果分析：
在HDFS上测试可知，随机读64K-block(64K? HBase IO的基本单位是64K)的延迟越为19ms。所以20MS的延迟主要是由于HDFS的延迟造成的。
注：如果没有BLOOMFILTER，性能会更低。
3.2随机查找测试2
除了4个客户端同时查询，其它与3.1相同。测试结果160次/S。每个客户端40次/S。
3.3随机查找测试3
一个客户端，查询不存在的记录，其它与3.1同。每秒可以查询75次，时延为1000ms/75 = 13ms。
测试结果分析：
测试结果比查询存在的记录稍高。原因是查询不存在的记录只需要读取bloom filter块；除此之外，查询存在的记录还需要读取数据块。
3.4 测试4
一个客户端进行范围查找，平均吞吐约为2400rows/s。
4 磁盘性能测试
4.1 顺序写
测试方法：一个进程，顺序写3000个文件，每个文件256MB，每次写64KB。
测试结果：写64KB的延迟为2.5ms，吞吐为28MB/S。
4.2 顺序读
测试方法：一个进程，顺序读3000个文件，每个文件256MB，每次读64KB。
测试结果：读64KB的延迟为0.8ms，吞吐为80MB/S。
4.3 随机64k-block读
测试方法：一个进程，随机读3000个文件，每个文件256MB，每次读64KB。
测试结果：读64KB的延迟为21ms，吞吐为3MB/S。

4.4 随机1b读
测试方法：一个进程，随机读3000个文件，每个文件256MB，每次读1KB。
测试结果：读1byte的延迟为18MS，吞吐为55B/S。
4.5 总结
磁盘读写延迟由三部分组成：寻道延迟+旋转延迟+传输延迟。
对比4.1和4.2， 读性能是写的3倍。
对比4.2和4.3，寻道延迟和旋转延迟占总时间的97%
4.4，IOPS能够达到55次/s
5 HDFS性能测试
5.1 顺序写测试
测试方法：一个进程，顺序写10个文件，每个文件10GB，每次写64KB。
测试结果：写64KB的延迟为4.7ms，吞吐为14MB/S。
5.2 随机64k-block读测试
测试方法：一个进程，随机读10个文件，每个文件10GB，每次读64KB。
测试结果：读64KB的延迟为2ms，吞吐为32MB/S。

HBase探索篇 _ 单节点多RegionServer部署与性能测试

[toc]

随着集群中总的Region数持续增长，每个节点平均管理的Region数已达550左右，某些大表的写入流量一上来，Region Server就会不堪重负，相继挂掉。

在HBase中，Region的一个列族对应一个MemStore，通常一个MemStore的默认大小为128MB（我们设置的为256MB），见参数 hbase.hregion.memstore.flush.size 。当可用内存足够时，每个MemStore可以分配128MB的空间。

当表的写入流量上升时，假设每个Region的写入压力相同，则理论上每个MemStore会平均分配可用的内存空间。

因此，节点中Region过多时，每个MemStore分到的内存空间就会变小。此时，写入很小的数据量，就会被强制flush到磁盘，进而导致频繁刷写，会对集群HBase与HDFS造成很大的压力。

同时，Region过多导致的频繁刷写，又会在磁盘上产生非常多的HFile小文件，当小文件过多的时候，HBase为了优化查询性能就会做Compaction操作，合并HFile，减少文件数量。当小文件一直很多的时候，就会出现 “压缩风暴”。Compaction非常消耗系统的IO资源，还会降低数据的写入速度，严重时会影响正常业务的进行。

关于每个Region Server节点中，Region数量大致合理的范围，HBase官网上也给出了定义：

可见，通常情况下，每个节点拥有20-200个Region是比较正常的。

其实，每个Region Server的最大Region数量由总的MemStore内存大小决定。每个Region的每个列族会对应一个MemStore，假设HBase表都有一个列族，那么每个Region只包含一个MemStore。一个MemStore大小通常在128~256MB，见参数： hbase.hregion.memstore.flush.size 。默认情况下，RegionServer会将自身堆内存的40%（我们线上60%）（见参数： hbase.regionserver.global.memstore.size ）提供给节点上的所有MemStore使用，如果所有MemStore的总大小达到该配置大小，新的更新将会被阻塞并且会强制刷写磁盘。因此，每个节点最理想的Region数量应该由以下公式计算（假设HBase表都有统一的列族配置）：

((RS memory) * (total memstore fraction)) / ((memstore size)*(column families))

其中：

以我们线上集群的配置举例，我们每个RegionServer的堆内存是32GB，那么节点上最理想的Region数量应该是： 32768*0.6/256 ≈ 76 （32768*0.6/128 ≈ 153）

上述最理想的情况是假设每个Region上的填充率都一样，包括数据写入的频次、写入数据的大小，但实际上每个Region的负载各不相同，有的Region可能特别活跃、负载特别高，有的Region则比较空闲。所以，通常我们认为2 3倍的理想Region数量也是比较合理的，针对上面举例来说，大概200 300个Region左右算是合理的。

针对上文所述的Region数过多的隐患，以下内容主要从两方面考虑来优化。

提高内存的目的是为了增加每个Region拥有的MemStore的空间，避免其写入压力上升时，MemStore频繁刷写，形成小的HFile过多，引起压缩风暴，占用大量IO。

但其实RS的堆内存并不是越大越好，我们开始使用HBase的时候，对CMS和G1相关的参数，进行了大量压测，测试指标数据表明，内存分配的越大，吞吐量和p99读写平均延时会有一定程度的变差（也有可能是我们的JVM相关参数，当时调配的不合理）。

在我们为集群集成jdk15，设置为ZGC之后，多次压测并分析JVM日志之后，得出结论，在牺牲一定吞吐量的基础上，集群的GC表现能力确实提升的较为明显，尤其是GC的平均停顿时间，99.9%能维持在10ms以下。

而且ZGC号称管理上T的大内存，停顿时间控制在10ms之内（JDK16把GC停顿时间控制在1ms内，期待JDK17 LTS），STW时间不会因为堆的变大而变长。

因此理论上，增加RS堆内存之后，GC一样不会成为瓶颈。

之所以考虑在单节点上部署多个Region Server的进程，是因为我们单个物理机的资源配置很高，内存充足（三百多G，RS堆内存只分了32G）、而HBase又是弱计算类型的服务，平时CPU的利用率低的可怜，网络方面亦未见瓶颈，唯一掉链子的也就属磁盘了，未上SSD，IO延迟较为严重。

当然，也曾考虑过虚拟机的方案，但之前YCSB压测的数据都不太理想；K8s的调研又是起步都不算，没有技术积累。因此，简单、直接、易操作的方案就是多RS部署了。

以下内容先叙述CDH中多RS进程部署的一些关键流程，后续将在多RS、单RS、单RS大堆环境中，对集群进行基准性能测试，并对比试验数据，分析上述两种优化方案的优劣。

我们使用的HBase版本是 2.1.0-cdh6.3.2 ，非商业版，未上Kerberos，CDH中HBase相关的jar包已替换为用JDK15编译的jar。

多Region Server的部署比较简单，最关键的是修改 hbase-site.xml 中region server的相关端口，避免端口冲突即可。可操作流程如下。

修改所需配置文件

hbase-site.xml 配置文件一定不要直接从 /etc/hbase/conf 中获取，这里的配置文件是给客户端用的。CDH管理的HBase，配置文件都是运行时加载的，所以，找到HBase最新启动时创建的进程相关的目录，即可获取到服务端最新的配置文件，如：/var/run/cloudera-scm-agent/process/5347-hbase-REGIONSERVER。需要准备的目录结构如下：

不需要HBase完整安装包中的内容（在自编译的完整安装包中运行RS进程时，依赖冲突或其他莫名其妙的报错会折磨的你抓狂），只需要bin、conf目录即可，pids文件夹是自定义的，RS进程对应pid文件的输出目录，start_rs.sh、stop_rs.sh是自定义的RS进程的启动和关闭脚本。

重点修改下图标注的配置文件，

还有日志文件名的一些输出细节，可以按需在 bin/hbase-daemon.sh 中修改。

运行或关闭RS进程

中间有异常，请查看相关日志输出。

集群Region数疯涨，当写入存在压力时，会导致RS节点异常退出。为了解决目前的这种窘境，本次优化主要从单节点多Region Server部署和提高单个Region Server节点的堆内存两方面着手。

那这两种优化方案对HBase的读写性能指标，又会产生什么样的影响呢？我们以YCSB基准测试的结果指标数据做为参考，大致评价下这两种应急方案的优劣。

用于此次测试的HBase集群的配置

此次测试使用的数据集大小

测试方法

压测时选择的读写负载尽量模拟线上的读写场景，分别为：读写3/7、读写7/3、读写5/5；

压测时唯一的变量条件是：多RS部署（32G堆，在每个节点上启动3个RS进程，相当于集群中一共有15个RS节点）、单RS部署（32G小堆）和单RS部署（100G大堆），并尽可能保证其他实验条件不变，每个YCSB的工作负载各自运行20分钟左右，并且重复完整地运行5次，两次运行之间没有重新启动，以测量YCSB的吞吐量等指标，收集的测试结果数据是5次运行中最后3次运行的平均值，为了避免第一轮和第二轮的偶然性，忽略了前两次的测试。

YCSB压测的命令是：

收集实验数据后，大致得出不同读写负载场景下、各个实验条件下的指标数据，如下图。

上述的测试数据比较粗糙，但大致也能得出些结论，提供一定程度上的参考。

多RS进程部署的模式，起到了一定程度上的进程间资源隔离的作用，分担了原先单台RS管理Region的压力，最大化利用了物理机的资源，但多出来的一些Region Server，需要单独的管理脚本和监控系统来维护，增加了维护成本。多个RS依赖同一台物理机，物理节点宕机便会影响多个RS进程，同时，某一个Region Server出现热点，压力过大，资源消耗过度，也许会引起同机其他进程的不良，在一定程度上，牺牲了稳定性和可靠性。

增加单个RS进程的堆内存，MemStore在一定程度上会被分配更充裕的内存空间，减小了flush的频次，势必会削弱写入的压力，但也可能会增加GC的负担，我们或许需要调整出合适的GC参数，甚至需要调优HBase本身的一些核心参数，才能兼顾稳定和性能。然而，这就又是一件漫长而繁琐的事情了，在此不过分探讨。

面对性能瓶颈的出现，我们不能盲目地扩充机器，在应急方案采取之后，我们需要做一些额外的、大量的优化工作，这或许才是上上之策。

hbase 如何进行测试并发性能

试试：
get 'scores','Jim',{COLUMN='grade',value='4'}
get 'scores','Jim',{COLUMN='grade',value='10'}
或者：
get 'scores','Jim',{COLUMN='grade',value=4}
get 'scores','Jim',{COLUMN='grade',value=10}
我没有用过HBase,最近刚在看，在Shell中，常量是不需要引号的，二进制需要双引号，其他值需要单引号。

淘宝为什么使用HBase及如何优化的

1 前言
hbase是从hadoop中 分离出来的apache顶级开源项目。由于它很好地用java实现了google的bigtable系统大部分特性，因此在数据量猛增的今天非常受到欢 迎。对于淘宝而言，随着市场规模的扩大，产品与技术的发展，业务数据量越来越大，对海量数据的高效插入和读取变得越来越重要。由于淘宝拥有也许是国内最大 的单一hadoop集群(云梯)，因此对hadoop系列的产品有比较深入的了解，也就自然希望使用hbase来做这样一种海量数据读写服务。本篇文章将 对淘宝最近一年来在online应用上使用和优化hbase的情况做一次小结。
2 原因
为什么要使用hbase？
淘宝在2011年之前所有的后端持久化存储基本上都是在mysql上进行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由于开源，并且生态系统良好，本身拥有分库分表等多种解决方案，因此很长一段时间内都满足淘宝大量业务的需求。
但是由于业务的多样化发展，有越来越多的业务系统的需求开始发生了变化。一般来说有以下几类变化：
a) 数据量变得越来越多，事实上现在淘宝几乎任何一个与用户相关的在线业务的数据量都在亿级别，每日系统调用次数从亿到百亿都有，且历史数据不能轻易删除。这需要有一个海量分布式文件系统，能对TB级甚至PB级别的数据提供在线服务
b) 数据量的增长很快且不一定能准确预计，大多数应用系统从上线起在一段时间内数据量都呈很快的上升趋势，因此从成本的角度考虑对系统水平扩展能力有比较强烈的需求，且不希望存在单点制约
c) 只需要简单的kv读取，没有复杂的join等需求。但对系统的并发能力以及吞吐量、响应延时有非常高的需求，并且希望系统能够保持强一致性
d) 通常系统的写入非常频繁，尤其是大量系统依赖于实时的日志分析
e) 希望能够快速读取批量数据
f ) schema灵活多变，可能经常更新列属性或新增列
g) 希望能够方便使用，有良好且语义清晰的java接口
以上需求综合在一起，我们认为hbase是一种比较适合的选择。首先它的数据由hdfs天然地做了数据冗余，云梯三年的稳定运行，数据100%可靠 己经证明了hdfs集群的安全性，以及服务于海量数据的能力。其次hbase本身的数据读写服务没有单点的限制，服务能力可以随服务器的增长而线性增长， 达到几十上百台的规模。LSM-Tree模式的设计让hbase的写入性能非常良好，单次写入通常在1-3ms内即可响应完成，且性能不随数据量的增长而 下降。
region（相当于数据库的分表）可以ms级动态的切分和移动，保证了负载均衡性。由于hbase上的数据模型是按rowkey排序存储的，而读 取时会一次读取连续的整块数据做为cache，因此良好的rowkey设计可以让批量读取变得十分容易，甚至只需要1次io就能获取几十上百条用户想要的 数据。最后，淘宝大部分工程师是java背景的同学，因此hbase的api对于他们来说非常容易上手，培训成本相对较低。
当然也必须指出，在大数据量的背景下银弹是不存在的，hbase本身也有不适合的场景。比如，索引只支持主索引（或看成主组合索引），又比如服务是 单点的，单台机器宕机后在master恢复它期间它所负责的部分数据将无法服务等。这就要求在选型上需要对自己的应用系统有足够了解。
3 应用情况
我们从2011年3月开始研究hbase如何用于在线服务。尽管之前在一淘搜索中己经有了几十节点的离线服务。这是因为hbase早期版本的目标就 是一个海量数据中的离线服务。2009年9月发布的0.20.0版本是一个里程碑，online应用正式成为了hbase的目标，为此hbase引入了 zookeeper来做为backupmaster以及regionserver的管理。2011年1月0.90.0版本是另一个里程碑，基本上我们今天 看到的各大网站，如facebook/ebay/yahoo内所使用于生产的hbase都是基于这一个版本(fb所采用的0.89版本结构与0.90.x 相近)。bloomfilter等诸多属性加入了进来，性能也有极大提升。基于此，淘宝也选用了0.90.x分支作为线上版本的基础。
第一个上线的应用是数据魔方中的prom。prom原先是基于redis构建的，因为数据量持续增大以及需求的变化，因此我们用hbase重构了它 的存储层。准确的说prom更适合0.92版本的hbase，因为它不仅需要高速的在线读写，更需要count/group by等复杂应用。但由于当时0.92版本尚未成熟，因此我们自己单独实现了coprocessor。prom的数据导入是来源于云梯，因此我们每天晚上花 半个小时将数据从云梯上写入hbase所在的hdfs，然后在web层做了一个client转发。经过一个月的数据比对，确认了速度比之redis并未有 明显下降，以及数据的准确性，因此得以顺利上线。
第二个上线的应用是TimeTunnel，TimeTunnel是一个高效的、可靠的、可扩展的实时数据传输平台，广泛应用于实时日志收集、数据实 时监控、广告效果实时反馈、数据库实时同步等领域。它与prom相比的特点是增加了在线写。动态的数据增加使hbase上compact/balance /split/recovery等诸多特性受到了极大的挑战。TT的写入量大约一天20TB，读的量约为此的1.5倍，我们为此准备了20台 regionserver的集群，当然底层的hdfs是公用的，数量更为庞大（下文会提到）。每天TT会为不同的业务在hbase上建不同的表，然后往该 表上写入数据，即使我们将region的大小上限设为1GB，最大的几个业务也会达到数千个region这样的规模，可以说每一分钟都会有数次 split。在TT的上线过程中，我们修复了hbase很多关于split方面的bug，有好几个commit到了hbase社区，同时也将社区一些最新 的patch打在了我们的版本上。split相关的bug应该说是hbase中会导致数据丢失最大的风险之一，这一点对于每个想使用hbase的开发者来 说必须牢记。hbase由于采用了LSM-Tree模型，从架构原理上来说数据几乎没有丢失的可能，但是在实际使用中不小心谨慎就有丢失风险。原因后面会 单独强调。TT在预发过程中我们分别因为Meta表损坏以及split方面的bug曾经丢失过数据，因此也单独写了meta表恢复工具，确保今后不发生类 似问题(hbase-0.90.5以后的版本都增加了类似工具)。另外，由于我们存放TT的机房并不稳定，发生过很多次宕机事故，甚至发生过假死现象。因 此我们也着手修改了一些patch，以提高宕机恢复时间，以及增强了监控的强度。
CTU以及会员中心项目是两个对在线要求比较高的项目，在这两个项目中我们特别对hbase的慢响应问题进行了研究。hbase的慢响应现在一般归 纳为四类原因：网络原因、gc问题、命中率以及client的反序列化问题。我们现在对它们做了一些解决方案(后面会有介绍)，以更好地对慢响应有控制 力。
和Facebook类似，我们也使用了hbase做为实时计算类项目的存储层。目前对内部己经上线了部分实时项目，比如实时页面点击系 统，galaxy实时交易推荐以及直播间等内部项目，用户则是散布到公司内各部门的运营小二们。与facebook的puma不同的是淘宝使用了多种方式 做实时计算层，比如galaxy是使用类似affa的actor模式处理交易数据，同时关联商品表等维度表计算排行(TopN)，而实时页面点击系统则是 基于twitter开源的storm进行开发，后台通过TT获取实时的日志数据，计算流将中间结果以及动态维表持久化到hbase上，比如我们将 rowkey设计为url+userid，并读出实时的数据，从而实现实时计算各个维度上的uv。
最后要特别提一下历史交易订单项目。这个项目实际上也是一个重构项目，目的是从以前的solr+bdb的方案上迁移到hbase上来。由于它关系到 己买到页面，用户使用频率非常高，重要程度接近核心应用，对数据丢失以及服务中断是零容忍。它对compact做了优化，避免大数据量的compact在 服务时间内发生。新增了定制的filter来实现分页查询，rowkey上对应用进行了巧妙的设计以避免了冗余数据的传输以及90%以上的读转化成了顺序 读。目前该集群存储了超过百亿的订单数据以及数千亿的索引数据，线上故障率为0。
随着业务的发展，目前我们定制的hbase集群己经应用到了线上超过二十个应用，数百台服务器上。包括淘宝首页的商品实时推荐、广泛用于卖家的实时量子统计等应用，并且还有继续增多以及向核心应用靠近的趋势。
4 部署、运维和监控
Facebook之前曾经透露过Facebook的hbase架构，可以说是非常不错的。如他们将message服务的hbase集群按用户分为数 个集群，每个集群100台服务器，拥有一台namenode以及分为5个机架，每个机架上一台zookeeper。可以说对于大数据量的服务这是一种优良 的架构。对于淘宝来说，由于数据量远没有那么大，应用也没有那么核心，因此我们采用公用hdfs以及zookeeper集群的架构。每个hdfs集群尽量 不超过100台规模（这是为了尽量限制namenode单点问题）。在其上架设数个hbase集群，每个集群一个master以及一个 backupmaster。公用hdfs的好处是可以尽量减少compact的影响，以及均摊掉硬盘的成本，因为总有集群对磁盘空间要求高，也总有集群对 磁盘空间要求低，混合在一起用从成本上是比较合算的。zookeeper集群公用，每个hbase集群在zk上分属不同的根节点。通过zk的权限机制来保 证hbase集群的相互独立。zk的公用原因则仅仅是为了运维方便。
由于是在线应用，运维和监控就变得更加重要，由于之前的经验接近0，因此很难招到专门的hbase运维人员。我们的开发团队和运维团队从一开始就很重视该问题，很早就开始自行培养。以下讲一些我们的运维和监控经验。
我们定制的hbase很重要的一部分功能就是增加监控。hbase本身可以发送ganglia监控数据，只是监控项远远不够，并且ganglia的 展示方式并不直观和突出。因此一方面我们在代码中侵入式地增加了很多监控点，比如compact/split/balance/flush队列以及各个阶 段的耗时、读写各个阶段的响应时间、读写次数、region的open/close，以及具体到表和region级别的读写次数等等。仍然将它们通过 socket的方式发送到ganglia中，ganglia会把它们记录到rrd文件中，rrd文件的特点是历史数据的精度会越来越低，因此我们自己编写 程序从rrd中读出相应的数据并持久化到其它地方，然后自己用js实现了一套监控界面，将我们关心的数据以趋势图、饼图等各种方式重点汇总和显示出来，并 且可以无精度损失地查看任意历史数据。在显示的同时会把部分非常重要的数据，如读写次数、响应时间等写入数据库，实现波动报警等自定义的报警。经过以上措 施，保证了我们总是能先于用户发现集群的问题并及时修复。我们利用redis高效的排序算法实时地将每个region的读写次数进行排序，能够在高负载的 情况下找到具体请求次数排名较高的那些region，并把它们移到空闲的regionserver上去。在高峰期我们能对上百台机器的数十万个 region进行实时排序。
为了隔离应用的影响，我们在代码层面实现了可以检查不同client过来的连接，并且切断某些client的连接，以在发生故障时，将故障隔离在某个应用内部而不扩大化。mapreduce的应用也会控制在低峰期运行，比如在白天我们会关闭jobtracker等。
此外，为了保障服务从结果上的可用，我们也会定期跑读写测试、建表测试、hbck等命令。hbck是一个非常有用的工具，不过要注意它也是一个很重 的工操作，因此尽量减少hbck的调用次数，尽量不要并行运行hbck服务。在0.90.4以前的hbck会有一些机率使hbase宕机。另外为了确保 hdfs的安全性，需要定期运行fsck等以检查hdfs的状态，如block的replica数量等。
我们会每天根踪所有线上服务器的日志，将错误日志全部找出来并且邮件给开发人员，以查明每一次error以上的问题原因和fix。直至错误降低为0。另外 每一次的hbck结果如果有问题也会邮件给开发人员以处理掉。尽管并不是每一次error都会引发问题，甚至大部分error都只是分布式系统中的正常现 象，但明白它们问题的原因是非常重要的。
5 测试与发布
因为是未知的系统，我们从一开始就非常注重测试。测试从一开始就分为性能测试和功能测试。性能测试主要是注意基准测试，分很多场景，比如不同混合读 写比例，不同k/v大小，不同列族数，不同命中率，是否做presharding等等。每次运行都会持续数小时以得到准确的结果。因此我们写了一套自动化 系统，从web上选择不同的场景，后台会自动将测试参数传到各台服务器上去执行。由于是测试分布式系统，因此client也必须是分布式的。
我们判断测试是否准确的依据是同一个场景跑多次，是否数据，以及运行曲线达到99%以上的重合度，这个工作非常烦琐，以至于消耗了很多时间，但后来 的事实证明它非常有意义。因为我们对它建立了100%的信任，这非常重要，比如后期我们的改进哪怕只提高2%的性能也能被准确捕捉到，又比如某次代码修改 使compact队列曲线有了一些起伏而被我们看到，从而找出了程序的bug，等等。
功能测试上则主要是接口测试和异常测试。接口测试一般作用不是很明显，因为hbase本身的单元测试己经使这部分被覆盖到了。但异常测试非常重要， 我们绝大部分bug修改都是在异常测试中发现的，这帮助我们去掉了很多生产环境中可能存在的不稳定因素，我们也提交了十几个相应的patch到社区，并受 到了重视和commit。分布式系统设计的难点和复杂度都在异常处理上，我们必须认为系统在通讯的任何时候都是不可靠的。某些难以复现的问题我们会通过查 看代码大体定位到问题以后，在代码层面强行抛出异常来复现它。事实证明这非常有用。
为了方便和快速定位问题，我们设计了一套日志收集和处理的程序，以方便地从每台服务器上抓取相应的日志并按一定规律汇总。这非常重要，避免浪费大量的时间到登录不同的服务器以寻找一个bug的线索。
由于hbase社区在不停发展，以及线上或测试环境发现的新的bug，我们需要制定一套有规律的发布模式。它既要避免频繁的发布引起的不稳定，又要 避免长期不发布导致生产版本离开发版本越来越远或是隐藏的bug爆发。我们强行规定每两周从内部trunk上release一个版本，该版本必须通过所有 的测试包括回归测试，并且在release后在一个小型的集群上24小时不受甘扰不停地运行。每个月会有一次发布，发布时采用最新release的版本， 并且将现有的集群按重要性分级发布，以确保重要应用不受新版本的潜在bug影响。事实证明自从我们引入这套发布机制后，由发布带来的不稳定因素大大下降 了，并且线上版本也能保持不落后太多。
6 改进和优化
Facebook是一家非常值得尊敬的公司，他们毫无保留地对外公布了对hbase的所有改造，并且将他们内部实际使用的版本开源到了社区。 facebook线上应用的一个重要特点是他们关闭了split，以降低split带来的风险。与facebook不同，淘宝的业务数据量相对没有如此庞 大，并且由于应用类型非常丰富，我们并们并没有要求用户强行选择关闭split，而是尽量去修改split中可能存在的bug。到目前为止，虽然我们并不 能说完全解决了这个问题，但是从0.90.2中暴露出来的诸多跟split以及宕机相关的可能引发的bug我们的测试环境上己经被修复到接近了0，也为社 区提交了10数个稳定性相关的patch，比较重要的有以下几个：
https://issues.apache.org/jira/browse/HBASE-4562
https://issues.apache.org/jira/browse/HBASE-4563
https://issues.apache.org/jira/browse/HBASE-5152
https://issues.apache.org/jira/browse/HBASE-5100
https://issues.apache.org/jira/browse/HBASE-4880
https://issues.apache.org/jira/browse/HBASE-4878
https://issues.apache.org/jira/browse/HBASE-4899
还有其它一些，我们主要将patch提交到0.92版本，社区会有commitor帮助我们backport回0.90版本。所以社区从 0.90.2一直到0.90.6一共发布了5个bugfix版本后，0.90.6版本其实己经比较稳定了。建议生产环境可以考虑这个版本。
split这是一个很重的事务，它有一个严重的问题就是会修改meta表（当然宕机恢复时也有这个问题）。如果在此期间发生异常，很有可能meta 表、rs内存、master内存以及hdfs上的文件会发生不一致，导致之后region重新分配时发生错误。其中一个错误就是有可能同一个region 被两个以上的regionserver所服务，那么就可能出现这一个region所服务的数据会随机分别写到多台rs上，读取的时候也会分别读取，导致数 据丢失。想要恢复原状，必须删除掉其中一个rs上的region，这就导致了不得不主动删掉数据，从而引发数据丢失。
前面说到慢响应的问题归纳为网络原因、gc问题、命中率以及client的反序列化问题。网络原因一般是网络不稳定引起的，不过也有可能是tcp参 数设置问题，必须保证尽量减少包的延迟，如nodelay需要设置为true等，这些问题我们通过tcpdump等一系列工具专门定位过，证明tcp参数 对包的组装确实会造成慢连接。gc要根据应用的类型来，一般在读比较多的应用中新生代不能设置得太小。命中率极大影响了响应的时间，我们会尽量将 version数设为1以增加缓存的容量，良好的balance也能帮助充分应用好每台机器的命中率。我们为此设计了表级别的balance。
由于hbase服务是单点的，即宕机一台，则该台机器所服务的数据在恢复前是无法读写的。宕机恢复速度决定了我们服务的可用率。为此主要做了几点优 化。首先是将zk的宕机发现时间尽量缩短到1分钟，其次改进了master恢复日志为并行恢复，大大提高了master恢复日志的速度，然后我们修改了 openhandler中可能出现的一些超时异常，以及死锁，去掉了日志中可能发生的open…too long等异常。原生的hbase在宕机恢复时有可能发生10几分钟甚至半小时无法重启的问题己经被修复掉了。另外，hdfs层面我们将 socket.timeout时间以及重试时间也缩短了，以降低datanode宕机引起的长时间block现象。
hbase本身读写层面的优化我们目前并没有做太多的工作，唯一打的patch是region增加时写性能严重下降的问题。因为由于hbase本身 良好的性能，我们通过大量测试找到了各种应用场景中比较优良的参数并应用于生产环境后，都基本满足需求。不过这是我们接下来的重要工作。
7 将来计划
我们目前维护着淘宝内基于社区0.90.x而定制的hbase版本。接下来除继续fix它的bug外，会维护基于0.92.x修改的版本。之所以这 样，是因为0.92.x和0.90.x的兼容性并不是非常好，而且0.92.x修改掉的代码非常多，粗略统计会超过30%。0.92中有我们非常看重的一 些特性。
0.92版本改进了hfile为hfileV2，v2版本的特点是将索引以及bloomfilter进行了大幅改造，以支持单个大hfile文 件。现有的HFile在文件大到一定程度时，index会占用大量的内存，并且加载文件的速度会因此下降非常多。而如果HFile不增大的 话，region就无法扩大，从而导致region数量非常多。这是我们想尽量避免的事。
0.92版本改进了通讯层协议，在通讯层中增加了length，这非常重要，它让我们可以写出nio的客户端，使反序列化不再成为影响client性能的地方。
0.92版本增加了coprocessor特性，这支持了少量想要在rs上进行count等的应用。
还有其它很多优化，比如改进了balance算法、改进了compact算法、改进了scan算法、compact变为CF级别、动态做ddl等等特性。
除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不错的特性，0.94是一个性能优化版本。它做了很多革命性工作，比如去掉root表，比如HLog进行压缩，replication上支持多个slave集群，等等。
我们自己也有一些优化，比如自行实现的二级索引、backup策略等都会在内部版本上实现。
另外值得一提的是hdfs层面的优化也非常重要，hadoop-1.0.0以及cloudera-3u3的改进对hbase非常有帮助，比如本地化 读、checksum的改进、datanode的keepalive设置、namenode的HA策略等。我们有一支优秀的hdfs团队来支持我们的 hdfs层面工作，比如定位以及fix一些hdfs层面的bug,帮助提供一些hdfs上参数的建议，以及帮助实现namenode的HA等。最新的测试 表明，3u3的checksum+本地化读可以将随机读性能提升至少一倍。
我们正在做的一件有意义的事是实时监控和调整regionserver的负载，能够动态地将负载不足的集群上的服务器挪到负载较高的集群中，而整个过程对用户完全透明。
总的来说，我们的策略是尽量和社区合作，以推动hbase在整个apache生态链以及业界的发展，使其能更稳定地部署到更多的应用中去，以降低使用门槛以及使用成本。

(课程)基于HBase做Storm 实时计算指标存储

Hi，大家好！我是祝威廉，本来微博也想叫祝威廉的，可惜被人占了，于是改名叫·祝威廉二世。然后总感觉哪里不对。目前在乐视云数据部门里从事实时计算，数据平台、搜索和推荐等多个方向。曾从事基础框架，搜索研发四年，大数据平台架构、推荐三年多，个人时间现专注于集群自动化部署，服务管理，资源自动化调度等方向。

这次探讨的主题是：

*** 基于 HBase 做 Storm 实时计算指标存储 ***

HBase 实时指标存储是我入职乐视云后对原有的实时系统改造的一部分。部分分享内容其实还处于实施阶段。架构方案设计的话应该是仁者见仁智者见智，也会有很多考虑不周的地方，欢迎大家批评指正。说不定大家听完分享后好的提议我们会用到工程上，也为后面的实际课程做好准备。

我之前做过一次大数据的课，比较 Naive，但是也包含了我对数据平台的一些看法。
参看： http://www.stuq.org/course/detail/999

好了，步入正文，O(∩_∩)O~

乐视云内部用 Storm 做 CDN，点播，直播流量的计算，同时还有慢速比，卡顿比等统计指标。相应的指标会由指标名称，业务类型，客户，地域，ISP 等多个维度组成。指标计算一个比较大的问题是 Key 的集合很大。

举个例子，假设我们有客户 10w，计算指标假设 100 个，5 个 ISP，30 个地域，这样就有亿级以上的 Key 了，我们还要统计分钟级别，小时级别，天级别，月级别。所以写入量和存储量都不小。

如果采用 Redis/Memcached 写入速度是没有问题的，毕竟完全的内存操作。但是 key 集合太大，其实压力也蛮大的，我去的时候因为加了指标，结果导致 Memcache 被写爆了，所以紧急做了扩容。

首先是 Redis 查起来的太麻烦。客户端为了某个查询，需要汇总成千上万个 Key。。。业务方表示很蛋疼，我们也表示很蛋疼
其次，内存是有限的，只能存当天的。以前的数据需要转存。

第三，你还是绕不过持久化存储，于是引入 MySQL，现在是每天一张表。那 Redis 导入到 MySQL 本身就麻烦。所以工作量多了，查询也麻烦，查一个月半年的数据就吐血了。

鉴于以上原因，我们就想着有没有更合适的方案。

我们首先就想到了 HBase，因为 HBase 还是具有蛮强悍的写入性功能以及优秀的可扩展性。而事实上经过调研，我们发现 HBase 还是非常适合指标查询的，可以有效的通过列来减少 key 的数量。

举个例子，我现在想绘制某一个视频昨天每一分钟的播放量的曲线图。如果是 Redis，你很可能需要查询 1440 个 Key。如果是 HBase，只要一条记录就搞定。
我们现在上图：

这里，我们一行可以追踪某个指标一天的情况。如果加再加个维度，无非增加一条记录。而如果是 redis，可能就多了一倍，也就是 2880 个 key 了。

假设该视频是 A，已经在线上 100 天了。我们会记录这个视频所有的 1 分钟播放数，用 Redis 可能有 100*1440 个 key，但是 HBase只要获取 100 条记录就可以找出来，我们把时间粒度转化为了 hbase 的列，从而减少行 (Key)。

我们知道 HBase 是可以多列族，多 Column，Schemaless 的。所以这里，我们建了一个列族，在该列族上，直接建了 1440 个 Column。Column 的数目和时间粒度有关。如果是一分钟粒度，会有 1440 个，如果是五分钟粒度的会有 288 个，如果是小时粒度的，会有 24 个。不同的粒度，我们会建不同的表。

写入的时候，我们可以定位到 rowkey，以及对应的 column，这里一般不会存在并发写。当然 HBase 的 increment 已经解决了并发问题，但是会造成一定的性能影响。

查询的时候，可根据天的区间查出一条相应的记录。我们是直接把记录都取出来，Column 只是一个 Int/Long 类型，所以 1440 个 Column 数据也不算大。
Storm 计算这一块，还有一个比较有意思的地方。假设 A 指标是五分钟粒度的，也就是说我们会存储 A 指标每个五分钟的值。但是在实际做存储的时候，他并不是五分钟结束后就往 HBase 里存储，而是每隔(几秒/或者一定条数后)就 increment 到 HBase 中，然后清除重新计数。

这里其实我要强调的是，到 HBase 并不是覆盖某个 Rowkey 特定的 Cloumn 值，而是在它原有的基础上，做加法。这样做可以防止时间周期比较长的指标，其累计值不会因为有拓扑当掉了而丢失数据(其实还是会丢的，但可能损失的计数比较少而已)。

丢数据比如你 kill-9 了。

大家可以想象一下，如果我计算一个五分钟的指标，到第三分钟挂掉了，此时累计值是 1000，接着拓扑重启了，五分钟还没完，剩下的两分钟它会接着累计，此时是 500。如果是覆盖写，就会得到不正确的结果，实际上整个完整的计数是 1500。

防止拓扑当掉并不是这样设计的主要原因，还有一点是计算延时了，比如某个数据片段因为某个原因，延时了十分钟才到 Storm 实时计算集群，这个时候新得到的值还可以加回去，如果是覆盖，数据就错误了。

所以 HBase 存储这块就变成做加法操作而不仅仅是简单的更新了。目前 HBase 添加了计数的功能 (Increment)，而另外一个比较神奇的接口设计的地方是，竟然没有从名字上看的出是批量increment接口，一开始我以为没有，后面是去看源码，才发现是有的，就是batch接口，put,increment等都可以使用这种接口去批量提交，提高查询效率。

另外 HBase 的 Client 也是非常的奇特，比如 HTablePool 竟然是对象池而不是真实的Connection连接池，多个 HTable 对象是共享一个 Connection 链接的。当然，这里 HTable 的 Connection 会比较复杂，因为要连 Zookeeper 还有各个 Region。如果过多了，可能会对Zookeeper造成压力，这倒也问题不大。

如果不使用批量接口，客户端的写入量死活是上不去。16 台 32G，24 核的服务器，我做了预分区 (60个左右)，用了四十个进程，300 个左右的线程去写，也就只能写到 60000/s 而已。

但实际并发应该是只有 40 左右的。300 个线程并没有起到太多作用。

还有就是，HBase 的 incrementColumnValue 的性能确实不高。至少和批量 Put 差距很大。所以一定要使用Batch接口。性能可以提升很多倍。

我们的测试中，还是比较平稳的，整个写入状态。抖动不大。

在整个过程中，有两点要注意：

预分区是要看场景的，在我们这个场景下是预分区是非常重要的。否则一开始都集中在一台机器的一个 Regin 上写，估计很快写的进程就都堵住了。上线就会挂。

所以我事先收集了几天的 key，然后预先根据 key 的分布做了分区。我测试过，在我们的集群上，到了 60 个分区就是一个瓶颈，再加分区已经不能提升写入量。

写入我们也做了些优化，因为写的线程和 Storm 是混用的(其实就是 Storm 在写)。我们不能堵住了 Storm。这点我们是通过rowkey的设计来解决，保证写入和读取都能均匀的分布在HBase的各个Regin上。如果写入出现问题(比如HBase出现堵塞)，一个可选的方案是将数据回写到kafka,然后再起一个拓扑尝试重新写。第二个就是HBase的主从高可用，这个有机会以后再谈。

上面的设计稿中，大家可以看到Rowkey的组成。我的建议是这样

因为md5还是有可能碰撞，所以真实的key必须存在，这点很重要，否则一旦有碰撞，计费就出问题了。

我们总结下上面的内容：

我们再看看整个存储体系完整的拓扑图。

第五个圆圈是为了在实时计算出错时，通过 Spark/MR 进行数据恢复。
第二个圆圈和第四个圆圈是为了做维度复制，比如我计算了五分钟的值，这些值其实可以自动叠加到对应的小时和天上。我们称为分裂程序
第三个圆圈就是对外吐出数据了，由我们的统一查询引擎对外提供支持查询支持了。

我们对查询做一个推演。如果我要给用户绘制流量的一个月曲线图。曲线的最小粒度是小时，小时的值是取 12 个五分钟里最高的值，我们看看需要取多少条记录完成这个查询。

我们需要取 31 条五分钟的记录，每条记录有 288 个点，对这 288 个点分成 24 份(具体就是把分钟去掉 groupBy 一下)，求出每份里的最大值(每组 SortBy 一下)，这样就得到了 24 个值。

我取过两天的，整个 HTTP 响应时间可以控制 50ms 左右（本机测试）。

上面的整体架构中，分裂程序是为了缓解实时写入 HBase 的压力，同时我们还利用 MR/Spark 做为恢复机制，如果实时计算产生问题，我们可以在小时内完成恢复操作，比如日志的收集程序、分拣程序、以及格式化程序。格式化程序处理完之后是 kafka，Storm 对接的是 Kafka 和 HBase。

上面就是今天分享的内容了。
感谢大家。

Q：海量存储容灾备份怎么做？

Q：祝同学现在的工作主要是哪些？我也是做云服务器的，想请教下以后的职业发展。

Q：祝老师能介绍下架构中数据恢复的机制么？

Q：distinctcount，是该如何计算，比如在这一个月 ip 数？

Q：祝老师，您好，对于初学者进入打数据领域学习，有什么建议于指导，是否需要这么大量的支撑，平时可能遇不到您说的那种情况。

Q：老师我对您那个架构有一个问题既然有 1在计算为啥还要有 2 和 4？

Q：针对你们的一分钟设计，如果列值比较复杂，比如要分析用户数，用户来源，用户 ip 等等，这个时候怎么设计表结构？

Q：HBase 是否适合做实时统计分析，比如 group by 操作如何能够支撑高并发？

Q：祝老师您好，我最近要一个协处理器的功能，但是业务需要区别 hbase 的新增和更新，我在 Google 找到 incrementcolumnvalue 可以做到，但是目前并没有试成功，请问您有没有这方面的经验或者建议呢？谢谢！ 关于hbase 性能测试和hbase性能优化包含哪些的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 hbase 性能测试的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于hbase性能优化包含哪些、hbase 性能测试的信息别忘了在本站进行查找喔。