AI 时代， 需要什么样的数据底座？

作者：杨克特 ProtonBase 技术副总裁

毕业于浙江大学计算机系，获硕士学位，具备 10 多年核心系统设计和研发经验。曾任阿里巴巴资深技术专家，负责过搜索引擎、资源调度、实时监控等系统的设计和研发。具备丰富的开源经验，是 Apache Flink 和 Apache Druid 的 PMC 成员，以及 Apache 软件基金会成员。

概念科普：Data Warebase = Data Warehouse + Database，由 ProtonBase 在业界首次提出。

---

今天主要和大家探讨一下在云原生时代大背景下，常见数据平台所面临的机遇和挑战，以及最新的演进趋势。同时还会分享 ProtonBase 在这一过程中的实践经验。最后，结合当下 AI 的流行趋势，探讨一些看法，希望能给大家带来一些启发。

典型的数据架构演进路径

在说到数据平台上云之前，先来看线下一个比较典型的数据架构是如何一步步发展出来的。

一般来说，每家公司一开始都会有自己的应用以及后台的应用服务。这些应用服务往往需要一个数据库来承接实时的读写流量。而当业务发展较为顺利时，单机数据库很可能无法满足业务需求。此时，很多公司会在其基础上进行分库分表操作。如果有一些对存储较为灵活的需求，可能会采用像 MongoDB 这样天然具备分布式能力的数据库。

随着业务的发展，数据库上简单的点查点写可能无法满足业务的复杂需求，比如像搜索这样的需求。此时，可能需要引入像 ES 这样的搜索引擎。由于公司里的数据都在前面的 MongoDB 和数据库里，就需要搭建一个数据同步链路，每天把数据从数据库里全量同步到数据仓库中，然后进行离线处理，再放到 ES 中，从而使整个业务具备搜索能力。

既然有了数据仓库，大部分公司接下来会开始构建自己的离线数据仓库，比如像典型的 Hive。构建完离线数据仓库之后，公司里的运营人员或主管们就可以开始查看报表。随着大家对数据实时性的要求越来越高，一天级或者小时级的离线处理显然无法满足这样的要求。那么，很有可能会引入像消息队列、Flink 这样的实时处理技术，针对源头业务中的数据通过 CDC 的方式拉取过来进行增量计算。

算完的结果可以同时放到 ES 和放到 Clickhouse 这样的一个实时 OLAP 引擎里，这个时候系统就具备了比较实时的做搜索以及实时分析这样的能力，这是线下的一个典型的业务架构的比较自然而然的发展流程。

数据平台上云的“得”与“失”

在云原生时代，很多企业也会把自己的数据平台搬上云，上云之后会有以下好处：

首先，显而易见的是资源的灵活性大大提升。就像刚才看到工商银行袁老师的分享，工行线下有很多服务器，有些服务 CPU 性能强，有些服务器内存容量大，还有些服务器存储能力强。但其实很难预知接下来一年公司内部的业务到底会更多地使用哪种机器资源。如果一开始规划不好，很可能就会造成一些资源浪费。

而在云上，这种情况就不存在了。云上有各种各样的资源，你可以按需采购，不用提前做那么复杂的规划。并且在上云之后，各云厂商或多或少都会提供一些半托管的产品，或者多种全托管的产品，有助于大家降低运维压力。

同时，各大云厂商也都有比较优秀的自研产品。因此，上云之后，企业不再局限于线下只能选择一些开源系统，而是有了更多的系统选择。

但上云也并非没有挑战：

首先，当你的数据架构完全平移到云上之后，会面临一个现实问题：由于每个系统的迭代速度不一样，有些系统可能并没有针对云原生做特别的优化，只是将原来运行在线下的系统直接搬到线上。这种情况下，其实和线下并没有太本质的区别。但当你选择了一个云厂商之后，数据反而可能会被其锁定（Lock-in），因为实现数据的多云部署其实并不容易。

而且，当你选择了一个云厂商之后，对于相同的软件，不同云厂商之间在该产品的能力上会存在差异。比如以我比较熟悉的 Flink 为例，阿里云的 Flink 在某些功能和性能优化方面可能表现得更为出色，而其他云厂商的 Flink 版本在这些方面可能相对弱一些。

