在过去的几年里，Hadoop 得到了无数赞誉——Hadoop 是一个以大象命名的强大的、用于存储和处理数据的开源框架。许多在 Hadoop 生态系统中投入巨资的组织发现自己处于十字路口，想知道 Hadoop 之后的生活是什么样的，以及未来会怎样。本文讨论了 Hadoop 之后的生活，并为进入后 Hadoop 时代的组织制定了战略。
回忆大象
对于许多组织来说，使用 Hadoop 的生活非常好，它为处理大量非结构化数据提供了一些真正的力量。对于一些人来说，SQL-on-Hadoop 解决方案甚至有助于从更复杂（和昂贵）的数据仓库中卸载工作。也就是说，像其他大象一样，Hadoop 的护理和喂养是，嗯……不是微不足道的——尤其是在洗澡和清理围栏的时候。我不会对我个人的宠物创伤进一步离题，但我只想说与大型动物一起生活有其不利之处。
例如，存储在 Hadoop 分布式文件系统 (HDFS 2.X) 中的数据的 3 倍复制方案在存储和其他资源方面产生了 200% 的开销。此外，Hadoop 集群中计算和存储之间缺乏分离导致计算（即 CPU）资源的长期利用率不足，同时不断地最大化服务器上的存储。这助长了另一个不幸的副产品——Hadoop 集群蔓延。
随着数据的爆炸式增长，组织发现自己拥有越来越多的 Hadoop 集群，每个集群都有自己复杂的配置、较差的计算利用率以及对存储的贪婪需求。
是的，使用 Hadoop 并不总是那么容易，基于 Hadoop 的应用程序也不例外。Hadoop MapReduce 为处理大量数据提供了强大的功能，但需要付出一定的代价。大规模、基于磁盘的 MapReduce 应用程序性能不佳，使其不适合支持新一波的数据驱动应用程序。
此外，Hadoop 市场本身在过去几年中经历了重大动荡，这让组织在思考 Hadoop 的未来时停顿了一下，这是可以理解的。鉴于挑战和不确定性，许多组织得出的结论是，尽管它很有用，但现在是时候让大象离开了。
双面困境
当然，对于考虑在 Hadoop 之后生活的组织来说，有两个核心问题需要回答：
- 我如何处理我的 Hadoop 分布式文件系统 (HDFS) 数据？
- 我如何处理使用它的基于 Hadoop（例如 MapReduce）的应用程序？
起初，答案可能看起来简单而明显，但许多组织了解到答案并不像最初想象的那么清晰或简单。管理海量数据绝非易事，挑战并没有随着 HDFS 等分布式文件系统的出现而消失。此外，MapReduce 并没有神奇地消除分布式数据驱动应用程序的挑战。
基本事实是 Hadoop 是为另一个时代的数据需求而设计和优化的。今天的数据环境与十年前有很大不同。尽管如此，数据技术采用的两个主要驱动因素仍然相同——价格和性能。也就是说，Hadoop 不再是任何一个类别的领导者。这提出了一些难以回答的难题。但是，已经出现了两种明确的策略来帮助组织过渡到后 Hadoop 时代。
后Hadoop时代：1 – 建造一个更好的数据湖
长期以来，Hadoop 数据湖是管理大量非结构化数据的首选策略。只需将所有内容都泵入湖中，让 MapReduce 应用程序处理它。然而，事情从未如此简单，大多数数据湖仍然涉及大量复制和低效的数据移动。此外，随着新兴技术挑战数据管理的关键假设并逐渐取代 HDFS 和 MapReduce 等 Hadoop 服务，很明显需要一种更好的方法来管理大量数据。
输入数据结构。
从根本上说，Data Fabric 是一种在分布式环境中高效访问和共享数据的手段；将不同的数据资产整合在一起，并通过一组托管的增强数据服务使其可访问。基本上，Data Fabric 从 Hadoop Data Lake 停止的地方接了过来。提供对海量数据的高效、多协议访问，同时最大限度地减少数据移动，并帮助在计算和存储之间提供急需的分离。
在当今的数据环境中，单协议 Hadoop 数据湖根本不足以应对当前的挑战。相比之下，HPE Ezmeral Data Fabric 等现代数据结构提供了极大增强的功能，同时仍提供对集中管理的数据资产的基于 HDFS 的访问。
但是，数据网格比Data Fabric更加现代，详细见：数据网格与Data Fabric的区别
后Hadoop时代：2 – 优化计算
如前所述，Hadoop MapReduce 应用程序多年来为处理数据提供了很多功能，并且它在某些任务（例如，distcp）上表现良好。但是，它在各种其他用例中的性能从未如此出色。因此，出现了像Spark这样的新服务来解决 MapReduce 的缺点。
Spark 引入了重要的创新，并超越了 MapReduce 有限的功能词汇（映射和归约处理数据行），采用列式数据处理方法并将数据结构化为有向无环图 (DAG)。这种方法非常适合处理复杂的工作负载，例如机器学习和图形分析。此外，Spark 的创新与内存中处理模型相结合，带来了显着的性能提升——在某些情况下比 MapReduce 快 100 倍。
Spark 的性能大幅提升归功于几个因素，包括：
- Spark 不受 I/O 限制。凭借其内存处理模型，Spark 不会在每次运行任务的选定部分时导致磁盘 I/O 性能损失。
- Spark 的 DAG 支持任务步骤之间的优化。与 Spark 不同，Hadoop 在 MapReduce 步骤之间没有任何循环连接，这意味着在该级别不会发生性能调整。
此外，Spark 得益于灵活的部署架构，并且 Spark 集群可以使用各种集群管理器进行部署，包括 Kubernetes 和 Hadoop YARN。Hadoop MapReduce 仍然是批量处理大量数据的最佳选择，但对于大多数其他用例，Spark 是更好的选择。
鉴于 Spark 的灵活性、对人工智能和机器学习的适用性以及性能的大幅提升，近年来它的采用率急剧增加。投资 Spark 和相关技术是未来的合理战略。