Streaming Ecosystem Complexities and Cost Management // Rohit Agarwal // #302
48:51 Share

我的名字是Rohit，我在Tecton工作，职位是工程总监，我主要负责几个工程团队。至于咖啡，我非常喜欢Cometeer，我喜欢咖啡冲泡过程的简单便捷。我在疫情期间开始使用Cometeer，当时所有的咖啡馆都关门了，从此就一直用它了，可能是疫情期间唯一坚持下来的事情。

今天，我们将与我的朋友Rohit深入探讨流数据，以及与传统机器学习相关的实时、低延迟用例。在我们开始之前，我想先讲一个故事，因为……

大约两个月前，在假期期间，我问社区里的每个人新年想看到什么内容。许多人说，他们想看到一些传统的机器学习内容，感觉我们谈论AI和LLM太多了。所以这一集就是为了满足你们的愿望。如果你在YouTube上收听，

全球各地的电台，我们推荐一首歌曲，来自一位粉丝Amy或Ami，因为我一直邀请社区成员分享他们最喜欢的音乐。这首歌是一颗我之前不知道的宝石，是Gibran Alkoser演唱的，歌名是《Idea 10》。

测试生产环境，这就是我们的运行方式。这次对话的缘起是我与你以及Tecton的联合创始人Kevin的一次通话，你们向大家解释了流数据和数据流生态系统的现状，我认为这是一个非常棒的播客主题，我很想和你深入探讨。所以我们应该从你的日常工作开始，你在Tecton做什么？

是的，当然。我大约四年前加入Tecton，当时我们规模很小，我几乎参与了所有工作，但我主要专注于实时部分，例如你提到的流数据以及相关挑战。

我的角色现在有所改变，我更多地担任管理角色，管理三个不同的团队，这些团队专注于流数据、批处理数据、在线推理、离线推理等等，也就是Tecton核心产品提供的核心数据流和基础设施。简而言之，我的日常工作有很多会议。但我们应该先说明一下，因为我们不能认为每个人都知道Tecton是做什么的。

是的，当然。他们是最初的OG特性平台之一，处理大量特性、转换数据，确保你可以进行欺诈检测、推荐系统、贷款评分等用例。

你是否看到人们大量使用Tecton进行其他用途？还用于保险理赔处理，这也是我们的一个重要用例。推荐系统有很多不同的形式，然后总的来说，欺诈和风险应用可以说是我们最大的用例。是的，这些用例需要非常快速的响应。

这就是为什么我们想谈论流数据，这直接引出了整个流数据生态系统。请分解一下，它是什么？现在是什么样子？自从我大约一年半前和你通话以来，有哪些变化？

是的，当然。我认为当我们观察客户时，他们中的大多数人都已经投资了流解决方案，这些解决方案可以低延迟地传输数据。例如，Kafka、Kinesis等等。但这只是一种数据传递机制，但在有效利用数据方面却存在不足。我们与许多应用公司交谈后发现，他们拥有Kafka流、Kinesis流中的数据，但他们却无法有效地利用这些数据来构建机器学习模型或分析用例。那么，为什么呢？

是的，我会解释一下。我认为从根本上说，生态系统在各种不同的工具和技术方面非常分散。

因此，你必须将许多这些东西串联起来，为每一样东西雇佣专家。即使你能做到这些，这也不是一次性的成本，你需要持续构建。但这些系统需要弹性和可靠性，因此基本上维护这些系统是一项持续的工作。我们看到的最简单的解决方案是，人们拥有Kafka流，他们会有一个流处理器，它可以是Spark或Flink。

然后他们基本上将其连接到存储，可能是键值存储，也可能是离线存储，如Iceberg，然后在其之上构建一个服务层，供应用程序使用这些数据。这些不同的步骤实际上需要不同的技能。组建一个团队来完成所有这些工作非常困难。生态系统中提供的工具本身也相当有限，难以使用，特别是如果你试图从零开始构建。我认为，如果你有一个非常庞大的团队，并且在Facebook或Meta这样的规模上运行Flink，那么它可能在某种程度上是可控的。但对于那些只想利用实时数据的较小公司和团队来说，生态系统并没有提供这些更简单的工具。

我知道DynamoDB在这方面扮演着重要的角色。它在哪里插入？是在服务层吗？是的，Dynamo基本上存储来自流处理器的记录，然后使其能够进行高吞吐量、低延迟的服务。本质上，某些东西需要写入Dynamo，某些东西需要从Dynamo读取。编写器和读取器是每个公司都以自己的方式构建的东西。DynamoDB

