Starburst CEO: AI 领域的胜者在于数据访问能力

初创公司 Starburst 利用 Trino 开源分布式 SQL 引擎开发并运用分布式 SQL 查询及分析各类分布式数据源。我们与首席执行官 Justin Borgman 就公司的战略进行了交流。

先回顾一下背景故事，始于 Presto。Presto 是 Facebook（现 Meta）于 2012 年推出的开源项目，旨在为其庞大的 Hadoop 数据仓库提供分析服务，通过分布式 SQL 查询引擎实现。它既能分析 Hadoop，也能查询 Cassandra 和 MySQL 数据源，并于 2013 年以 Apache 许可证开源。

四位 Presto 创始人 —— Martin Traverso、Dain Sundstrom、David Phillips 和 Eric Hwang —— 由于对 Facebook 对 Presto 治理方式的不满，于 2018 年离开了 Facebook。

他们随后将 Presto 代码分支为 PrestoSQL。Facebook 于 2019 年将 Presto 捐赠给 Linux Foundation，并成立了 Presto Foundation。到那时，已有成千上万的企业和其他组织在使用 Presto。由于 Facebook 获得了 “Presto” 商标，预防潜在法律风险，PrestoSQL 后来更名为 Trino。分支团队在 2019 年创立了 Starburst，联合创始人兼首席执行官 Justin Borgman 负责供应用 Trino 同时销售 Trino 连接器和提供技术支持。

Borgman 曾于 2010 年联合创办 SQL-on-Hadoop 公司 Hadapt。Hadapt 于 2014 年被 Teradata 收购，Borgman 随后担任其 Hadoop 产品部门的副总裁兼总经理。他于 2019 年辞职，加入其他 Starburst 创始团队。

Eric Hwang 现为 Starburst 的杰出工程师。David Phillips 和 Dain Sundstrom 曾分别担任首席技术官职务，但他们今年早些时候离职，共同创办了专注数据安全的隐蔽公司 IceGuard。Martin Traverso 现任 Starburst 的首席技术官。

Starburst 分四轮融资共筹集了 4.14 亿美元，分别在 2019 年（ A 轮 2200 万美元）、2020 年（ B 轮 4200 万美元）、2021 年（ C 轮 1 亿美元）及 2022 年（ D 轮 2.5 亿美元）。

公司在 2024 年初以及同年晚些时候招聘了更多高管，助力其在混合数据云和 AI 领域的发展。

今年早些时候，Starburst 报告其全球销售额创下历史新高，其在北美和 EMEA 区域均实现显著增长，每个客户的年经常性收入（ ARR ）超过 32.5 万美元。其旗舰云产品 Starburst Galaxy 的采用率同比增长 94％，同时公司签署了迄今为止最大的一笔交易 —— 与一家全球金融机构签订了一份多年、年交易额达八位数的合同。

Blocks and Files：Starburst 在我看来相当于一个虚拟数据湖仓一体化平台，通过这个平台你可以从各种数据源获取数据，再将数据馈送给上游需要它的人。

Justin Borgman：嗯，我喜欢这种表述。我们虽然不称自己是虚拟湖仓，但这种说法很贴切。

Blocks and Files：Databricks 和 Snowflake 已经和 AI 搭上了关系，过去六到九个月内大语言模型的采用十分火热。Starburst 是否也在进行类似探索？

Justin Borgman：在某种程度上是，但我可以具体阐述一些不同点。对我们来说，我们并不专注于大语言模型本身。

基本上我们认为客户会自行选择大语言模型，无论是 OpenAI 还是 Anthropic 或其他。不过，我们的重要作用在于那些具备代理功能的 RAG 工作流程，这些工作流程访问不同数据源，并将数据传递给大语言模型，以确保上下文信息的准确性。

这正是我们相对于那两家大型公司可能具备优势的地方。虽然对方规模远大于我们，我能理解他们在这方面走得更远，但如你所说，我们可以访问企业中所有数据。在这个代理和 AI 的时代，我认为最终赢家是拥有最多数据的一方。所以，我们真正提供的，就是访问企业内所有数据的能力，而不仅限于单一数据湖或单一数据仓的数据。

Blocks and Files：这让我有两个想法。第一，你们肯定已经拥有大量连接器，将 Starburst 与各种数据源连接。我想一个重要但在背后的工作，是确保这些连接器保持最新，并不断接入尽可能多的数据源。

Justin Borgman：没错。

Blocks and Files：第二，我认为你们可能会提供某种 AI 数据管道，通过管道从数据源中选取数据，并进行一定的过滤。例如，去除敏感信息后再上送给上游。至于上送数据时 Starburst 的工作在何处结束，可以有多种方案。比如，你从各数据源中选取并过滤出一些数据，这些数据以数据表形式呈现，但实际上这些数据原始无加工，AI 模型需要经过 Token 化和向量化处理，也就是这些向量需要存储在某处，然后用于训练或推理。那么 Starburst 的服务在什么阶段终止？

Justin Borgman：你说得都对。我来具体说明一点：正如你之前提到的，我们目前已拥有超过 50 个连接器，这涵盖了你能想到的所有传统数据库系统、所有 NoSQL 数据库，基本上是你能想到的每一种数据库。之后我们开始扩展，增加了大型 SaaS 提供商，如 Salesforce、ServiceNow 等。因此我们可以访问所有这些资源。

你还说得对，我们在所有这些系统上都能提供非常细粒度的访问控制，包括行级、列级控制，我们也可以进行数据屏蔽，而这正是我们平台的强项，确保你用于 AI 的数据可以被精细管理和治理。这包括基于角色和基于属性的访问控制。

