Big data is dead, analytics is alive
50:21 Share

欢迎来到实用人工智能。如果您从事人工智能工作，渴望了解或好奇人工智能相关技术如何改变世界，那么这档节目适合您。

感谢我们飞IO合作伙伴的支持。飞IO提供飞变压器容器，可在三十多个地区、六个区域的硬件上运行，从而让您能够在用户附近启动应用程序。了解更多信息并了解原因。但是...

朋友们，你们...

知道我们非常喜欢飞IO。我在这里与飞IO联合创始人兼首席执行官Curt Mai在一起。我们已经有一些，我听说过你们说公共云很糟糕。您个人认为公共云为什么很糟糕？飞IO是如何避免这种糟糕情况的？

好的，公共云很糟糕，我实际上认为互联网上大多数托管方式都很糟糕。我对为什么会这样有很多想法，因为几乎无关紧要。现实情况是，我构建了一个新的应用程序，用于生成三明治食谱，因为我的家人，只是特定类型的三明治，使用棕色酱作为成分，例如。

然后我想把它放在某个地方。您访问AWS，这比从这里获得专用服务器更难。这就像弄清楚如何在AWS上部署我的dump anal jp应用程序实际上更复杂，因为它并非为我作为开发人员提高生产力而构建的。

它是为其他人构建的。它是为平台团队构建的，以便他们构建他们梦想的基础设施，并希望为他们合作的开发人员创造新的用户体验。同样，每次谈论这个问题时，我都感觉自己太心急了。

我特别不想去弄清楚这么多事情，仅仅是为了让我的三明治应用程序呈现在人们面前，我特别不想在应用程序成为大型iOS应用程序后不得不与平台团队交谈。我必须这样做，例如，进行部署。我感觉所有这些事情都应该在我无需请求许可、与其他人交谈的情况下为我工作。

因此，这与我们构建飞IO的方式有很多关联，我们仍然是一个公共实验室。我们仍然拥有与大型公司非常相似的底层原语。但总的来说，它们旨在直接由开发人员使用。

它们不是为平台团队拼凑而构建的。它们旨在快速为开发人员提供帮助。我们思考这个问题的一种方式是，如果您可以将一个非常困难的问题变成一个两小时的问题，人们将构建更多有趣类型的应用程序。

因此，这就是我们为什么做了诸如轻松在多个区域运行应用程序之类的事情的原因。在公共云上运行多区域应用程序并不容易，因为在没有大量前期工作的情况下做到这一点在功能上是不可能的，这就是我们为什么创建了虚拟机原语，使其仅通过一个简单的API即可使用的原因。大多数人不会像代码和标记或他们自己的虚拟化那样做，因为这并不容易。在云之上没有其他途径。

总的来说，我觉得，这对我来说并不公平，公共云很糟糕，因为我构建的应用程序是为不同的时代构建的。如果您从2007年开始构建这些东西，那么世界与现在非常不同。因此，我所说的很多内容是，公共云有点过时了，我们都应该构建在新的公共云版本之上。作为一名开发人员，我比五到六年前在某种程度上陷入困境时要快乐得多。

因此，它构建于不同的时代，不同的云时代，飞IO是一个公共云，是的，但它是一个为开发人员构建的公共云，他们的船只，这就是区别。我们在这里改变了开发人员的船只，所以你们应该相信我们，尝试飞IO，飞IO.io。

超过300万个应用程序，包括我们，已在飞IO上启动，包括全球负载均衡、零配置专用网络、硬件隔离和即时WireGuard VPN连接，以及一键式部署，可扩展到数千个实例。这是您想要的云。访问飞IO.io。

飞IO.io。

欢迎来到另一期实用人工智能播客。我是Daniel Whitenack。我是预测卫士的首席执行官，我们正在构建一个私有安全人工智能平台。

我像往常一样与我的合伙人Chris Benson一起，他是Loggery Martin的首席人工智能研究工程师。Chris，你做得怎么样？我做得很好，Daniel，一切进展顺利。我对这一期非常兴奋，因为，你知道，我们安排了很多节目，当然，它们都很有趣，但偶尔会有一个节目主题与我目前正在从事的工作或我发现真正令人兴奋且非常有用的东西相关。因此，我个人对本周与MotherDuck的Till和Adithya的访谈非常兴奋。