即使维护它也是一项挑战，因为你需要考虑模式是什么，它有利于读取延迟还是写入延迟，哪一个对你更重要，以及如何随着时间的推移来改进它，所有这些都是构建所有这些管道的人必须深入思考的挑战。是的，因为你试图让事情保持超级快速，并确保贷款评分、欺诈检测或推荐系统等用例非常快速。因此，你需要考虑在任何地方都能节省毫秒。是的，还有一个额外的维度是成本，因为我一直认为这是同一枚硬币的两面，即

你想要多新鲜的数据，以及你愿意为此支付多少，对吧？理想情况下，它们应该彼此同步，这意味着如果我想要毫秒级粒度的实时数据，我愿意为此支付更多费用。如果我能够接受一小时的新鲜度，那么我愿意为此支付更少的费用，对吧？理想情况下，你希望系统内置合适的旋钮，可以让你进行这种权衡，并且你实际上可以进行调整。

对于我们在现实世界中看到的许多系统来说，这并不存在，这意味着它们要么拥有一个为非常低的延迟而构建的系统，该系统的成本非常高，要么完全相反，成本相对较低，但系统无法承受应用程序所需的相当低的延迟。而且

大多数公司都有各种各样的用例。有些需要非常低的延迟，有些可以接受稍微更高的延迟等等。因此，我认为拥有一个能够管理这种新鲜度成本的系统非常重要，而不是像，你知道的，构建它，最简单的比喻是，你知道的，

人们并不仅仅寻找法拉利，因为它很快，而且非常昂贵。然后人们真正想要的是，他们想要一个在需要时速度很快的系统，但在你想去杂货店买牛奶和鸡蛋时，也可以像福特SUV一样。是的，和你的家人在一起。是的，这完全有道理，因为你有不同的用例有不同的需求和不同的新鲜度，以及你愿意为之支付的费用也有所不同。因此，对于这些情况中的每一个，你都希望能够根据你拥有的不同约束条件来配置它。

是的，当然。我想到的另一件事是，因为你谈到了人们如何使用Flink或Spark，我想我记得……

DuckDB以某种方式插入到这里。你能跟我谈谈这个吗？

是的，在批处理方面，我们提供了一个名为Rift的解决方案，它使用.db作为某些批处理管道的替代方案。这有点像Spark Batch的等价物，对吧？但在流处理方面，我们不使用.db，我们有自己的流引擎。是的，这说得通。好的，所以基本上，你设置的场景是，这个难题有很多不同的部分。大多数人都为其组织中的所有用例构建了一种通用的解决方案，他们没有考虑如何为每个用例提供服务。

然后你还有这些管道和平台的可靠性或维护问题。你如何看待团队处理维护过程？

是的，我的意思是，说实话，这非常具有挑战性，因为很多时候构建这些系统的团队有时是机器学习工程师或更专注于数据层的人员。但是维护系统的生产经验通常会落到不同的团队身上。团队之间的这种隔阂往往是我们看到的许多客户面临的巨大挑战。

最重要的是，用户关心端到端的可靠性，而不是我的Flink是否宕机或我的工作程序是否宕机等等。他们正在寻找能够在整个管道中提供端到端可靠性的解决方案。

这很难构建，因为许多值班生产团队会单独考虑一项服务。许多机器学习团队关心的是整个管道的端到端可靠性。这种不匹配往往是我们看到的许多客户非常关心的问题。

所以，这意味着基本上，凌晨3点被ping的SRE正在被ping某个特定部分，例如Flink宕机了。是的，没错。但是机器学习工程师在想，好吧，我有Kafka，我有我的Flink，他们是如何看待它的？这不仅仅是……

仅仅是该服务宕机了。是的，例如，如果你的Flink宕机了，或者你的Spark结构化流引擎宕机了，那么可能没有消息在Kafka中备份。现在机器学习应用程序看到的是高新鲜度，基本上它们不再处理任何实时数据。因此，这些后果是如此之远，以至于

如果你正在构建一个需要将许多这些不同的工具串联起来的解决方案，那么这就像一个永无止境的尝试构建端到端可靠性的游戏，因为对于单个组件来说，这非常困难，然后你开始看到这就是你可以为之辩护的地方

