淘宝主搜索离线集群完成hadoop2.0升级

标签: 其他 分布式技术 | 发表时间:2014-03-12 01:49 | 作者:天风
出处:http://www.searchtb.com

搜索离线dump集群(hadoop&hbase)2013进行了几次重大升级:

alt

2013-04

第一阶段,主要是升级hdfs为2.0版本,mapreduce仍旧是1.0;同时hbase也进行了一次重大升级(0.94.5版本),hive升级到0.9.0;

2013-09,2013-12

第二阶段,主要升级mapreduce到2.0版本即(YARN),hive升级到0.10.0,在13年年底的时候对hbase进行了一次小版本升级;

至此,dump离线集群完全进入2.0时代:

alt

通过升级hdfs 2.0优化shortcircuit read,使用domain socket通信等等提升了效率,加快了任务运行速度,同时支持成熟的NAMENODE HA,Federation,解决了让大家担心的集群NN单点问题,集群容量和扩展性得到大大提升。

alt

通过升级yarn对集群资源进行更有效的管理,摒弃了slots的物理划分,采用内存资源控制使集群资源被更有效的利用,从而提高整个集群的吞吐,同时支持丰富的计算框架,为后续DUMP应用架构优化调整提供了广阔的舞台。

当然集群的升级过程也遇到了很多问题和困难

第一阶段升级过程中遇到的主要问题:

1)hdfs升级为2.0后,需要同时升级下hive版本(hive-0.9.0-cdh4.1),之前使用老版本hive jar编译的任务需要使用新版本jar包重新编译

2)mr1任务要运行在hdfs 2.0上部分任务会运行失败,主要是2.0中将原来的class换成了interface,需要重新编译即可,少量代码需要添加下throws IOException,依赖的hadoop-core jar包也被拆分成了几个(common,hdfs,mr1等)

3)hdfs shell命令差异,主要是针对mkdir或者touchz等中间如果有不存在的路径不会自动创建

4)从云梯distcp数据由于hdfs版本不兼容,必须使用hftp的方式,且因hftp不支持密码访问,后来patch解决

5)升级hdfs 2.0后集群整体读I/O升高明显,从而导致特别是I/O需求高的build任务延时

原因是2.0对dfs.client.read.shortcircuit的调整,在检查是否有权限(dfs.block.local-path-access.user中配置的用户名)进行shortcircuit读取时如果没有权限会将本地的datanode作为deadnode处理,然后数据通过远程读取

又因为hbase中dfs.client.read.shortcircuit.buffer.size设置的值不合适导致多读了很多无谓的数据,导致整个集群I/O升高

解决方案:

设置dfs.client.read.shortcircuit.buffer.size=16K与hbase的block的大小相匹配

详细的分析过程见:

http://www.atatech.org/article/detail/2733/193

http://www.atatech.org/article/detail/7207/193

第二阶段升级遇到的主要问题:

1)升级到yarn后,Capacity Schedule进行了更新,job提交只需要指定叶子queue名字即可,指定全路径会报错

2)没有了map/reduce slots的概念,集群只需配置可用的内存大小,主要的参数:

集群:

yarn.nodemanager.resource.memory-mb:                            一个nodemanager上可分配给container使用的物理内存大小
yarn.scheduler.minimum-allocation-mb:                                  resource manage分配内存的最小粒度,暂设成1024,job提交需要内存必须为此参数的整数倍
yarn.scheduler.capacity.<queue>.maximum-am-resource-percent:   am所占资源比例,可按queue设,暂设成0.3
yarn.scheduler.capacity.<queue>.user-limit-factor:            单个用户提交job限制,可按queue设,单用户如要抢占最大资源,需要设大

应用:

mapreduce.map.memory.mb,mapreduce.reduce.memory.mb:          map,reduce的内存数,默认是1024,2048,如需设大,必须是1024的整数倍,可以简单理解为之前的slots数配置
mapreduce.map.java.opts,mapreduce.reduce.java.opts:           java child进程的jvm heap大小,比上面的值小些
mapreduce.job.reduce.slowstart.completedmaps:                      对于map数较多需要跑多轮,可以设大此值,延迟reduce启动避免占用资源

3)yarn中不在兼容commons-cli-2.0-SNAPSHOT.jar,之前通过将该jar文件copy到hadoop classpath中使用的应用需要部署到各自应用的相关目录下,并在提交任务的时候引用

4)一些使用0.19等老版本的hadoop-streaming.jar需要更换为新版本

5)container内存超配被kill掉,考虑到job内存的自然增长及一些使用共享内存的任务,所以设置yarn.nodemanager.vmem-pmem-ratio=false关闭物理内存检查

6)客户端向AM获取job status报错:IOException

原因是AM内存设置太小,频繁GC导致,通过调大yarn.app.mapreduce.am.resource.mb解决

7)c2c_merge任务在yarn上运行缓慢

