HBASE在QIHOO 360搜索中的应用

标签: hbase qihoo 搜索 | 发表时间:2015-04-07 06:10 | 作者:zhangxiong0301
出处:http://www.iteye.com

【CSDN现场报道】中国IT界技术盛会——Hadoop与大数据技术大会(Hadoop&BigData Technology Conference 2012,HBTC 2012)于2012年11月30日-12月1日在北京新云南皇冠假日酒店隆重召开。本次大会以“大数据共享与开放技术”为主题,聚焦于Hadoop与大 数据,力邀数十位国内外Hadoop及大数据技术应用的产学界人士和实践企业,探讨大数据技术生态系统的现状和发展趋势,并围绕Hadoop与大数据热点 技术和应用实践进行深入解析。

在12月1日“大数据应用”主题分论坛,QIHOO 360系统部工程师赵健博带来的议题是《HBase系统在搜索网页库的应用》。为什么是HBase?他表示这是因为搜索网页库数据规模巨大,而且网页通常会有多个版本,而HBase非常擅长解决这些问题,并且扩展性、可靠性高。

QIHOO 360系统部工程师 赵健博

以下是演讲实录:

赵健博:这次主要介绍的内容是说360在使用HBase应有到网页库业务上的应用情况。

这次想要介绍的主要内容包含以下五个地方,第一点为什么我们选择HBase?这个主要从网页库需求入手分析的。第二点,介绍一下目前在360这边使用HBase的集群规模和使用的版本情况。第三,重点介绍一下在我们使用HBase服务网页库业务的过程中,我们遇到的一些问题,以及我们一些改进的方法。从这个小节里可以看出,其实每次报告我们重点介绍的是HBase本身,而不是业务本身。第四,介绍一下未来我们要做的工作。最后对于网页库这个业务,我们用HBase服务监控的一些工作。

我们为什么选择HBase系统?

网页库顾名思义,就是要存下互联网上所有网页的资源,这个数据量通常是非常巨大的。涉及到网页的调控数通常是千亿级别的,HBase有一种海量数据的存储系统,能够满足这么大的数据存储需求。所以第一没有问题。

第二,网页库中每个网页需要保留版本,HBase在功能设计之初就支持。

第三,网页库的规模不是一下子长到很大,而是逐步怎样上去,对于我们集群来说,也是一下子的调到这么大的规模,所以集群通常具有高扩展的能力。

第四,数据一旦存储以后不能丢失,HBase的高可靠性也是这点需求的。

第五,数据存到网页库中,光存储没有意义,更重要的是根据这些数据进行提取和挖掘,能够获得有价值的信息,这是最重要的。所以我们需要强大的分析工具来完成这个事情。HBase天然的可以完成这些框架。

除了满足上面的需求,在数据读取方面,每天我们有TB新增数据导入到网页库中,这样的话需要高效的数据导流方式,HBase可以将海量数据导入。另外一个网页要存在多种属性,比如它包含的正文、链接、标签是怎样的,会有很多。经常这些属性会有增、删、改的需求,HBase满足了这些需求。所以对这些需求来讲,HBase也是能够满足我们需且的。

作为数据读取方面,网页库经常有按列,就是按一种属性,HBase提供了列的概念,能够达到高效按列读取的需求。所以说第一条也是满足的。第二条也在很多时候,我们可能要扫一些某一个站点下所有网页所有的相关属性的需求。第三,在有些时间我们需要获取一批网页库的相关属性,这批网页很随机,不是说连续或者说规律的,通常可能分布在网页库的不同地方。这样的话HBase系统对K键索引,提供了快速查找的共凝,所以批量的读取也是可以满足的。第四,获得某个时间段范围内的网页属性,HBase提供了按时间范围查找的接口,通过这个接口也是可以满足需求的。

经过上述的这些对需求的分析,我们可以确认目前HBase系统是能够满足目前对网页库相关的所有需求,所以我们就选择了HBase系统作为我们网页库的后台支持的方案。需求方面,为什么我们选择了HBase就这么多。