很多钱都被烧掉了。是的，我的意思是，我们经常遇到客户花费数万美元，甚至数十万美元用于简单的流管道。我只是在谈论它的基础设施成本。还有其他成本，例如SRE成本和日常运营成本。但仅仅是AWS基础设施

对于所有这些管道来说，都是相当高的，而且考虑到他们的技术栈，优化它非常困难。你是否考虑过关于如何优化它的不同最佳实践？除了像，好吧，在这里插入Tecton，对吧？我想象你已经看到团队做得很好。那是什么样的？

是的，我认为，说实话，许多正在出现的较新技术实际上旨在降低设置这些东西的运营成本和一次性成本。我认为这需要从……

一种思维模式的转变，即我想使用谷歌和Facebook正在使用的技术，通常可能是Flink等等。我认为这需要你对一些正在出现的较新技术持开放态度。我将举一个例子，我们看到许多流解决方案不使用连接到节点的本地磁盘，而是使用S3作为存储服务，并通过S3传输所有这些数据，基本上是在对象存储上构建。

一个很好的例子是WarpStream，它基本上是S3上的Kafka。他们最近被Confluent收购了。我们看到许多这些新兴的实时运营系统真正为云而构建，并利用对象存储。我认为这是一个巨大的方法，客户可以利用的巨大杠杆，看看我们在堆栈中是否有效地使用了云资源。

这仅仅是因为通过S3这样做更便宜吗？

它更便宜，而且它也提供了弹性。我认为你可以这样考虑，你可以开始独立地扩展计算和存储，而不是例如，如果你使用连接到服务器的磁盘，那么每次添加新服务器时，你也会向其中添加更多磁盘。因此，很难将两者解耦，而某些应用程序可能需要更多计算。在这些情况下，你仍然最终要为更多存储付费。

我认为云提供了这种弹性，能够独立地扩展不同的层。这不仅降低了成本，而且降低了运营开销。是的，这很酷。还有什么技巧？因为我还没有听说过这些刚刚被Consulate收购的家伙。他们的名字是什么？WarpStream。WarpStream。是的，很有趣。是的，

我认为我们看到一些客户使用其他有趣的技巧。例如，流工作负载的一大成本通常是检查点，即你多久写入一次存储，以防你的流应用程序、你的流管道失败，你可以从最新的检查点恢复。通常情况下，你检查点的频率越高，

你为这个检查点成本支付的费用就越高。但你可以获得的好处是，如果你宕机了，你可以从最近的检查点恢复，这可能只是几秒钟前，对吧？因为你正在频繁地进行检查点。我认为对于我们的许多客户来说，许多这些流应用程序的默认检查点设置非常高。他们经常会惊讶于账单出来时的成本。对于我们的许多客户来说，我们可以看看……这只是其中一件事……

当大多数客户问我们，为什么我的现有堆栈的流账单这么高时？人们首先查看的是，你多久进行一次磁盘检查点等等？我认为我们的许多客户都对此感到惊讶，好吧，我甚至不知道这一点。大多数情况下，你不需要进行如此频繁的检查点是什么？

所以我认为检查点通常非常重要，应该进行。问题在于，你想每秒进行一次，每10秒进行一次，每30秒进行一次，每分钟进行一次，还是每小时进行一次。许多流工作负载的默认设置是进行非常积极的检查点。如果，即使你可以将其从一秒调整到例如10秒，并且你的应用程序允许这种恢复点目标级别，那么你可以为我们的许多用户节省相当可观的成本。

是的，从一秒到10秒感觉差别很大。是的，我的意思是，正如我所说，这是一个你愿意为多少新鲜度支付多少成本的杠杆。这些旋钮存在于某些系统中，但你需要知道这些旋钮是什么以及如何有效地调整它。否则，你最终可能会为不需要那种新鲜度的负载花费大量成本。这回到了你一开始所说的，当你必须将许多不同的工具拼凑在一起时，你必须拥有了解并精通所有这些工具的人，以便他们知道

哦，我们可以每10秒进行一次检查点。是的，他们还需要对端到端管道进行推理，并了解这一个事情将导致端到端管道，因为大多数应用程序团队都关心这一点，而不是例如这个其他目标。这只是一个非常难以解决的问题。我知道你谈到了你如何看待数据的形状作为你可以使用的杠杆。所以它是。

