很久没有发博客了, 最近这段时间工作上、生活上杂事比较多。最近经常有人问我在学校还是在公司。其实之前在学校读研, 入研之前工作过几年。那时候在学校研究MapReduce, 部署了10台的PC机做些Hadoop与机器学习的研究。08年末觉得学校限制我的发展, 就联系了几家公司实习。最后我到了淘宝实习了一年半, 那时候因为身份还是学生, 前期主要维护淘宝的Hadoop集群, 后期主要研发Hive, 同时向社区贡献了一些代码。半年前我正式入职了淘宝, 担任数据平台的分布式计算组组长, 主要负责Hadoop MapReduce及Hive的研发。
?
严重跑题了, 转回正题。前段时间淘宝由于业务的数据突增, 集群规模不断扩容, 集群上运行的作业更是日益增长。由于淘宝的Hadoop数据性质与搜索公司有所不一样: 淘宝的数据一般为数十MB至数百GB不等, 而大型的搜索公司的输入数据经常为TB级别以上。所以搜索公司的Hadoop作业经常有以下特征：
?
- long term型, 可以运行数小时甚至数天
- 作业比较大, 占用的slots数可达上万个或数十万个
- 因为作业都偏大, 集群能同时吞吐的作业数不多, 导致每天完成的作业数目不多
?
符合以上特征的Hadoop集群, 研发人员有几点会考虑:?
?
- 作业运行时间偏长, 万一失败就前功尽弃了, 所以最好作业有阶段性成果, 所以会考虑实现作业运行时运态添加Input Path.
- 由于数据量非常大, 导致NameNode的元数据非常多. NameNode采用CMS GC也经常会因为内存碎片, 导致young generation promote至old generation失败而形成full GC. 当然, 有一些办法能抑制full GC的频率. 但元数据的内存瓶颈始终是个问题.
- 由于数据量非常大, NameNode重启时处理各DataNode节点的block report时间非常长。
- 由于作业偏大, JobTracker在处理heartbeat的时候会经常卡在getTasksToKill()方法里。这个方法会从taskidToTIPMap取得task id 对应的TaskInProgress对象. ?全局的job数目不多, 而每个job都偏大, 所以全局的task数目会很多. 这个TreeMap取数据的时间会偏长。
- ...
?
以上是我在0.01秒时间内能想到的一些问题, 仅能代表其中的1%问题. 而淘宝的Hadoop作业有以下特征:?
?
- short term型, 大多数运行几分钟或十几分钟.绝大多数在半小时之内。
- 作业都比较小, 占用的slot数一般为数千
- 因为作业偏小,?集群能同时吞吐的作业数比较多。繁忙的时候同时运行的作业有几百个, ?每天完成的作业可达数万个.
- 各作业的依赖性比较大, 后面一组作业的开始时间受限前一组作业的结束时间。
?
符合这种特征的Hadoop集群, 会碰到这些情况:?
?
- 同时运行的作业数多, 目前Hadoop常用的调度器计算作业优先级的算法时间复杂度为O(NlogN), assign tasks的时间复杂度为O(N). 调度器的效率是一个比较大的问题.
- 同时运行的作业数多, JobTracker在处理heartbeat的时候会经常卡在getSetupAndCleanupTasks()方法里。这个方法会遍历JobTracker存储的所有jobs.?
作为个案，淘宝所使用的Hadoop集群还有以下特征及问题:
?
- 淘宝使用的最大集群——云梯是与集团其它公司共用的, 由阿里云的一个team维护。这样可以节约成本, 但作业的优先级及slots数目的分配都比较繁琐, 这对调度器的公平性要求比较高。
- 淘宝数据平台的数据同时向公司的各部门开放，也共享于集团的各子公司。所以,UGO的数据安全也满足不了需要。?
- 淘宝数据平台的Hadoop下游产品时效性要求比较高。生产作业在上班之前完成可以满足量子统计、数据魔方等产品的需要，如果没有完成则会有一系列买卖家的投诉
当然以上两种集群只要规模上了1000台, 问题就会更多。?RPC, NameNode锁、JobTracker锁、及DataNode, TaskTracker的问题都是一大堆。我们于12月初解决了JobTracker的一些性能问题, ?但是NameNode的吞吐量一直没有上来。针对这些问题我们开了几次紧急会议, 会议的决定是由我负责开展一个NameNode优化专门项目。经过大约一个月的努力, 我们的NameNode吞吐量已经上升8+倍。接下来的笔记将连载我们是如何发现NameNode的问题, 并进行NameNode优化的，敬请期待!
相关文章