你做得怎么样？

很高兴能在这里。是的，在鸟类中提到DuckDB，所以编辑们，你们不必把我们屏蔽掉。当然，这对于你们来说是一个老笑话。我可以很容易地指出我如何偶然发现了DuckDB和MotherDuck。有一个博客文章，标题非常简单。它说大数据已死，当我看到标题时，我立刻想，谢天谢地，终于来了。

但我很好奇，你们是否可以稍微退后一步，不一定非要提到那篇博客文章中的观点，而是如何看待当前的数据分析、大数据和人工智能的交叉点？人们正在思考哪些担忧和问题，这促使他们转向DuckDB，当然，然后我们很明显地深入探讨DuckDB和MotherDuck以及你们正在做的一切，但首先，让我们了解一下人们在努力解决什么问题？他们过去对这种大数据炒作（无论正面还是负面）有什么认识？这如何改变人们对分析和数据库的看法？

我可以讲述一下我是如何与该团队取得联系的，这始于数据库项目的早期。我实际上是在做我的硕士论文，并且知道它起源于CWI，然后我毕业后，Honeywell的开发人员联系了我，我们进行了交谈，他们说他们正在进行一个新项目，他们正在开发一个数据库系统。

他们对可能加入或参与其中感兴趣。但我非常专注于机器学习以及类似的事情。所以我想要进入数据分析、数据科学等领域。

一年后，我在一家科技公司工作，我们使用Spark分析客户数据。有一天，发布了tgdb的早期版本之一。所以我安装了它，运行了第一个简单的聚合查询，可能是一个包含一百个数据点的数据集。

我感到惊讶，因为我认为出了问题。我认为这是不可能的。这只是聚合，对吧？因为从使用Spark的工作经验来看，我习惯了，好吧，现在至少要旋转十秒钟。

这真的让我大开眼界。我从许多人那里听到了类似的经历，甚至直到今天。他们都有类似的故事和经历。

是的。对我来说，事情以不同的方式开始。我首先意识到DuckDB的存在，您可以在浏览器中绘制分析引擎。想到这一点非常疯狂。

您可以在其上执行的操作开始看起来非常疯狂。当我第一次接触DuckDB时，我非常兴奋的一件事是能够进行地理空间分析。当时，当我第一次接触DuckDB时，我正在进行地理空间分析。然后，想到可以在浏览器中实际完成这项工作，这真是令人难以置信，这就是我的DuckDB之旅开始的地方。

所以，让我问一个后续问题，你们正在深入研究自己的热情，对于那些可能还没有熟悉它，并且听到数据库、大数据已死、在浏览器中执行这些操作的听众来说，请简要介绍一下你们所处的生态系统，以及这个想法是什么，以便人们可以跟随你们进入其中。是什么吸引了你们的热情和注意力，让你们说，哦，这就是方法，假设有人不熟悉它。

我想，我从机器学习方面进入这个领域，或者我习惯于使用Spark等工具构建数据管道，然后我遇到了这个数据库，它似乎以比我以前使用的数据集大小快得多的速度执行聚合。

这有点像幻想。我们可以在DuckDB中执行多少数据准备管道？这个想法一直伴随着我多年，我认为它仍然是一个令人兴奋的话题。

稍微深入探讨一下过去几年中大数据分析的方式。我注意到，您需要云中的服务器，您需要无法在本地访问的资源才能执行大型分析，但DuckDB打开了这种可能性，这在以前是不可能的。

在本地计算机上，例如在您的Mac上，利用该计算机执行此类大型分析。我想，这标志着Spark生态系统发生了变化，我想这就是我们所处的领域。

我非常认同这一点。所以，从数据科学家的角度来看，经历了多年，人们告诉您，嘿，您知道，使用Spark来完成这项工作。我在这类生态系统中的经历就像，我会尝试编写一个查询，它会得到正确的结果。

但问题是，我将永远等待结果。然后，我必须将其发送给某个名叫Ugly的人，他非常聪明，能够想出让它变快的办法。但我从未成为那个Ugly。所以，我非常认同这一点。