你在我脑海中描绘的这幅图就像，有很多利益相关者参与其中。这只会增加解决方案的复杂性，因为任何时候你都必须投入更多的人力来解决问题，这都会增加解决方案的复杂性。

但是你还有，就像我想象数据科学家并没有过多地考虑模式，以便使其完全优化速度。是的，没错。我将举一个例子，我们遇到一个客户，他们将protobuf消息存储在消息流中，对吧？好吧，这说得通，因为将数据放入流中的团队是

正在处理protobuf，他们就是这样做的。但是，在消费者端，我们必须将所有这些protobuf反序列化为我们可以解析和摄取的消息，以便将其摄取到存储和服务解决方案中。当你与数据科学家交谈时，他们

只是不想考虑为什么首先要存储协议，这只是一个抽象级别的思考，他们习惯于操作略高于抽象级别，这完全说得通，但他们要么被迫考虑更低的抽象级别，要么他们必须处理他们正在获得的性能损失，是的，这似乎他们必须以某种方式为许多现有的BSC系统支付税款。

是的，这是一个很好的观点，因为他们只会做最简单的事情。这就像水流向下游，试图减少它遇到的摩擦。因此，如果这是他们知道的唯一有效的解决方案，他们可能会承担这个责任。这让我想到，

在组织方面，这些不同的利益相关者相互沟通和了解彼此的目标是多么重要，并且知道，好吧，数据工程师正在为我设置这个。那么，更多地谈谈数据工程师可以做什么，对吧？如果我是一个数据科学家，我正在深入研究数据工程，这可能不是我的强项，但这将帮助我了解这些人

能够做什么

或者这将帮助我了解这些人可以使用的杠杆。是的，没错。例如，我们看到的情况是，有些人不在乎流中有什么，只要他们将这些消息中的每一个都视为黑盒即可。他们的工作只是确保这些黑盒流经系统。还有一些团队关心黑盒内部的内容以及这如何影响端到端系统。而且

我们一次又一次地看到这种情况，这就像，这不是我的问题，是你的问题，这不是我的问题，是你的问题。但最终，它损害了实际需要这些数据的应用程序。是的，这甚至不是一个维度，就像上游数据创建的地方。

是的，没错。试图弄清楚如果上游发生变化，那么它将如何产生多米诺骨牌效应。是的，没错。我们看到的是，当我们看到应用程序团队基本上说，嘿，我们看到

不新鲜。我们过去看到的是一秒钟前的事件，现在我们看到的是一小时前的事件，对吧？调试这对于我们的许多客户来说需要付出很多努力，那就是，是处理屏幕的应用程序延迟了吗？还是将消息放入屏幕的应用程序延迟了吗？是消费者应用程序延迟了吗？所以这有点像，你知道的，高速公路，即使

即使一个地方卡住了，它也会影响整个后端，找出确切的问题所在通常具有挑战性。哦，是的。而且你必须成为一名侦探。你使用的工具越多，

头痛就越多。是的，问题变得非常困难，因为现在你需要检查所有不同的工具交互。现在，如果你使用两个工具或四个工具，那么现在你需要检查8个或16个不同的交互点。我为所有那些每天都在处理这个问题的人感到难过，因为这听起来很痛苦。

你还有什么要告诉我的吗？还有什么技巧？以及流生态系统方面的内容。我的意思是，我喜欢这样一个事实，即我在这个领域非常缺乏经验，而你却生活在这个领域。

所以，你告诉我的简单的事情让我大开眼界。是的，例如，我们看到的另一件事是，有多少数据，你的流中有多少数据保留。例如，流通常包含最近的数据，但最近本身是主观的。你可能会在你的流中保留一天的数据，或者你可能会在你的流中保留七天的数据，或者你可能会在你的流中保留30天的数据等等。你可以一直扩展它。同样，你……

需要有效地考虑你想要多少数据。让我稍微回顾一下。所以我们的许多客户必须……

将流数据和批处理数据拼接在一起，因为他们想要了解的是，是的，他们想要了解过去五分钟内发生的事情，这可以通过查看流数据来实现，但他们也想知道过去七天或十天内发生的事情，对吧？这可能包括查看，好吧，我将查看过去一天的流数据。然后我查看我的批处理数据，因为我的批处理数据包含过去六天的数据，对吧？所以基本上，

