首页 > 解决方案 > 为什么最新的 Hadoop 中没有内存计算功能?

问题描述

我们都知道 Spark 使用 RAM 来存储处理后的数据,Spark 和 Hadoop 都使用 RAM 进行计算,这使得 Spark 访问数据的速度非常快。但是,如果这是产生很大差异的一件事(除了 Tungsten 和 Catalyst),我们可以将它添加到 Hadoop 本身中。为什么我们没有仅仅改变 Hadoop 中的存储例程(使其在内存中),而是完全发明了一个不同的工具(Apache Spark)?是否有任何其他限制阻止 Hadoop 在内存存储中实现?

标签: apache-sparkhadoopin-memory

解决方案


有两个主要因素决定了在 Hadoop 之上完全使用另一个平台来实现更快的计算(例如Spark)而不是改革后者执行其应用程序的方式的“选择”。

1. Hadoop 不仅仅是一个分布式计算库,它更像是一个基础设施

而且我绝不意味着您不能使用它来通过使用MapReduce范例的方式来根据您的需要开发应用程序。当我们谈论在 Hadoop 中工作时,我们不仅在谈论资源管理器 (YARN) 或分布式文件系统 (HDFS),而且还必须包括基于或适用于它的产品生态系统(如FlumePigHive,是的,你也猜对了 Spark)。这些模块充当 Hadoop 之上的扩展,以便在Hadoop MapReduce处理任务和/或在磁盘上存储数据的方式变得麻烦时使事情变得更容易和更灵活。

在从 HDFS 的目录中检索数据的同时,您实际上使用 Spark 运行应用程序的可能性很大,您会发现 Hadoop 只是运行应用程序的平台的基础。无论您可以放在上面什么都是您的选择和偏好,完全取决于您的需求。

2. 主存更加昂贵和复杂

当您在 Hadoop 中开发应用程序时,您可以松一口气,因为您知道所有已处理的数据将始终存储在系统/集群的磁盘中,因为您知道:

a) 通过自己查看中间和最终过程数据,您将能够轻松指出突出的问题,并且

b)您可以轻松支持可能需要 500GB 到 10-20TB 的应用程序(如果我们谈论的是集群,我猜)但是如果您可以支持重型(我的意思是重型,比如多 GB 的 RAM ),那就完全不同了) 应用程序内存方面

这与在 Hadoop 等项目中扩展资源的整个横向扩展方式有关,在这些项目中,与其构建一些可以处理大量数据的强大节点,不如只添加更多功能较弱的节点构建时考虑了通用硬件规格。这也是 Hadoop 在某种程度上仍然被误认为是一个以构建小型内部数据仓库为中心的项目的原因之一(但这确实是另一个故事)。


然而,我不得不说,由于以下最新趋势,Hadoop 的使用量正在慢慢下降:

  • 像 Spark 这样的项目在使用更复杂的东西(如机器学习应用程序)时变得更加独立和平易近人/用户友好(你可以阅读这篇关于它的小而整洁的文章,这里给出了一些现实检查

  • Hadoop 的基础设施方面受到使用 Kubernetes 容器而不是其 YARN 模块或实际上可以完全取代 HDFS 的 Amazon 的 S3 的挑战(但这并不意味着 Hadoop 的情况还没有那么糟糕,您可以尝试一下这篇更广泛和基于观点的文章中实验和当前状态)

最后,我相信 Hadoop 会在未来几年内找到它的用途,但每个人也在继续前进。了解和掌握 Hadoop 的概念是很有价值的,即使可能没有任何公司或企业实施它,因为你永远不会真正知道是否会更容易和更稳定,或者不使用 Hadoop 而不是使用每个人都使用的更新和更光滑的东西。


推荐阅读