分布式应用解决方案-linkbase

《分布式应用解决方案-linkbase》由会员分享，可在线阅读，更多相关《分布式应用解决方案-linkbase（8页珍藏版）》请在金锄头文库上搜索。

1、分布式应用解决方案linkbase 一、分布式linkbase背景 1、背景介绍 网页链接库（简称linkbase）是百度搜索引擎中重要的一部分，它存储的链接数量、更新速度等直接影响到从整个互联网抓取网页的效率和质量，从而影响搜索结果。下面的示意图说明了linkbase在网页抓取和处理中的位置以及和其他模块、系统的关系。 Link库存储spider所需要的链接数据 Select将待抓取的链接从link库中选出，发送给抓取系统CS到互联网上抓取网页 Saver将收到的新链接合并到link库中 EC将CS抓取的网页进行分析，交给DC分发给不同的存储系统，DC将网页数据发送到webinfoDB存储，

2、将链接数据发送给saver处理2、分布式网页链接库三个阶段的发展 百度的分布式网页链接库近几年经历了三个阶段的发展：第一阶段：基于主域分环的静态分布式linkbase。整个linkbase按照链接的主域进行划分到144台机器，每个主域的所有链接仅在一台机器存储和处理。主要问题是随着链接数大规模增长，存在严重的机器负载不均情况。第二阶段：基于分布式基础架构的分布式linkbase。采用分布式文件系统HDFS存储linkbase链接数据，分布式计算模型MapReduce进行linkbase的更新和挖掘。主要问题是linkbase存储为多个HDFS文件，这些文件大小差别很大（如10倍）时造成处理起来

3、时间被最大的文件拖长。第三阶段：基于分布式基础架构的自动均衡分布式linkbase。采用增加索引的存储方式和自动均衡输入数据的处理方式，解决文件大小不均的问题。二、基于主域分环的分布式linkbase 1、背景 基于单机架构的分布式linkbase将整个linkbase按照链接的主域进行划分，每个主域的链接仅被一台机器存储和处理，一台机器可以处理多个主域的链接。例如的所有链接由A机器处理，的所有链接由B机器处理，某几个小站点的链接由X机器处理。 2、存在的问题 这种架构缓解了用一台机器存储和处理所有linkbase数据的压力，在链接大量增长的情况下，存在下面几个严重的问题：(1)扩展性问题：

4、机器数量是固定的144台，增加机器相当困难，无法应对互联网数据不断增长的需求。 (2)负载均衡问题： 部分主域（如baidu, sina, qq）的链接明显比其他主域多，而一个主域的链接是不能分到多台机器的，所以链接最多的主域对应的机器就成为短板，它的硬盘和CPU压力都比其他机器大， 一方面这个主域的链接处理会比其他机器慢，另一方面这个主域的机器出现故障的可能行和影响也比其他机器要大。 (3)稳定性问题: 某台机器出现故障，它对应主域的链接处理就要停止，直到该机器恢复服务，期间会损失抓取流量。 三、基于分布式基础架构的linkbase 1、新的设计方案 为了解决上述单机架构分布式linkbas

5、e的问题，分布式linkbase基于已有的分布式基础架构进行了新的设计： (1)采用分布式文件系统HDFS： HDFS将文件的数据自动分布到集群的节点，保证文件的冗余副本，在部分机器下线时会自动进行副本拷贝保证数据可靠性。 (2)采用分布式计算模型MapReduce: MapReduce 利用整个集群的计算资源，将计算任务分配到各个节点执行，并提供了自动容错的能力。 2、新的设计中有几个关键的功能点： (1)要保证整个linkbase是按照URL长相全局有序的，因为linkbase需要提供按照URL随机访问和查找某个范围（如某个主域或站点）的链接的功能。 (2)超大主域不能成为短板，且能进行基

6、于主域的统计和处理。 (3)Linkbase的处理过程中有些大的词典、配置，不能全部加载到单机内存中。 3、分布式linkbase的存储方式 基于以上的功能要求，分布式linkbase的存储方式如下： (1)整个linkbase按照链接数量划分成N个HDFS文件，每个文件称作一个库文件，每个文件内部是升序的，第i个文件最后一个链接比第i+1个文件第一个链接小，因此整个linkbase 1 N 个文件顺序遍历是全局有序的； 这种存储方式下，一个主域的链接可能跨多个相邻的库文件，而不会集中在一个超大的库文件中。 (2)所有的词典、配置都划分成同数量的N个HDFS文件，划分的点和linkbase N

7、个文件的划分点完全一致，因此每个linkbase库文件有一些与之对应的词典、配置文件，这些文件的序号相同，都能加载到单机内存中。 4、linkbase的主要处理工作 在这种存储架构下，linkbase的主要处理都变得很简单： (1)新链接合并： 新链接先按照linkbase库文件的划分点进行排序并切分成同数量的N个HDFS文件，然后将进行合并，在MapReduce模型中，每个map加载第i号配置和词典，二路归并第i号库文件和新链接文件，写到新的库文件中。 (2)待抓取链接选取： 同样每个map加载第i号配置和词典，从第i号库文件中选取待抓取的链接。 5、linkbase存储和处理不同之处 词典

8、和配置大多是文本数据，使用广泛使用的文本格式存储和hadoop streaming处理即可，而linkbase的链接数据是二进制的，包括URL和其对应的属性，它的存储和处理有所不同： (1)用SequenceFile存储库文件，SequenceFile是hadoop中使用的一种二进制数据格式，它按照length,keylenthg,key,value的格式存储key/valule序列，每隔一段插入一个同步块以便定位，支持数据压缩。 (2)Linkbase的每个链接对应一个key/value对，key为实际链接数据，value为空，采用lzo压缩算法压缩数据。 (3)应用程序对数据进行处理采用b