我认为有效的一点是决定批处理和流处理中存储数据的截止点，对吧？因此，降低成本的一种方法可能是，我只会在流中保留过去两天的数据。然后，从那时起直到历史记录的所有内容都将存储在我的批处理数据中。或者你可以说，我不处理批处理数据，我的应用程序只需要30天的统计数据，我将所有这些数据都保留在流中。

你做出的每一个决定都会以相当大的方式影响成本。例如，我们帮助许多客户的一种简单方法是，如果你有一个系统能够有效地，你知道的，

处理批处理和流数据，并将其提供给应用程序，而应用程序并不关心它来自批处理还是流处理，那么你就可以真正开始根据你想要在流中获得的内容和想要在批处理中获得的内容进行套利，对吧？你可以开始在你的流中放入越来越少的数据，例如只有最近的相关数据，并将更多内容推送到批处理。

但这需要你拥有一个非常先进的，我认为，数据工程管道，它能够有效地组合来自批处理和流处理的数据。例如，我们可以使用甚至，你知道的，流中的几小时数据，只要超过该时间的数据来自批处理，那么如果他们习惯于在流中存储30天、7天、10天的数据，这就可以真正降低用户的成本。

老兄，那么你是否看到人们为批处理和流处理创建了两个不同的系统

是的，这实际上非常有趣。所以我们看到的是，如果，例如，一个机器学习工程师或数据科学家说，“我需要五个数据点。”一个是过去五分钟的最近交易历史，一个是过去一小时的，一个是过去十天的，一个是它的终身总和，基本上是总数，对吧？前两个是比较近期的，

就像工程师们会为它构建一个流式管道一样。另外两个更像是历史性的，比如七天或终身。他们会为此构建一个单独的批处理管道。对。是的。嗯，然后这些完全是不同的管道，数据科学家必须为每个管道分别编写转换等等。然后他们会像使用它一样在机器学习模型中，并根据它分别进行训练和服务。嗯，

拥有这些单独的管道通常对客户来说是一个巨大的挑战，因为它会导致工作重复、基础设施成本以及每个管道的运营维护。

我们又回到了运营维护。这是不容低估的事情。是的，我的意思是，成本不仅仅在你上线的那一天就停止了。这有点像是它的开始，实际上大多数人实际上都觉得，如果你花了比如说三到六个月的时间把它投入生产，你的工作就完成了。但是，

实际上，这只是工作的开始。除此之外，真正将其投入生产才是最难的部分。是的，这就是你收到账单的地方。突然间你就像，我们在这些东西上花了这么多钱？是的，没错，是的。

我们看到的另一件事是，许多流式生态系统参与者也日趋成熟，他们在其中提供了越来越多的服务。一个很好的例子是，如果你今天有一个管道，它正在获取流数据并将其转储到 S3 或 Iceberg 等中。实际上，像 Confluent 正在为此提供托管服务。所以你只需要像

并且只需说，嘿，把它转储到 Iceberg，他们有一个名为 TableFlow 的新服务。因此，我们看到行业中存在很多这种碎片化，也许有一些供应商只是为了生成流消息并将其提供出来。另一个供应商是将它们放入对象存储中。也许还有另一个供应商将它们放入在线存储中。我们看到其中有一些整合，这实际上再次提高了您需要考虑的抽象级别

例如，正如我提到的，Confluent 现在提供了一种完全托管的服务，基本上可以将您的流转储到冰川中，您甚至不必考虑数据如何从您的流传输到冰川以及在那里会发生什么等等。

我认为这些托管服务在考虑成本时价格昂贵，例如一次性成本。但是，如果您真的能够考虑它的运营成本，我认为这些服务是有意义的。我们越来越多地看到这一点，例如，即使在 Dearbricks 中，即使在 Confluent 中也是如此。

甚至像 Snowflake 这样的公司也提供了一些这样的服务。例如，如果您有一个 Kafka 流，并且您希望将记录转储到 Snowflake 表中，他们正在为此提供托管服务。然后显然他们拥有 Snowflake 堆栈之外的整个存储。因此，我们看到实际上许多这些供应商都提供了更端到端的解决方案

并承担将这些工具串联在一起的复杂性。我认为，如果您正在运营一项服务，如果您正在运营一家处理许多这些不同工具的公司，那么使用不同供应商的一些托管服务可能对您非常有用。我们在 MLOps 社区 Slack 中一直看到这种情况。许多人都来提问，这几乎就像，