以 AWS 为例，当系统架构迁移到云上之后，你会发现 AWS 的 RDS 非常出色，我们可以将原本的开源 MySQL 替换为 RDS。同时，AWS 的 Redshift 也很强大，可以将 Hive 升级为 Redshift，以获得更高效的数据分析能力。此外，还可以替换搜索系统，以实现更强大的搜索功能。同时，S3 提供了非常经济高效的存储解决方案，可以利用它来存储大量数据。

所以，完成这样的升级之后，你会发现架构的本质并没有发生根本性的变化，但确实带来了一些显著的好处。当然，这也伴随着一些成本的付出。然而，各个公司对业务的需求远远没有停下来，反而越来越多。例如，常见的 TP 和 AP 混合查询在这种架构下就比较难以应对。

我们常常面临一个比较尴尬的问题：到底是应该在 TP 库中运行 AP 查询，还是在像 ClickHouse 这样的 AP 系统中运行一些点查（TP）操作呢？如果同一个业务流程中涉及到的查询既需要 TP 的实时性，又需要 AP 的分析能力，那就更让人头疼了。如果放在 TP 库中运行，不仅速度会变慢，还可能影响 TP 库的稳定性；而如果放在 AP 系统中运行，又可能因为数据延迟，导致 AP 系统中找不到最新的数据。

当我们建立了离线和实时两套 BI 流程后，大家在使用过程中发现实时计算出的结果和昨天离线计算的相同时间点结果对不上，这就会让人感到困惑。因此，这也促使我们开始探索离线和实时一体化处理的解决方案。

现在 AI 很火，大家也开始思考如何从业务数据中提取和加工 AI 所需的特征。对于离线特征，由于企业所有的业务数据都存储在 S3 上，我们可以在 S3 上进行处理，生成离线特征并将其存储到 Redshift 中。同时也可以通过 Flink 计算实时特征，并将这些特征存储到 MongoDB 中，以便进行实时服务。

随着生成式 AI 的主键流行，基于业务数据做向量检索的需求也不断增加，我们又会选择搭建一个专门的向量数据库，并进行数据同步。

总之，随着新的需求的不断到来，图里的线似乎可以无止境地画下去，甚至还可以在上面摆出更多系统。虽然上云带来了诸多灵活性的优势，但它并没有解决整个数据系统内在的原生复杂度。在我看来，这种复杂度会引发三个方面的问题。

数据系统的“熵”

• 开发视角：首先，从业务开发人员的视角来看。当业务系统越来越多时，公司就需要招聘更多不同类型的研发人员。有些研发人员对系统 A 和 B 比较熟悉，而有些研发人员可能对系统 C 和 D 比较熟悉。系统越多，所需的研发人员类型就越丰富，这无疑提高了门槛。而且，每个研发人员还需要清楚地了解系统 A 擅长什么，系统 B 擅长什么，如果这两个系统都不擅长，那就得去找系统 C，这就大大拖慢了开发的效率。
• 运维视角：同时，因为系统众多，系统间的数据搬迁就成了一大难题。你不得不开发大量数据迁移任务，这些任务数量往往非常庞大，成了系统稳定性的薄弱环节。除此之外，大量的数据同步任务也使得成本急剧上升。
• 业务视角：另外，从业务人员的角度来看，假设有一天业务方提出了一个新需求，我们要做的第一件事情不是开发业务代码，而是增加新的数据同步链路。这样一来，迭代效率就会变得很低。更糟糕的是，假如现有的业务系统中没有一个能满足要求，还需要临时去采购一个新的系统，而这个采购周期通常要以半年以上来计算。

回过头来看，数据链路的复杂度逐日上升的根本原因是，过去二十年我们对大数据带来的挑战没有形成一个系统性的解法。当时的解法就是见招拆招。数据存不下，那就先造个 HDFS，把海量数据存起来；面对海量的 KV 读写需求，那就先造个 HBase 来扛住。每个系统都只具备少数几个核心能力，当需求复杂了后自然就需要大量系统的协同工作。

理想中的数据系统

但如果站在 2025 年的今天来回溯，假设我们已经掌握了所有的相关知识，面对刚才提到的那些数据需求，从零开始去打造一个理想中的系统，那么它大概会是什么样子呢？

