Daft 以 “工具适应数据” 为设计理念，原生支持多模态数据处理，具备无缝扩展、深度优化 AI 工作流等优势，正试图解决多模态数据处理的核心难题。本文将深入探讨 Eventual 的解决方案、技术创新及背后的行业意义，解析多模态数据处理领域的现状与未来。

你有没有想过，为什么那些最聪明的AI工程师要把80%的时间浪费在修复数据基础设施上，而不是构建真正改变世界的AI应用？这个看似不合理的现象，正是Eventual创始人Sammy Sidhu和Jay Chia在Lyft自动驾驶部门工作时亲身经历的痛苦。自动驾驶汽车每天产生海量的多模态数据——3D扫描、照片、文本、音频，但没有任何一个工具能够同时理解和处理所有这些不同类型的数据。工程师们只能将各种开源工具拼凑在一起，这个过程既漫长又不可靠。更让人沮丧的是，这些拥有博士学位的顶尖人才，本应专注于构建核心应用，却被迫将大部分精力投入到基础设施的维护上。

这种现象并非Lyft独有。随着生成式AI的爆发，每一家构建AI应用的公司都需要处理大量的文本、图像、文档和视频数据，但他们使用的工具却仍然是为处理网页点击和银行交易而设计的传统系统。这种错配不仅效率低下，更是在系统性地阻碍整个行业的创新步伐。正是这种深刻的痛点体验，促使Sidhu和Chia决定构建一个全新的解决方案，这就是现在获得3000万美元融资的Eventual。

多模态数据处理的痛点有多深

在深入了解Eventual的解决方案之前，我想先帮大家理解现有数据处理工具在面对多模态AI工作负载时的根本性局限。传统的数据处理引擎，比如Apache Spark，最初是为处理结构化数据而设计的——想想银行交易记录、用户点击流这类规整的表格数据。这些系统在处理数字和文本时表现出色，但当你让它们处理图像、视频或者LiDAR扫描数据时，就像是让一台为城市道路设计的小汽车去爬珠穆朗玛峰一样不现实。

我在与一些AI公司的工程师交流时发现，他们经常遇到这样的困境：为了让Spark处理图像数据，他们不得不写大量的适配代码，将图像转换成Spark能理解的格式，然后再转换回来。这个过程不仅繁琐，还极其脆肪。在测试环境中0.1%的失败率可能是可以接受的，但当你要在生产环境中处理数百万个文件时，这个失败率就变成了灾难。更糟糕的是，现代AI工作负载还需要运行自定义模型、调用外部API，以及处理各种各样的数据类型，这些需求远远超出了传统数据处理引擎的设计范围。

Sidhu在接受采访时提到了一个令人深思的观察：”我们看到所有这些优秀的博士、业界的杰出人才在开发自动驾驶汽车，但他们花费大约80%的时间在处理基础设施问题，而不是构建他们的核心应用。”这种资源错配的程度是惊人的。想象一下，如果一家制药公司的顶级科学家需要花80%的时间来维修实验室设备，而只有20%的时间用于药物研发，这将对整个行业的创新速度产生多大的影响。

这个问题在ChatGPT发布后变得更加严重。随着生成式AI的普及，越来越多的公司开始在他们的应用中使用图像、文档和视频。但他们很快发现，现有的数据基础设施完全无法应对这种多模态数据的处理需求。Sidhu观察到：”ChatGPT的爆发让我们看到很多其他人开始构建具有不同模态的AI应用。然后每个人都开始在他们的应用中使用图像、文档和视频等内容。这正是我们看到使用量急剧增长的地方。”

Eventual的革命性解决方案

Eventual的核心创新在于他们从零开始构建了一个专门为多模态AI工作负载设计的数据处理引擎——Daft。这不是对现有工具的改进或适配，而是一个全新的架构，将多模态数据的固有复杂性视为特性而不是缺陷。在我看来，这种设计理念的转变是革命性的：不再试图将复杂的多模态数据强行塞入为简单表格设计的框架中，而是构建一个原生理解和处理各种数据类型的系统。

