项目简述：
基于开源Hadoop2.0架构的集群网络，进行海量数据的分布式计算。由于Hadoop集群规模不断扩大，而搭建一个同等规模的测试集群需要一笔昂贵的开销。目前有100台左右物料，期望预测计算节点1500+的集群网络性能，目前考虑通过模拟仿真或数学建模的方法来预测大规模集群极限性能，以及对大规模集群的瓶颈进行推测和提出解决方案。
 
项目预期目标：
1.       针对目前Hadoop集群性能瓶颈提出解决方案；
2.       依据小规模Hadoop集群，预测大规模Hadoop集群性能；
3.       预测大规模Hadoop集群瓶颈，提出解决方案；
4.       针对不同业务场景，评估Hadoop集群系统极限性能进行量化评估；
5.       进一步建立合理的数学模型；

---

目前已知的Hadoop集群性能瓶颈：
1．  单NameNode瓶颈：集群太大；任务量大，中心节点资源调度分配瓶颈；中心管理节点的计算和带宽能力有限，因此当集群节点的规模大时，会导致规模扩展差的问题。中心节点故障导致的问题会很严重。
2．  网络瓶颈：MapReduce和Spark的shuffle阶段拉取数据对网络压力很大(可能多于输入数据量，采用基本的多数据业务物理网卡复用)，超时导致失败；
3．  数据分布倾斜热点：受数据类型影响，计算层少量task计算了大量数据；
4．  MapReduce\Yarn\Spark提交任务的RPC请求太多，导致消息队列溢出；
5．  HBASE写入和查询并发，HBASE依赖zookeeper能力（200 TPS，目前提升不了了，ZK最多5个节点，增加后性能变差，因为要同步，而且好算，不用太关注）；
6．  业务阶段心跳能力：简单心跳场景下，模拟心跳激励AMS，实测能力为单线程10K/s，3s上报一次，最多5线程，因此实际能力为150K/3s，而实际Container并发心跳总量为1500*32=48K/3s，可以满足；复杂心跳没测过；NM和RM之间心跳压力更小；
7．  客户端操作：客户端并发读写HDFS NameNode TPS =10K~20K，短时间解决不了，只能上多namenode Frederation命名空间特性，使用NNBENCH激励；

---

以下为部分参考资料，仅供参考：
模拟仿真方法：
[1]潘旭明,  MapReduce FairScheduler的高性能优化及超大规模集群模拟器设计及实现[D].浙江大学，2012
[2]曾林西, 基于性能预估的Hadoop参数自动调优系统[D].华中科技大学, 2013
[3]刘知俊, 面向性能调优的MapReduce集群模拟器的研究与设计[D],杭州电子科技大学,2012
 
数学建模方法：
[1] 韩海雯. MapReduce 计算任务调度的资源配置优化研究[D]. 广州: 华南理工大学, 2013.
[2] Han J, Ishii M, Makino H. A hadoop performance model for multi-rack clusters[C]//Computer Science and Information Technology (CSIT), 2013 5th International Conference on. IEEE, 2013: 265-274.
[3] Lin X, Meng Z, Xu C, et al. A practical performance model for hadoop mapreduce[C]//Cluster Computing Workshops (CLUSTER WORKSHOPS), 2012 IEEE International Conference on. IEEE, 2012: 231-239.