• 统一的 API：首先，我觉得第一点是必须有一个统一的 API。就像刚才提到的，业务开发人员不希望去学习五花八门的多种语言，每个系统的 API 都不一样。如果能有一个统一的 API，那么这个 API 的表达能力就需要足够强大。
• 统一存储：同时，我们也不希望数据在不同的七八个系统之间来回流转。而是希望整个数据存储至少在一个地方都能看到，没有数据孤岛，也不需要做太多的数据同步。
• 存算分离：此外，借助云计算灵活的资源环境，我们希望整个系统是存算分离的。存储不够就加存储，计算不够就加计算，这样可以实现非常高效的水平扩缩容。
• 实时写入、实时查询：从系统的查询能力来讲，这个系统能够实现数据实时写入、实时可见、实时可查。
• 多模态支持：同时，系统应具备搜索引擎的能力，支持全文检索、多维检索和聚合查询。此外，系统还应具备实时分析和向量检索的能力。总的来说，它需要具备多模的能力。

过去几年，我们也带着这个问题去做了一些尝试。先从 API 看起，从语言的表达能力来看，SQL 是久经考验的，选择 SQL 基本不会引起太大争议。但具体选择什么样的 SQL，就需要仔细考量。我们发现 PG（PostgresSQL）的生态近年来发展得非常繁荣。虽然在 10 多年前，PG 可能还处于不温不火的状态，但如今，它的上下游工具、文档以及相关产品都形成了非常完善的生态。

PostgreSQL 生态的优势与挑战

从流行度来看，PG 在过去 10 年一直保持着高速增长，并且在近两年的 Stack Overflow 开发者调查中，连续蝉联了“最受欢迎的数据库”这一称号。

PG 的流行离不开它的诸多优点：

首先，它是一款数据库，天然具备 ACID 能力，能够保证数据的强一致性。它支持多种数据类型和多种索引。最关键的是，它的可扩展架构非常强大。从上图可以看出，基于 PG 构建的系统，不仅可以直接使用 PG 本身的功能，而且很多创业公司基于 PG 开发出了适用于不同场景的核心能力。比如，有些公司基于 PG 开发了时间序列的扩展，还有公司开发了 PG vector 这样的向量检索扩展。这说明 PG 的扩展性非常强，也给我们带来了很大的启发。

如何解决 PG 水平扩展的问题？

但如果基于 PG 去构建一个全新的系统，最大的问题是：PG 是一个单机数据库，我们需要实现水平扩展的能力，以及如何做到弹性伸缩。

先来看第一个扩展问题，这个问题的关键点在于如何给数据做分片。常见的分片策略其实都比较简单。一种是哈希分片。如果一开始大概知道表要分成三片，做过分库分表的同学应该就很熟悉了：给 key 计算一个哈希函数，然后对 3 取模，根据取模的结果就能确定某一行数据应该去到哪一个分片。

还有一种比较主流的做法是 Range 分片。这种方式不是按哈希值来分，而是根据数据的取值范围来划分。比如， a 到 c 是一个分片， d 到 h 是第二个分片。

我们仔细对比一下它们的优劣：

首先，从系统开发者的角度来说，哈希分片是很吸引人的。它实现起来非常简单，而且效果也不错。只要选择一个合适的哈希函数，数据进来后基本都能均匀分配到各个分片，用户无需太担心热点问题。而且，哈希分片的查询路由也很简单。如果查询是基于 key ，系统只需要计算一下哈希值，就能直接定位到数据所在的分片。如果不是基于 key 的查询，那就直接广播到所有分片即可。所以哈希分片的实现复杂度其实很低，效果也不错。

Range 分片比较吃亏，因为在数据进入系统之前，系统无法预知数据的范围分布，比如无法确定是 a 到 c 是一个分片，还是 a 到 d 是一个分片更加合理。因此，系统需要一直维护一个全局的路由信息来管理这些分片。

但如果反过来，从使用者的角度来看，这两种分片策略在实际表现上会有一些不同。比如，Range 分片在范围查询方面就比较有优势。假设你的过滤条件是 Key 上的大于、小于或等于之类的范围查询，Range 分片在查询时会更高效，因为它不需要广播查询到所有分片。从易用性角度来看，Range 分片也更好一些，用户不需要提前预配置分片数。在实现时，系统通常会自动进行分片，并且能自动进行拆分（split）或合并（merge）。

哈希分片一旦在一开始配置好了分片数，后续想要修改就比较困难，这是一件比较伤筋动骨的事情。想象一下，假如一开始配置成了 10 个分片，所有数据的哈希值都是模 10。这个时候如果想把分片数从 10 改成 11，所有数据的哈希值都要改为模 11。由于以前模 10 的结果和现在模 11 的结果会有非常大的区别，所以整个数据可能需要重新搬迁一次。因此，从用户的角度出发，如果想给用户提供更好的使用体验，ProtonBase 认为 Range 分片会更好一些。