下面看一下我们的集群规模情况。

目前HBase集群300个节点,大于10万个region。集群选用的版本选用了Facebook开源出来的版本。

接下来重点介绍一下我们在使用过程中HBase遇到的一些针对网页库的业务,我们遇到的一些问题,以及我们改进的方法。

这些问题11个,规一下类别有几个方面:

第一,数据导入,相关的问题有四个。第二个问题关于Compaction方面,有三个问题。第三个方面,关于Split。在这方面的问题有三个。第四方面,一旦HBase有异常,恢复时间在改动之前比较长,改动以后恢复时间比较短了。关于这个问题有一个。

下面看一下数据导入方面的四个问题:

第一,在我们进行数据导入的过程中,我们发现调用Put接口切入数据的话,这种写入的性能不是高效的。原因有两个,我写一份数据的时候,写路径上Commitlog的写与Sync过程持锁进行IO操作,阻塞并发写线程,不够高效。还有compaction与写commitlog占用额外的磁盘于网络资源。第二,采用bulklmport方式导入数据,效率极大提升。

问题二,bulklmport的数据准备阶段对输入文件格式的处理不够通用。原因是bulklmport的数据准备阶段程序对输入文件格式所有限制,不能满足公司内部原文件的文件格式。所以为了以后处理的方便,我们就把这个数据准备阶段程序进行了一次重写,提供了推用了数据文件数据格式的解析框架。有了这个框架以后,后续各种格式的输入文件都可以通过这个文件来解决。

问题三,bulklmport的数据准备阶段,当region数很大时,数据准备阶段的时间较长。原因是这样的,大量reduce从map中shuffle很少数据,或者甚至没有数据,导致整体shuffle过程低效。因此我们做了改进,修改了rartition与reduce逻辑,使得一个reduce可以生成多个region的数据。通过这个修改以后,这里有一个比较,对于10TB数据修改,修改前需要五个小时,修改后一个小时就可以完成了。

问题四,bulklmport的数据导入阶段比较慢。目前的导入阶段时间比较长,原因是bulklmport的数据导入阶段,是单进程串行进行。改进的方式是MR版本的数据导入程序,并发了数据导入过程。改进后60万文件的规模以前需要2到3小时,改进后需要30分钟。

以上四个问题设计了关于数据导入方面我们遇到的问题。接下来的三个问题主要是和compaction相关。

问题五是使用bulklmport后,compaction操作会产生大量的IO。经过分析以后我们发现现有的compaction的文件选择算法对bulklmport的后的文件支持不好,可能会选择到大文件,从而产生大量的IO。改进的方法是手动触发compaction新接口,可选择文件大小范围,时间范围,以及文件个数。另外一个改进是提供自动minor compaction的开关,可将其关闭。

提问:你们有没有考虑开源呢?

赵健博:目前还没有考虑,但是将来成熟的话会考虑。

提问:你讲的这些已经在360落地了?

赵健博:对,现在已经开始用了。我继续。

下面是第六个问题。问题六:compaction的并发调整整理需重regionserver,代价较高。我们分析原因,regionserver起动时读取配置,后续不可更改。针对这个问题,我们利用了现有的HBase,将compaction并发参数更改的功能通过HTTP服务提供。

和compaction相关的第三个问题也就是第七个问题,目前compaction的并发可以控制,但是单个compaction线程的执行速度却没法口头。原因是代码尚未实现单并发限速功能。所以在compaction的路径上增加限速功能,提供参数调整接口,可通过HTTP方式动态更改。

上面的三个问题是与compaction相关的问题,通过这三个问题解决以后,我们可以严格的控制速度和网络带宽占有的情况,有了这些改进以后,可以对业务的不同情况灵活的加以调整满足业务的需求。

