Hadoop 衰落，数据湖项目开始失败，我们该如何应对？

2019 年 8 月 15 日 InfoQ

作者丨Monte Zweben

译者丨核子可乐

Apache Hadoop 于 2006 年第一次在 IT 领域亮相，承诺为组织提供以往商用硬件从来没能达到的强大数据存储能力。这一承诺不仅一举解决了数据集大小的问题，同时也让我们得以应对更多数据类型——包括物联网设备、传感器、服务器以及企业越来越关注的社交媒体生成数据。这种数据量、处理速度以及类型变化的总和，形成了我们当下最为熟悉的新概念——大数据。

在 Hadoop 的普及当中，schema-on-read 起到了至关重要的作用。企业发现，他们不再需要担心表内数据以及表间相互连接的繁琐定义流程——以往这类工作往往需要耗费数月之久，而且在此期间所有数据仓库都无法接受正常查询。在 Hadoop 带来的美丽新世界中，企业能够尽可能多地存储数据，从基于 Hadoop 的存储库（被称为数据湖）中获取数据，并考虑如何进行后续分析。

自此开始，数据湖广泛出现在企业运营环境当中。这些数据湖由商业大数据版本支持——一般通过单一平台提供独立的开源计算引擎。该平台能够为数据湖提供不同的数据分析方式。最重要的是，这一切都属于开源项目，可供企业免费试用！听起来前景一片大好啊，怎么会出问题？

1 问题出在 schema-on-read 身上

就像生活中的很多事物一样，Hadoop 受到广泛好评的核心优势，也逐渐成为其致命的弱点。首先，随着 schema-on-write 模式限制的解除，数以 TB 计的结构化与非结构化数据快速流入数据湖。由于 Hadoop 的数据治理框架与功能还没有完全成熟，因此企业发现其越来越难以确定数据湖内容以及数据之间的继承关系。此外，这些数据也没有做好接受消费的准备。企业开始对数据湖中的数据失去信心，最终数据湖变成了数据沼泽，这也意味着 Hadoop 当初提出的“构建即可消费”的架构读取理念遭遇失败。

2 Hadoop 复杂性与零散的计算引擎

第二，Hadoop 各发行版提供众多开源计算引擎，包括 Apache Hive、Apache Spark 以及 Apache Kafka 等等。但事实证明，这种丰富性本身也不完全是好事。一套典型的商用 Hadoop 平台当中可能包含多达 26 种此类引擎。这些计算引擎的操作非常复杂，需要由具备专门技能的人员将其“粘合”在一起。可以想见，市场上没那么多符合要求的人选。

3 关注点错误：数据湖还是应用

第三点，也是最重要的一点，数据湖项目开始失败，这是因为企业原本希望利用数据湖将所有企业数据存储在同一中心位置，以供全部开发人员随意使用。换言之，大家也可以将其视为一种超级数据仓库。但实际情况是，数据会对应用程序产生直接影响。因此，Hadoop 集群通常会成为企业数据流水线中的网关，其负责数据的过滤、处理与转换，而后将数据导出至其它数据库及数据市场以便传递至下游——这意味着预期应用方式与实际运营体系发生了冲突。因此，数据湖最终成为另外一组庞大的差异性计算引擎，其运行在不同工作负载之上，且所有负载都共享同一套存储系统。这令管理工作变得无比艰难，虽然生态系统中的资源隔离与管理工具确实在不断改进，但仍有很长的道路要走。而这一切复杂性，仅仅只是为了实现数据报告功能。

在大多数情况下，企业不希望把关注重点从关键任务应用程序那边，转移至数据湖这种本应充当廉价数据存储库与数据转移通道的方案身上。例如，Apache Hive 与 Apache Spark 是 Hadoop 数据湖领域使用最广泛的两款计算引擎。这两款引擎都拥有强大的分析能力——要么负责处理类 SQL 查询（Hive），要么执行类 SQL 数据转换并构建预测模型（Spark）。但很明显，这些数据湖并没有充分关注应用程序究竟是如何使用数据的。

4 战略进展