如何选择一个合理的存算分离架构？

解决完分片的问题之后，再来看看如何选择一个合理的存算分离架构。这是一个非常简单的示意图：

现在，绝大多数大数据系统基本上都是采用存算分离架构。具体来说，底层可以使用像 S3 这样的对象存储，计算节点直接连接 S3 进行存储和计算。为了保证吞吐量，通常还会引入一些本地的高速磁盘，用于做本地缓存。

这种架构在吞吐量方面表现较好，但面临的一大挑战是高并发实时写入场景。比如在使用数据库时，通常会有高并发的实时写入，或者单条记录的更新、删除等操作。在这种架构下，由于所有写入操作都需要同步地持久化到底层存储，而像 S3 这样的存储本身并不擅长支持低延迟且高频的调用，因此在这种实时高并发场景下，该架构较难满足需求。

要解决这个问题，如果希望既要保证吞吐量，又要在延迟上有较好的表现，一般来说，首先需要依赖一个高速的底层存储。比如高速的本地 SSD 盘，或者高速的云盘，来实现非常低延迟的持久化操作。

再往上，由于数据需要可靠存储，就需要引入分布式一致性协议来保证数据不丢失。因此，若想在保证吞吐量的同时确保低延迟，大部分情况下就需要引入专门的存储服务，由它来提供高可靠、高吞吐、低延迟的读写能力。唯一的缺点是实现起来比较困难，但既然这是正确的方向，ProtonBase 还是希望朝着这个目标去努力。

结合刚才提到的 Range 分片和存算分离，我们可以回过头来思考一下：折腾了这么久，我们到底是为了达到什么样的效果？

✨ Data Warebase 核心能力 1：秒级弹性伸缩

其实 ProtonBase 考虑了很多方面，其中我个人觉得从用户角度来说非常重要且体验很好的一点，就是低成本且快速的扩缩容能力。

在一个正在运行的集群中，由于计算节点是无状态的，我们可以随时随地增加或减少计算节点。当用户加入一个计算节点后，如果现有的分片数量不足以充分利用新节点的计算能力，系统可以自动对已有的分片进行拆分。由于采用的是 Range 分片，分片拆分的代价随时很低的。而且，得益于存算分离架构，新拆分出来的分片可以被新节点实时的看到。这样一来，新节点就能实时地将部分负载从其他节点接管过来。

从用户的角度来看，当他们加入一个新节点时，可能只需 5 秒钟，这个节点就能立刻开始提供服务，并且完全不需要进行任何数据搬迁。同样地，当系统的计算节点容量出现冗余，或者计算资源过多时，用户可以轻松地移除一个节点，而无需担心数据搬迁的问题。在移除节点后的几秒钟内，原本分配给该节点的所有负载会自动且均匀地重新分配到其他计算节点上。这就是 ProtonBase 系统所具备的弹性伸缩能力。

HTAP 常见架构对比

现在我们来看一下 TP 和 AP 混合检索的需求。首先，我们先对比一下现在主流的 HTAP 的实现架构。一般来说，企业会搞两套数据库，一套是 TP 的数据库，一套是 AP 的数据库。它们中间通过 ETL 任务去做数据的同步。

除了刚才提到的负载分发问题，通过 ETL 任务进行数据同步的方式还会引入一定的数据延迟，导致数据的可见性无法得到保障。现在有一些更新的架构，例如 HTAP 数据库，它内部可以同时支持两套存储格式：行存和列存。行存适合 TP 引擎访问，能够高效处理事务操作；列存适合 AP 引擎访问，能够高效处理分析查询。所有已提交的 TP 事务可以自动从行存同步到列存，而且这种同步的延迟可以做到非常低。

但是这里面有一个比较细微的，但在某些业务场景下非常关键的问题，那就是很难保证事务的一致性。在此解释一下什么是事务的一致性：假设用户有一个业务场景，想在一个大的事务内完成一系列操作。一开始，用户先进行一些 TP 的简单修改。修改完成后，由于不知道这些修改会引发多大的后续变动，用户需要先运行一些校验操作。比如，修改了一个值，接着运行一些统计 SQL，以确保修改的结果符合预期。只有在这些校验都通过后，用户才敢提交这个事务。如果列存只能看到已经提交的事务，那么这种非常强的一致性要求就很难满足了。

