`
coderplay
  • 浏览: 571285 次
  • 性别: Icon_minigender_1
  • 来自: 广州杭州
社区版块
存档分类
最新评论

NameNode优化笔记 (一)

阅读更多

很久没有发博客了, 最近这段时间工作上、生活上杂事比较多。最近经常有人问我在学校还是在公司。其实之前在学校读研, 入研之前工作过几年。那时候在学校研究MapReduce, 部署了10台的PC机做些Hadoop与机器学习的研究。08年末觉得学校限制我的发展, 就联系了几家公司实习。最后我到了淘宝实习了一年半, 那时候因为身份还是学生, 前期主要维护淘宝的Hadoop集群, 后期主要研发Hive, 同时向社区贡献了一些代码。半年前我正式入职了淘宝, 担任数据平台的分布式计算组组长, 主要负责Hadoop MapReduce及Hive的研发。

 

严重跑题了, 转回正题。前段时间淘宝由于业务的数据突增, 集群规模不断扩容, 集群上运行的作业更是日益增长。由于淘宝的Hadoop数据性质与搜索公司有所不一样: 淘宝的数据一般为数十MB至数百GB不等, 而大型的搜索公司的输入数据经常为TB级别以上。所以搜索公司的Hadoop作业经常有以下特征:

 

  1. long term型, 可以运行数小时甚至数天
  2. 作业比较大, 占用的slots数可达上万个或数十万个
  3. 因为作业都偏大, 集群能同时吞吐的作业数不多, 导致每天完成的作业数目不多

 

符合以上特征的Hadoop集群, 研发人员有几点会考虑: 

 

  1. 作业运行时间偏长, 万一失败就前功尽弃了, 所以最好作业有阶段性成果, 所以会考虑实现作业运行时运态添加Input Path.
  2. 由于数据量非常大, 导致NameNode的元数据非常多. NameNode采用CMS GC也经常会因为内存碎片, 导致young generation promote至old generation失败而形成full GC. 当然, 有一些办法能抑制full GC的频率. 但元数据的内存瓶颈始终是个问题.
  3. 由于数据量非常大, NameNode重启时处理各DataNode节点的block report时间非常长。
  4. 由于作业偏大, JobTracker在处理heartbeat的时候会经常卡在getTasksToKill()方法里。这个方法会从taskidToTIPMap取得task id 对应的TaskInProgress对象.  全局的job数目不多, 而每个job都偏大, 所以全局的task数目会很多. 这个TreeMap取数据的时间会偏长。
  5. ...

 

以上是我在0.01秒时间内能想到的一些问题, 仅能代表其中的1%问题. 而淘宝的Hadoop作业有以下特征: 

 

  1. short term型, 大多数运行几分钟或十几分钟.绝大多数在半小时之内。
  2. 作业都比较小, 占用的slot数一般为数千
  3. 因为作业偏小, 集群能同时吞吐的作业数比较多。繁忙的时候同时运行的作业有几百个,  每天完成的作业可达数万个.
  4. 各作业的依赖性比较大, 后面一组作业的开始时间受限前一组作业的结束时间。

 

符合这种特征的Hadoop集群, 会碰到这些情况: 

 

  1. 同时运行的作业数多, 目前Hadoop常用的调度器计算作业优先级的算法时间复杂度为O(NlogN), assign tasks的时间复杂度为O(N). 调度器的效率是一个比较大的问题.
  2. 同时运行的作业数多, JobTracker在处理heartbeat的时候会经常卡在getSetupAndCleanupTasks()方法里。这个方法会遍历JobTracker存储的所有jobs. 

作为个案,淘宝所使用的Hadoop集群还有以下特征及问题:

 

  1. 淘宝使用的最大集群——云梯是与集团其它公司共用的, 由阿里云的一个team维护。这样可以节约成本, 但作业的优先级及slots数目的分配都比较繁琐, 这对调度器的公平性要求比较高。
  2. 淘宝数据平台的数据同时向公司的各部门开放,也共享于集团的各子公司。所以,UGO的数据安全也满足不了需要。 
  3. 淘宝数据平台的Hadoop下游产品时效性要求比较高。生产作业在上班之前完成可以满足量子统计、数据魔方等产品的需要,如果没有完成则会有一系列买卖家的投诉

当然以上两种集群只要规模上了1000台, 问题就会更多。 RPC, NameNode锁、JobTracker锁、及DataNode, TaskTracker的问题都是一大堆。我们于12月初解决了JobTracker的一些性能问题,  但是NameNode的吞吐量一直没有上来。针对这些问题我们开了几次紧急会议, 会议的决定是由我负责开展一个NameNode优化专门项目。经过大约一个月的努力, 我们的NameNode吞吐量已经上升8+倍。接下来的笔记将连载我们是如何发现NameNode的问题, 并进行NameNode优化的,敬请期待!

4
0
分享到:
评论
6 楼 sunny1988720 2011-09-22  
我也想读研的时候实习啊 不知能否给个机会去实习呢 已经给您的邮箱发了简历 期待您的回复
5 楼 bhjackson 2011-05-18  
期待优化详情~~~~
4 楼 vozon 2011-03-21  
额,期待后文吖~~~~
3 楼 david.org 2011-01-14  
Google Reader上有好几个人分享了这篇文章,原来是周大哥写的啊,呵呵。

支持哦,期待下文 ;-)
2 楼 lance_123 2011-01-12  
great,优化效果确实很明显,待期更详细的分享,另外NN和JT还是对效率影响比较重的二个东西。
1 楼 leeing.org 2011-01-12  
读研的时候能出去实习真好。对这一块很感兴趣,但平时只能呆在实验室里,有时间也不能跑去实习,只能自己看。 要是能有远程工作的实习就好了 

相关推荐

Global site tag (gtag.js) - Google Analytics