是的，这个问题以某种形式提出，嘿，我正在使用 XYZ 托管服务，无论是 SageMaker、Databricks 还是其他什么。但它太贵了，我在考虑我们可以做些什么来降低成本。不可避免地，有人会在主题中插话并说，好的，您可以……

使用这个开源替代方案，或者您可以尝试以这种方式自行推出。但不要忘记将要维护它的工作人员的成本。因此，您认为它更便宜，也许在纸面上，您的云成本下降了。但是您的经理或您的经理的经理正在查看它并说，我们刚刚在云成本上花费更少，但我们在人员配置上花费更多。

是的，这确实是我们看到的一件事。我们看到的另一件事是，许多公司都希望专注于产品速度，对吧？因此，例如，即使您设置了所有这些东西，但您预计需要构建三倍或四倍数量的功能和模型等，并将其投入生产。

这是否会成为我快速发布这些新模型、管道和产品的瓶颈？这确实是一个问题，因为它会延迟您快速将这些产品推向市场的能力。因此，我们也在整个行业中看到了这一点，其中

有时人们只是来找我们，因为他们觉得，嘿，我知道这个。我可以自己运行这个。我甚至可以雇人，我可以做所有这些事情。但作为一个企业，我只是不想关注这些事情。我只是想专注于产品速度，并能够向最终消费者推出最好的产品，而不必担心

这个产品是否会因为其他团队没有将其列入他们的路线图而被延迟，并且需要更多资源来维护这些东西。我前几天看到 fly.io 的一篇博客文章，谈论他们如何……

创建了 GPU 产品，因为他们是，你知道，像这样的云。他们基本上说我们对整个 GPU 产品是错误的，这需要很多努力，我们不会继续进行。他们并没有停止它，但他们并没有真正向前推进。在这篇博客文章中，有一个我认为是我听过一段时间以来最酷的短语的小片段。它让我印象深刻。它说，

看待初创公司的一种非常有用的方法是，它是一场学习东西的竞赛。是的，这很有道理。是的。

这只是一场失败和失败的竞赛，然后学习什么有效。所以这正是你所说的。就像它呼应了这个产品速度。如果这个产品有效或无效，我们可以学习多快？是的，没错。而且你想消除尽可能多地减慢你的学习曲线的瓶颈。而且可能唯一的一个瓶颈应该是你从客户那里获得反馈的速度有多快？但除此之外，你不想减慢向客户交付价值的过程。

是的，因为那是掌握在你手中的。没错，是的，是的。是的，其他事情，也许获得反馈或循环返回有点困难。所以这是有道理的，伙计。所以，好吧，酷。好吧，这是一个可靠的。我的意思是，托管服务也是如此，不同的产品进入不同的领域总是让我着迷，因为它感觉像

每个人都试图成为一个平台，就像 Databricks 一样。因此，五年后，您现在可以在 Confluent 上执行 Databricks 上可以执行的所有操作。我不知道你对此有什么想法。是的，我认为一个很好的例子是，例如，Iceberg。我认为 Iceberg 正在成为……

我认为像 GitHub 对代码一样，我认为它将成为任何组织的数据。它将成为所有内容存储的中心位置。像所有供应商一样，可能是 Databricks，可能是 Snowflake，可能是 Confluent。基本上，他们必须从中读取和写入，但是所有内容都存储在那里。我们看到越来越多的这些服务变得与这些实现无关，而更专注于……

他们如何能够更好地相互兼容，尤其是在存储现在转移到通用解决方案的情况下？我认为我们将看到更多这样的事情，您可以更容易地从一个供应商转移到另一个供应商，因为您不必考虑数据将如何从一个供应商迁移到另一个供应商，这曾经是最大的挑战。

如果您将数据存储在一个供应商中，只需将其迁移到另一个供应商而不会以安全的方式丢失它，我认为这将成为过去的事情。如果所有这些数据最终都存储在 Iceberg 等中，或者存储在云上的开放标准格式中，那么从一个计算供应商切换到另一个计算供应商我认为将变得容易得多。哇。也许它甚至不是那样

好的，我们在 Databricks 上。现在我们将迁移到 Snowflake。就像对于这项工作，我们使用 Snowflake，而对于另一项工作，我们使用 Databricks。

这项工作本质上可以是 Databricks Spark 作业。它可以是 Snowflake 查询。它可以是 BigQuery 的某些东西。它可以是 CBB 等。我认为我们已经开始看到这种早期迹象，许多公司现在都在强制要求我们将所有存储都放在 Iceberg 中，因为我们不想被任何特定供应商锁定在数据存储中。伙计，这太疯狂了，就像类比一样

