数据湖与仓库的技术架构之争

数据大辩论

嘉宾

鲍勃·穆利亚

米歇尔·乌福德

马丁·卡萨多

特里斯坦·汉迪

乔治·弗雷泽

节目摘要：数据湖的未来、两套技术栈是否会合二为一、数据网格、现代数据栈的下一个用例、延迟需要降到多低

数据湖与数据仓库、分析与AI/机器学习、SQL与其他一切……随着数据湖和数据仓库技术能力的趋同，运行AI/机器学习的工具和团队与分析领域的工具和团队是否也在走向融合？

在本期播客中（原为Fivetran现代数据栈会议的一部分），五位数据基础设施领域的领袖就这一问题展开了辩论：a16z合伙人、软件定义网络先驱马丁·卡萨多；Snowflake前CEO鲍勃·穆利亚；Noteable创始人兼CEO米歇尔·乌福德；Fishtown Analytics创始人兼开源项目dbt负责人特里斯坦·哈迪；以及Fivetran创始人乔治·弗雷泽。

他们的对话涵盖了数据湖的未来、现代数据栈的新用例、数据网格（去中心化团队和工具是否是未来）以及延迟实际需要降到多低。尽管辩论主题是现代数据栈，但其中的主题和不同观点触及了一个更长久的问题：技术如何在复杂的企业环境中演进？

正文

数据湖的未来

乔治：我将用一个有争议的话题开启讨论，至少在这个圈子里有争议，那就是数据湖。“数据湖”这个词含义模糊，不同的人用它指代不同的事物。为了便于讨论，我们将其定义为：以开源文件格式（如Parquet或ORC）存储在公有云对象存储（如S3或谷歌云存储）中的表格数据（即表、行和列）。

在一个数据仓库也使用对象存储来存储数据并带来数据湖某些优势的世界里，数据湖还有一席之地吗？马丁，先从你开始，数据湖有未来吗？

马丁：我们这个行业最大的谬误之一是，看到一种架构就觉得它能做所有事情，因此会把它推向所有服务场景。但技术的发展并非如此。我们基于技术的主要使用场景在设计空间内做出决策。

看看数据仓库的使用场景，它们主要由分析驱动，这是一种特定的工作流和查询模式。而数据湖则截然不同。数据湖往往包含更多非结构化数据，专注于运营型AI，计算密集。从各自的技术来看，它们正为了不同的使用场景在这个庞大的设计空间中进行着优化。

从架构上讲，它们确实都能做对方能做的事，但最终，产品和企业是围绕使用场景进行优化的。我认为运营型AI的使用场景更大，增长也更快。所以，从长远来看，我认为可以论证是数据湖最终会吞噬一切，而不是数据仓库。

乔治：马丁，你只是想挑衅鲍勃。

鲍勃：你成功了。

马丁：我看着鲍勃的脸呢。

乔治：好的，鲍勃。请谈谈你的看法。数据湖有未来吗？

鲍勃：没有。我认为这些东西很大程度上会收敛到一个基于关系型SQL的模型上。五年后，数据将位于SQL提示符之后，SQL数据仓库将取代数据湖。

从存储结构化和半结构化数据来看，云SQL数据仓库已经能做所有必要的事情。除了历史沿革的原因，人们实在没有理由再单独维护一个数据湖。许多公司来自拥有大量Hadoop环境下半结构化数据的环境，拥有数据湖是一个自然的过渡。从某种意义上说，数据湖（即S3存储加上任何你想要的工具）是一个非常通用的平台。

但随着时间的推移，基础设施会不断演进以承载越来越多的用例。SQL关系型数据仓库已经发展到，对于结构化和半结构化数据的存储和查询，它几乎涵盖了今天所有需要做的事情。剩下的就是图像、视频、文档、PDF。

我不把这些称为非结构化数据，那是个误称。根本没有“非结构化数据”这回事。所有数据都有某种结构。结构化数据是表、行和列。半结构化数据如JSON，本质上是层次化的。我认为还有第三类数据，我称之为复杂数据：图像、文档、视频。大多数流式数据都属于这一类。越来越多的机器学习可以应用于这些数据源的内容，将其转化为可用于构建复杂数据应用和进行预测性分析的半结构化数据。

所以，当前数据仓库缺少的是对复杂数据的支持。但这一点会得到解决，这只是一个“功能”问题。你能想象如果可以在数据仓库中，将这些类型的图像、视频以及任何来源的半结构化数据一起进行完整的事务处理吗？这将开启令人瞩目的应用，而这将在未来两三年内实现。

