您现在的位置：首页 --> 查看专题： hbase
HQueue是一淘搜索网页抓取离线系统团队基于HBase开发的一套分布式、持久化消息队列。它利用HTable存储消息数据，借助HBase Coprocessor将原始的KeyValue数据封装成消息数据格式进行存储，并基于HBase Client API封装了HQueue Client API用于消息存取。
HQueue可以有效使用在需要存储时间序列数据、作为MapReduce Job和iStream等输入、输出供上下游共享数据等场合。
高并发读写HBase的应用需要尽量保证对HBase的合理使用，不合理的使用有可能会导致某一个region server甚至整个hbase集群的性能出现问题，而hbase的性能问题又反过来使得所有应用性能下降，此时如果应用选择继续加大对hbase的并发访问，甚至有可能因此陷入一个性能继续变差的恶性循环。
针对HBase在单column family单column qualifier和单column family多column qualifier两种场景下，分别批量Put写入时的性能对比情况，下面是结合HBase的源码来简单分析解释这一现象。
HBase 0.92版本之后，Region Server的Compact过程根据待合并的文件大小分为small compaction和large compaction两种，由此可能导致在集群写入量大的时候Compact占用过多的网络出口带宽。本文将详细描述集群使用过程中遇到这一问题的排查过程及其解决方法。
这里结合对HBase Thrift接口（HBase版本为0.92.1）的使用经验，总结其中遇到的一些问题及其相关注意事项。 字节的存放顺序 HBase中，由于row（row key和column family、column qualifier、time stamp）是按照字典序进行排序的，因此，对于short、int、long等类型的数据，通过Bytes.toBytes(…)转换成byte数组后，必须按照大端模式（高字节在低地址，低字节在高地址）存放。对于value，也是同样的道理。因此，在使用Thrift API（C++、Php、Python等）方式时，最好对于row和value都统一按照大端进行pack和unpack处理。
HBase集群在读写过程中，可能由于Region Split或Region Blance等导致Region的短暂下线，此时客户端与HBase集群进行RPC操作时会抛出NotServingRegionException异常，从而导致读写操作失败。这里根据实际项目经验，详细描述这一问题的发现及排查解决过程。 1. 发现问题 在对HBase集群进行压力测试过程中发现，当实际写入HBase和从HBase查询的量是平时的若干倍时（集群规模10~20台，每秒读写数据量在几十万条记录的量级），导致集群的读写出现一定程度的波动。
本文结合HBase 0.94.1版本源码，对HBase的Block Cache实现机制进行分析，总结学习其Cache设计的核心思想。 1. 概述 HBase上Regionserver的内存分为两个部分，一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读。 写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满64MB以后，会启动 flush刷新到磁盘。当Memstore的总大小超过限制时（heapsize * hbase.regionserver.global.memstore.upperLimit * 0.9），会强行启动flush进程，从最大的Memstore开始flush直到低于限制。
目前HBase已经运用于淘宝主搜索的全量和增量的数据存储，有效的减低的数据库的压力，增强了业务扩展的能力。Dump系统的特点是要求在短时间内处理大量数据，对延时要求高。在实施这个项目过程中，我们积累了一些优化的实践，抛砖引玉，供大家参考。环境：Hadoop CDH3U4 + HBase 0.92.1 1、 尽可能用LZO 数据使用LZO，不仅可以节省存储空间尤其是可以提高传输的效率，因为数据是在regionserver端作解压的。通过测试，可以明显提高HBASE从HDFS的读的性能。尽量不用GZ的方式，GZ的方式在bulkload时有线程安全问题。 2、 根据场景调整Block size 由于使用我们非常关注随机读的性能，一条记录的长度较小，通过设置blocksize=8k，可以提高随机读的性能。
(H2与HBase)面向行or面向列的存储模型? 目录 0. 示例 1. H2怎么存储pet表的记录? 1. 1 DATA_LEAF页格式 1. 2 DATA_NODE页格式 2. HBase怎么存储pet表的记录? 2. 1 Data Block格式 2. 2 Data Block如何存下面这些记录? 2. 3 leaf索引块的格式: 2. 4 root索引块的格式: 2. 5 IntermediateLevel索引块
HBase的优点：分布式，易扩展，高性价比，运维成本低都是它的优点。HBase可以支持海量数据，单张表的数据量不上T，都不好意思出来打招呼。甚至可以拿很烂的SATA盘来作为存储，由于依赖底层的HDFS。新装的机器甚至可以不用做硬RAID。
HBase 中的LoadBalancer策略控制了如何在集群启动时Assign所有用户Region到各个RegionServer上，以及如何定期检查Region分布情况并重新调整Region位置的。这些工作在0.92之前的版本中都是在HBase Master内核中实现的，开发人员如果希望扩展自己的LoadBalancer插件，只能Hack源码，但这随着社区版本的升级，Hack工作必须移植到新的版本中。幸好在0.92版本中，HBase将LoadBalancer策略从Master内核中抽取了出来，开放了LoadBalancer Interface，允许开发者根据自己的业务特定扩展自己的LoadBalancer插件。
目前稳定版本的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应用程序设计与开发的角度，总结几种常用的性能优化方法。有关HBase系统配置级别的优化，这里涉及的不多，这部分可以参考：淘宝Ken Wu同学的博客。 1. 表的设计 1.1 Pre-Creating Regions 默认情况下，在创建HBase表的时候会自动创建一个region分区，当导入数据的时候，所有的HBase客户端都向这一个region写数据，直到这个region足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创建一些空的regions，这样当数据写入HBase时，会按照region分区情况，在集群内做数据的负载均衡。
目前NoSQL产品最被人诟病的就是其稳定性，不得不承认，目前HBase离做到数据库那样的高稳定还有距离（丢数据、不能读写、DDL失败等严重问题），这篇blog将用来记录我们在运维HBase时碰到的问题（会不断更新），希望能给使用HBase的同学有一些帮助。
NoSQL现在风生水起，hbase的使用也越来越广，但目前几乎所有的NoSQL产品在运维上都没法和DB相提并论，在这篇blog中来总结下我们在运维hbase时的一些问题以及解决的方法，也希望得到更多hbase同行们的建议，:) 在运维hbase时，目前我们最为关注的主要是三大方面的状况： 1. Cluster load； 2. 读写； 3. 磁盘空间。
根据最近生产环境使用的经验，更多的项目的采用，以及采用了更加自动的测试平台，对HBase做了更多的场景的测试，在这篇blog中来分享下纯粹的随机写和随机读的性能数据，同时也分享下我们调整过后的参数。 ps: 强烈推荐同事的blog，其中记录了很多我们对HBase的改进，以及我们在运维HBase项目时碰到的各种奇怪、诡异的问题。
[ 共28篇文章 ][ 第1页/共2页 ][ 1 ][ 2 ]
近3天十大热文
-
[67] Go Reflect 性能 -
[66] Oracle MTS模式下 进程地址与会话信
-
[63] 如何拿下简短的域名
-
[61] android 开发入门
-
[60] 【社会化设计】自我（self）部分――欢迎区
-
[59] IOS安全–浅谈关于IOS加固的几种方法
-
[59] 图书馆的世界纪录
-
[54] 视觉调整－设计师 vs. 逻辑
-
[49] 读书笔记-壹百度:百度十年千倍的29条法则
-
[48] 界面设计速成
赞助商广告