而且，这个概念是，嘿，那里有一些看似庞大的数据集，我想对它们执行一些复杂的分析类型的查询，甚至执行聚合或其他过程的工作流，正如您提到的那样，我可以在笔记本电脑上运行的系统中执行这些操作，或者在本地执行，这真的很吸引人。所以，也许现在是正式介绍DuckDB的好时机。

所以，在DuckDB方面，DuckDB是一个快速、本地化且轻量级的数据库。也许你们中有人可以尝试思考那些可能不相信我们刚才描述的可能性，或者生活在一个不可能实现这种可能性世界的数据科学家。描述一下DuckDB是什么，以及为什么它作为一种功能成为可能。

我想我可以谈谈DuckDB的动机，至少在我当时看来是这样。它实际上起源于R生态系统。是的，所以...我非常参与该生态系统。

人们使用R来处理相对较大的数据，使用相对原始的方法。当时，CWI有一个名为MonetDB的数据库系统和分析数据库系统，它包含了矢量化查询执行的概念。这是一个大型系统，对于普通用户来说并不容易采用。所以，第一个想法是，嘿，让我们构建一个MonetDB的轻量级版本，并将其与，我想是Delphi或类似的东西集成，然后我们让它在本地运行，但最终发现可能更容易从头开始构建一个数据库系统，它实际上设计用于本地运行，非常轻量级，非常易于安装，基本上是为了将这种矢量化查询执行能力带给数据分析师。

我想知道，当谈到本地化和轻量级时，对于那些不熟悉该术语的人，它意味着什么？它与其他非本地化数据库有何不同？它们有自己的进程，但它们如何运作？你能描述一下吗？

传统的数据库系统采用多层体系结构。通常，您有一个在某个地方运行的数据库服务器，以及一个与数据库服务器进行交互的客户端。然后，结果通过某种传输协议返回给客户端。

并且，正如Mark Rosman等人的论文所指出的那样，他们正在研究基准测试客户端协议，结果表明，这实际上是一个巨大的瓶颈。所以，即使您在本地机器上运行PostgreSQL，您仍然有客户端和协议的开销。解决这个问题的方法是让数据库实际运行在您的进程中，也就是说，在这种情况下，可能是R或Python，并且可以直接访问内存中的结果集，而无需进行任何传输。

也许我想补充一点，对于那些可能不熟悉编程的听众来说，在进程之间来回传递数据非常昂贵，并且与数据库服务器在不同的进程中进行交互，这需要大量资源来从您当前的进程移动到另一个进程，然后再返回。所以，这基本上将所有内容都放在一个沙盒中，您可以最大限度地提高效率。这是否是一个公平的评估？

是的。我认为这种模型的另一个优点是您可以共享进程之间的内存。为了稍微深入探讨一下技术方面，Till刚才解释的瓶颈更多的是数据传输瓶颈。

但是，在这种情况下，当它在进程中运行时，您可以共享相同的内存。您可以共享在例如，一个批处理中计算的值，然后在您的数据中访问该值。这同样适用于其他示例。

这对于开发人员来说非常强大，开发人员体验也非常好。我想，除了数据库本身非常快之外，使用DuckDB的开发人员体验非常棒，这在某种程度上也促进了它的成功。但是...

好的，朋友们，我在这里与我们新朋友Athar一起，他是Timescale的。所以，Athar，你能解释一下Timescale到底是什么吗？

Timescale是一个PostgreSQL公司。我们构建了云工具，开放源代码系统，使开发人员能够在PostgreSQL中做更多的事情。因此，它用于诸如时间序列、分析和最近的AI应用程序，例如Crag和Surge。

如果我们的听众想开始使用PostgreSQL、Timescale和AI应用程序开发，您会告诉他们什么？

如果您想开始构建AI应用程序或对该领域正在进行的创新感兴趣并想参与其中，那么您应该做什么？好消息是，任何开发人员都可以使用他们已经了解和喜爱的工具成为AI工程师。

因此，我们在Timescale中与PostgreSQL AI项目所做的工作是让开发人员能够使用他们已经了解的工具和数据库构建AI应用程序。这意味着您可以提升职业生涯，承担新的、有趣项目。

