问题描述
众所周知，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 这样的项目变得更加独立和平易近人/用户友好（你可以阅读这篇关于它的小而精巧的文章，其中对{{ 3}})
-
Hadoop 的基础设施方面受到使用 Kubernetes 容器而不是其 YARN 模块或实际上可以完全取代 HDFS 的 Amazon S3 的挑战（但这并不意味着 Hadoop 的情况就那么糟糕） ，您可以在这篇更广泛、更基于观点的文章中体验实验和事物的当前状态 here)
最后，我相信 Hadoop 会在未来几年找到它的用途，但每个人也都在向前发展。了解和掌握 Hadoop 的概念很有价值，即使可能没有任何公司或企业实施它，因为您永远不会真正知道使用 Hadoop 而不是每个人都在使用的更新、更灵活的东西。
,当然总是有内存计算。您无法在磁盘上添加、减少。
除此之外：
-
Hadoop 的主要目标是在批处理模式下从磁盘执行数据分析。因此，原生 Hadoop 不支持实时分析和交互。它的优势在于，当推送到位时，它可以处理比 Spark 更大的数量，但与 Spark API 相比，使用它很麻烦。
-
Spark 设计为在 Scala 中开发的处理和分析引擎，使用尽可能多的内存处理。为什么”随着信息的实时分析成为进行需要迭代处理和交互式查询的机器学习的模式和能力。
-
Spark 依赖/依赖于 Hadoop API 和 HDFS 或云等效数据存储，以及 YARN（如果不使用 Spark Stand-Alone 容错）。现在有了 K8 和 S3 等，一切都变得有点模糊，但使用 Spark 更容易，但不适合胆小的人。
-
Spark 至少在很多方面都依赖于 HDFS——例如容错，访问 HDFS 的 API。
简单地说，他们做不同的事情并继续这样做。