前段时间淘宝由于业务的数据突增, 集群规模不断扩容, 集群上运行的作业更是日益增长。由于淘宝的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优化的，敬请期待!