冰川对数据来说就像 github 对代码一样，是的，我的意思是，如果你今天去任何组织，大体上大多数可能会有几个团队，比如几个不同的工程团队，可能是 ui 团队、前端团队、后端团队等等，他们可能都将他们的代码存储在 github 上，它们都是可搜索的，并且它们具有共同的机制，它们可能具有不同的构建过程等等，就像构建代码等等

但是他们实际上都在从 GitHub 读取，并且他们正在对那里的存储库进行更改。我认为，我认为代码可能领先于时代，而数据现在可能正在赶上。但我确实想象一个这样的世界，我们不必考虑，这些数据是否存储在

一个供应商，而这些数据存储在不同的供应商中？数据只是存储在 Iceberg 中，您可以从任何地方读取和写入，基本上，只要您具有标准数据格式和标准目录即可。是的。好吧，这就是梦想。然后呢？就像数据一样

专门用于其专门的用例。就像，哦，我有这个生成式 AI 用例，或者我有这个欺诈检测用例，它正在做，就像你说的那样，它正在启动某种计算，

是的，我的意思是，我们已经看到这种情况适用于结构化数据。我认为它正在集中于此。我认为非结构化数据和不同类型的数据（如视频等）仍然有一些空间需要改进。但我相当肯定，对于结构化数据以及非结构化嵌入数据，我们距离许多组织将所有内容都存储在 Iceberg 中的世界并不遥远。该死。是的，这……

非常酷的想法，以及它解锁了什么。是的，我认为，例如，Databricks 收购 Tabular 时，Databricks 本身实际上正在构建 Delta，这是一种与 Iceberg 不同的格式。我认为这是一个很好的迹象，表明即使可能是供应商本身也看到了他们需要前往的方向以及错误所在。首先想到的是，这是在

没有像正式委员会这样的标准化机构，它只是因为人们看到这是前进的方向而发生的，是的，我的意思是，很多冰川社区都来自不同的公司，我认为可能有 10 到 20 家公司正在运营，但我认为他们都意识到我们必须共同努力才能实现这个解决方案，否则

我们将最终进入一个世界，在这个世界中，可能 90% 的世界都在使用 Iceberg，我们有自己的存储格式，他们不想在这个世界中，他们像在其他地方的孤岛上一样。因此，当这个领域有足够的动力时，我认为这个领域有足够的动力，许多人都想加入这种动力，而不是像，你知道，远离它或逆流而上。

现在，让我们回到你之前说过的一件事，那就是人们理解他们不一定需要像谷歌或 Facebook 一样。他们不需要为如此巨大的规模而构建。更多地谈谈这个。是的，我认为我们面前最大的例子是……

是 DuckDB。我认为在一个这样的世界里，你知道，谷歌提出了 BigQuery，并且像……

有 Snowflake，有 Databricks，还有 Presto、Spark。许多这些非常大规模的批处理数据处理解决方案通常来自非常大的公司，因为他们需要它。他们有点被强加给其他所有人，这就是你必须使用的，对吧？即使我没有那么多数据，或者即使我没有那么大的规模，我仍然需要使用该系统并处理使用该系统的复杂性。就像，你知道，如果我想从……

旧金山到纽约，而不是乘坐商业航班，我需要驾驶战斗机，并且处理复杂性，这就像不需要的东西，但你知道有些人可能需要它，所以这就是为什么我现在必须使用它，我认为像 Duck TV 最近的流行就是一个很好的例子，人们看到是的，我的意思是，像 Snowflake BigQuery 这样的解决方案对于……

某些类型的负载是有意义的，但并非所有类型的负载都是如此。我需要查看我需要支持的工作负载，以及它们是否更适合 DuckTB 或 Snowflake，以及 BigQuery 等。我们也看到了这一点，许多数据管道不需要非常复杂、分布式、多并行的批处理解决方案。它们实际上在更简单的工具上构建起来要简单得多。我们已经看到了这一点，我认为我们已经看到了这一点

在批处理领域，我认为我们也将在流处理领域看到这一点，人们将查看比 fling 或 spark streaming 等简单得多的系统，并查看在这些原语之上构建这些系统。流式处理，我认为还为时过早，可能存在

