我们都知道 Spark 使用 RAM 来存储处理后的数据，Spark 和 Hadoop 都使用 RAM 进行计算，这使得 Spark 访问数据的速度非常快。但是，如果这是产生很大差异的一件事（除了 Tungsten 和 Catalyst），我们可以将它添加到 Hadoop 本身中。为什么我们没有仅仅改变 Hadoop 中的存储例程（使其在内存中），而是完全发明了一个不同的工具（Apache Spark）？是否有任何其他限制阻止 Hadoop 在内存存储中实现？
【问题讨论】：
标签： apache-spark hadoop in-memory
有两个主要因素决定了在 Hadoop 之上完全使用另一个平台来实现更快的计算（例如 Spark），而不是改革后者执行其应用程序的方式。
1. Hadoop 不仅仅是一个分布式计算库，更像是一种基础架构
我绝不是暗示您不能使用它来通过使用 MapReduce 范例的方式来根据您的需要开发应用程序。当我们谈论在 Hadoop 中工作时，我们不仅在谈论资源管理器 (YARN) 或分布式文件系统 (HDFS)，而且还必须包括基于或适用于它（如Flume、Pig、Hive，是的，你也猜对了 Spark）。这些模块充当 Hadoop 之上的扩展，以便在 Hadoop MapReduce 处理任务和/或在磁盘上存储数据的方式遇到麻烦时让事情变得更容易和更灵活。
很有可能您实际上使用 Spark 运行应用程序，使用其精美而全面的库，同时从 HDFS 中的目录检索数据，您会发现 Hadoop 只是运行应用程序的平台的基础。您可以添加什么内容完全取决于您的需求。
2。主存储器更昂贵和复杂
当您在 Hadoop 中开发应用程序时，您可以松一口气，因为您知道所有已处理的数据将始终存储在系统/集群的磁盘中，因为您知道：
a) 通过自己查看中间和最终过程数据，您将能够轻松指出突出的问题，并且
b) 您可以轻松支持可能需要 500GB 到 10-20TB 的应用程序（如果我们谈论的是集群，我猜）但如果您可以支持重型（我的意思是 heavy ，比如多 GB 的 RAM）应用程序内存
这与在 Hadoop 等项目中扩展资源的整个横向扩展方式有关，在这种方式中，与其构建一些可以处理大量数据的强大节点，不如优先考虑只需添加更多功能较弱的节点，这些节点是在考虑通用硬件规范的情况下构建的。这也是 Hadoop 在某种程度上仍然被误认为是一个以构建小型内部数据仓库为中心的项目的原因之一（但这真的是另一个故事了）。
但我不得不说，由于以下最新趋势，Hadoop 的使用量正在慢慢下降：
像 Spark 这样的项目在使用机器学习应用程序等更复杂的东西时变得更加独立和平易近人/用户友好（你可以阅读这篇关于它的小而简洁的文章，其中正在对here进行一些现实检查）
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。
简单地说，他们做不同的事情并继续这样做。
【讨论】：