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

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的内容有考虑吗？

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

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

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