接下来介绍一下关于regioe遇到的三个问题。第一个问题是我们发现比较严重的问题,多CF的表可能出现带有引用文件的regioe也能够被分裂的情况,从而导致该regioe不能被正常的打开。原因是regioeSplit时,仅仅对第一个CF进行了检测。改进很直观,就是regioe Split时,检测regioe中任何一个CF中存有引用文件,则禁止分裂该regioe,这样的话就解决了这个问题。

下面是第二个关于分裂的问题,多CFregioe Split后,两个daughter的数据不均匀。原因是regioe Split时只根据第一个CF的分裂点进行分裂。改进的方法是regioe Split时,选择数据最大的那个CF的分裂点进行分裂。

关于分裂的最后一个问题,因为我们每天对regioe进行分裂,有些时候如果有一天数量比较比较多,regioe的个数也会比较多,当regioe达到一定的数量,regioe分裂的触发过程变得也比较长,这个不是regioe分裂的过程,而是发命令过程比较长。分析他们目前的原因,目前触发regioe Split的借口是是通过扫描一次META来判断Split的目标是regioe还是table。改进的方法是提供Split regioe接口。效果比较是比原来提高了一千倍。

最后一个问题关于meta表到一定规模后,RS异常宕掉后,master触发的恢复时间比较长。我们分析发现在scan meta表,查找异常regioe的过程效率低下,消耗了大量的时间。改进的方法是使用caching模式,扫描meta表,之前是20到25分钟完成,现在2到3分钟完成。

这是在我们使用网页库的过程中遇到的问题,简单的跟大家分析了一下,以及介绍一下我们目前改进的方式。

未来有两点还需要继续做,我们需要优化减少HBase集群启停时间。第二个工作,进一步优化减少RS异常退出后的恢复时间。在RS宕掉后要尽快的发现它,主要包含两大步骤,一个是对RS按照regioe分裂,第二部分是扫描meta表。

最后介绍一下我们目前运维控制的工作。

第一,compaction和Split每天手动触发,我们把分裂,而且最近把compaction的功能全部关闭了,所以我们期望regioe,compaction分裂每天一次,这样的话涉及到的数据量是何以严格控制的,尽可能的把资源提供出来给业务使用。还有我们信息有一个详细的统计。第三,我们会针对目前每天普用户regioe的详细的信息。第四,我们在使用HBase系统使用中并不是非常的强壮,比如regioe关了,我们meta并不知道。第五,meta提供的健康状态检测。第六,应用级别监控。

本次想介绍的就这么多,大家还有什么问题?

提问:真个的数据流向是怎样的?

赵健博:跟业务相关,我也不是很清楚,但是我觉得先落一次地。

提问:是先存到业务机还是先存到HBase上?

赵健博:这个我不太清楚,因为具体到相关的业务细节了。

提问:HA的内容有考虑吗?

赵健博:因为我们这方面的需求不是很强烈,所以还没有考虑。

提问:我看你们每一个网页趴的内容是放在多个上还是一个上?

赵健博:目前是多个上面。



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [hbase qihoo 搜索] 推荐:

HBASE在QIHOO 360搜索中的应用

- - 开源软件 - ITeye博客
【CSDN现场报道】中国IT界技术盛会——Hadoop与大数据技术大会(Hadoop&BigData Technology Conference 2012,HBTC 2012)于2012年11月30日-12月1日在北京新云南皇冠假日酒店隆重召开. 本次大会以“大数据共享与开放技术”为主题,聚焦于Hadoop与大 数据,力邀数十位国内外Hadoop及大数据技术应用的产学界人士和实践企业,探讨大数据技术生态系统的现状和发展趋势,并围绕Hadoop与大数据热点 技术和应用实践进行深入解析.

HBase在淘宝主搜索的Dump中的性能调优

- - 搜索技术博客-淘宝
目前HBase已经运用于淘宝主搜索的全量和增量的数据存储,有效的减低的数据库的压力,增强了业务扩展的能力. Dump系统的特点是要求在短时间内处理大量数据,对延时要求高. 在实施这个项目过程中,我们积累了一些优化的实践,抛砖引玉,供大家参考. 环境:Hadoop CDH3U4 + HBase 0.92.1.