Daft的强大之处在于它是Python原生的开源数据处理引擎，专门设计用于快速处理从文本到音频和视频等不同模态的数据。Sidhu说他们的目标是让Daft对非结构化数据基础设施产生与SQL对表格数据集产生的同样变革性影响。这个对比很有启发性：SQL的出现让任何人都能够查询和分析结构化数据，而不需要深入了解底层的数据库架构。Daft希望为多模态数据带来同样的简便性和强大功能。我深刻理解这种愿景的重要性，因为当前处理多模态数据就像是在没有SQL的时代直接操作文件系统一样痛苦。每种数据类型都需要专门的处理逻辑，每个项目都要重新发明轮子，这种重复劳动不仅浪费时间，还容易出错。

从技术实现角度看，Daft使用Rust构建，这确保了在单节点上与DuckDB和Polars相当的性能，同时可以轻松扩展到分布式集群，无需更改任何代码。这种设计让开发者可以在笔记本电脑上开发和测试代码，然后直接部署到生产环境的大规模集群上。我认为这种无缝扩展能力对于AI工作负载特别重要，因为数据量通常从开发阶段的几MB增长到生产环境的PB级别。这种扩展能力的实现原理很巧妙：Daft将计算逻辑抽象成任务图，可以在单机上顺序执行，也可以在集群上并行执行，而开发者只需要改变一行配置代码。这消除了传统分布式系统开发中最痛苦的部分——在本地开发和集群部署之间的巨大鸿沟。

更让我印象深刻的是Daft对AI工作流的深度优化。它不仅支持传统的分析操作如分组、连接和聚合，还允许开发者编写任意的Python代码作为用户定义函数（UDF）。这意味着你可以在同一个数据处理流水线中进行数据清洗、特征提取、模型推理和结果分析，而不需要在多个工具之间切换。这种一体化的设计解决了一个长期困扰AI工程师的问题：工具链的碎片化。传统上，你可能需要用pandas做数据清洗，用Spark做大规模处理，用Ray做分布式训练，用不同的工具做模型部署。每个工具之间的数据传递都是一个潜在的故障点，而且维护这样的工具链需要大量的运维工作。

Daft的UDF系统特别值得深入讨论。它不仅支持普通的Python函数，还专门为AI工作负载设计了异步UDF。在他们的演示案例中，通过使用异步UDF，GPU推理的吞吐量提高了5-6倍。这种性能提升的原理在于，传统的同步推理会导致GPU在等待I/O操作时空闲，而异步UDF可以在一个请求等待时处理其他请求，从而充分利用GPU的计算能力。这种优化对于大规模AI推理至关重要，因为GPU的成本很高，任何空闲时间都意味着资源浪费。更重要的是，Daft计划进一步优化这个过程，包括支持流式UDF，让结果可以在生成时立即返回，而不是等待整个批次完成。

在他们的演示中，工程师能够在两天内构建一个AI招聘平台，处理了15000个GitHub仓库、3300万次提交，并对25万名开发者进行了AI代码审查——这种速度在传统工具下是不可想象的。让我们深入分析这个案例的技术细节：他们首先使用GitHub API收集了15000个热门仓库，然后克隆所有仓库并解析git日志提取提交信息。这个过程在传统工具下可能需要数周时间，因为你需要处理API限制、存储管理、错误恢复等复杂问题。但使用Daft，他们只需要将API调用包装成UDF，系统自动处理并发、重试和结果存储。接下来的数据清洗和聚合步骤，包括按开发者分组提交记录和去重处理，在Daft中只需要几行代码，而在传统工具中可能需要复杂的MapReduce作业。最令人印象深刻的是AI代码审查阶段：他们使用大语言模型对25万名开发者进行评估，整个过程只用了3小时。这种效率的实现依赖于Daft的异步UDF支持和智能批处理策略。