9、istreaming二进制框架和libmapred C+编程接口，原有的linkbase C+代码可以方便地进行复用。 6、linkbase索引服务器 为了提供随机访问一条URL链接数据的功能，应用层利用SequenceFile的定位功能实现了linkbase索引服务器： (1)在合并新链接过程中写SequenceFile格式的linkbase库文件时，每隔一定数量的URL，就获取当前写入的位置，输出到索引文件。 (2)合并新链接过程结束后，通过MapReduce分布式将每个库文件的索引文件合并成一个索引文件。 (3)索引服务器将合并的索引文件加载到内存，对外提供根据URL查找对应的linkb

10、ase库文件和offset的功能，拿到文件和offset，就可 以利用SequenceFile的定位功能，定位到offset最近的同步块，然后读取少量数据就访问到URL对应的链接数据。 7、性能优化 分布式linkbase的一轮合并、选取时间影响spider的抓取流量，因此处理性能至关重要，进行了下面一些性能优化： (1)hadoop性能参数调整，包括map/reduce/shuffle的内存buffer，用lzo压缩代替gzip压缩。 (2)读写HDFS的C接口libhdfs缓存优化，单机单线程读速度从23MB/S提升到90MB/S。 (3)HDFS master节点namenode吞吐优化

11、，减少拒绝连接异常。 (4)通过profile发现应用层代码性能瓶颈并进行优化。 由于linkbase库文件的划分点和划分的文件数是固定不变的，随着新链接的不断合并，少数库文件变得很大，超过平均大小的10倍以上，一次链接合并或 选取的时间受到最大库文件的短板限制，在某些异常情况下链接暴涨时问题更明显，整体运行时间中高达50%是一个map在处理最大的一个库。 解决该问题的临时方案是定期对linkbase库文件以及对应的词典、配置文件进行重新切分，整个切分过程需要停止合并和选取，需要OP人工进行操作，时间在10小时左右，且随着数据量增加时间还会增长。 四、自动均衡的分布式linkbase 1、Li

12、nkbase库文件出现大小严重不均匀的根本原因 Linkbase库文件会出现大小严重不均匀的根本原因是，库文件按照固定的划分点划分成固定个数的文件，而库文件之所以要这样划分，是因为处理每个库文 件时要加载对的词典、配置，它们要和库文件保持对应，就必须有固定的划分点和文件数。因此要彻底消除这种不均的问题，就要改变库文件和词典、配置的划分方 式及对应关系。 最终采取的方案是建立索引： (1)每个词典、配置不用再划分成N份，而是建立一个对应的索引文件，索引文件的每一项长度固定以便二分查找，索引的key是URL长相，对应查找到相应的文件offset。 (2)第i个map不再固定地处理第i号库文件，而是

13、处理一块逻辑上连续的链接数据，且每个map处理的数据量大致相同，并能方便的获取这块链接数据的URL长相范围。 (3)不再加载第i号词典、配置文件，而是先获取到对应库文件的URL长相范围，然后根据这个范围的上下界和索引加载词典、配置对应范围的部分。 上述方案的关键有两点：一是保证每个map的输入数据逻辑上连续有序、大小相当，且map 0 map n输入数据是全局有序的，二是索引的查找要足够高效，且对应用层比较简单，尽量不要引入第三方系统。 2、BalancedInputFormat的主要特点 为了达到map输入均匀有序的目的，为linkbase库文件设计了新的输入数据格式切分和读取方式Balan

14、cedInputFormat，它的主要特点是： (1)要求输入的所有文件，按照某种方式（默认是字典序）将文件名排序后，从第一个文件开始到最后一个文件末尾是全局有序的。 (2)对于上面的输入，按照期望的平均大小（默认1GB）进行切分，每个map尽量处理平均大小的数据，这块数据可能正好是一个文件，也可能是几个相邻小文件的合并，也可能是某个大文件的一部分。 (3)每个map启动时，BalancedInputFormat对应的reader自动会读取当前map的第一条记录X和下一个map的第一条记录Y， 作为当前map处理的数据范围X, Y)，之所以是下一个map的第一条而不是当前map的最后一条，是因

15、为在合并新链接时，可能有新链接落在当前map最后一条后下一个map第一条之间， 这部分链接需要被当前map合并。 为了使索引简单高效，采用了下面的实现： (1)每个索引设计为一个HDFS文件，HDFS提供了文件seek操作，索引的每一项长度固定，因此可以进行快速的二分查找。 (2)索引文件比普通文件的副本数(3)高，避免所有机器从少数几个副本读取索引文件时副本所在的机器成为瓶颈。 五、总结 回顾分布式linbase的不断演进，不难发现，通过HDFS+MapReduce满足了linkbase的几个需求，其实也是比较通用的： (1)排序：以URL为key全局是有序的，每个文件局部也是有序的。 (2)自动分裂和聚合达到大小均衡：小的文件自动合并，大的文件自动拆分。 (3)随机和一个连续范围数据的访问：应用层为linkbase增加索引，提供了以URL为key的访问。 而这些正是Bigtable模型所提供的核心功能，Bigtable与之相比最大的区别是实时性要更好一些，所以目前分布式linkbase的模型实际上是用HDFS + MapReduce 实现了一个批处理的Bigtable。 这个模型抽象出来对于百度其他一些需要全局排序的存储计算需求也是能适用的，虽然实时性不如Bigtable，