既然我们已经能够将引擎统一到一个数据库里，并且同时支持行存和列存，那么下一步比较直接的想法就是：为什么不把这两种存储格式的优点结合起来，形成一种混合存储格式呢？行存支持高效的 TP 工作负载，而列存则支持较好的 AP 能力。

✨ Data Warebase 核心能力 2：混合存储

这就是 ProtonBase 的另一核心能力：混合存储。由于数据存储在同一种文件格式中，所以用户完全不用担心一致性问题，它天然就是强一致的。所有写入的数据都不需要进行额外的数据同步，也不需要外部的 ETL 操作。

在混合存储之上，我们内置了一套 TP 引擎和一套 AP 引擎，它们之间的负载隔离非常重要。首先，有不同的隔离方式。如果不想把部署搞得过于复杂，可以在相同的计算组内做一定的软隔离。

✨ Data Warebase 核心能力 3：负载隔离

从优化器的视角来看，它会帮助用户分析这是一个比较小的 TP 查询，还是一个比较大的 AP 查询，然后根据成本来动态选择最合适的执行计划。我们支持不同负载之间的优先级，并将优先级传递到 CPU、内存、IO 等共享资源上进行一定的负载隔离，保证 TP 和 AP 之间的负载不会有很大的互相影响。

但软隔离终究有其局限性，隔离能力肯定存在上限。如果需要实现非常强的硬隔离效果，可以启动多个计算组。例如，一个计算组专门运行 TP 工作负载，另一个计算组用于处理复杂的分析场景。当然，还可以再创建一些计算组，用于运行特别复杂的离线加工作业。每个计算组都可以根据需求随时启动或停止。对于那些复杂的加工任务，如果平时不需要运行，完全可以将其全部停掉，等到需要时再启动。

离线实时一体化架构演进的问题

刚才也提到了实时和离线口径不统一的问题，这其实是很经典的问题，做大数据的同学应该都很熟悉。这种问题通常会采用 Lambda 架构来解决，Lambda 架构在一定程度上确实解决了如何融合离线和实时结果的问题。然而，它的问题也是显而易见的。

比如，文件系统的存储和消息队列的存储显然是冗余的。而且，你还需要用两个大数据引擎来处理数据，用 Hive SQL 写一套离线处理逻辑，同时可能还需要用 Flink 或 Spark SQL 写一套实时处理逻辑。毕竟，每个链路都开发一套离线，一套实时计算系统，这个代价还是挺大的，并且还要两边互相调试、交叉对比。

所以，业界这几年也一直在摸索架构的下一步迭代。

• 第一阶段：计算引擎统一。比如，Spark 和 Flink 现在都具备了跑离线批处理和流处理的能力，这样就不用再维护多个计算引擎了。同时，由于是同一个引擎，它们在语义上也能够尽量做到一致，这是第一阶段发生的事情。
• 第二阶段：存储统一。最初，文件系统存储一套数据，消息队列又存储一套数据。现在，人们开始思考能否在一套存储系统上，既能实现文件系统的批量扫描能力，又能具备消息队列读取增量数据的能力。因此，目前像 Iceberg、Hudi 等湖存储的主流发展方向，正是朝着这种融合能力的方向发展。

但是在这两个阶段完成之后，仍然遗留了一些问题：

1.  尽管计算引擎实现了统一，但 SQL 并没有统一。实时 SQL 仍然有其特殊性。不知道大家有没有开发过 Flink 的实时作业，比如你可能需要理解一些像 Watermark 的概念，或者是否存在维表关联等概念，所以它还是有一些独特之处的。
2.  实时作业和离线作业的运行模式天然不同。离线作业基本上是计算一次、产出结果就完成了；而实时作业为了实现增量计算，需要在内部存储大量的状态信息，比如在进行 join 操作时需要将 join 的输入都存在内部的状态存储里。因此，离线 SQL 和实时 SQL 的运行模式存在本质区别，基本上很难实现两者的无缝切换。
3.  实时作业虽然可以做到很低的延迟，例如达到秒级，但其成本相对较高。然而，在一些业务场景中，并不需要那么高的实时性，比如 5 到 10 分钟的延迟就足够了。目前，无论是离线还是实时计算，都没有很好地满足这种对实时性要求介于两者之间的需求。

