我们都知道Spark使用RAM来存储处理后的数据，Spark和Hadoop都使用RAM进行计算，这使得Spark能够以极快的速度访问数据。但如果这是造成很大差异的一件事(除了 Tungsten 和 Catalyst)，我们可以将它添加到 Hadoop 本身中。为什么我们不只是改变 Hadoop 中的存储例程(将其存储在内存中)，而是完全发明一个不同的工具(Apache Spark)？是否还有其他限制阻止 Hadoop 在内存存储中实现？
最佳答案
有两个主要因素决定了“选择”在 Hadoop 之上使用另一个平台来实现更快的计算(例如 Spark)，而不是改革后者执行应用程序的方式。
<强>1。 Hadoop 不仅仅是一个分布式计算库，更是一种基础设施
我绝不意味着您不能使用它来通过使用 MapReduce 范例的方式来根据您的需求开发应用程序。当我们谈论在 Hadoop 中工作时，我们不仅谈论资源管理器 (YARN) 或分布式文件系统 (HDFS)，而且还必须包括基于或的产品的生态系统适用于它(例如 Flume 、 Pig 、 Hive ，是的，你也猜对了 Spark)。这些模块充当 Hadoop 之上的扩展，以便在处理任务和/或在磁盘上存储数据的 Hadoop MapReduce 方式遇到麻烦时使事情变得更容易、更灵活。
您很有可能在从 HDFS 中的目录检索数据时实际使用 Spark 来运行应用程序(使用其精美而全面的库)，并且您可以发现 Hadoop 只是您的应用程序运行的平台的基础。无论您可以在上面添加什么，都是您根据自己的需求进行的选择和偏好。
<强>2。主存储器更加昂贵和复杂
当您在 Hadoop 中开发应用程序时，如果您知道所有处理后的数据将始终存储在系统/集群的磁盘中，那么您可以放心，因为您知道:
a) 通过亲自查看中间数据和最终过程数据，您将能够轻松指出突出的问题，并且
b)您可以轻松支持可能需要 500GB 到 10-20TB 的应用程序(如果我们谈论的是集群，我猜)，但如果您可以支持重型(我的意思是重型，例如多 GB RAM)应用程序内存
这与 Hadoop 等项目中扩展资源的整个横向扩展方式有关，在这种方式中，最好不要构建一些可以处理大量数据的强大节点只需添加更多功能较弱的节点，这些节点是根据通用硬件规范构建的。这也是 Hadoop 在某种程度上仍然被误认为是一个以构建小型内部数据仓库为中心的项目的原因之一(但这确实是另一个故事了)。
然而，此时我不得不说，由于以下最新趋势，Hadoop 的使用量正在慢慢下降:
像 Spark 这样的项目在使用机器学习应用程序等更复杂的东西时变得更加独立、平易近人/用户友好(您可以阅读这篇关于它的小而简洁的文章，其中对 here 进行了一些现实检查)
Hadoop 的基础设施方面受到了使用 Kubernetes 容器而不是其 YARN 模块的挑战，或者亚马逊的 S3 实际上可以完全取代 HDFS(但这并不意味着 Hadoop 的情况还很糟糕) ，您可以在这篇更广泛且基于观点的文章中体验实验和当前的状态(here)
最后，我相信 Hadoop 会在未来几年找到它的用途，但每个人也在不断前进。 Hadoop 的概念对于了解和掌握很有值(value)，即使可能没有任何公司或企业实现它，因为您永远不会真正知道使用 Hadoop 来开发某些东西是否会更容易、更稳定，而不是使用每个人都使用更新、更灵活的东西。
关于apache-spark - 为什么最新的Hadoop没有内存计算功能？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/65750527/