Eventual的商业化策略也很明智。他们首先构建了强大的开源核心Daft，已经在Amazon、CloudKitchens和Together AI等公司的关键任务工作负载中处理PB级别的多模态数据。现在他们正在基于这个开源引擎构建Eventual Cloud——第一个从头开始为多模态AI工作负载构建的生产就绪平台。通过这种方式，他们既建立了强大的技术护城河，又培养了活跃的开源社区，为商业化产品奠定了坚实基础。这种开源+云服务的策略很聪明，因为它让用户可以先通过开源版本体验Daft的强大功能，然后自然地升级到提供更多企业级功能的云服务。这种策略在数据基础设施领域特别有效，因为企业在选择关键基础设施时非常谨慎，他们需要先验证技术的可靠性和性能。

为什么现在是多模态数据处理的关键时刻

我认为Eventual获得投资者青睐的原因，不仅在于他们解决了一个真实存在的技术痛点，更在于他们抓住了一个巨大的市场时机。据管理咨询公司MarketsandMarkets预测，多模态AI行业在2023年到2028年间将以35%的复合年增长率增长。这个增长速度反映了企业对多模态AI应用的迫切需求，也意味着对专门处理多模态数据的基础设施的巨大需求。

数据量的爆炸性增长为这种需求提供了更深层的支撑。Felicis的普通合伙人Astasia Myers指出：”年度数据生成量在过去20年中增长了1000倍，世界上90%的数据是在过去两年中生成的，根据IDC的数据，绝大多数数据都是非结构化的。”这些数字让人震撼，但更重要的是其背后的含义：我们正处在一个数据性质发生根本性转变的时代。过去的数据主要是数字和文本，现在越来越多的是图像、视频、音频和传感器数据。

这种转变对现有数据基础设施提出了前所未有的挑战。传统工具不仅在技术上难以应对，在成本上也变得不可持续。想象一下，如果你需要处理数百万小时的视频内容来训练一个计算机视觉模型，使用为处理银行交易设计的系统会有多么低效。你不仅需要大量的适配工作，还会面临极高的计算和存储成本，更不用说系统的可靠性问题了。

从投资者角度看，Myers表示她通过市场映射发现了Eventual，当时她正在寻找能够支持日益增长的多模态AI模型的数据基础设施。Eventual之所以脱颖而出，不仅因为他们是这个领域的先行者，更因为创始人亲身经历过这个数据处理问题。这种第一手经验确保了他们构建的解决方案真正解决了实际问题，而不是象牙塔中的理论构想。

我特别认同Myers关于宏观趋势的观察：”Daft适应了围绕文本、图像、视频和语音构建生成式AI的巨大宏观趋势。你需要一个多模态原生的数据处理引擎。”这句话点出了关键：不是改造现有工具来适应新需求，而是构建原生支持新需求的工具。这种思维转变对于技术基础设施的发展至关重要。

技术创新背后的深层思考

在研究Eventual的技术架构时，我发现他们的创新不仅体现在功能层面，更重要的是在设计哲学上的突破。传统数据处理系统遵循的是”数据适应工具”的逻辑——你需要将数据转换成工具能够处理的格式。而Daft则实现了”工具适应数据”的逻辑——系统原生理解各种数据类型，不需要强制转换。这种哲学转变的意义远比表面看起来更深刻。

这种差异的影响是深远的。在传统系统中，每当你需要处理新类型的数据时，都需要编写大量的预处理和后处理代码。这不仅增加了开发复杂性，还引入了潜在的错误源。更严重的是，这种方法本质上是在为每种数据类型重新发明轮子。而在Daft的架构中，系统从底层就被设计为多模态原生，新数据类型的支持变成了配置问题而不是开发问题。我认为这种设计哲学的转变类似于从面向过程编程到面向对象编程的跨越，它从根本上改变了我们思考和解决问题的方式。

从性能角度看，这种设计带来的优势更加明显。传统系统在处理多模态数据时会有大量的序列化和反序列化开销，而Daft通过原生支持避免了这些不必要的转换。在他们的演示案例中，处理15000个仓库和3300万次提交只用了30分钟，这种性能提升不仅来自于分布式架构，更来自于对多模态数据的原生优化。这种性能差异在大规模生产环境中会被放大数倍，意味着企业可以用更少的资源完成更多的工作，或者在相同时间内处理更大规模的数据。