米歇尔：我能想象图像可以轻松地从数据库中检索出来。但你真的认为所有的图像处理或视频处理也会在数据库中进行吗？

鲍勃：不能用SQL。SQL做不到。至少目前，你需要使用过程逻辑和Python或其他工具。从长远看，关系型最终也会赢，但那可能还需要8到10年。

马丁：鲍勃，我觉得我们已经为这个等了40年了。

鲍勃：是的，但看看已经发生的变化。80年代的导航型和层次型被SQL取代。过去10年左右，OLAP被SQL取代。MapReduce被关系型取代。所有这些，关系型总是赢。

米歇尔：关系型赢在真正的检索上，但处理呢？处理图像所需的技术与检索数据记录有着根本的不同。

乔治：特里斯坦，你怎么看？

特里斯坦：我完全同意SQL将主导数据处理，至少是很大一部分数据处理。但是数据湖和数据仓库暴露的API不同。首先是文件存储层。出于很多原因，我认为一个组织会将文件存储一次，不会同时存在数据仓库副本和数据湖副本——而在某些现有架构中，正是如此。这就要求你有一个开源文件格式，能够在数据仓库用例和其他用例之间共享。

在此之上，是索引和元数据，这既是数据仓库的核心部分，也是数据湖的核心部分。我认为这些也必须开始收敛，以便不同的用例能利用相同的东西。然后是SQL提示符层，也许在这一层数据仓库占主导地位，但我认为也需要允许不同的访问模式，因为没有一个闭源公司能完成世界上所有的数据处理用例。

鲍勃：所有这些东西都应该以开源和开放格式的方式进行互操作。但格式问题已经基本解决，因为你可以非常容易地输入输出任何格式，并导出为任何格式。

问题在于：需要对数据湖中的数据执行哪些操作？如今，任何与复杂数据相关的操作，数据仓库都帮不了你，所以今天有充分的理由使用数据湖。但到2025年，我不这么认为。

我认为全球真正会形成五大平台：Snowflake、Databricks，以及三大云厂商。Snowflake和Databricks虽然起点不同——Snowflake将始终采用SQL和声明式方法，而Databricks历史上当然是过程式和基于代码的，在某种意义上这是SQL与代码的版本之争——但你会看到这两家公司以及业内几乎所有其他公司都在各自的平台内提供这两种能力。

马丁：所以，有两种技术，起点用例不同，架构也有些不同，但它们显然会走向一个融合点，即兼具声明式和过程式能力。不管最终谁在上层，它们两者都能做对方的事。但与此同时，这是一个长达十年的旅程，在这个旅程中，存在围绕用例优化的架构。构建这类系统时所做的权衡和决策数量非常庞大……

特里斯坦：是的，比如TimescaleDB的特性与Snowflake非常不同，这些特性是针对特定工作流进行优化的。

马丁：没错，整个公司都专注于设计空间中具有不同优化参数的不同点。正是用例驱动着技术，因为所有的“引力”都围绕用例。所以，如果AI/机器学习和运营型用例增长更快（事实似乎如此），那么从架构角度看，这将决定技术的走向。

特里斯坦：马丁，你已经几次提到AI/机器学习领域增长更快。我以前没听过这种说法。

马丁：我来澄清一下。 broadly speaking, 有两个用例。一个是分析用例，由查询和仪表盘驱动。另一个是数据科学家创建复杂模型，然后在生产环境中提供服务，例如等待时间预测、欺诈检测、动态定价等。过去人们用R语言在现有数据上构建复杂模型，然后想出特制的方法来提供服务。现在这显然正在变成一种由数据湖提供服务的模式。

它的基数小得多，但如果你看看行业现状，这是一个增长非常迅速的用例。

乔治：米歇尔，你在数据科学社区和分析社区都待过。笔记本在许多方面是这些东西有时会结合在一起的地方。我很想听听你对两套技术栈如何演变的看法。也许它们在融合，也许它们在构建对方的功能，变得越来越相似。但这会将我们带向何方？五年后我们还会拥有两套独立的技术栈吗？

米歇尔：我认为我们会继续看到越来越高的专业化，因为我们没有能力或预算雇佣足够的数据科学家。这些技术栈会继续演变，并根据它们试图完成的任务进行专门化。