因此，在前两个发展阶段的基础上，ProtonBase 提出了对这个问题的一些思考。我们认为可以借鉴数据库的物化视图，结合增量计算的能力，来进一步统一计算模型，从而更好地解决这种需求。

✨ Data Warebase 核心能力 4：增量物化视图

首先，物化视图是数据库中的一个原有概念，它与离线 SQL 完全一致，没有任何实时的特殊性，从而解决了 SQL 语义不同或 SQL 方言不同的问题。

以一个物化视图为例，当全量运行时，它与离线作业并无二致。比如，一个表与另一个表进行连接操作并产生结果。在此基础上，如果表一和表二的数据发生了变化，我们不希望重新运行全量作业，而是希望读取这些表的最新变化，并将这些变化反映到结果中。这本质上就是 Flink 或 Spark 等实时作业所做的事情，而增量物化视图模型也完全可以实现这样的功能。

它带来的好处也很明显。首先，ProtonBase 的表天然具备批量读取和增量读取的能力，没有额外的冗余存储开销。此外，还有一个显著优势是，以往这些数据处理链路中的作业都需要同步到外部的 OLAP 系统中进行服务。但如今，由于 ProtonBase 的系统本身具有强大的 OLAP 能力，无论是原始表还是经过加工的物化视图（MV）结果，都可以直接在数据库内部提供服务。因此，我们认为这种基于物化视图结合增量计算能力的统一计算模型，是未来计算模型演变的一个趋势。

Data + AI

刚才讲的基本上都是围绕数据相关的内容，接下来我想结合当下比较流行的 AI 和大家探讨一下数据和 AI 到底能够碰撞出什么样的火花。

在讲 AI 之前，先回顾一下刚才讲的内容。从整个数据链路的起点说起，包括后面提到的 HTAP 以及实时离线一体化等概念，它们为什么会逐步提出这些需求？它们有哪些共性的本质变化在逐步演进？

一方面，对数据实时性的要求越来越高，数据从业务源头产生到最终能够被查询的时间间隔需要不断缩短。与此同时，用户对查询的吞吐量（QPS）也提出了更高的要求，并且查询的形式也越来越丰富多样。最初可能只有简单的点查点写操作，但随着业务的发展，逐渐增加了数据分析、关键词搜索等多种查询形式。

举个例子，像最早大家都还在用离线数仓的时候，大部分情况下离线数仓的加工时效性只能以天或小时为单位。比如，企业可能每天凌晨运行一次数据处理任务，生成前一天的报表，这些报表通常只有公司高管或者少数关键人员才能看到。这其实本质上是因为数据时效性比较低，同时查询的吞吐量（QPS）也不高，导致它能够带来的价值非常有限。所以在这个时期，降本基本就是主旋律。

随着技术的发展， 整个数据链路的时效性开始提升至分钟级甚至更低。与此同时，对数据的需求也从少数人员逐步扩大到更多的业务同学，甚至可能直接提供给公司的客户，这带来了更高的 QPS 需求。更新鲜的数据，叠加更高频的数据访问，能够带来更大的业务价值。从这个阶段开始，数据应用开始给业务增效。

毕竟人的查询能力终究是有限的。我们也看到，现在很多业务系统开始采用代码或规则引擎等方式来访问数据。通过这种方式，系统可以基于数据自动执行一些简单的决策，从而替代人工操作，对系统的访问量可能又会上升一个台阶。在这种情况下，代码实际上替代了人的角色，能够为公司带来一些比较典型的业务价值。

更实时的数据，结合更加高频的多模态查询，才能真正发挥数据的价值，这也是过去数据系统不断演进的底层逻辑。未来有了更加智能的 AI 之后，这个趋势是否能延续下去？

AI 时代，数据还重要吗？

这里还得先回答一个问题：在 AI 时代，大模型已经掌握了世界上几乎所有知识的情况下，你们公司内部的数据是否还重要？我觉得这个问题的答案最好还是交由 AI 自己来回答。

这就是我向 DeepSeek 提出的问题：

我并没有透露自己是哪家公司的，也没有多说其他信息，只是问了关于公司是否提供停车位的问题。DeepSeek 前面回答了一堆，但其实没什么帮助。不过，它最有价值的回答在最后那个框里：“请提供更多的上下文让我来帮你解答。”所以，数据重不重要，其实就藏在 AI 的答案里。它虽然掌握了世界上所有的知识，但却不知道你们公司内部的知识。

