Databricks × Snowflake 纷纷下注，PostgreSQL 成 AI 时代数据库标准？
时间：2025-06-09 | 栏目：业界 | 点击：次
作者 | 王绍翾 @ProtonBase
本文内容整理自 ProtonBase CEO 王绍翾在 AICon 的主题演讲《Data Warebase: Instant Ingest-Transform-Explore-Retrieve for AI Applications》。作者的职业经历贯穿了 AI 1.0、2.0 和 3.0 的时代，从搜索推荐，到视觉 / 语音 / NLP 智能，再到当前正全力投入的大模型 AI 浪潮，本文将结合其多年来对数据基础设施的实践与反思，深入探讨生成式 AI 时代对数据系统提出的全新挑战与潜在机遇。
文章结构：
Trending： 数据基础设施在 AI 时代的新趋势
Introducing Data Warebase： 什么是 Data Warebase
Data Warebase for AI Workload： 如何支撑 AI 工作负载
Use Cases of Data Warebase： 典型落地场景
The Difference Between Data Warebase and Other Technologies： 与现有技术的差异与优势
Trending：数据基础设施在 AI 时代的新趋势
未来的所有应用，将主要对接两个接口：一个 Data API，一个 AI API。
首先，回顾一下近期在数据领域以及 Data for AI 领域的相关思考。这段时间里，有三条重大新闻格外引人注目：
第一，Neon： Databricks 以 10 亿美元收购 Neon 的举措在行业内引发了广泛关注。目前，全球最具影响力的数据公司无疑是 Snowflake 和 Databricks——它们不仅在数据基础设施领域占据核心地位，也正成为众多企业构建 AI 能力的关键平台。
第二，Supabase 在 4 月底宣布完成新一轮融资，金额高达 2 亿美元，估值也随之攀升至 20 亿美元。与此同时，市场上传出有多家科技巨头有意收购 Supabase 的消息，无疑为数据基础设施领域注入了新的活力与关注度。
第三，ClickHouse 也完成了最新一轮融资，估值已超 60 亿美元。从其对外宣称的目标来看，ClickHouse 似乎已经准备好向 Snowflake 发起挑战。
接下来，我将分享我对这三家公司近期为何备受资本青睐、频频获得投资、收购关注的几点观察与思考。
趋势一：大语言模型的出现正在颠覆传统范式
在我离开达摩院之前，尽管其在语音识别和自然语言处理(NLP)等领域已采用了大语言模型(LLM)的技术路线，但当时尚未尝试使用 LLM 对全网数据进行统一训练。直到 OpenAI 的成功落地，整个行业才真正意识到这种方式的可行性与革命性。随之而来的是，几乎所有技术公司都开始拥抱大语言模型，将海量数据汇聚在一起，借助大语言模型的能力为每个人回答日常问题，重构人机交互体验。
但从趋势来看，未来具备能力训练大模型的企业将是极少数。AI 工程之后的重点，将逐步从基础模型的训练转向应用层的落地与价值释放 。而 AI 应用层的两个关键支点正是：
Inference（推理） ：如何以高效、低成本的方式透出模型能力;
Database for Application（面向 AI 应用的数据库系统） ：如何支撑上下文管理、向量检索、数据调用与语义理解等数据层能力。
根据美国市场调研数据，已有约 70% 的企业已在实际生产业务中使用 AI 相关的能力，说明这场范式转变已迅速从前沿技术走向主流实践。
趋势二：Agent 数量快速增长，数据底座成核心支撑
在前文提到的三家公司中，前两家均专注于构建基于 PostgreSQL 数据库的智能代理(Agent)服务，而第三家则聚焦于通过提供数据仓库的能力为 AI 应用提供数据分析的能力 。这一趋势显示出，大模型 Agent 的生态正快速繁荣，背后对高效、高可用的数据基础设施的需求也在同步升级。未来，Agent 的数量会越来越多，谁能够提供真正适配 AI Agent 的数据系统，将成为基础设施竞争的核心关键。
Neon
首先我们先来看 Neon 是什么。
Neon 是一个基于开源 PostgreSQL 构建的云原生数据库，它做了几件非常关键、适合于 AI 应用开发者的事情：
第一，它将传统的单机数据库架构转变为存算分离的云架构。
这一点使得数据库具备了更强的弹性与可扩展性，也为其后续的一些创新能力打下了基础。
第二，在产品设计上，Neon 有两个非常突出的亮点：
Scale to Zero(按需弹性，空闲即释放)
Neon 官网强调其核心优势之一在于 Scale to Zero，也就是说，当你不使用它时，它能够将计算资源完全释放，真正做到“用多少，付多少”，这对于资源敏感型应用尤其重要。
Branching(数据库分支管理)
另一个亮点是 Branching 概念。就像我们使用 Git 一样，Neon 支持数据库级别的“分支”操作。为什么需要这个?
因为在 AI Agent 开发过程中，越来越多的场景涉及大量试验、多人协作、并行工作——允许开发者快速创建、管理和切换数据库的独立副本(分支)，极大提升了开发、测试和数据管理的灵活性。Neon 将数据库转变为一个支持敏捷协作的开发平台，为 AI 和数据工程打开了全新的范式。
一个有趣的观察：AI Agent 正在大量创建数据库
Neon 团队也观察到一个显著趋势：AI Agent 正在以前所未有的速度创建数据库实例。
从 2024 年 10 月到 2025 年 5 月，短短 7 个月时间，数据库创建量出现了爆发式增长。
从 Neon 发布的柱状图中可以看到，绿色部分代表由 AI 自动创建的数据库，相较于人工创建的实例占比显著提升，这说明 AI Agent 正在成为数据库使用的新主力，数据库平台也必须为这种新型工作负载做好准备。
Supabase
Supabase 同样是构建在 PostgreSQL 之上的数据库平台，它与 Neon 构成了直接的竞争关系。但与 Neon 相比，Supabase 提供了更为丰富的功能集，包括身份验证、对象存储、实时订阅、边缘函数等服务，几乎可以看作是“开源版的 Firebase”，定位为开发者的一站式后端服务平台。
为什么这些公司在最近备受关注?
这背后有一个非常清晰的趋势判断：大模型训练的红利期正在接近尾声 。虽然业界尚未正式宣布“训练时代”的终结，但从资本和技术动向来看，未来再去投资新的基础模型公司已不再是主流。相反，所有人的注意力都在向“应用层”聚焦——这就是我们观察到的第一个重要现象：
Inference（推理）和数据应用正在成为新焦点。
无论是 Neon、Supabase，还是其他新兴的数据基础设施项目，本质上都在围绕这个趋势进行布局。
PostgreSQL：新兴数据库的共识基石
几乎所有的新型数据库项目都选择基于 PostgreSQL 构建。我们刚才提到的 Neon 和 Supabase 只是其中的两个代表，实际上，全球近几年新出现的数据库产品，CockroachDB，YugabyteDB，和 DuckDB 也都无一例外的选择了 PostgreSQL 作为查询 API。
PostgreSQL 靠其强大的可扩展性和生态，赢得了全球所有新兴数据库的青睐。
为什么 PostgreSQL 会成为事实上的行业标准？
原因很简单：
PostgreSQL 非常标准和规范，除了 SQL 本身就覆盖了 OLTP 和 OLAP 的需求外，其最大的优点就是有强大的可扩展性。它允许用户通过扩展（Extensions）来增强数据库功能（全文检索，向量检索，地理信息检索，时序处理等等），而无需修改核心代码。
PostgreSQL 已形成强大的社区生态和工具支持。
以向量检索 为例：
PostgreSQL 提供了原生的 pgvector 扩展 ，可以直接支持向量数据的存储与检索;而在 MySQL 标准中，缺乏可扩展性接口与生态，MySQL 数据库系统往往需要自行定义向量数据存储和检索的 API，导致实现千差万别，缺乏标准。这也是为什么越来越多的 AI 公司，特别是 OpenAI、Anthropic、Notion 等大型 AI 初创项目，都选择 PostgreSQL 作为其核心数据引擎。
我曾看到一则非官方的报道：OpenAI 内部的一个 PostgreSQL 只读从库就部署了近 50 个实例 。 虽然目前 OpenAI 尚未采用分布式数据库架构，但随着业务规模的持续扩张，这或将成为其未来必须应对的架构挑战。
Agent Talk to MCP：PostgreSQL 是默认选项之一
我即将介绍的一个概念是“Agent Talk to MCP(Model Context Protocol)”。这个概念最早由 Anthropic 提出，而在其官方文档中，明确列出的第二个支持平台就是 PostgreSQL。
这进一步印证了 PostgreSQL 在 AI 应用工作负载中的关键作用——它不仅是一种数据库，更是 AI 系统与数据交互的中枢平台。
ClickHouse 的定位演变与多模数据库的崛起
相比 Neon 和 Supabase，ClickHouse 的定位其实有所不同。它本质上是一款数据仓库。此前，在它的多轮对外宣传中，一直强调自身是一个 Real-time Data Warehouse(实时数仓)。但最近我再次打开 ClickHouse 的官网，发现它也开始称自己为 Database(数据库)了(ClickHouse 确实一直在开发 OLTP 的能力，只是一直还没有正式发布)。这背后反映出一个趋势：未来 AI 应用层将越来越依赖数据库，尤其是多模态数据库将成为核心基础设施。
举个例子：
如果你正在开发一个基于 AI 的 Agent，它势必需要与各种数据系统和应用系统交互。按照传统架构的分工模式：事务性数据放在关系型数据库中;
数据的横向水平分布式扩展用 MongoDB 或 HBase。
搜索功能用 Elasticsearch(ES)实现;
分析需求用 ClickHouse 支撑;
这意味着，一个企业仅在数据底层就要维护至少 4 个不同的 MCP(Model Context Protocol )服务。这对大模型来说是个巨大的挑战。理论上它可以理解这些差异化的服务，但实际运作中非常复杂，对其“智力”构成高强度负荷。能对接一个 MCP，谁还要对接 4 个呢?这也正是为什么越来越多的 AI 初创公司选择 PostgreSQL ，而未来大型企业在面向 AI 场景进行数据库选型时，也一定会倾向选择支持多模态的数据库平台。
虽然我们刚才提到训练的时代接近尾声，但训练本身的问题依然存在，尤其是在存储层面。我们曾有一句行业共识：“AI 的瓶颈在计算，计算的瓶颈在存储。”这句话主要是针对模型训练阶段而言的。而我们以后更关注的将是 AI 应用和 Workflow 的执行效率 。
当前，大模型并不能完全替用户整理好所有数据，配合大模型一起工作的 AI workflow 主要集中在四个关键环节：
Ingestion（数据摄取）
Transform（数据加工）
Explore（探索分析）
Retrieve（查询检索）
训练的瓶颈仍然存在，但重点正在转向 AI 应用流程（AI Workflow）
虽然我们刚才提到训练的时代接近尾声，但训练本身的问题依然存在，尤其是在存储层面。我们曾有一句行业共识：“AI 的瓶颈在计算，计算的瓶颈在存储。”这句话主要是针对训练阶段而言的。而我们现在更关注的是 AI 应用和 Workflow 的执行效率。
当前，大模型并不能完全替你整理好所有数据，尤其在真实生产环境中，它也不会自动创建数据库。它能做的，主要集中在我们前面提到的四个关键环节：
Ingestion（数据摄取）
Transform（数据加工）
Explore（探索分析）
Retrieve（查询检索）
AI workflow 从数据库、应用日志、埋点系统等来源收集数据;随后通过数据清洗与转换进行加工;加工后的数据可能进入 Feature Store，然后由数据工程师或算法专家进行探索与分析，做出参数调整等关键决策。当这些数据准备充分后，结合大模型的能力，便可实现下一阶段的重要能力。
Multi-Modal Retrieval：下一代智能检索范式
什么是 Multi-Modal Retrieval？ 它的核心含义是：在数据检索过程中，不再局限于某一种查询方式，而是融合结构化、半结构化、非结构化以及向量检索 等多种方式，实现更智能、更全面的查询体验。这项能力对于 AI 应用尤其重要。因为 Agent 面对的问题往往不是“查一条信息或者一个向量”，而是需要对多个模态、多维数据进行理解、关联和调用——这就需要底层数据库具备原生的多模处理能力。
以“智能城市”为例，如果我们需要在监控系统中搜索某辆车或某个人，最基础的方式可能仅涉及向量检索——比如通过图片或视频帧进行相似度匹配。但一旦我们引入更具体的查询条件，比如“某个十字路口”“某个下雨天”“某个时间段”，“和某个车的图片相似”的场景就会涉及到更多模态的信息：
“十字路口”是位置标签 ;
“下雨天”是环境标签 ;
“时间段”是结构化数据 ;
“车的图片”会被 embedding 成向量数据 ;
这类查询就不再是单一模态的检索，而是需要同时融合结构化数据 + 标签信息 + 向量检索的 Multi-Modal Retrieval（多模态检索）。
再比如在社交推荐场景中，人与人之间的推荐可能通过 Embedding 大部分特征成为向量，再靠向量相似度检索来实现。但如果用户添加了“同一个城市”或“同一活动”的过滤条件，就引入了地理位置或事件标签，从而升级为真正的多模态检索任务。
多模态检索对架构提出了更高要求
实现 Multi-Modal Retrieval，意味着系统必须同时处理：
结构化数据；
半结构化数据（如 JSON）；
向量数据。
在传统架构中，不同类型的数据往往被存储在不同的系统中：
结构化数据用关系数据库或数仓;
半结构化数据的存储和检索用 NoSQL;
向量检索用向量数据库。
这样的问题是当我们要执行一个 Top 100 推荐任务时，分布在多个系统中的结果很难直接进行 Join 操作 ，因为性能很差。于是，我们只能尝试从每个系统中提取大量结果(如 Top 100 万)，再在应用层合并关联处理。这个过程不仅开销极大，而且也从理论上无法保障拿到最后正确的 Top 100。这正是 Hybrid Database（混合型数据库） 登场的理由：
将多种模态数据统一存储与检索，消除系统间的分割，让多模态查询变得自然、实时且可扩展。
AI Workflow 的五个关键需求
为了支撑真正的 AI 工作流，从数据获取到结果交付，系统必须满足以下五大核心能力：
1.Fresh Data（数据新鲜性） 模型必须基于最新的数据进行推理，数据滞后将严重影响 AI 产出质量。
2.Instant Retrieval（即时检索） 需要毫秒级的数据访问能力，以满足实时响应和推荐需求。
3.High Concurrency（高并发） 特别是在面向 C 端或 Agent 场景中，系统需能支撑成千上万用户同时访问，具备高吞吐能力。
4.Fast Analytics（快速分析） 不仅要能存储数据，还要能快速完成聚合、过滤、排序等分析任务，为 AI 决策提供支持。
5.Simplicity（易用性） 整个系统要具备良好的开发者体验和管理简洁性，避免多工具链、多平台切换带来的复杂性。
这些能力构成了现代 AI 应用工作流的基础保障。只有构建一个满足实时性、融合性、高并发与易用性 的数据平台，才能真正释放大模型和 Agent 的智能潜力。
为什么传统数据库和数据仓库难以满足 AI Workflow 的全部需求？
前面提到的那些产品之所以备受欢迎，本质上是它们各自解决了 AI 工作流中的关键痛点 ，但仍存在明显局限：
数据库 ：擅长处理 Fresh Data(数据新鲜性) 和 Instant Retrieval(即时检索)，适用于实时写入和快速查询场景。但其大多基于单机或简单主从架构，难以支撑大规模的高并发访问 。
数据仓库（如 ClickHouse） ：在 分析性能(Fast Analytics) 和 使用简洁性(Simplicity) 方面表现出色，但它们普遍不适合高频写入或低延迟响应场景 。
换句话说，没有一个系统能够同时兼顾 AI 应用的五大关键诉求。
Introducing Data Warebase ：什么是 Data Warebase
因此，我们提出了 Data Warebase 的概念——将 Data Warehouse 与 Database 融合于一体，构建统一的数据底座，以全面支撑 AI 工作流中从数据采集、加工、分析到检索的全过程。
根据我们前文的架构模型，任何一家公司在构建数据系统时，都会面临如下几类核心需求：
事务型数据库 ：用于实时写入与查询(如订单、行为日志)
文本搜索引擎 ：处理非结构化关键词匹配(如全文搜索)
向量搜索引擎 ：支撑语义检索
分析引擎 ：进行数据分析(如行情分析、指标监控、报表)
传统做法是将这些功能拆分成多个独立组件，组成所谓的“多引擎架构”，例如：
使用 MongoDB 或 HBase 做分布式存储;
用 Elasticsearch 处理全文检索;
用向量数据库做 vector 检索;
用 ClickHouse 或 Snowflake 执行分析任务。
这种架构虽然功能齐全，但存在三大问题：
系统运维复杂 ：需管理多个技术栈，版本依赖、部署、运维压力大;
数据割裂严重 ：数据需在多个系统间反复同步、复制，口径难统一;
性能和响应链路长 ：查询需跨系统拼接，影响响应时间和稳定性。
我们将这种架构称为典型的 Legacy Data Architecture（传统数据架构） 。它已经难以适配 AI 时代日益增长的实时性、统一性和智能化需求。
Data Warebase 的目标，正是通过统一架构，将多模数据能力集成于一个平台之上，以更简洁的方式支持复杂 AI Workflow。它不是将多个引擎简单拼装，而是从底层架构开始融合事务处理、搜索引擎、向量检索和实时分析，真正做到“一个系统、全场景覆盖”。
Data Warebase 本质上是一个多模数据库
正如之前讨论的，几乎所有的数据问题理应由一个统一的数据系统解决，而这个系统必须对 AI 友好。AI Agent 需要一个多模数据库来处理多种数据类型和任务，这一点我们之前已经讲过。
当客户问到如何实现这个目标时，最初他们往往难以相信一个系统能集成如此多的功能，因为挑战确实很大。简单来说，如果数据量只有 100 行，实现之前提到的功能并不难，大多数单机数据库都能轻松胜任。但当数据量达到 1 亿、10 亿甚至 100 亿行时，挑战才真正开始。
因此，Data Warebase 的核心竞争力在于支持行列混存且具有分布式横向水平扩展的能力 。这种能力主要依赖三个关键技术支撑：存储、索引和存算分离 。
打造 Data Warebase 的核心三要素：存储、索引和存算分离
1.存储架构：灵活多样，兼顾 OLTP/ 搜索 /OLAP 的需求
无论是传统数据库还是大数据系统，都通过行存储支持点查或高速查询，通过列存储支持分析和搜索。Data Warebase 系统中任何一张表支持三种存储模式：行存表、列存表和行列混存表。
行存： 适用于键值查询(KV)场景，支持快速单行访问。
列存： 适合分析和倒排索引，支持高效压缩和列级扫描。
行列混存 ：在不确定负载特性时，自动兼顾行存与列存的优势。
2.索引体系：全面 / 完整 / 正交
Data Warebase 实现了多种索引机制，包括：
OLTP 的全局二级索引 ：支持跨节点的数据定位。
倒排索引 ：满足文本搜索需求。
列存索引 ：优化分析查询。
JSON 索引 ：支持半结构化数据的高效访问。
有了这些索引，结合智能查询优化器，系统能够动态选择最优执行路径，实现复杂查询的低延迟响应。从理论上讲，这些技术在以前各种数据库和大数据系统都分别实现了，我们只是把这些索引能力放在了一个数据库中并把它落地成为了现实。
3.存算分离：数据库的云原生创新
Data Warebase 采用云原生架构设计，将存储与计算资源解耦：
计算层 ：灵活弹性，支持按需扩展。
热存储层 ：保证实时和近实时数据访问的低延迟。
冷存储层 ：经济高效，满足海量历史数据存储，并且支持直接查询冷存上的数据(通过一些架构的优化，冷存上的查询延迟可以做到接近热存，但是吞吐会远低于热存)。
不同于传统大数据存算分离直接使用云上高可用的对象存储，Data Warebase 在块存储云盘上自主设计了高性能分布式文件系统，实现了在线数据库级别的存算分离，这个挑战要比大数据系统的存算分离难一个数量级。
同时，存算分离架构带来的秒级弹性(infinite scale & scale to zero)，负载隔离 ，和数据克隆(Branching)的能力，是实现 AI Agent 灵活工作流和多场景并发计算的关键。
4.其他关键能力
数据分区（Partitioning） ：细粒度数据划分，方便管理数据，在某些场景下可提升查询性能。
实时增量物化视图 ：突破传统物化视图“全量重计算”的瓶颈，实现 Subsecond 级别的增量更新，极大简化实时 Transform 流程。
时间旅行（Time Travel）功能 ：支持基于时间维度的数据版本管理，满足 AI 训练过程中的特征追踪与历史数据回溯需求。
总结一下，Data Warebase 的诞生之初就预见到未来的所有应用系统将 build 在两个 API 之上：一个是 Data API，另一个是 AI API 。 我们专注于做好 Data API，而它恰好在 AI 领域也能满足 AI Workflow 的所有需求。我们下面来看看它是如何满足这些需求的。
Data Warebase for AI Workload：如何支撑 AI 工作负载
为了满足 AI workload 需求，Data Warebase 需要完成数据接入（Ingestion）、转换（Transform）、探索（Explore）和检索（Retrieve） 。我们分别来看这几个环节：
1. Ingestion
数据进来时，首先需要能够快速地导入。Data Warebase 能够支持数据库级别的即时增删改查操作，保障了数据“写入即可见”，同时它支持通过 Foreign Table 直接从 Data Lake 中读取数据。此外，作为一个数据库，它还支持 CDC 输出，而许多大数据系统并不支持这一点。这种能力确保了整个 Workflow 可以无缝串联起来，同时保证了数据存储的强一致性。
2.Transform
在 Transform 环节，我认为最重要的功能有三个：
实时增量物化视图
Schema Evolving
Generated Columns 和 Built-in Functions。
首先，实时增量物化视图可以高效地处理数据的实时更新和查询，大大提升了数据处理的效率。大部分数据库系统只支持全量物化视图和非常有限的增量物化视图能力，所以用户往往还需要 Flink 这种产品做数据的 Transform。Data Warebase 实现了完整了增量物化视图的能力，以后数据的 Instant Transform 再也不需要 Flink 了。其次，Schema Evolving 允许数据模式灵活演变，能够适应不断变化的数据结构。再次，Generated Columns 功能也非常强大。用户可以直接在原表上添加一个新的计算列，而无需使用物化视图，这使得 Transform 变得非常容易，成本更低。最后，Built-in Functions 可以轻松解决大量数据加工的 ETL 工作。
3. Explore
在数据经过 Transform 之后，用户需要在上面进行各式各样的查询和分析。我刚才提到，多模数据库非常重要，因为很多查询不仅仅是纯分析型 OLAP 的，也不是纯事务型的，而是需要混合型的查询能力。此外，对于 AI 工程师来说，Sampling 功能也非常重要，因为他们需要通过采样来观察数据的趋势。最后，正如刚才提到的，在有些时候算法工程师需要研究 Feature 的变化对模型的影响，因此他们需要知道一个 Feature 在不同时间点的精确数值，在普通的大数据系统中，这需要不断地存储所有 Feature 不同时间的数值，造成大量的存储浪费。Data Warebase 作为一款数据库，支持 Transaction 和 MVCC，因此有很好的 built-in 的 Time Travel 的能力，可以给算法同学提供低成本的 Feature 按时序观测的能力。
4.Retrieve
在 Retrieve 环节，最关键的是要能做多模检索 。如果没有多模检索的能力，很多应用场景几乎是无法实现的。刚才介绍的几个具体场景，也看到了越来越多的场景需要这种能力。因此，多模检索能力决定了系统在处理更复杂场景时的表现，尤其是当数据量增大时。如果数据量很小，比如只有 100 行数据，那么问题不大，但随着数据量的增加，这种能力就显得尤为重要。
Use Cases of Data Warebase：典型落地场景
接下来分享几个 Data Warebase 落地案例。简单来说，可分为六大类。但从抽象层面来讲，其实只有两大类型。
依靠多模能力精简架构(Simplicity)：例如 AI Agent 和 Feature Store ， 未来大部分服务将依托 AI Agent 进行智能交互，而 AI Agent 需要一个强大的 Data API，Data Warebase 提供了强大的多模查询、极致弹性、以及分支管理的能力，能够很好地支持 AI Agent 的场景。
实时决策 (Instant Decision )： 例如超实时高吞吐的金融行情分析和风控，高弹性高吞吐的运维可观测性场景，车联网车机信号实时监控与故障诊断需求，以及实时搜索广告推荐系统。
关于 AI Agent，之前已经解释过不再赘述。Instant Decision 下的一个大类是可观测性。可观测性从广义上来说，万物似乎都具备可观测性，但这个范畴太宽泛了。而狭义的可观测性，主要是指对日志、标签和行为的分析 。以前，这个领域主要是时序数据库的天下。然而，大家后来发现时序数据库存在一些局限性，比如它只能做数据的 Append 插入，不能 Update，也无法进行文本检索和复杂的分析查询。
于是，大家开始使用 ES 和 ClickHouse。不过，ES 最大的问题是冷热数据分层的挑战(冷数据需要重新加载，否则无法直接访问)，而且它主要只能用于标签过滤和文本检索。ClickHouse 在大宽表上做多维分析的性能非常不错，但它的 Upsert 能力和 Join 操作性能并不理想。更重要的是，在可观测性场景下，弹性能力至关重要。因为在系统正常运行、没有报警或行情平稳时，可能只有小几个人在观测;而一旦系统出现问题或者来了一波新的金融行情，会有更多的人涌入查看，系统很容易崩溃。因此，云上的弹性能力非常重要。Data Warebase 因为使用了最领先的存算分离架构，可以做到业务无感情况下的秒级弹性扩缩容。
所以，其实可观测性场景即需要 Simplicity 又需要 Instant Decision 的能力。
而在金融领域，像 Trading、Fraud Detection，以及车联网领域中的信号收集、检测和报警，以及 Ads、Search 和 Recommendation 这几类场景中，它们都属于需要 Instant Decision 的场景。接下来介绍几个具体案例。
案例一：AI Agent
未来的 AI Agent，不需要对接多个 MCP，而是连接一个多模数据库。用一个数据库，一个 MCP 接口，极大降低 LLM 大模型的智力和推理的门槛。
首先是 AI Agent。未来，所有的服务都将提供 AI Agent 的服务 。以我们的产品为例，会出现至少两个大的 MCP 出口。
第一个 MCP 是数据库本身 。 我们用标准的 PG MCP 就可以把数据库服务暴露给大模型调用。客户既可以使用 SQL 来查询，也可以通过大模型来访问我们的产品，使用 Data Warebase 会变得更加简单。
第二个 MCP 是平台服务 。 除了数据库本身，Data Warebase 还提供平台服务(扩缩容，监控，报警)，这些平台服务也可以对外暴露 MCP 服务。这样，客户的 OPS 系统可以通过 AI 来智能了解数据库的运行情况。运维同学可以直接提出具体的问题，比如“今天一天中哪个时间点的 Workload 最高?”“今天的 Workload 比昨天高了多少?”“有哪些指标有些异常?”.
平台服务以前主要是通过 SDK 来实现的，但现在都转向了 MCP。未来应用层的业务逻辑会越来越薄，业务应用慢慢的都会变成只由前端界面、AI 和数据这 3 层架构来支持。
另外，我刚才提到的 Data Warebase 的混合查询能力非常强。用户再也不用担心要管理多个数据库，一个数据库就能搞定大部分的事情。此外 Data Warebase 还支持 Scale to Zero，也就是说，当没有连接和 Activity 的时候，计算资源可以直接释放掉。同时，它也能支持无限的水平扩容。最后，刚才提到的存算分离架构能够很好地支持数据 Snapshot 的快速复制，可以很好地满足 AI Agent 在 Branching 上的能力需求。
案例二：金融行业案例
第二个案例是金融行业的一个场景，你可以把它理解为一个交易系统。这个系统会接收到大量的行情数据，这些数据需要在客户端以最快的速度展示(Freshness 在亚秒级)，因为每当有一个交易完成后，后面会有大量的 AI 机器人做分析和交易决策。所以，数据输入必须是 Instant 的，要求“写入即可见”，并且查询量非常大。另外，它的查询也比一般的点查复杂的多。它不仅仅是简单地查看一行行数据，而是需要通过大量的标签进行过滤做多维分析，以便能够只观测某些特别关注的标签并据此做出决策。这也是为什么我之前提到可观测性的范畴非常大，从理论上讲，这也是可观测性的一个应用场景。
在这种能力要求下，传统数据库能够满足的是 Subsecond Level 的新鲜度和高吞吐量，但它无法满足多维分析的需求。而 Search 和 Lakehouse 架构能够在一定程度上满足分析需求，但它们无法同时满足高吞吐量和低延迟的要求。所以，正如我之前所说，Data Warebase 的这种真正的混合能力，也就是多模查询的能力，在这里就显得非常重要。
案例三：车联网案例
第三个案例是车联网。我们接入了一个头部的车联网用户，它的车机信号传输频率非常高，每辆车每秒都会上传车机信号，100 万辆车就意味着每秒有 100 万条数据涌入。以往，这些数据进来后，我们只是将其存储起来，以满足监管要求。但如今，随着电动车越来越受欢迎，情况发生了变化。大家都知道，电动车的系统升级是通过 OTA 来实现的，而不是像传统汽车那样需要开到车厂，插上线进行升级。这些电动车会不断地推送软件更新，而这些软件更新可能会对车机产生影响。所以，现在数据进来之后，我们还需要对某些关键列进行分析。即使在不升级的时候，也需要对核心车辆信号做实时监控报警，确保车辆和车主的安全。
以前的分析型数据库可以统计一些聚合值，但不擅长明细查询，因为明细查询的时候可能需要对非主键字段做过滤，需要真正的全局二级索引，而这种索引一般也只有 OLTP 数据才具有。所以，这种场景非常适合使用多模数据库。
案例四：广告和推荐案例
第四个案例是广告和推荐。广告的量比推荐大，因为大部分广告公司收集了众多 APP 的流量，且每次做决策时的查询逻辑也比较复杂。当我们在使用各种手机应用时，每次跳转到下一个界面，其实都是一个决策过程。这些决策过程中查询的数据量非常庞大。推荐系统也是如此，现在几乎所有的推荐系统，尤其是电商平台的推荐系统，都需要相对实时地进行决策。
例如，当你在电商平台上搜索 1000 元的手机时，系统会在下一秒为你推荐 1000 元左右的手机，而不是 1 万元的手机，因为系统已经根据你的搜索范围做出了精准的判断。对于新用户，系统可能一开始对你不了解，但一旦你购买了某一类药品，系统就能根据这一行为推断出你的大概年龄段和性别，从而进行个性化推荐。后续的推荐决策会变得更加积极主动，进一步提升用户体验。这种实时性和个性化的能力，是现代推荐系统区别于传统推荐系统的重要特征。这种推荐系统同样需要实时写入，且高频分析查询。
总结一下，今天主要分享了在 Data for AI 时代我观察到的现象和思考，以及 Data Warebase 的概念。最后，介绍了 Data Warebase 如何满足 AI 应用在 Ingestion、Transform、Explore 和 Retrieve 等方面的需求。
Data Warebase 与现有技术的差异与优势
最后再简单提一下很多小伙伴过来询问 Data Warebase 与现有技术的差异与优势。
1. Data Warebase 与 HTAP 的区别
首先从客户的角度来看，不应该常常要关心去区分 TP 和 AP，因为 SQL 本身是能写出来 TP 和 AP 的 Query 来的。只是在数据量大的时候，一个系统要么是 TP 性能好一点，要么是 AP 的性能会好一点。所以 HTAP 要求的是一个系统能够在 TP 场景和 AP 场景下性能都非常好。
真正的 HTAP，不止是简单 TP+AP 的结合，更多的是存储，索引，和查询优化器一体的结合。
其次，HTAP 的核心在于是否能真正实现 TP 和 AP 的无缝融合。如果只是将 TP 系统的数据同步到 AP 系统去满足报表查询，这并不算真正的 HTAP。真正的 HTAP 需要具备以下特点：
真正的 HTAP 数据库应该既能独立作为一个 OLTP 数据库，也能独立的作为一个 OLAP 数据库，还能变成一个混合的 HTAP 数据库。
低延迟：数据能够即时进入系统，无论在什么模式下，数据写入即可见，并且立即能够无延迟的服务 AP 查询。
高吞吐：能够支持高吞吐的查询。
复杂查询：支持完整的复杂的 OLAP 分析查询。
如果没有复杂查询的需求，那么基本可以通过传统的 TP 系统解决。只有像金融行情分析这样的场景，需要数据实时写入和高吞吐的复杂查询，才是真正的 HTAP。Data Warebase 因为具有行列混存的能力以及丰富的索引，天然的支持 HTAP，用户做了合理的存储和索引的配置后，所有查询 SQL 都能在物理极限上拿到最高的吞吐和最低的延迟。用户再也不用为不同场景的数据库选型而担心。
2. Data Warebase 与流批一体的区别
流批一体的终极解法，不是 Flink，而是数据库的实时增量物化视图。
流批一体是我们最早在阿里搜索主搜时提出的，当时用 Flink 做实时处理，再用批计算，后来我们用 Flink 的批处理统一了流和批的计算框架和 SQL。但 Flink 运维难、成本高，我们认为物化视图是解决流批一体的最佳方案。大部分数据系统只是支持全量物化视图和非常有限的增量物化视图(例如双表的 join，大部分数据系统只能通过全量物化视图来做)。Data Warebase 实现了实时增量物化视图，这使得真正的流批一体最简单的方案成为现实。
3. Data Warebase 与湖仓一体的区别
关于湖仓一体，简单来说，就是让仓和湖之间的数据能够打通，流转起来，最终让仓可以直接访问湖的数据，做一些查询加速。其次要求数据仓库能够对接标准的湖存储，做外表的查询，计算和写入。
刚才讲的是数据库的趋势。如果放大到大数据的趋势，只有一件事值得关注：未来数据湖的标准只有一个，就是 Iceberg。 因为全球两大数据巨头 Snowflake 和 Databricks 都在围绕 Iceberg 展开。Snowflake 的存储一开始就是基于 Iceberg 设计和实现的，Databricks 之前有自研的 Delta Lake，后来收购了 Iceberg 背后的公司 Tabular。所以我们可以预见，未来这两个世界最大的数据巨头都会围绕着 Iceberg 来布局数据湖生态。
结 语
数据库和大数据演进到 Data Warebase，不只是架构革新，更是为 AI 工作流打下坚实的数据底座。在新一轮的 AI 浪潮中，谁拥有更完整更强大的 Data API，谁就拥有更高的智能上限。
作者简介：
王绍翾 ，ProtonBase 创始人兼 CEO。曾在 Facebook 负责在线基础设施开发，并深度参与了 Memcache，RocksDB 和自研分布式图数据库 TAO 的开发，该数据库支撑了 Facebook 每秒几十亿次的海量数据查询。2015 年加入阿里巴巴，先后负责两项核心工作：一是用 Flink 打造了搜索推荐相关的数据处理与 AI 机器学习平台，二是负责达摩院机器智能工程团队，包括视觉 / 语音 /NLP 等 AI 场景的模型训练，推理，以及向量检索技术。2021 年开始创业，创立“小质科技”，推出了自研产品 ProtonBase，一款融合数据库与数据仓库能力于一体的新一代 Data Warebase(Data Warehouse + Database)。