HBASE在QIHOO 360搜索中的应用

【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非常擅长解决这些问题,并且扩展性、可靠性高。

HBASE在QIHOO 360搜索中的应用_第1张图片

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)