数据湖只是个哗众取宠的伪概念吗？

本文翻译自“ Are Data Lakes Fake News? ”，翻译已获得原作者 ** Uli Bethke ** 授权。Uli Bethke 是 Sonra 公司的 CEO，也是爱尔兰 Hadoop 用户组主席。

数据湖是个伪概念吗？最直接的答案是是的，在这篇文章中我会告诉你原因。

最大的问题在于“数据湖”这个词已经不堪重负，被供应商和分析师们赋予了太多不同的含义。如果有什么东西不属于传统的数据仓库架构，那就把它归结为某一种数据湖。最后数据湖就成了一个不清楚的、模糊的概念。众所周知，模糊的概念会导致模糊的思路，最后做出很差的决定。

我见过很多关于数据湖的定义，在本文中我们会挨个讨论。有时候大家提到数据湖时指的只是某一个概念，有的时候又会把几个概念混起来谈。有的人谈数据湖时却指的是下面的所有概念。

(点击放大图像)

作为原始数据水库的数据湖

这是最早提出数据湖概念时的含义。从这个概念看，数据湖与数据仓库的一个中转区域没有太大的不同。在中转区域中，我们从源系统复制一份数据过来。把这份数据向下游传输和整合，就形成了数据仓库。一个原始数据水库可以用来替换掉一个企业级数据仓库的中转区。

但在中转区和原始数据水库的概念之间还有着许多重要的不同。

• 从传统意义上讲，一个中转区域只会有一个消费者：生成数据仓库的下游进程。但原始数据水库却有多个消费者，不只是生成数据仓库的 ETL，还有用于自助服务和高级分析的沙箱、企业级搜索引擎、主数据管理集线器等。让原始数据可以为更多的消费者所用，这样做的好处在于不必多次访问源系统了。
• 在数据水库中我们也可以存储非结构化数据，包括文本、音频、视频等。
• 最后但同样重要的，我们可以选择对原始数据进行审计，或标记版本，只要将变化的历史以不可修改的方式保留下来即可。这可能会对兼容性之类的问题有所帮助。

原始数据水库的概念很有用，它从企业级数据仓库的中转区中借鉴了许多想法，而且做了改进。它应该成为现代企业数据架构中的一个核心组件。不过请记住，原始数据本身是没有用处的。它必须在经过整合、转换，即 ETL 之后才会变得有用。

作为数据水库加 ETL 的数据湖

有时候大家认为 ETL 也是数据湖的一个重要组成部分。这与数据水库有了轻微区别，这种情况可以用公式表述成“数据湖 = 数据水库 +ETL”。

数据囤积障碍

我想大家都会赞成原始数据水库是一个有用的概念。不过有些人建议把所有的企业数据都存储在数据水库中，因为也许在不久的将来就会派得上用场。这样做会带来的后果就是灾难，我给这种问题起了个名字，叫数据囤积障碍。

Mayo Clinic 说：“对于一个家庭来说，堆积会造成非常局促的生活环境，家中的所有空间都被堆满，只留下一堆堆物品之间的狭窄过道。台面、水槽、炉灶、桌子、楼梯和几乎所有的表面都堆满了东西。当屋子里面没法继续堆东西之后，杂物就会堆砌到车库、汽车、花园等其它地方”。

你应该看明白了。只为了保存数据而存储数据，这不是一个好主意。你应该有一个明确的使用目的，然后只向数据供应链中导入相关的数据。当数据水库中的数据不再有用时，就直接丢弃它。没有必要把某个特别的应用程序生成的所有数据都存储下来。以物联网为例，传感器会产生奇大无比的数据量，但大多数时候其实我们只是在意一些极端值而已，比如温度超出了某个阈值范围。Bill Inmon 在他的书《数据湖架构》中讨论了针对物联网案例减少数据量的不同方法。

原始数据水库技术

你想知道哪种技术最适合来实现数据水库吗？这和你的数据类型有关。对非结构化数据来说，像S3 或Hdfs 之类的分布式文件系统就很适合。对于少量的数据，比如引用、主数据、或业务系统的应用程序数据等，关系型数据库就很适合。切记，Hadoop 有个处理小文件的问题，即它不适用于处理大量的小文件。分布式文件系统对大量的事件和事务型数据非常合适。Kafka 之类的消息队列也是持久化存储大量事务型数据的理想选择。不过Kafka 一般用作数据的临时存储，用于持久化存储的场景倒真不多见。如果有人把Kafka 用作原始数据的持久化存储，请通过LinkedIn 联系我一下，我倒真的有兴趣听听你的具体应用场景。