您可以添加更多技能，而无需学习一整套新技术。最棒的是，所有这些都是开源的，例如PostgreSQL AI、PostgreSQL向量缩放，我们的开源项目。您可以使用DuckDB在本地机器上运行这些项目。遵循其中一个教程，例如Crag的教程。这些是像Crag和Surge这样的尖端应用程序，而无需学习十种不同的新技术。只需使用您可能已经了解的PostgreSQL和SQL语言即可。是的，这就是PostgreSQL AI项目，您可以访问Timescale网站，找到PostgreSQL AI或PostgreSQL向量缩放，并遵循其中一个教程来开始成为AI工程师。

好的，只需使用PostgreSQL即可开始AI开发，构建向量搜索，所有这些都是开源的，访问Timescale.com，尝试AI，使用PostgreSQL向量缩放，所有这些都在您的桌面计算机上，都是开源的，再次访问Timescale.com，尝试AI。

所以，你刚才描述的是开发人员体验，嗯，我绝对会说这是一种神奇的体验，你用 DuckDB 提醒了我们。也许为了让大家了解，当我最初探索类似于你们谈论的体验时，我会鼓励我们的听众去安装 DuckDB，在本地尝试一下，因为它真的很有趣，特别是对于那些过去使用过传统数据库系统的人来说，突然之间……所以，你安装了 RTB，在本地安装它很重要，作为一个库。

然后你可以查询，你知道，指向 CSV 文件或 JSON 文件或 parquet 文件，甚至指向一个 PostgreSQL 数据库或其他数据源，并且你拥有这种一致的、等同于接口。它很熟悉，你可以对这些数据进行查询。所以，也许你们中有人能描述一下 WTV 的一些用例，也许一方面是它作为主要用例或最常发生的用例，人们使用 DuckDB 并使用它，然后也许在另一方面，帮助人们理解它在哪里不那么相关。嗯，如果你有任何想法。

我可以简要概述一下。DuckDB 的最大用户来自大型生态系统，这意味着它正在成为数据标准。例如，使用 TPC，它在聚合方面非常快。

对于 Python 生态系统，它有助于用作与其他机器学习库一起使用的 DataFrame。对吧？所以这就是生态系统的一部分。

生态系统的另一部分是让数据工程师能够从不同的数据源中提取数据，就像你说的那样，从 PostgreSQL、CSV 中提取，并能够连接这些不同的数据集。连接在 DuckDB 中也很出色。

以及创建转换后的数据集也很有用。对于数据分析师来说，在编写 SQL 查询时，DuckDB 的一个非常好的方面是其单一方言本身，它有很多 DuckDB 函数，可以轻松进行数据清理和数据转换。例如，我们还有一个方言，它说从表中，这将只显示该表。

在执行 select * from table 时，你可以执行 from table，这将从该表中获取数据。所以，DuckDB 的方言有很多功能，这使得它非常强大。

我还查看了 DuckDB 的网站等内容。我知道它在所有主要平台和架构上运行，并且支持多种语言。我很好奇，因为我有一个问题，出于我自己的兴趣，自私地说，你们是否支持某种嵌入式环境，以及在边缘设备上运行，诸如此类的东西？你们在哪里发现它嵌入在操作系统中，或者它不一定是云服务器上的主要平台之一？这是否是一个典型的用例？

这是 DuckDB 的一个很好的用例。由于 DuckDB 具有运行 DuckDB 的轻量级协议，它可以在任何地方运行，无论是在笔记本电脑上还是在任何地方。

所以，他们还优化了它在不同架构上的运行。所以这使得它可以在任何地方运行，并且可以进一步扩展，你也可以在浏览器中运行它。所以，在任何边缘环境中，你都可以运行它，当然，对于当前的大多数边缘环境，有很多优化。并非所有边缘环境都经过优化以进行交互式使用，但我猜它也正在朝着在所有边缘环境中运行的方向发展。

我们的投资者可能很好奇，为什么像我这样的人在 AI 世界中每天都在关注数据。

我的意思是，我当然在更广泛的数据科学领域有经验，并且随着时间的推移，我一直在感受到这种痛苦。但也有一个非常相关的部分与 AI 社区更广泛的需求以及他们的工作流程相交。

