既然Spark比Hadoop性能好很多，Hadoop未来发展方向是什么？
既然Spark比Hadoop性能好很多，Hadoop可不可以从Spark中借鉴一些技术，可以借鉴哪些技术，未来Hadoop可不可能达到与Spark类似的水平？ 首先两者的定义需要先进行清晰的理解。spark是大一统的软件栈，Hadoop是基于Hadoop平台的软件生态。因此拿软件栈和软件生态去做对比，我觉得实属不妥。容易混淆的点往往是拿Spark core和Hadoop MapReduce进行了对比。因为在并行计算性能上的差距，总会提出的MapReduce是否可以借鉴spark的技术思路进行改善。
我认为让MapReduce去改善性能，追赶上spark的这个发展方向思路几乎微乎其微。原因在于MapReduce本身的设计理念和spark有本质的区别，MapReduce走的是多进程并行计算模型，spark则走的是多线程并行处理，那么多进程在共享资源的情况下显然不如多线程那么方便，因此spark就能很方便的实现资源池的任务分配，shuffle中间过程的内存i/o利用，反观MapReduce只有通过介质作为中间数据的交换场地，让进程间使用。那么要改变MapReduce性能，除非做内存虚拟磁盘技术，但是这个成本太大。
从Hadoop的发展来看，我认为正确的方向应该是Hadoop朝着更可靠的路线发展，解决Hadoop hdfs namenode集中管理带来的问题，管理者应该走分布式模式，Google下一代技术正在朝这个方向发展。另外计算方向，寻找新的高性能的计算框架成为Hadoop新的标准部分，例如tez，替换掉MapReduce的这架老车，成为hive，pig等上层工具的基础引擎。
关注 @读字节(大数据) 了解更多大数据知识
读字节 | 创作中心 www.readbyte.com 首先需要明确一点，Hadoop应该算是大数据技术的代名词了，现在所讲的Hadoop，更多是大数据技术生态，而不是单纯的只是在讲Hadoop本身。
Hadoop作为第一代大数据技术，发展至今已经有了十几年了，现在的版本已经迭代到了Hadoop3。由此可以看出，与其说是Hadoop已经过时了，不如说MapReduce作为第一代大数据技术已经完成了其该有的历史使命。现在Hadoop的发展更多是生态兼容，因为很多的大数据处理框架，还是要依赖于Hadoop，比如资源调度框架YARN，分布式文件系统HDFS，都是目前使用频次比较高的大数据技术，再比如SQL ON Hadoop的OLAP分析引擎Hive，这些无一例外都需要依赖于Hadoop。
在说回Hadoop本身，Hadoop包括HDFS、MapReduce和YARN，其中HDFS是目前使用比较多的分布式文件系统，YARN也是目前使用比较多的资源调度框架，而MapReduce主要用于批处理，由于中间结果要落入磁盘，所以速度会比较慢，另外，map和reduce的编程范式也比较单一，对于复杂的计算不是很友好，可以说是很少使用了。
我们在来看Spark，Spark可以说是第二代大数据处理引擎，以其内存计算(并不单纯的基于内存)和擅长迭代计算而著称，Spark官网也显示其性能是Hadoop的100倍，所以在数据处理方面，Spark无疑是优于Hadoop的MapReduce的。另外，Spark是一个统一的大数据分析引擎，也就是说既可以支持批处理(比如SparkCore，SparkSQL)，又支持流处理(比如SparkStreaming等)，还要就是Spark还提供了机器学习的库SparkML以及图计算的库GraphX，可以看出Spark是一个生态栈，即支持一站部署，可以满足不同场景的业务需求。但是这并不能说Spark可以取代Hadoop，两者并不是互为替代品，而是互补的，比如在企业中会把Spark的任务部署在YARN上进行资源调度，比如使用SparkSQL处理Hive数据(数据存储在HDFS上)。
在来说一下目前比较火的Flink，Flink可以说是第三代大数据处理引擎，业务目前比较火的流处理引擎，Flink从一开始就是擅长流处理，发展至今，已经成为了非常成熟的大数据处理引擎，未来的方向是流批统一。对比Spark和Flink，你会发现，它们之间有很多的相似之处，其实大数据处理引擎本质上都是相似的，就目前而言，Spark和Flink的使用率都是很高的。
回到问题本身，既然Spark比Hadoop性能好很多，Hadoop可不可以从Spark中借鉴一些技术，可以借鉴哪些技术，未来Hadoop可不可能达到与Spark类似的水平？其实上面的解释也已经很清楚了，一句话就是定位不一样，每个技术都是有自己的适用场景的，所以Hadoop的发展发现也不是Spark。至于Hadoop的未来发展方向，那要看未来其他大数据技术是否还依赖于Hadoop，如果整个大数据技术生态都抛弃了Hadoop，那么Hadoop就真的过时了，不过话又说回来，目前的比较成熟的大数据处理引擎还是很依赖与Hadoop的，所以未来Hadoop可能会作为一个大数据处理引擎的基础设施，而不是成为下一个Spark或者Flink。
关于大数据学习，我平时会写一些大数据技术的原创文章，欢迎各位看官一起交流
[*]基于Canal与Flink实现数据实时增量同步(一)
[*]CDH集群之YARN性能调优
[*]Flink运行架构剖析
[*]Flink的状态后端(StateBackends)
[*]基于Canal与Flink实现数据实时增量同步(二)
[*]Flink的八种分区策略源码解读
[*]经典Hive-SQL面试题
[*]Flink1.10集成Hive快速入门
[*]LeeCode数据库部分题目汇总
[*]Impala使用的端口汇总
[*]浅析数据库缓冲池与SQL查询成本
[*]你真的了解Flink Kafka source吗？
[*]如何使用Hive进行OLAP分析
[*]Flink DataStream API编程指南
[*]Flink的时间与watermarks详解
[*]Flink内部Exactly Once三板斧:状态、状态后端与检查点
[*]Flink DataStream API 中的多面手——Process Function详解
[*]透过窗口观无限数据流——Flink的Window全面解析
[*]Flink DataSet API编程指南
[*]Hive开窗函数实战
[*]Greenplum集群Master与Segment节点故障检测与恢复
[*]Hive的条件函数与日期函数全面汇总解析
[*]一统江湖的数仓开发辅助神器--DBeaver
[*]Flink Table API & SQL编程指南(1)
[*]Flink Table API & SQL编程指南之动态表(2)
[*]Flink Table API&SQL编程指南之时间属性(3)
[*]数仓开发需要了解的BI数据分析方法
[*]数仓|Hive性能调优指北
[*]实时数仓|Flink SQL之维表join
[*]数据分析|使用多元线性回归构建销售额预测模型
[*]Hive的架构剖析
[*]数仓开发应避免的10个陷阱
[*]Kafka生产者ack机制剖析
[*]Kafka的Controller Broker是什么
[*]数仓规范|使SQL更易于阅读的几个小技巧
[*]数仓|大数据时代,维度建模过时了吗?
[*]第一篇|Spark概览
[*]第二篇|Spark core编程指南
[*]第三篇|Spark SQL编程指南
[*]第四篇|Spark Streaming编程指南(1)
[*]第五篇|Spark-Streaming编程指南(2)
[*]第六篇|Spark MLlib机器学习(1)
[*]第七篇|Spark平台下基于LDA的k-means算法实现
[*]数仓面试|四个在工作后才知道的SQL密技
[*]内含面试|一文搞懂HBase的基本原理
[*]Flink1.11中的CDC Connectors操作实践
[*]SQL查询的底层运行原理分析
[*]元数据管理|Hive Hooks和Metastore监听器介绍
[*]项目实践|基于Flink的用户行为日志分析系统
[*]使用SQL窗口函数进行商务数据分析
[*]Hive SQL使用过程中的奇怪现象
[*]面试|Kafka常见面试问题总结
[*]篇一|ClickHouse快速入门
[*]篇二|什么是ClickHouse的表引擎?
[*]篇三|ClickHouse的数据类型
[*]篇四|ClickHouse的可视化界面与集群状态监控
[*]Kafka生产环境的几个重要配置参数
[*]第八篇|Spark SQL百万级数据批量读写入MySQL
[*]第九篇|Spark的五种JOIN策略解析
[*]Impala的组件和架构介绍
[*][第十篇|SparkStreaming手动维护Kafka Offset的几种方式
大数据技术与数仓：面试|不可不知的十大Hive调优技巧最佳实践大数据技术与数仓：篇五|ClickHouse数据导入(Flink、Spark、Kafka、MySQL、Hive)大数据技术与数仓：第十一篇|基于SparkSQL的电影分析项目实战大数据技术与数仓：数仓开发需要了解的5大SQL分析函数 Hadoop是一个很大的软件集合，其中直接和Spark冲突的是MapReduce。目前由于Spark已经证明了自己优于MapReduce的地方，所以MR方面的开发基本已经停止了，但是Yarn等集群管理方面的feature应该会继续开发。它们的目标是构造一个通用的集群管理的操作系统，不但可以支持MR，Spark，还可以支持任何符合标准的分布式应用。 Impala比Spark性能还要好，但你看它现在这个鸟样。
认真来讲，Hadoop现在分三块HDFS/MR/YARN，Spark比Hadoop性能好，只是Spark作为一个计算引擎，比MR的性能要好。但它的存储和调度框架还是依赖于HDFS/YARN，Spark也有自己的调度框架，但仍然非常不成熟，基本不可商用。
目前来看，YARN在Hadoop的发展过程中占的比重较多，而且作为一个调度和资源管理框架，它可以兼容多计算框架。而且现在大数据领域的框架底层存储基本都依赖于HDFS，这也就是为什么很多文章开头就说“Hadoop已经是大数据领域的事实标准”。
回到问题，大数据领域，“性能”可能并不是衡量一个大数据组件的唯一标准，安全、可靠性、与其他框架的兼容性、资源管理、可扩展性同样很重要，而Hadoop作为大数据领域的核心组件，这些方面肯定都需要考虑，而不单单是性能。
--------------------------7月16日更新分割线---------------------
Spark And Hadoop Are Friends, Not Foes这里有一篇文章，大意相同，但阐述更详细一点。 泻药！Hadoop不一定也非要做内存计算哇。每个开源项目做好自己擅长的部分，把其他项目更擅长的部分留给他们做到极致，各得其所。何况Spark和Hadoop兼容，同属阿帕奇，可能性就更小了。
页:
[1]