我特别欣赏Daft对异步处理的支持。在演示中，工程师通过使用异步UDF将GPU推理的吞吐量提高了5-6倍。这种优化对于AI工作负载至关重要，因为模型推理通常是整个流水线的瓶颈。通过原生支持异步操作，Daft让开发者能够充分利用现代硬件的并行处理能力，而不需要自己管理复杂的并发逻辑。这种设计的巧妙之处在于，它将复杂的异步编程模式抽象成简单的API，让数据科学家和AI工程师可以专注于业务逻辑，而不需要成为分布式系统专家。

让我深入分析一下刚才提到的AI招聘平台案例中的技术细节，因为它完美展示了Daft的技术优势。整个项目在两天内完成，处理流程包括数据收集、清洗、AI推理和结果展示四个阶段。在数据收集阶段，他们首先通过GitHub API搜索热门仓库，这本身就是一个挑战，因为API有严格的速率限制。传统方法可能需要编写复杂的重试机制和队列系统，但在Daft中，他们只需要将API调用包装成UDF，系统自动处理并发控制和错误恢复。当遇到API限制时，他们巧妙地转向直接克隆仓库并解析git日志，这种灵活性在传统数据处理框架中很难实现，因为你需要在不同的工具之间切换。

数据清洗阶段揭示了另一个有趣的技术问题：开发者可能使用多个邮箱地址提交代码，导致同一个人被识别为多个不同的贡献者。这是一个典型的实体解析问题，在传统工具中可能需要复杂的MapReduce作业或者专门的数据清洗工具。但在Daft中，他们通过简单的分组和聚合操作就解决了这个问题。这种简洁性不仅提高了开发效率，还降低了出错的可能性。更重要的是，这种处理方式展示了Daft在数据质量管理方面的优势——它让数据清洗变成了数据分析的自然延续，而不是一个单独的流程。

AI推理阶段是最能体现Daft技术优势的部分。他们需要对25万名开发者进行代码审查，这需要调用大语言模型数十万次。传统方法可能需要搭建复杂的任务队列系统，处理失败重试、负载均衡、成本控制等问题。但使用Daft的异步UDF，他们只需要将LLM调用包装成一个函数，系统自动处理并发控制和资源优化。更巧妙的是，他们使用Pydantic模型来标准化LLM的输出格式，确保结果可以直接集成到Daft的数据框架中。这种设计展示了Daft在AI工作流集成方面的深度思考——它不仅是一个数据处理引擎，更是一个AI应用的构建平台。

性能优化方面，异步UDF的5-6倍性能提升特别值得深入分析。这种提升的原理在于充分利用了GPU和网络I/O的并行性。在同步模式下，每个推理请求都需要等待前一个请求完成，导致GPU在等待网络I/O时空闲。而异步模式允许系统在一个请求等待时处理其他请求，从而保持GPU的高利用率。这种优化在大规模AI推理中价值巨大，因为GPU是最昂贵的资源，提高利用率直接转化为成本节约。据我估算，在大规模部署中，这种优化可能为企业节省数百万美元的GPU成本。

更令人兴奋的是Daft的发展路线图。他们计划扩展对新数据类型如视频和变体的多模态支持，为AI工作负载提供更好的原语包括流式和异步UDF，继续投资数据目录如Iceberg和Unity，以及构建下一代分布式执行引擎代号为”Flotilla”的系统。这个路线图显示了他们对多模态数据处理未来的清晰愿景，不仅要解决当前的痛点，还要为未来的需求做好准备。特别是流式UDF的支持，将使实时AI应用成为可能，这对于自动驾驶、实时推荐系统等场景意义重大。新的分布式执行引擎”Flotilla”暗示着他们在底层架构上的持续创新，可能会带来更大的性能突破。

Daft的另一个值得关注的特性是其对数据目录的深度集成。现代企业的数据分布在各种系统中，包括云存储、数据湖、数据仓库等。Daft对Iceberg、Unity等数据目录的支持，意味着它可以无缝访问企业现有的数据资产，而不需要数据迁移。这种能力对于企业采用新工具至关重要，因为数据迁移往往是最大的障碍。通过消除这个障碍，Daft大大降低了企业的采用门槛，这也是它能够快速获得Amazon、CloudKitchens等大客户的重要原因。