其中一个，你知道，我开始关注的是人们正在尝试构建的那些仪表板式 AI 应用，从某种意义上说，像我这样的数据科学家在生活中遇到的另一个痛苦是构建仪表板，因为你总是构建它们，你知道，它们永远不会回答人们真正想要的问题。所以，人们真正想要的是像自然语言问题输入，然后你可以非常快速地计算出该自然语言问题的答案，通过使用 AI 来生成 SQL 查询，以连接到多个数据源。

但是，当你开始思考，哦，现在人们上传了这些 CSV 文件到聊天界面，或者我需要连接到这些类型的数据库，或者数据存储在三个桶中，我的答案可能来自这些不同的位置。突然之间，你谈到的这种丰富的、等同于方言，这种非常快速且可以在不同数据源上运行的标准 API，对我来说变得非常有趣。我一直在思考所有这些数据源，我可以使用 AI 来回答问题，但是如何建立一个快速且标准化的接口来访问所有这些不同类型的数据集，并且以开发人员的角度来看，使用起来也很容易？但我当然知道你比我看到的要多得多，也许这可能是一个你看到的切入点。我想知道你是否可以更广泛地谈谈 DuckDB 解决的问题，以及你的客户正在关注的问题，以及它们如何与快速发展的 AI 工作流程相交互。

我的意思是，描述 DuckDB 的一种方法是它是一个分析的秘密武器。所以，嗯，这基本上是一种非常简单、非常开发人员友好的方式来实现你刚才描述的内容。如果我想为我的新文本生成模型创建演示，如果我使用 DuckDB，我甚至可以创建一个完全基于 DuckDB 的演示。

例如，我不会遇到 CSV 上传问题。可能会有数据库问题。我们必须指定用户更新的限制。

所以，我必须向我的用户显示一个对话框，说，哦，它是逗号分隔的，它有一个头等等，使用 DuckDB 就很方便。所以，嗯，它消除了你可能在使用其他数据库时遇到的某些问题。并且，正如你所说，它与不同的存储格式集成，例如，它可以读取来自 S3 的数据，它可以读取来自 HDFS 的数据。

当我看到一个有趣的 huggingface 或 getup 文件时，我只是运行 retrive CSV from this URL。然后，我的数据就在我的本地计算机上，在我的 Python 环境中。此外，当我有一个 Python 环境时，我启动一个 colab 笔记本，对吧？我创建了一些 DataFrame，然后使用 DuckDB，我可以直接读取这些 DataFrame。

我见过一些非常酷的演示，人们基本上使用 DuckDB 来分析 Pandas DataFrame 中的数据，嗯，在幕后，DuckDB 就在那里，基本上直接从这些 Pandas DataFrame 中读取数据，顺便说一句，这是共享内存的进程内功能的另一个好处。它不仅用于获取结果，还用于直接从进程中读取数据。所以，在这种情况下，从 Pandas 中读取数据非常令人兴奋。我很乐意详细讨论文本生成模型。我们在 MotherDuck 有一个关于它的项目，但是……

是的，是的，也许在我们深入探讨这些故事之前，我认为它的一方面是将分析部分集成到 AI 工作流程中。但是，如果我没记错的话，DuckDB 也有一些向量搜索功能，我想你们中有人可以谈谈。

是的，这也是 DuckDB 的一个令人兴奋的方面。所以，如果我退后一步，思考其他生态系统，例如，PostgreSQL 在很多方面都非常出色，PostgreSQL 已经扩展到你可以做的事情，因为它有一种很棒的扩展机制，你可以添加扩展和功能。

同样，DuckDB 也有扩展机制，你可以访问 DuckDB 的内部工作原理，并在 DuckDB 的基础上添加更多工作流程，对吧？DuckDB 具有向量搜索功能，例如，它还具有混合搜索，其中你也可以将全文搜索和向量搜索结合起来以创建混合搜索。DuckDB 的一种方法是它有一个非常棒的数据类型。

嗯，我可以深入探讨其内部工作原理，这也很令人兴奋。但其中一件事情是，它提供了一种数据类型，你可以拥有一个浮点数的数组，然后你可以将其存储为数据类型。然后，它最终成为一个你可以进行余弦相似度计算的嵌入向量。