经过排查分析是因使用的mmap文件在pagecache中频繁换进换出导致,根本原因还是18与32内核的差异,因为集群升级过程中也对内核进行了升级,通过修改应用代码

去除madvise设置的MADV_SEQUENTIA后问题解决,参考:

http://baike.corp.taobao.com/index.php/Kbuild在32内核上性能退化问题

8)IPV4和IPV6差异引起的长短机器名问题及job data local比例低的问题

在yarn resource manager下显示部分机器是长机器名,部分机器是短机器名

hbase集群下显示全是长机器名,原因是yarn与hbase获取机器名调用的方法不一样,得到的结果也不一样,导致resourcemanager在分配container时进行优先的host匹配是匹配不上,最后变成任意匹配导致

获取机器名差异的根本原因经过分析是java处理ipv6有bug和yarn脚本bug共同导致

http://bugs.sun.com/view_bug.do?bug_id=7166687

http://www.atatech.org/article/detail/10731/193

解决方案1是修改yarn脚本,并提交issue到社区: https://issues.apache.org/jira/browse/YARN-1226

解决方案2就是给集群配置上机架感知,且让一个机器一个rack的虚拟机架配置,通过rack匹配绕开任意匹配,在 http://www.atatech.org/article/detail/10731/193 中有详细分析

9)由于我们当时在方案1还未得出结论前临时采用方案2快速解决线上data local低的问题后发现有部分任务提交失败报错: Max block location exceeded for split

原因是:配置了一个节点一个机架后CombineFileInputFormat获取split的block localtion时会根据block分布在哪些rack上获取locations信息,由于机架数等同于机器数,获取到的localtions数会超过集群的默认配置:

mapreduce.job.max.split.locations = 10,而yarn上修改了代码会在超出这个配置值时抛出异常,所以任务提交失败

解决方案1:增大mapreduce.job.max.split.locations和集群节点数一致

解决方案2:patch修改JobSplitWriter中超过配置值抛异常为打印警告日志,与升级前一致

详情见: http://www.atatech.org/article/detail/11707/193

10)gcih不能正常工作

GCIH: http://baike.corp.taobao.com/index.php/GCIH

不能正常工作的原因有两个:

l 集群升级到yarn后,nm管理job临时目录和distribute file的方式与tt不同,导致GCIH会生成多个mmap文件gcih.dat

l 在修复上述问题的过程中,发现散列到不同磁盘上task,jvm classpath加载顺序不一致,导致GCIH不能正常工作

解决方案,升级GCIH

将gcih.dat生成到gcih.jar软连对应的源目录下,这样一个job只会有一个

调整gcih.jar的加载顺序,放到preload里

11)集群资源使用100%,job一直hang住

当集群root跑满100%而下面的子queue未满时(因为希望集群的资源共享竞争,queue的最大可用资源会进行适当的超配)

不会触发抢占reduce资源的过程

解决方案:

l 不同queue的大任务尽量避开运行

l 后续patch修改在root满时触发抢占

详细分析过程见:

http://www.atatech.org/article/detail/10924/193

12)load任务写hbase偶尔会卡住

原因是当集群中有节点挂掉或者网络等出现异常可能会导致hbaseclient在select时无线等待,而锁无法释放

解决方案:

在hbase client的代码里设置超时时间

具体原因分析见:

http://www.atatech.org/article/detail/9061/193

13)集群有节点出现问题,上面的任务一直失败,后续别的任务起来后还会将container分配到这个节点

原因是yarn和之前mr1黑名单机制发生了改变

mr1是全局的黑名单,一旦被加入黑名单后续任务不会再分配

yarn的黑名单是在AM上的,也就是任务级别的,被AM加入黑名单后可以保证当前任务不会被分配上去,但是其他任务的AM中是没有这个信息的,所以还是会分配任务上去

解决方案:等待NM将节点健康信息汇报给RM,RM将节点从集群摘除

如果一直无法汇报,可以通过yarn支持的外围用户脚本来做健康检查和汇报(需要在yarn配置中配置该脚本)

详细分析见:

http://www.atatech.org/article/detail/11266/193

hive相关:

1)out join被拆成多个job

问题发现:loader在做多表join的过程时原来的一个job被hive拆成了8个job,耗时由原来的3分钟变成30分钟

通过patch解决,参考:

http://mail-archives.apache.org/mod_mbox/hive-user/201305.mbox/+r2mdv_tsofa@mail.gmail.com>

https://issues.apache.org/jira/browse/HIVE-4611

2)设置mapreduce.map.tasks不生效

分析是Hive的InputFormat的问题

如InputFormat设置为org.apache.hadoop.hive.ql.io.CombineHiveInputFormat,需要设置mapreduce.input.fileinputformat.split.maxsize来控制map的个数

如InputFormat设置为org.apache.hadoop.hive.ql.io.HiveInputFormat,则此参数生效

解决,将hive配置中默认的InputFormat配置成org.apache.hadoop.hive.ql.io.HiveInputFormat

3)写redis的hive job拆成了两个job