对整个AI基础设施行业的启示

Eventual的成功对整个AI基础设施行业具有重要的启示意义。我认为我们正在见证AI基础设施的第二次革命。第一次革命是从通用计算转向AI专用硬件，如GPU和TPU的普及。现在我们正在经历第二次革命：从为结构化数据设计的软件架构转向为多模态AI工作负载原生设计的软件架构。

这种转变对整个技术栈都有深远影响。在存储层面，我们需要能够高效存储和检索各种数据类型的系统。在计算层面，我们需要能够原生处理多模态数据的引擎。在应用层面，我们需要能够无缝集成各种AI模型和工具的框架。Eventual在计算层面的创新为整个栈的演进指明了方向。

从商业角度看，Eventual的成功也验证了专业化基础设施工具的市场需求。过去，企业可能会选择通用解决方案并接受一定的性能损失，但随着AI应用的复杂性和规模不断增长，专业化工具变得不可或缺。这为专注于特定技术领域的初创公司创造了巨大机会，也解释了为什么投资者愿意为Eventual这样的公司投入大量资金。

我观察到，越来越多的AI公司开始意识到数据基础设施的重要性。过去，数据基础设施被视为支持性功能，现在它正在成为核心竞争优势。能够更快、更可靠地处理多模态数据的公司，在构建AI应用时就拥有了显著优势。这种认知转变推动了对专业化数据处理工具的需求，也为Eventual这样的公司创造了广阔的市场空间。

从技术人才角度看，Eventual的团队构成也很有启发性。他们汇集了来自Databricks Photon、GitHub Copilot、Pinecone矢量数据库、Render和AWS PartiQL等项目的开发者，这些都是大规模系统的构建者。这种人才配置表明，构建下一代AI基础设施需要深厚的分布式系统经验和对AI工作负载的深刻理解，而不仅仅是AI算法知识。

挑战与未来展望

尽管Eventual在多模态数据处理领域取得了突破性进展，但我认为他们仍然面临一些重要挑战。首先是生态系统的建设。虽然Daft在技术上很先进，但要让更多开发者采用，还需要建立完整的工具链、文档、培训资源和社区支持。目前大多数数据工程师都熟悉Spark和pandas，切换到新工具需要学习成本。

我也关注到多模态数据处理的标准化问题。不同的AI模型和应用对数据格式的要求各不相同，如何在保持灵活性的同时建立某种程度的标准化，将是一个长期挑战。Eventual需要在支持各种数据格式的同时，推动行业形成一些最佳实践和通用标准。

从竞争角度看，Eventual作为先行者有明显优势，但这个领域很可能变得拥挤。大型云服务提供商可能会推出自己的多模态数据处理解决方案，传统数据库公司也可能加强在这个方向的投入。Eventual需要继续保持技术领先优势，同时快速扩大市场份额。

成本优化也是一个重要考虑因素。虽然Daft在性能上有优势，但多模态数据处理本身就是资源密集型的。如何帮助客户在获得更好性能的同时控制成本，将是Eventual商业化成功的关键。他们需要提供清晰的ROI证明，让企业愿意为更好的工具付费。

尽管存在这些挑战，我对Eventual的未来充满信心。他们正在解决一个真实存在且日益严重的问题，拥有强大的技术团队和充足的资金支持。更重要的是，随着AI应用的普及，对多模态数据处理的需求只会继续增长。Eventual不仅在构建一个产品，更是在定义一个新的技术类别。

从更宏观的角度看，我相信Eventual代表了AI基础设施演进的方向。我们正在从”让AI适应现有基础设施”转向”让基础设施原生支持AI”。这种转变将释放AI技术的真正潜力，让更多企业能够构建强大的AI应用，而不是被基础设施的限制所束缚。最终，像Eventual这样的公司将成为AI时代的基础设施提供商，就像AWS为云计算时代提供基础设施一样。他们的成功不仅将推动自身业务的增长，更将加速整个AI行业的发展。