所以，这可以进行嵌入式搜索。你还可以进行全文搜索，在你的文档中创建关键字的反向索引，并根据关键字搜索文档，并根据分数对它们进行排序。然后，你可以将来自嵌入搜索和全文搜索的两个分数结合起来，以进行混合搜索。所以，所有这些都是可能的，并且非常易于访问。

当然有很多有用的 AI 工具，但是使用这些工具意味着你必须在更多工具之间来回切换。所以，这只会让你的工作流程变得更复杂，而不是更简单。但 Notion 并非如此。

Notion 是组织各种内容的理想场所，例如任务、跟踪习惯、编写漂亮的文档、与团队协作以及知识库。你向 Notion 添加的内容越多，Notion AI 就越能理解你的工作，并为你提供个性化的回复。例如，聊天框中的 Notion AI 了解你的工作上下文。

此外，它还拥有多个知识来源。它使用来自 GPT-4 和 Claude 的信息，这可以帮助你讨论任何主题。而且，现在处于测试阶段，Notion AI 可以搜索 Slack 讨论、Google 文档、表格、幻灯片，甚至更多工具，例如 getup 和 Jira。这些功能即将推出。

与需要在不同应用程序之间切换的专用工具或遗留工具不同，Notion 具有无缝的、集成的、灵活的和易于使用的功能，因此你可以专注于完成最重要的工作。从小型团队到大型财富 500 强公司，这些团队（无论是小型还是大型）都使用 Notion 来减少电子邮件、取消更多会议、节省时间来查找工作，并减少工具支出，这有助于每个人保持一致。

今天免费试用 Notion，访问 notion.com/practicalAI，这就是 notion.com/practicalAI，今天就体验强大的、易于使用的 AI。当然，当你使用我们的链接时，你也在支持我们的节目。我知道你很乐意再次这样做。notion.com/practicalAI。

所以，嗯，蒂尔，你开始涉足 MotherDuck 在 DuckDB 之上所做的一些事情，嗯，我希望我们能深入探讨这些用例，这些是你与客户或内部团队合作完成的事情。但是，在我们这样做之前，嗯，我知道，我也看到了关于 DuckDB 效率的故事，但它具有这种多用户方面，作为你在 DuckDB 上所做工作的一部分。所以，也许你们中有人可以描述一下，现在我认为我们已经了解了 DuckDB，它是一个免费的、开放的工具，我可以下载、安装和快速运行它，在我的笔记本电脑上运行，在我的浏览器中运行，执行这些分析查询。所以，现在，也许可以描述一下你们如何通过 MotherDuck 将其进一步发展，以及你们如何思考一些企业用例。

我想描述 MotherDuck 作为 DuckDB 的云伴侣。所以，嗯，很容易想到或联系到，嗯，我们将 MotherDuck 带到云端，这是我们描述自己的方式之一，与 DuckDB 联系起来。我们提供无限的云扩展。

你给我们一个工作负载，我们会在后台启动数百个 DuckDB 实例，以一种类似于 DuckDB 的方式，嗯，处理你的数据。但是，嗯，MotherDuck 的一个假设，我们的公司正是基于这个假设，即单节点计算，这意味着一个 DuckDB 数据库，现在，硬件云硬件实际上可以让你走得很远。所以，当你的本地计算机资源达到限制时，你将拥有云实例，最多可拥有 24 个 TB 的内存，这对于大数据来说相当大。所以，这是一个方面，对吧？

所以，通过一个 DuckDB 实例进行扩展，以及另一个方面是协作。所以，一旦你连接到一个云实例，你就可以与组织中的其他用户共享上下文。你可以创建共享数据集，你可以共享笔记本等等。当然，随之而来的是所有企业级功能，一些企业客户需要适应这些功能。

我很好奇，你真的让我对这个描述印象深刻，所以，例如，通过绘制一些人们以前使用 PostgreSQL 做的事情，你谈到了拥有许多并发运行的 DuckDB 实例。

你知道，从用户的角度来看，以一种实际的方式来理解它，你看到人们通过这种架构解决了哪些问题，以及他们可能在过去几年中在其他平台上的先前数据库功能中没有拥有的新功能？他们现在可以通过这种方式解决哪些新的问题？