在流式处理中，没有什么像 DuckDB 在批处理领域那样流行。我认为这是一个很大的差距，有一些公司正在解决这个问题，但没有什么像 DuckDB 在批处理方面那样大受欢迎。我认为一旦我们进入那个世界，我认为看看人们如何选择像 DuckDB 这样的更简单的工具，与更复杂的解决方案相比，这将很有趣，无论是在批处理还是流式处理中。是的。

DuckDB 以其用户体验而闻名，我认为人们喜欢这一点。它的简单性，或者只是它之上的开发者体验，都是神奇的。正确，是的。你认为为什么在流式处理领域，我们还没有看到等效的东西？我只是认为流式处理是一个稍微更难解决的问题，尤其……

我认为你需要考虑持续状态，而不是在批处理领域需要考虑的。批处理工作负载通常有点短暂。就像你可以启动一些东西，计算它，然后丢弃它，因为你有结果。流式处理更像是一件持续的事情，你需要不断地保持状态，而这本身可能会随着时间的推移而增长等等。这是一个稍微更难解决的问题，但我非常相信，像这样的事情

在未来五到十年内出现，甚至可能更早。我听到很多人都谈论流式处理是必需的，最终一切都会转向流式处理。你相信吗？说实话，我不相信。我认为我可能有点反对意见。我不认为人们会

需要始终只拥有流数据和流式处理中的所有内容。批处理系统在处理大量数据方面变得非常强大。流式处理系统非常擅长获取最新数据，对吧？我将给你一个数据库类比，我认为这可能会使这个更简单一些，对吧？例如，我们一直都有像 Postgres、MySQL 等事务数据库。

我们也有分析数据库，例如 Snowflake BigQuery，对吧？分析数据库非常有效地查看过去的历史数据。事务数据库非常擅长更改一行或更改一个数据点等等。在数据库社区中，我觉得曾经有一段时间人们觉得我们可以只用一个系统来完成所有工作。就像，他们有一个叫做 HTAB 的系统，嗯，

混合事务分析处理。因此，他们可以拥有一个可以同时执行两项工作的系统。他们可以执行事务处理以及分析处理。这些系统实际上确实出现了。然而，事实证明，这些系统是

他们可以在分析和事务处理方面做得平庸。另一方面，买家正在寻找针对分析工作负载的最佳解决方案。他们正在寻找针对事务工作负载的最佳解决方案。他们不满意在两方面都做得平庸的解决方案，对吧？因此，我觉得即使是流式处理，即使我们进入一个可以完全在流式处理中完成所有工作的世界，我也相当肯定，像

其中某些部分在性能和整体易用性方面将比批处理更平庸。因此，我认为我们可能会进入一个这样的世界，其中每个系统都将存在，并且它们在执行其最擅长的事情方面将变得更加强大。是的，只是依赖于他们的优势。没错，是的。还有什么我们没有谈到的你想谈谈的吗？嗯……

我认为我们看到的一件事，有趣的是，我认为我们可能会看到更多的是自带云。我的意思是，很多时候人们对供应商有负面感觉，因为许多供应商都希望所有数据处理都在他们的帐户中进行。许多客户都表示，您正在处理敏感数据，我不希望数据离开我的帐户。

通过 WarpStream 的收购，我们看到 Confluent 现在提供了 BYOC 解决方案或自带云，因此您的数据仍然可以保留在您的帐户中。Red Panda 正在做 BYOC，并且他们做得非常好。我们看到 Databricks 已经提供 BYOC 解决方案。Snowflake 从历史上看并没有这样做。他们一直处于这样的世界中，即所有内容都存在于 Snowflake 中，并给我所有数据，我将在我的帐户中存储和处理所有内容。

我认为流式处理解决方案以及批处理解决方案都可能会更多地转向 BYOC 解决方案。我认为这将使许多公司更容易接受供应商，并且比现在稍微少一些挑战。因此，BYOC 只是……

供应商去你所在的地方？是的，没错。就像，基本上，供应商将在您的云帐户中部署他们的堆栈，而不是要求您将您的数据移动到他们的云帐户中。是的，这是一个趋势。

这对我来说很有意义。是的，我认为从历史上看，供应商一直有点反对这一点，但我认为他们意识到重力就在数据所在的地方。移动他们的计算系统比将任何供应商的数据移动到任何其他人的帐户更容易。没错，将数据转移到其他地方非常困难，仅仅是因为数据的敏感性。是的，没错。是的。