数据湖会有一席之地。你的图像、Blob存储，这些东西很可能在很长一段时间内继续留在数据湖里。只是它的样子会和现在不同。现在，对到底需要收集哪些数据缺乏理解只是问题的一方面。我们从一个极端走向了另一个极端。以前我们不收集任何数据，现在则因为不知道什么有价值而收集一切。实际上，这也不一定是个好主意。

我认为我们会看到数据移动停止，但格式将变得非常重要。我们需要那种互操作性，因为大规模重新处理数据成本高昂，时间上也难以承受。如果能避免，我们不想这么做。

而且我认为你会看到较低层级的去中心化，即业务单元内嵌，或者新产品团队、数据科学团队内嵌到产品团队中。你需要在最顶层有一个统一层，由技术构成，让每个人更容易查询或提供信息。

我认为笔记本可能是最适合这个角色的，因为它具有语言无关的方法。它能让你同时查看数据和代码，拥有所有上下文，丰富的业务上下文和可视化效果。我们将看到它演变成现代的“数据文档”，可以作为我们统一层的一部分。这样你的数据科学家可以用R语言工作，数据分析师可以用SQL工作，但最终我们可以隐藏所有代码，真正触及问题的核心：我们所做的事情对业务有何影响？

两套技术栈会合二为一吗？

乔治：这引出了我想讨论的第二个主要话题：我们如何将机器学习、Python、Scala世界与分析、SQL、BI工具世界结合在一起？确实存在两套技术栈和两个社区，仅仅因为运营原因，他们同步完全相同的数据源到Delta Lake和Snowflake。这不是根本的技术原因，只是工具演进的方式使得跨越那个边界太过不便。

主要有三种愿景。一种是将机器学习融入SQL，BigQuery可能在这方面走得最远，基本上是创建一堆UDF来做线性代数。另一种是Databricks的愿景，将SQL放入Python或Scala，使用DataFrame来实现。还有第三种愿景，使用Arrow作为交换格式，让所有东西都能相互通信，你可以任意安排。

你认为哪种愿景会胜出？

米歇尔：我希望能胜出的是像Arrow这样的方案，以实现互操作性。你会看到机器学习进入SQL，因为数据工程师完全有能力并且也需要做一些异常检测或逻辑回归，这在他们能力范围内。对他们来说，特征工程只是另一种数据转换。但他们没有同样的统计学背景，所以只能做到一定程度。

在另一端，你会看到数据科学家拥有非常好的数学背景，懂得如何进行更高级的深度学习，但缺乏技术技能。SQL是处理数据最成功的语言，所以你会看到两者都能真正变得有能力支持这两种用例。最终，你会继续看到专业化：做深度学习和做预测模型要做的事情有根本不同。

特里斯坦：我经常思考Arrow的愿景。我认为最终它会占据主导地位，原因正如马丁所说：工具会随着它们所服务的人物角色和使用场景而演变。

我想做所有的数据准备和特征工程，然后在此基础上训练机器学习模型。当然，人们确实这么做。但是，做这两件不同事情的基础设施通常是分离的，造成了巨大的迟滞。这纯粹是技术上的迟滞。Arrow并不能解决所有问题。Arrow当然有帮助，但还有一些愚蠢的问题，比如做这些事情的服务器在不同的云上，以及交换费用（或者叫出口费用）很高。

马丁：存在多种语言是有原因的，并非因为一种图灵完备而另一种不是。原因是人们围绕语言及所有工具构建整个工作流。所以你会得到一个异构、碎片化的系统。因此，确实需要开放的接口。

乔治：鲍勃？

鲍勃：目前，我非常相信采用多个系统与通用格式交互的方法。

Arrow在这方面是巨大的一步，不仅因为它是一种高效的格式，还因为它为人们在Spark环境中做高级分析提供了一致的内存布局。这是目前世界运作的方式，因为大多数客户实际上同时拥有数据仓库和分析平台，并将它们连接在一起。

然而，我将继续做一个彻底的激进派，并宣称我们今天在机器学习方面采取的方法大致相当于汽车中的内燃机方法。Arrow将那些预测系统与声明式数据库连接起来，实际上创造了混合动力或普锐斯时代。

混合动力将在未来三到五年内占据主导地位。每个主要供应商都会构建混合系统，它们都将使用某种接口集成完整的预测栈和完整的声明式、关系型SQL栈。但这只是暂时的，直到关系型真正解决更广泛的问题。

乔治：这是否意味着你会使用SQL函数，比如PredictX之类的？