我的观点是，很多公司想要将分析工作负载迁移到云端，但选择相对有限。其中一些选择是 Snowflake 或 Databricks，当然，这些系统经过优化以支持大数据规模。但是，观察结果是，很多公司实际上没有那么多数据，当他们运行查询时，或者他们可能拥有大量数据，但他们运行的查询只访问数据的一个很小的子集。例如，你知道，你运行每月报告，它们不会接触到你的所有历史数据，所以这些公司可能想要一些更简单、更易于使用、更易于设置的东西，并且比其他现有解决方案更具消费者友好性。

我们还没有谈到的一件事是，MotherDuck 和 DuckDB 如何与本地和远程方面协同工作，你可以在本地和远程运行相同的客户端，以便你实际上可以做同样的事情。所以，很容易从一个地方切换到另一个地方，做同样的事情。

MotherDuck 还提供双重执行，其中你的本地 DuckDB（如果你在本地运行它）可以与远程 MotherDuck 通信，并在两者之间无缝执行。例如，假设你有一个表在你的本地 DuckDB 中，你想将其与远程 DuckDB 表连接起来以运行查询。然后，我们运行了一种优化，我们传输从远程或本地到远程所需的数据，并以一种智能的方式执行它，我可以这么说。这在本地和远程运行相同客户端的双重执行方面开辟了新的可能性。

我很好奇，你正在做这件事，你有一个本地版本和一个远程版本，两者之间的连接看起来是什么样的？如果它们相隔很远，如果 MotherDuck 在云端，而我使用的是非云设备，那么你们如何处理这些不同类型的用例，你们是如何处理高效通信的？

嗯，双重执行的两个原则之一是尽可能减少需要传输的数据量。例如，一个用例是，我有一个非常大的数据集在云端，我想将其与我笔记本电脑上一个小数据集连接起来。

那么，在这种情况下，当我们决定，与其将一个恐怖的数据集下载到本地设备并进行联合处理，不如将你的小型本地数据集上传到云端工作器并进行处理，这样一来，带宽需求就会减少很多，同样，如果你知道，对大型数据集进行过滤推送，那么传输只需要发生一次。并且，如果你使用的是分区数据，你也可以使用 DuckDB 获得类似的效果。因此，DuckDB 有许多巧妙的方法来优化远程文件访问。当然，没有 MotherDuck，但使用 MotherDuck 的好处是，它甚至可以处理数据。如果你的数据没有分区，云端工作器仍然会处理所有工作，并只返回你实际需要的结果。

我们谈论的很多都是 DuckDB 的功能。然后，MotherDuck 所做的就是在此基础上添加功能，以及这些功能与 AI 工作流（例如文本到 SQL、向量搜索和混合搜索）的交叉点。所有这些都与构建 AI 工作负载的人非常相关。

但我发现有趣的是，我看到你写了一篇博客文章，我正在阅读，这表明你也在思考如何将 AI 智能地应用于你自己的产品中，以及如何让你的产品用户（可能是技术用户）能够构建自己的工作流，同时将 AI 集成到某些功能中。我正在查看这个 FixIt 功能。所以我想问一下，你能不能谈谈它是如何同时支持 AI 开发人员，又如何将这项技术整合到产品中的？至少，我的理解是这样的。

是的，DuckDB 的一个主要吸引力在于它的简洁性，这吸引了很多用户。我认为这种简洁性可以扩展到一定程度的 AI 使用，尤其是在数据分析、数据管理等方面。这涉及到多个方面，一方面是用户体验。

那么，我们如何才能让编写 SQL 查询更容易？我认为答案不仅仅是 SQL 查询优化。FixIt 就是其中一部分。我们开发 FixIt 的主要目标是使其尽可能不显眼，不会打断你编写 SQL 查询的流程。

为什么在触发时仍然需要帮助？我认为，例如 Kasa，是将 AI 集成到数据科学或软件开发人员工作流的绝佳示例。而在我们的案例中，我们需要更多地考虑数据工程师和数据科学家。我认为，对于这类事情来说，这是一个非常令人兴奋的时代。