RAG 基本原理

这就引出了现在很流行的基于 RAG 的召回流程。简单过一下这个流程，防止有一些同学可能对这个不是特别熟悉。就像刚才这样的一个问题，我们把它打到后端的召回系统，召回系统会对这个问题进行抽象，把它加工成一个向量，然后向量就可以在公司内部的知识库做搜索，之后可以把相关的文档进行召回。

比如刚才提到的停车位的例子，召回的文档可能包括公司各种停车策略以及负责停车事务的行政人员等信息。把所有相关文档都召回后，将这些内容作为上下文提供给大模型，本质上就是先给它铺垫 2000 字左右的背景信息，比如公司停车的具体策略、涉及的人员等，最后再问公司停车位的情况。这样，大模型就能清楚地知道怎么回答了。这其实就体现了大模型对上下文的需求，而且在大多数情况下，它能够据此给出一个比较好的回答。

从知识库中召回相关文档是信息检索中的关键步骤。对于有搜索引擎开发经验的人来说，这一步骤可能并不陌生。过去，用户主要依赖关键词搜索来召回文档，通过关键词的匹配和相似性计算来实现。而如今的向量搜索技术则通过语义理解来召回文档。由于关键词搜索在精确匹配方面具有优势，因此将向量搜索与关键词搜索相结合的混合检索策略，可能会比单一策略更具优势。

融合传统搜索技术和向量检索

单一的向量搜索在某些情况下效果并不理想。如果将向量搜索与成熟的关键词搜索技术相结合，并利用关键词搜索的相似性计算，这种融合策略往往比单一策略更有效。例如，有研究对比了仅对大模型进行微调与采用混合检索策略的效果。研究发现，将向量搜索和关键词搜索相结合的混合检索策略，比仅对大模型进行微调后的效果更好。

✨ Data Warebase 核心能力 5：索引

在这种场景下，数据系统需要具备倒排索引和向量索引的能力，以满足关键词搜索和语义搜索的需求。倒排索引能够快速定位包含特定关键词的文档，而向量索引则通过语义理解来匹配文档。这种混合检索策略结合了两者的优点，能够弥补单一检索技术的不足，提升检索效果。

AI 是对数据系统的一次“大考”

所以，如果让我畅想一下未来 AI 对数据系统的要求，我觉得 AI 其实给整个数据系统带来了一场全方位的“大考”。过去，用户对数据系统的使用在某些情况下可能还相对简单，但一个成熟高效的 AI 应用链路，必然会对数据系统提出全方位的挑战。

首先明确要求整个数据系统必须是实时的。无论是通过数据库的实时同步，还是通过消息队列的实时同步，关键在于所有源头数据能够实时写入到这个数据系统中。

在将数据写入该系统之后，需要在系统内进行二次加工。可能需要生成一些向量，也可能需要创建一些索引，同时还要完成数据仓库中常见的操作，比如数据清洗、过滤等，所有这些工作都需要在这个系统内完成。

当准备好这一系列数据之后，一个比较智能的 AI agent 就会向数据系统发出各种各样的查询。这些查询不仅限于刚才提到的关键词搜索、向量搜索（这些是已经熟悉的），它还可能发起基于图的检索，或者其他一些我们目前还未演进出来的检索方式。这可能需要根据 AI agent 的真正策略来决定，但可以肯定的是，这里的检索一定是一个多模态的检索。

有了这样的多模态检索之后，它才能将决策实时反馈到业务端。而在这个过程中，还需要科学家对整个流程进行有效监控。他们需要对检索结果进行实时分析和探索，甚至可能需要提供一些输入，思考如何更新或迭代 AI agent 的策略。此外，科学家可能还需要在数据上进行实时挖掘和分析。因此，在一个完整的系统中，需要强大的支撑，这其实对数据系统来说是一个全方位的挑战。

数据架构新范式

以上就是过去几年 ProtonBase 的一个实践，我们希望使用一个系统来解决当下以及未来对数据的大部分需求。

最后，简单总结一下。在云原生飞速发展的当下，如果能够充分利用云的能力，将为企业的数据系统带来更出色的体验。从过去的数据发展历程，到未来 AI 面临的挑战来看，实时性、多模态、一体化这几个方面都将面临更多的需求和挑战。而 ProtonBase 提倡的 Data Warebase 理念正是应对这些需求和挑战的总结与解决方案。