(点击放大图像)

也可以在下游用这些技术来做数据转换和整合。引用数据和少量数据的转换可以在 RDBMS 中完成。Hadoop 适用于非结构化数据或非常大量数据的转换。也可以把引用数据复制到 Hadoop 上，通过检索引擎查询和访问。Hadoop 和 RDBMS 都很适合用于行存储。

作为自助分析平台的数据湖

代理商和分析师们常常把原始数据水库和自助分析的概念结合起来。在这样的理想场景下，商务部门的用户不需要 IT 部门的介入帮忙，也不需要使用 ETL 这么复杂的东西，就可以直接访问中央数据湖产生数据洞察。有些数据治理，再有些数据发现和数据准备的工具，就可以开工了。听起来简直好得不像是真的？好吧，这的确不是真的。

数据湖之谬见

数据湖主要有些什么问题呢？

• 其实你的商务用户根本不会有使用商务智能工具去完成各种不同类型检索任务的时间或兴趣。当你向他们展示一个数据准备工具的时候，你觉得他们会是什么反应？你真的觉得他们能处理得了原始数据吗？就算是你把这个世界上最好的数据治理和数据准备工具交给他们都没用。说实话，可能的确会有一些商务用户是对数据敏感的、可以进行分析操作的，最典型的就是会计了，他们是最早的数据分析师。但绝大多数人都是既没时间又没兴趣去花时间折腾数据的。这并不是说决策者和商务用户不应该精通数据处理。恰恰相反，他们应该掌握数据的所有细节。
• 你能想像在一家公司里，成千上万的用户都在一套中央数据湖系统上完成各种分析和探索性的任务吗？为各种各样高可预测性的工作去规划数据仓库已经够难了。商务智能相关的查询都是相似的、重复性的，所以非常适合用于缓存。但在探索性的环境里就完全不是那么回事了，只要一条模糊的查询就可能会把整个集群宕掉，也就是说有些分析任务要求在主节点上处理的工作量比在工作节点上做的还多。通过培训，还有让软件可以处理模糊查询，这些方法虽然在一定程度上有效，但总之都不是什么令人愉快的经历。你可能需要成百上千台服务器才能组成这样的集中式环境，还得授权给几百人。不过这样的场景可能会适合大型互联网公司，因为他们的 DNA 中已经包含了大数据处理能力，但对于一般普通规模的公司来说，我看不出这样的可能，起码在不久的将来不太可能。

自助分析只是个白日梦吗？

数据湖的自助服务愿景难道不可能实现吗？我不觉得。不过，自助服务这个概念本身是需要重新定义一下的。下文是我关于一个成功的自助分析平台的愿景。

自助分析的用户

自助分析的目标用户都有谁呢？我们早已确认，并不是那些典型的商务人士，也不是管理层。自助分析用户包括数据分析师、Excel 行家、数据工程师和数据科学家等。从经验来看，这些都是精通与数据打交道的技巧的人，而且他们之中大多数人还有技术背景，会写代码，至少也是熟悉 SQL 的。这群人缺乏的就是公司为他们提供的一个基于网页的平台，以满足他们特殊的需求。他们希望可以合作攻克某些难题，共享并重用代码和数据集，通过图形用户界面来少写些代码，将某些任务自动化，在必要时才写代码将数据可视化等。我脑海中的自助分析概念可以在企业中创造出满足这些需求的一个地方，让他们可以在工作中更高效。

最少的 IT 介入

自助分析从定义上就已经将 IT 的介入最小化了。IT 负责部署基础设施、管理接入和访问数据的权限，还有监控性能等。IT 部门，甚至 ETL 开发者们都不介入数据转换的工作。处理数据的是自助服务功能。

自助服务的用户可能来自于公司的各处，他们可能属于某个业务部门，也可能在一个集中的数据能力中心工作。

自助分析的沙箱

自助分析只应该被用于处理已经明确定义、而且可以用数据解决的问题。所以依我愚见，集中式管理的数据湖概念是不对的，它鼓励了数据的混乱状态，并让大家无法聚焦。每一种明确定义的问题都有自己的沙箱环境、预算和资源（人力、硬件、软件等）。一旦这些都达成之后，我们就可以把所需的数据迁移到相应的环境里了。

