云上Hadoop之挑战

引言

在云上云行Hadoop，很多人担心性能。因为一提到虚拟化就会有人想到有成本，往往得出有偏见的结论-在云上运行肯定比物理机器上运行性能差。如果单独把10台物理机虚拟化跑Hadoop，这肯定是有部分性能的开销的。但是如果在公共云上，情况就不是这样了。因为公共云虚拟化的开销最终是由平台方来承担的，其一是平台方采购机器有规模优势，其二平台方可以在保证虚拟机性能的情况超卖部分资源。
平台卖给用户8core32g的虚拟机就保证有这个规格的能力的。
结合云上的弹性优势，企业的总体成本是会下降的。

在云上运行Hadoop对平台方还是面临一些挑战的，下面主要讲述这些挑战及平台方怎么解决的。

云上Hadoop的挑战-Shuffle

Shuffle分为Push模式，Pull模式。Push模式就是直接通过网络发送到下一个节点，比如：storm、flink。Pull模式就是数据先存储在本地，再启动下一个节点拉取数据，比如：Hadoop MR、Spark。
在push模式下，主要瓶颈点是网络。在一般的云环境中，网络跟线下没有太多的区别，可以满足需求。
在pull模式下，主要瓶颈点是磁盘。在云环境中，会提供本地磁盘或者用SDD加速的方案。如下：

另外：
根据spark社区的报告，在机器学习等很多场景下，瓶颈点现在是CPU了

云上Hadoop的挑战-数据本地化

数据本地化含义是分析时，把计算移动到数据节点的。如果计算存储分离，则存在数据放在OSS中，需要从OSS远程拉取数据。一般情况下，认为这样会有性能问题。

当前，网络的带宽发展非常快：

云上Hadoop的挑战-自动化运维

• Master挂
• 各种日志清理等
• 节点挂掉，自动补回
• Datanode掉线处理
• NodeManager掉线处理
• Job运行监控报警
• 负载过高监控报警
• 节点数据均衡
• 单节点扩容
• 版本自动升级
• 重要数据备份
• Hbase等指标监控报警
• Storm等指标监控报警

云上Hadoop的挑战-专家建议

• 是否需要扩容
• Hive SQL，可以给SQL评分，给出最优写法
• 分析存储，比如：指明是否需要压缩；小文件是否过多，是否需要合并；访问记录分析，是否可以把冷数据归档处理
• 分析运行时各种JOB统计信息，如：Job的map时间是否过小，运行时reduce是否数据倾斜，单个job是否有一些参数调整

这个主要是针对存储、作业调优的，优化性能之类的。在一般企业内部是没有这套系统的。云上可以做成一套这样的系统，帮助广大的企业。

HBase技术交流社区 - 阿里官方“HBase生态+Spark社区大群”点击加入：https://dwz.cn/Fvqv066s