技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 查看专题: 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的源码来简单分析解释这一现象。
    拿row counter这个简单例子来说,我要统计总行数,如果每个region 告诉我他又多少行,然后把结果告诉我,我再将他们的结果汇总一下,不就行了么?现在的问题是hbase没有提供这种接口,来统计每个region的行数,那是否我们可以自己来实现一个呢?没错,正如本文标题所说,我们可以自己来实现一个Endpoint,然后让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客户端API提供了Write Buffer的方式,即批量提交一批Put对象到HBase服务端。本文将结合HBase相关源码,对其进行深入介绍,分析如何在实际项目中合理设置和使用它。 什么时候需要Write Buffer? 默认情况下,一次Put操作即要与Region Server执行一次RPC操作,其执行过程可以被拆分为以下三个部分: T1:RTT(Round-Trip Time),即网络往返时延,它指从客户端发送数据开始,到客户端收到来自服务端的确认,总共经历的时延,不包括数据传输的时间; T2:数据传输时间,即Put所操作的数据在客户端与服务端之间传输所消耗的时间开销,当数据量大的时候,T2的开销不容忽略; T3:服务端处理时间,对于Put操作,即写入WAL日志(如果设置了WAL标识为true)、更新MemStore等。
    目前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分区情况,在集群内做数据的负载均衡。
    由于项目开发的需要,使用HBase作为数据统计应用的存储系统,这里是一些经验总结以及对于使用过程中存在问题的解决思路。
    目前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项目时碰到的各种奇怪、诡异的问题。
    本文以HBase 0.90.2为例,介绍如何在Windows系统,Eclipse IDE集成环境下,使用Java语言,进行HBase客户端编程,包含建立表、删除表、插入记录、删除记录、各种方式下的查询操作等。 1. 准备工作 1、下载后安装jdk包(这里使用的是jdk-6u10-rc2-bin-b32-windows-i586-p-12_sep_2008); 2、下载eclipse,解压到本地(这里使用的是eclipse-java-helios-SR2-win32); 3、下载HBase包,解压安装包到本地(这里使用的是hbase-0.90.2)...
[ 共28篇文章 ][ 第1页/共2页 ][ 1 ][ 2 ]
赞助商广告
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1