引言
Hadoop一出生就是存储与计算在一起的，前几年面试题中都问，Hadoop怎么保证高性能呢？其中一个原因是存储不动，计算(code)动，不同于传统的集中式的存储模式。那我们为什么还要谈存储计算分离呢？众观历史，分久必合、合久必分，在计算机历史中也很类似，如今，也许到了计算与存储分离的阶段。后面我们以实际的case说明，分离的好处与劣势。
我们交流群为开源大数据技术社区召集令，欢迎大家关注。特别推荐 E-MapReduce产品，如果有大数据的需求，欢迎大家尝试使用，以下的讨论、测试都是基于E-MapReduce平台的。
为什么呢？
先说一个笔者的，也应该是大家的经历：笔者家里的带宽是100mpbs，现在从来不保存电影，要看直接下载，基本几分钟就好了。这在几年前不可想象。
笔者也在《云上Hadoop之挑战》中分析了其中的挑战，其中有本地化的挑战：
带宽的速度，特别是机房内带宽的速度，已经从1000mps、2000mps、10000mps，甚至100000mpbs。但是磁盘的速度基本没有太大的变化。
因为硬件的变化，带来了软件架构的变化。
基本架构
架构其实比较简单，OSS作为默认的存储，Hadoop、Spark可以作为计算引擎直接分析OSS存储的数据。
以上比较了计算与存储分离的优缺点。
- 灵活性：在《E-MapReduce(Hadoop)10大类问题之集群规划》 一文中分析了集群规划问题，关键是匹配计算量与存储量，如果把计算与存储分离后，则 集群规划则变得简单很多，基本不需要估算未来业务的规模了，真正做到按需使用。
- 成本：存储与计算分离后。按照 1 master 8cpu32g 6 slave 8cpu32g 10T数据量 估算大致为，成本下降一倍。在ecs自建的磁盘选择 高效云盘。
- 性能：大约下降10%以内，对于一般的应用是可以接受的。后续详细说明。
场景测试及数据
- 测试的代码为：https://github.com/fengshenwu/spark-terasort/tree/master/src/main/scala/com/github/ehiggs/spark/terasort
- 集群规模：1 master 4cpu 16g 、8 Slave 4cpu 16g、每个slave节点250G*4 高效云盘
- 测试spark脚本
/opt/apps/spark-1.6.1-bin-hadoop2.7/bin/spark-submit --master yarn --deploy-mode cluster --executor-memory 3G --num-executors 30 --conf spark.default.parallelism=800 --class com.github.ehiggs.spark.terasort.TeraSort spark-terasort-1.0-jar-with-dependencies.jar /data/teragen_100g /data/terasort_out_100g
- 测试的性能图
- 时间对比
分析
我们可以看到，emr+oss后，成本节约了一半，但是性能下降基本可以忽略不计。从性能图上看，emr+oss对比ecs自建hadoop对比：
- 整体的负载更低
- 内存利用率基本一样
- cpu使用低一些，特别是iowait与sys低很多，这是因为ecs自建有datanode及磁盘操作，需要占一些资源，增加cpu的开销。
- 从网络看，因为sortbenchmark有两次读取数据，第一次是采样、第二次是真正的读取数据，开始网络比较高，随后shuffle+输出结果阶段，网络比ecs自建hadoop低一半左右，从网络来看，整体使用量基本持平。
也就是整体来讲，emr+oss比自建使用更少的资源，如果提高emr+oss的并发度，则时间上有可能超过ecs自建hadoop集群的。
哪些场景不适合
并不是所有的场景都适合使用emapreduce+oss，对于以下场景目前不适合：
- 过多的 小的文件，比如小于10m，请合并小文件，当数据量在128m以上，使用emr+oss的性能最佳。
- 频繁操作OSS元数据的操作，此块emr+oss正在优化，目前并不太适合。
后记
优化无止尽，请持续关注后续E-MapReduce的发展。
时间： 2024-12-14 10:21:32