鲍勃：不。具有讽刺意味的是，我认为尽管SQL在2030年代之前将主导数据建模和数据转换，但在此之上还有另一个层次，即业务建模，这需要用知识图谱来表示。知识图谱将是我们2030年代进行预测性分析的方式。未来需要发生的是，产生新一代基于关系知识图谱的数据系统来实现这一点。

数据网格：去中心化的团队，统一的架构？

乔治：米歇尔，你之前提到一个词我想跟进一下——“数据网格”。你能为在座各位简单定义一下吗？因为类似于数据湖与数据仓库之争，它更多是一个历史现象，还是一个我们想继续采用的、真正良好的架构？

米歇尔：数据网格实际上是一种概念，将数据处理、ETL和分析去中心化到各个独立的业务单元，然后在顶层有一个统一的解决方案。要做好这一点，需要专业的数据团队、专业角色、可供他们进行数据处理的“基础设施即服务”，以及一个类似“联邦”的总体标准委员会（由数据工程师组成），以确保所有ETL看起来一致，这样当你在某个通用查询工具上尝试数据检索时，能获得所需的熟悉感。

我们很快会看到像Arrow这样的东西走到前台。我认为客户会要求它，因为我们目前面临诸多挑战：存储和处理成本高昂，试图进行处理的团队缺乏所需的业务上下文，导致来回反复和大量时间浪费，大量数据质量问题，数据重复等等。最终，我们想把知识主体提取出来，并将技术置于知识主体所在之处。数据网格就是这种尝试。

鲍勃：数据网格倡导者谈论的一部分是关于如何组织、如何构建团队来管理大型企业中非常分散且重要的数据源。这非常非常重要，数据网格在这方面有一些好想法。

从架构上讲，数据网格有一个奇怪的想法，认为数据基本上是流式的，你可以使用Kafka之类的工具在数据传输过程中进行转换。我不相信这一点。

虽然存在流数据，你可以对流数据（即仅追加的数据）做很多事情，但对我来说，另一个关键的数据源是来自业务系统的事务数据。流式解决方案对此没有答案，它们只是假装数据一致性不重要。我不理解这一点，因为我在考虑数据管理时，把数据一致性放在首位。

马丁：“网格”历来是这样一个术语，它将架构与管理域、分布式服务网格、分布式WiFi网格、网状网络等混为一谈。我认为鲍勃说得完全正确：确实存在一个非常现实的问题，即独立的管理域、独立的处理域、对工具集的独立访问。这与构建一个完全分布式的架构（这往往困难且低效）非常非常不同。通常不是推广网格理念的人，而是当人们听到“网格”这个词时，会默认联想到完全分布式，而这往往是一种糟糕的系统构建方式。

乔治：像个网络人说的话。

马丁：过去几十年在其他领域目睹了完全相同的事情。

特里斯坦：我们都是非常关注技术的人，所以当我们想到数据网格时，往往会考虑其中的架构部分。鲍勃，很高兴你指出了分布式团队和人的方面。我对数据网格一直的疑问是：为什么不能用统一的架构来实现你所谈论的这种分布式本质呢？

米歇尔：我的偏好始终是拥有一个非常干净、易于理解的、我们不需要移动的数据集，它在我们的大批量批处理分析以及数据科学工作中都表现出色。那是理想境界。目标就是只有一个数据存储，然后在它之上运行一些东西，每个东西针对不同用例进行专门化，但你只有一个数据存储。

现代数据栈的下一个用例

乔治：现代数据栈正在不断吞噬越来越多的用例。它之前消灭了多维数据集，现在基本上也消灭了Hadoop。它不断地将更多用例拉入自己的轨道，因为它从根本上非常灵活，能够足够好地处理许多不同的事情，以至于你不想再为一个用例去购买另一个系统、构建另一个系统。未来几年，有哪些最有趣、最令人惊讶、最重要的用例可能会被拉入现代数据栈的轨道？

鲍勃：复杂数据。我们现在在预测性分析领域发生了很多非常有趣的事情。对我来说，我们已经从半结构化数据作为最有趣的数据源，发展到拥有各种各样的数据源。昨天我和一家医疗领域的公司交谈，现存的数据量极其丰富，图像、医生笔记，所有这些对我们当今的系统来说都是不透明的。但五年后就不会了。所有这些都将成为现代数据栈的一部分，对我来说，这对于未来几年将被创建的应用类型来说是一个巨大的变革。

特里斯坦：我上一份工作是负责一家公司的营销，深入涉足增长营销。你遇到的问题是需要不断编写代码在系统之间来回推送数据，因为不同的运营系统做不同的事情，而你又需要所有系统中都有相同的数据。