我认为 MotherDuck 是从事这类工作的一个特别有趣的地方，因为我们拥有的独特优势之一是，我们有一个实际的数据库在用户的浏览器中运行，如果有人使用我们的网页，那么该用户实际上是在浏览器中运行 DuckDB，这可以进行实时绑定。这让我们能够获得有关当前查询状态的许多信息，这使得我们能够编写更安全的 SQL 查询助手。

因此，在我们结束时，你真的让我思考了一些我之前没有想到的用例，以及我可能能够做的事情。嗯，就像一个好奇的孩子一样，我必须问你，我希望你们每个人都能谈谈。今天你谈到的可能性，对我们来说非常酷。

你们是如何思考未来的？你们脑海中有哪些新的酷东西？我经常说，当你真正努力解决问题时，你可能会在一天结束时放松一下，你的思维会自由地漫游，你会想，如果我们能做到这一点该多好？

我可以想象，我们可以看到通往那里的道路。你们是如何思考 MotherDuck 和 DuckDB 的未来，如果你们想畅所欲言的话？这并不一定需要基于当前的工作，而是更多地基于想象力和抱负。

我喜欢的 AI 当前状态之一是本地模型（小型模型，可以在本地运行）的出色表现，以及围绕它的出色生态系统。在此之上，我看到本地模型的一个好处是，我们可以使用实际的 RQ 机制来为这些本地模型提供上下文。

这些本地模型也可以在边缘运行，例如本地笔记本电脑或边缘设备。知识库基本上是为了防止这些类型的故障而创建的。

创建知识库的一个浪费方面是每个人都在创建非常单一的知识库，对吧？如果有一种机制可以共享这些知识库该多好？用户可以创建知识库，并可以共享知识库。我脑海中一个有趣的词是，MotherDuck 如何能够做到这一点，即共享知识库，这样你基本上可以在远程表中拥有一个远程知识库，然后在本地 DuckDB 客户端中提取你想要的知识空间。

使用本地知识库，你的本地模型可以获得当前问题的相关上下文，然后当你不需要知识库时，你也可以删除知识库，这就像拥有一个远程知识库，可以提取你想要的内容。这只是我的一些想法。想想 MotherDuck 和 DuckDB 如何能够对这些有所帮助。

关于知识库和 RAG 应用的另一个方面是，并非所有应用和工作流都需要实时数据库来构建代理。其中一些代理可以作为后台代理，每天运行一次工作流。与其为此使用实时数据库，不如提供一个非常轻量级的逻辑引擎，可以在本地运行，并且成本很低。这也可以将一些工作卸载到远程云端。这让我在晚上思考这些类型的用例时感到兴奋。

嗯，也许我可以补充两点。其中一点是将 AI 和机器学习功能更多地集成到数据库中。我们看到的一个趋势是，与两年前相比，语言模型的推理成本下降了很多。

我认为，现在使用 GPT-4 进行推理的成本仅为 GPT-3 的 2%。这使得在你的表上运行语言模型推理成为可能，以及在你的表上进行计算。SQL 只是为此提供了一个非常方便的用户界面。

因此，我们有时会将此功能与向量搜索结合使用，这样你就可以根据提示进行基于向量搜索的查询。因此，你可以在数据库中使用语言模型进行数据推理，并结合本地模型，使用混合执行模型，例如，在本地完成一部分工作，或者使用本地 GPU 完成一部分推理。

如果你想更快地完成，可以在云端完成。

非常感谢你们抽出时间，讨论你们的分析、AI 和数据库工作。这非常棒。我强烈建议大家尝试一些东西，尝试一些示例，查看 MotherDuck 网站以及他们的一些很棒的博客文章，看看他们的示例或正在做的事情，因为这绝对是你可以添加到你的 AI 堆栈中并进行实验的非常棒的东西。非常感谢 Till 和 Adithya 的参与。

很高兴能参与。

感谢各位，很高兴能在这里。

好了，本周的 Practical AI Deep Dive 就到此结束。如果你还没有加入，请加入我们的免费 Slack 团队，在那里你可以与 Chris 和整个 Changelog 社区互动。今天就访问 practicalaidfm/community。

再次感谢我们的合作伙伴 Fly.io，以及各位听众。感谢你们抽出时间与我们一起。本次节目到此结束。下次再见。