有两个主要因素决定了“选择”在hadoop之上使用另一个平台进行更快的计算（例如spark），而不是改革后者执行应用程序的方式。
1.hadoop不仅仅是一个分布式计算库，更是一个基础设施
我并不是说你不能用它来开发一个基于你的需要的应用程序。当我们谈论在hadoop中工作时，我们不仅仅谈论资源管理器（yarn）或分布式文件系统（hdfs），还必须包括基于它或适用于它的产品生态系统（比如flume、pig、hive，是的，你也猜对了spark）。这些模块充当hadoop之上的扩展，以便在hadoopmapreduce处理任务和/或在磁盘上存储数据的方式遇到麻烦时使事情变得更简单、更灵活。
在hdfs中从目录中检索数据时，您很有可能实际使用spark来运行一个应用程序，使用它漂亮而全面的库，您可以得到hadoop只是运行应用程序的平台的基础。任何你能放在上面的是你的选择和偏好完全基于你的需要。
2.主存储器更昂贵，也更复杂
当您在hadoop中开发应用程序时，如果您知道所有处理过的数据都将始终存储在系统/集群的磁盘中，那么您就可以松一口气了，因为您知道：
a） 通过查看中间和最终的过程数据，您可以很容易地指出什么像拇指疼痛一样突出
b） 您可以很容易地支持可能需要500gb到10-20tb的应用程序（如果我们讨论的是集群，我猜），但是如果您可以支持重（我是说重，比如多gb的ram）应用程序内存，那就完全不同了
这与hadoop这样的项目中扩展资源的整体扩展方式有关，hadoop不需要构建几个功能强大的节点来处理大量的数据，而只需要添加更多功能较弱的节点，这些节点是在考虑通用硬件规范的情况下构建的。这也是hadoop在某种程度上仍然被误认为是一个以构建小型内部数据仓库为中心的项目的原因之一（但这确实是另一个时代的故事）。
不过，我不得不说，由于以下最新趋势，hadoop的使用正在缓慢下降：
像spark这样的项目在使用更复杂的东西（比如机器学习应用程序）时变得更加独立、平易近人/用户友好（你可以阅读这篇关于它的小而简洁的文章，这里会给出一些现实检查）
hadoop的基础设施方面面临的挑战是使用kubernetes容器，而不是它的yarn模块，或者amazon的s3，它实际上可以完全取代hdfs（但这并不意味着hadoop现在就那么糟糕，你可以在这篇更宽泛、基于观点的文章中领略一下实验和当前的状况）
最后，我相信hadoop会在未来几年找到它的用途，但每个人也都在向前迈进。hadoop的概念是很有价值的，即使没有任何公司或企业实现它，因为你永远不会真正知道使用hadoop开发什么东西会更容易、更稳定，或者不使用hadoop而不是每个人都使用的更新、更流畅的东西。

当然，内存计算总是存在的。不能在磁盘上添加、减少。
除此之外：
hadoop的主要目标是以批处理模式从磁盘执行数据分析。因此，原生hadoop不支持实时分析和交互性。它的优点是，它可以处理比spark更大的数据量，但与sparkapi相比，使用它是很麻烦的。
spark是scala开发的一个处理和分析引擎，使用尽可能多的内存处理。为什么“随着信息的实时分析成为机器学习的模式和能力，这需要迭代处理，以及交互式查询。
spark依赖于hadoopapi和hdfs或云等效的数据存储，如果不使用spark单机版，则具有容错性。现在与k8和s3等，这一切变得有点模糊，但与Spark工作更容易，但不为胆小的心。
spark至少在许多方面依赖hdfs—例如容错、访问hdfs的api。
简单地说，他们做不同的事情，并继续这样做。