还没有人重新架构这些系统，以在现代数据栈中，只需获取你已摄入的所有工作，然后将其推送回你的操作系统或运营系统。但我认为我们正处于这个阶段的起点。

鲍勃：特里斯坦，你实际上谈论的是现代数据应用的出现。它本质上是一个能够自主为企业做出决策的运营性应用。我们看到的这类应用还很少，例子也很简单，但它们在将来会非常重要。

乔治：我见过关于数据应用的两种愿景。一种是将数据应用视为一个独立的系统，你从数据仓库中取出重要数据，然后推送给它。另一种愿景是数据应用原生地构建在数据仓库之上运行。我很好奇大家对这两种模式的看法，以及它们未来的走向。

鲍勃：这实际上还是我们一直在谈论的关于这些东西如何构建的同一个话题。数据应用是实际上能采取自主行动的预测性分析。它获取原本会呈现给人的数据，并利用这些数据在业务中实际采取行动。如今它们以各种方式构建，因为缺乏好的工具来构建数据应用。几年后就不会这样了。

延迟：我们需要降到多低？

乔治：当你尝试构建数据应用并自动采取行动时，会遇到的一个问题是延迟变得极其重要。生态系统中的每个人都在与这个问题作斗争。关于如何解决延迟问题以及我们需要将延迟降到多低，有很多不同的愿景。延迟需要多低？到什么程度我们就能覆盖大多数有趣的用例？

鲍勃：人们有几十到几百甚至几千个运营系统。它们越来越多的是SaaS运营，位于你的组织外部。它们现在始终是事实来源，代表“现在”，而数据仓库或数据湖则关于历史或“过去”。

延迟需要多低？需要是零秒吗？我不这么认为。有些应用需要零秒或即时，主要与事件和某种告警有关。大多数情况下，如果你能在一两分钟内获得数据，你就可以利用历史系统中的数据结合预测性分析来开始对其执行操作。

马丁：这是一个非常复杂的话题，我认为非常依赖具体用例。但系统设计者在延迟和吞吐量之间通常会进行严肃的权衡。如果你想要更高的吞吐量，你会进行批处理。批处理的原因是可以减少域交叉。

然而，如果你审视大多数系统，你可以做出权衡。这意味着你可以在数据湖中实现低延迟，也可以在数据仓库中实现高吞吐量，反之亦然。这些不是架构限制，它们只是为了服务主要用例而做出的权衡。我听过很多关于延迟-吞吐量权衡的讨论，当你深入到机器层面时，它们只是系统构建时所作权衡的结果。

乔治：我们注意到的有趣一点是，开始需要花费更多成本来降低延迟的那个点，实际上比人们想象的要低。我怀疑通过面向吞吐量优化的架构，你可以将延迟降到10秒左右。基本上，我认为面向吞吐量优化的架构能做到比我们预期更低的延迟。

米歇尔：你认为服务层会发生什么？你的网站仍需要基于这些数据运行。你认为会继续存在一个缓存层吗？还是一个独立的系统？

鲍勃：这取决于系统需要什么特性。如果某个东西需要极低的延迟，当今的数据仓库并不总是合适的解决方案。这完全取决于应用。这些产品的延迟会降低，但正如马丁所说，某些架构选择使得Snowflake的延迟特性与例如MemSQL的延迟特性有所不同。

特里斯坦：我希望未来能看到更多Lambda架构，但使用现成的工具。我的数据同时流入一个更接近流式的系统和一个更接近批处理的系统，这样我就能两全其美。当你构建这些系统时，你是在做权衡。作为用户，我希望能够做出选择，并且两者都能拥有。

乔治：我们只剩一分钟了。我想问每个人一个是否问题：在Snowflake、Databricks、谷歌、AWS和Azure之外，还会出现另一个主要的数据平台吗？米歇尔，从你开始，会还是不会？

米歇尔：会。

乔治：鲍勃？

鲍勃：你的时间范围是多久？

乔治：未来五年内。

鲍勃：会。

米歇尔：会。

鲍勃：但相对于那些巨头，新平台可能规模较小。

乔治：我说的是“主要”。这听起来有点模棱两可……

鲍勃：五年前的Snowflake也很小。

乔治：特里斯坦？

特里斯坦：我认为不会。

乔治：马丁？

马丁：会。

乔治：好的，非常感谢各位的参与。这是一次非常有趣的对话。我非常感谢各位的到来。我知道我们的听众也一样。FINISHED