至于你问我们服务终止的点，好问题。实际上，在今年 5 月，我们将会宣布一些更进一步的功能，虽然我目前不便透露太多细节，但我可以说，在 5 月时，你们将看到我们几乎实现了你今天所描述的全部功能。我认为我们会在向量化之前停止这部分工作，而目前就是这样。

Blocks and Files：我可以理解 Starburst 的思路，我们虽然不是数据库公司，但确实能够访问存储数据的保管库，而且我们可能是通过获取关于数据源的元数据来访问这些数据的。所以在上送数据时，我们可能直接传送实际数据，即从各个数据源中抽取并输出数据，或者仅仅使用元数据再上送。请问是谁来做这个工作？是你们采集数据后再传上去，还是目标系统来做？

Justin Borgman：实际上我们会两种方式都采用。首先，我们发现许多客户使用我们产品中的一个功能，称为数据产品，这基本上是一种创建优选数据集的方法。正如你所描述的，我们作为虚拟湖仓，可以将来自多个数据源的数据整合成一个数据产品，这个数据产品本质上是多个数据源之间的统一视图。在这种情况下，无需一定移动数据，你只是在构造视图。

但最终，当你执行 RAG 工作流程并把数据（可能作为提示）传递给调用大语言模型的 LLM 函数时，我们可能会移动数据。

Blocks and Files：如果你们要对数据进行向量化，那么这些向量需要存储在某个地方，你们可以自行存储，也可以与 Pinecone、Milvus 或 Weaviate 配合。你能透露一下目前的倾向吗？

Justin Borgman：你问的问题切中要害。我正在思考该如何回答……今天我就先不多说。除此之外，你的问题非常好，我大约六周后会给出一个明确的答案。

Blocks and Files：如果我与潜在客户交谈时，对方说他们在各个数据中心以及公共云中拥有分散的数据，还有 SaaS 数据集，那么应该建议他们选择单一湖仓数据仓供应商，比如 Snowflake 或 Databricks 之类的，还是继续保留现有数据，并在需要时通过类似 Starburst 的方式进行虚拟聚集？这种两种方案各有什么优缺点？

Justin Borgman：我们的回答其实是两者结合，我来解释一下。我们认为，将数据存储在对象存储中，以 Iceberg 表等开放格式存储在数据湖中，是存储大量数据的理想方案。我甚至认为，应尽可能多地利用这种方式，因为其经济性非常理想，尤其是采用 Iceberg 这一开放格式后，因为业界已经认可 Iceberg 是通用格式，这为客户提供了极大的灵活性。因此我们认为数据湖很不错。然而，我们也认为不可能把所有数据都放进数据湖，这只是一个美好的憧憬，实际上永远难以实现。我这么说部分基于我自身的经验……

所以我们需要吸取过去的教训。我的看法是，存储数据必须采取两手策略。我认为数据湖应当成为主要的数据重心，也许是最大的一个重心，但你始终会有其他数据源，因此你的策略需要兼顾这一点。

我认为，必须将所有数据集中在一个地方以实现 AI 战略，这一观念并不实用，因为你的数据永远会有延迟，总是无法做到实时更新。你总会有专门的数据库系统在处理事务及其他特定任务。所以我们主张两者并举。这解释清楚吗？

Blocks and Files：非常清楚，Justin。你提到了数据库、结构化数据。那么 Starburst 能否支持利用块存储数据库中的结构化数据？

Justin Borgman：是的，可以的。

Blocks and Files：你们是否与知识图谱在表达这种数据方面有所关联？

Justin Borgman：我们确实有一些连接器可以支持几个图数据库，所以这是一个选项，但我不会说这是我们目前的核心竞争力。

Blocks and Files：稍微转个话题。类似 Cohesity 和 Rubrik 的备份数据保护公司会说，我们有大量备份数据存储在数据仓库中，我们是 Retrieval-Augmented Generation 的理想数据源。在一定程度上，这看起来是可行的。如果遇到潜在客户说，我们在 Cohesity 的备份库中有大量信息，并正用这些数据构建 AI 管道，你们能做些什么？或者你认为这只是一种有效但不足以单独取胜的方法？

Justin Borgman：根据我们的客户使用情况，我还没有看到利用 Cohesity 或 Rubrik 作为数据源的案例，但我们确实看到了大量对象存储的应用。实际上，我们与 Dell 建立了合作关系，Dell 正在其对象存储之上销售 Starburst，我们也与 Pure 和 MinIO 以及其他所有使其存储与 S3 兼容的供应商合作。看起来比较常见的就是 S3 类型的存储，而像 Cohesity 和 Rubrik 这类产品，我还没见过相关案例。所以我也不确定其性能是否足够。这是个合理的问题，我目前不得而知，但可能正因如此，我才没有见过相关应用案例。

Blocks and Files：再说 Veeam。Veeam 可以将备份发送到对象存储，这理论上可以通过 S3 类型的连接器访问这些数据。但如果 Veeam 将备份存入自有存储，那这些数据对你们来说就不可见，除非你们与 Veeam 搭建一个相应的连接器。而我敢打赌，到那时 Veeam 会表示不感兴趣。

Justin Borgman：是的，我认为确实如此。

Blocks and Files：我是否可以理解成，尽管 Cohesity/Rubrik 模式提供信息以支持 RAG 是有其合理性的，但这并非实时数据，因此可能使客户处于潜在劣势？

Justin Borgman：这正是我的印象。是的，我的印象就是这样。