基于Nutch+Hadoop+Hbase+ElasticSearch的网络爬虫及搜索引擎

- - zzm
网络爬虫架构在Nutch+Hadoop之上,是一个典型的分布式离线批量处理架构,有非常优异的吞吐量和抓取性能并提供了大量的配置定制选项. 由于网络爬虫只负责网络资源的抓取,所以,需要一个分布式搜索引擎,用来对网络爬虫抓取到的网络资源进行实时的索引和搜索. 搜 索引擎架构在ElasticSearch之上,是一个典型的分布式在线实时交互查询架构,无单点故障,高伸缩、高可用.

从未降级的搜索技术 – HBase集群升级与优化

- - 搜索技术博客-淘宝
战争从来都是拼后勤拼平台支撑的,天猫双十一这一天对于我们搜索事业部来说,就是一场高强度的数字化战争. 为了这一天,各兄弟业务线的战友们已经摩拳擦掌,纷纷亮出各种新式武器,而我们原有的离线系统平台却渐渐显出疲态,慢慢被来自各业务线的不断提升的压力需求搞得捉襟见肘了. 个性化搜索实时数据处理平台(Pora)在双十一将正式亮相,当时我们预计会有数以十亿计的新增HBase读写请求,如果不进行升级优化,原有的离线集群预计将无法承受这一前所未有的压力;天猫业务线的增量在双十一更是重中之重,届时预计会有数倍甚至十多倍的增长,不断流,不延迟对于原有的离线集群来说也是巨大的考验;主搜、国际站等业务线也都对底层平台提出了越来越高的要求,凌晨全量的时间极其有限,不能出现任何闪失.

hbase介绍

- AreYouOK? - 淘宝数据平台与产品部官方博客 tbdata.org
hbase是bigtable的开源山寨版本. 是建立的hdfs之上,提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统. 它介于nosql和RDBMS之间,仅能通过主键(row key)和主键的range来检索数据,仅支持单行事务(可通过hive支持来实现多表join等复杂操作). 主要用来存储非结构化和半结构化的松散数据.

Riak对比HBase

- - NoSQLFan
文章来自 Riak官方wiki,是一篇Riak与HBase的对比文章. Riak官方的对比通常都做得很中肯,并不刻意偏向自家产品. 对比的Riak版本是1.1.x,HBase是0.94.x. Riak 与 HBase 都是基于 Apache 2.0 licensed 发布. Riak 的实现是基于 Amazon 的 Dynamo 论文,HBase 是基于 Google 的 BigTable.

[转]HBase简介

- - 小鸥的博客
   Hbase是一个分布式开源数据库,基于Hadoop分布式文件系统,模仿并提供了基于Google文件系统的Bigtable数据库的所有功能. 其目标是处理非常庞大的表,可以用普通的计算机处理超过10亿行数据,并且有数百万列元素组成的数据表. Hbase可以直接使用本地文件系统或者Hadoop作为数据存储方式,不过为了提高数据可靠性和系统的健壮性,发挥Hbase处理大数据量等功能,需要使用Hadoop作为文件系统.

HBase表设计

- - 互联网 - ITeye博客
默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据, 直到这 个region足够大了才进行切分. 一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入HBase时,会按 照 region分区情况,在集群内做数据的负载均衡.

HBase Memstore配置

- - 行业应用 - ITeye博客
HBase Memstore配置. 本文为翻译,原英文地址:http://blog.sematext.com/2012/07/16/hbase-memstore-what-you-should-know/.     当regionserver(以下简称RS)收到一个写请求,会将这个请求定位到某个特定的region.

hbase原理

- - CSDN博客云计算推荐文章
1.hbase利用hdfs作为其文件存储系统,利用mapreduce来处理数据,利用zookeeper作为协调工具. 2.行键(row key),类似于主键,但row key是表自带的. 3.列族(column family) ,列(也称作标签/修饰符)的集合,定义表的时候指定的,列是在插入记录的时候动态增加的.