hive默认设置中,当map输出文件太小,会新起一个job合并小文件

解决方案:set hive.merge.mapfiles=false;

仍然存在待解决的问题:

1)有部分job会导致单disk io到100%,拖慢这个任务

2)机器出现异常问题,task全部都在localizing,job一直pending,只能kill掉重新提交

3)job或者task被kill掉后,日志也被删除,history中看不到该job的信息,排查问题困难

集群HADOOP 2.0的升级,在更好的支持现有业务:主搜,商城,店铺内,PORA个性化,尼米兹平台,中文站(offer,company,minisearch),国际站(ae,sc,p4p,aep4p,scp4p)的基础上为后续离线dump平台:ADUMP的建设夯实了基础。

一个统一存储,模块插件化设计,减少各业务线之间数据冗余,避免重复开发,同时支持快速响应各条业务线新需求的全新平台ADUMP将在3月底左右上线,紧跟集群升级的节奏,离线DUMP也将马上进入2.0时代,敬请期待!

相关 [淘宝 搜索 集群] 推荐:

淘宝主搜索离线集群完成hadoop2.0升级

- - 搜索技术博客-淘宝
搜索离线dump集群(hadoop&hbase)2013进行了几次重大升级:. 第一阶段,主要是升级hdfs为2.0版本,mapreduce仍旧是1.0;同时hbase也进行了一次重大升级(0.94.5版本),hive升级到0.9.0;. 第二阶段,主要升级mapreduce到2.0版本即(YARN),hive升级到0.10.0,在13年年底的时候对hbase进行了一次小版本升级;.

【读图】淘宝搜索排名规则

- - i天下网商
有心人虎用军根据视频《淘宝搜索排名规则——相关性解读及其策略》整理出了详尽的思维导图,虽然不能完全代表淘宝搜索排名规则,但对于初级阶段的卖家来说,是不可多得的一份实战干货. 天下网商视觉团队设计,图说淘宝搜索排名规则. (注:此图仅供卖家学习交流,具体操作请以淘宝官方制定的淘宝搜索排名规则为准. 【网商百宝箱】淘宝搜索新规解读.

淘宝搜索算法现状

- - 互联网分析
淘宝搜索排序的目的是帮助用户快速的找到需要的商品. 从技术上来说,就是在用户输入关键词匹配到的商品中,把最符合用户需求的商品排到第一位,其它的依次排在后续相应的位置. 为了更好的实现这个目标,算法排序系统基本按三个方面来推进:. 当用户输入关键词进行搜索的时候,系统依据算法模型来给匹配到的每个商品进行实时的计算,并按照分数的大小对商品进行排序.

文本搜索:淘宝搜索新玩法

- - 派代网 - 资讯
“对于消费者和商家来说,都是新的开始. 淘宝搜索部门负责人文德如此描述将于1月7日测试上线的文本搜索选购知识的新功能. 这项新功能主要在用户搜索结果中增加产品选购的相关知识,而选购知识的提供者就是卖家. 淘宝搜索历来都是卖家关注的焦点,每一个排名的变化都会影响到卖家的切身利益,也会带来卖家或多或少的批评.

淘宝搜索规则十大金牌经验

- - i天下网商
史上最全搜索规则经验分享,包括:常见的违规现象、详情页链接的问题、主图质量的问题、卖家信誉的问题、橱窗推荐位和下架时间的使用、滞销宝贝的处理、宝贝属性的影响、消保的影响等. 处理: 系统识别后对涉嫌虚假销量、信用的宝贝给予三十天的单个宝贝搜索降权,同时根据卖家店铺涉嫌虚假交易情节严重程度给予卖家七至九十天的全店宝贝搜索降权.

【读图】27条影响淘宝搜索排名的因素

- - i天下网商
27条影响淘宝搜索排名的因素,不是绝对真理,却是非常实用的经验分享,给精细化运营添点料. 天下网商视觉团队作图,图说淘宝搜索排名因素. 【读图】2011淘宝母婴数据分析.

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

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

鬼脚七:淘宝卖家需知的搜索知识(上)

- - 派代网 - 资讯
对淘宝卖家来说,自然搜索流量最重要的一部分,如何从淘宝搜索获取更多的免费流量,是每个卖家最关注的话题之一. 之前很多卖家朋友会经常问我,能否讲讲搜索排序算法. 1、所有搜索引擎的排序算法,都是最保密的,无论是Google、Baidu,还是淘宝搜索. 我不可能告诉大家具体的算法,更何况算法每个月都有调整,或大或小.

淘宝搜索中Query下拉推荐技术

- - IT技术博客大学习
标签:   推荐   搜索. 作者:元宗 (一淘及搜索事业部-搜索技术-算法技术-主搜索与商城). 什么是Query suggestion.    Query下拉推荐是指搜索引擎系统根据用户当前的输入,自动提供一个Query候选列表供用户选择,Query下拉提示(Query suggestion)在搜索引擎和广告竞价平台中已经是标配的产品.