注意：我们会根据手头上的问题来为这样的沙箱环境选择相应的技术。不要像巴甫洛夫的狗一样一下子又提起 Hadoop 来了。

自助分析的场景

场景一：数据描述与探索式分析

这是一类应该归于数据仓库的新主题。作为企业数据仓库生命周期的一部分，数据分析师应该负责管理与数据源有关的描述、完整性和质量等问题。数据分析师搭建起沙箱环境，然后从数据源中拉取数据，并在需要时用数据准备环境来探索、描述、可视化并适当地整合数据。

场景二：性能分析

假设我们要分析一家被收购的公司的销售业绩。相关的数据还没有被载入数据仓库中。按过去的做法，许多数据分析师在这时候就会被分派任务，去把新的数据导入 Excel 或其它客户端工具里，然后他们就需要集中工作几个星期，专门分析这些数据，这样做当然是令人抓狂的。由于这整个流程和用到的工具都非常容易出错，最后我们得到的常常是错误的结果。而在新的环境中，我们只需搭建起一个沙箱，拉入需要的数据，再用基于网页的数据准备工具来转换和整合数据，最后用 Tableau 之类的工具将数据展示给管理层就好了。而且还有个意外的收获，这样产生的洞察还可以很容易地被产品化。自助分析平台可以成为数据仓库的数据排放点。

场景三：高级分析

哪些客户会对公司的产品感兴趣呢？这是预测性分析的一个标准问题。在以前，像 Matlab、SPSS，甚至 Excel 之类的客户端工具都被用来寻找答案了。大家把相应的数据拷到自己的电脑上，然后就开始分析了。这类方法当然有很多缺陷。首先就没有协作功能，而且还让公司的机密数据处于有风险的状态（比如笔记本电脑丢了，而数据还没加密），再者这样的方法也只能处理非常少量的数据，没法扩展。有了沙箱之后，我们就可以把需要的数据拖到一个基于网页的环境里，构建、训练和产品化一个预测性模型的整个生命周期都是基于协作式方法的。

从上面这些场景可以看出，沙箱实在是对传统数据仓库架构的一个有用补充。

我们在本节只是浅显地分析了一下在实现自助服务沙箱时需要考虑哪些因素。下面是一个不完全列表：

• 数据治理
• 技术
• 建议的工具有哪些（数据准备和数据科学平台）
• 如何将自助分析得到的洞察产品化？

数据湖即 Hadoop

接下来咱们再看看另一个关于数据湖的通俗定义。“数据湖就是 Hadoop 或其它的技术”。这样说不算太合理。数据湖是一个概念（虽然模糊），而 Hadoop 只是一种适用于少数几类用例的技术而已。这和说数据仓库就是关系型数据库犯的是一样的错误。下面是 Bill Inmon 的博客上关于这种误解的一段有趣的话：

在某种意义上与这个概念有关的想法就是，公司里所有的数据相关程序都应该运行在 Hadoop 平台之上，比如说 Docker 容器，而且还要使用类似 YARN 这种资源管理器。

数据湖——总结

数据湖也有许多不足，有些缺点也被详细地讨论过，比如缺乏数据治理和元数据管理等。对元数据可读和原始数据的可用性完全被夸大了。我本该在这里继续讨论一下这个“不要 ETL”问题的，这个荒谬的主意也来自于供应商的市场部门。

总结一下我提到的数据湖的几个主要问题：

• 这个词就是个万金油，可以用在任何传统数据仓库架构不适用的地方。在业界内还没有一致的可以达成共识的定义。
• 数据湖可以被没有技术和数据分析技能的用户访问，这样的想法是非常可笑的。
• 数据湖非得是所有数据和数据程序的集中存储和处理区域吗？
• 说数据湖就是一种技术，这是在把苹果和梨做对比。

我们到底得到了什么？在数据湖这个标签之下，其实有许多有用的概念和想法（当然前提是用法得当），比如原始数据水库和自助分析等。但是，因为这个词的概念太泛泛了，可以适用于任何非数据仓库的地方，而且包含了太多的概念和想法，所以其实没什么用。在工程界，我们应该抛弃它。

感谢蔡芳芳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。