因此，如果您所在的组织关注 Hadoop 生态系统的最新进展，并且发现自己很难证明数据湖的实际价值，那么您应该首先关注运营应用程序，而后再反过来审视自己的数据。

通过对具有数据及智能元素的应用程序进行现代化升级，您终将能够利用数据预测应用程序中可能发生的未来趋势，并根据经验主动做出应对决策，最终获得卓越的业务成果。下面来看应用程序现代化战略中的五大基本要素：

选择需要进行现代化的应用程序：我们应该首先选择一个希望实现现代化的应用程序，而非集中精力关注数据。您可以从众多定制应用程序当中选择其一，这类应用往往拥有一大共性——已经落后于市场趋势，需要提升敏捷水平、智能程度以及实现数据驱动性。在确定了能够为组织带来竞争优势的应用程序之后，您就可以专注于为该应用程序提供必要的数据，并判断是否能够从数据湖中获取这些数据。
使用横向扩展 SQL 实现应用程序现代化：多年以来，SQL 一直是企业工作负载中的主力，组织中一般都存在数百位非常熟悉 SQL 的开发人员、业务分析师以及 IT 人员。他们能够轻松将原本的 SQL 应用程序重写为底层 NoSQL API，且由此产生的时间、费用与风险成本都比较低。我们首先选择一个平台，用以保持熟悉的 SQL 模式以及强大的功能，同时确保应用程序现代化过程中其架构仍然能够在低成本基础设施上实现弹性扩展。横向扩展使得整体集群能够承载更多计算负载，且运行速度要远超集中式系统上的旧有 SQL 系统。通过横向扩展，您可以添加更多资源容量，并在工作负载发生变化时随时做出调整。
采用 ACID 平台：ACID 合规是负责维护数据库内事务完整性，并帮助用户执行提交与回滚等操作的机制。它也是为应用程序操作提供支持的关键性功能，可以确保数据库在发出提交请求之前不会向其他用户显示变更后的结果。大家可以首先在数据库内的单一事务层级中引入 ACID 能力，这样能够避免将所有一致性分支都交由应用程序代码处理。所有传统 SQL 系统都符合 ACID 标准，数据湖也正是因为错误地放弃了这一标准才使得配套应用程序变得难于编写。
统一分析引擎：根据 Gartner 公司发布的文章，我们原先确实有充分的理由将 IT 基础设施划分为运营（OLTP）与分析（OLAP）这两大类；但如今情况开始发生变化。ETL 带来的延迟会导致 SLA 得不到保障。过去，运营与分析负载会相互干扰，所以才不得不进行拆分。另外，遗留数据平台的执行往往非常糟糕，我们必须得把运营模式转换为更适合分析类工作负载的星形或者雪花模式。由于不再需要 ETL，我们可以在运营平台上以运营模式执行分析任务。通过这种方式，我们能够确保应用程序始终运行在数据移动需求量最低的平台上，因此不致引发过高的应用程序延迟。如此一来，我们还能通过报告与仪表板轻松将当前数据与昨天或者上周的版本进行对比，从而快速获得洞察见解。
嵌入原生机器学习机制：之所以有必要推动应用程序现代化，主要原因之一就是借此将 AI 与 ML 注入其中，以使应用程序能够从经济当中学习、以动态方式适应变化，同时做出即时决策。为了实现应用程序智能化，我们必须选择一套在数据库层级内置机器学习方案的平台，以确保各模型能够随时利用最新数据进行实验、训练与执行。

从本质层面来看，如今的使用场景已经与当初的数据湖使用方式完全不同。通过新方式，能够利用数据湖资源的应用程序将更快为业务线提供真实可见的商业价值。

这种方法除了通过应用程序现代化帮助企业建立竞争优势之外，还能帮助大家继续保留原有数据湖投资组合。

最后，感兴趣的朋友也可以点击此处获取本份白皮书副本，其中详尽阐述了应用程序落后于数字化转趋势的五种迹象以及其它细节信息。

原文链接：

https://towardsdatascience.com/what-happened-to-hadoop-what-should-you-do-now-2876f68dbd1d