当前位置： 首页  >> 科技数码  >> 查看详情

为什么Data Warebase是AI时代首选Data API？

来源： 环球科技网  日期：2025-06-09  责编： 殷绪江  
分享:
   【环球科技网】本文内容整理自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概念。就像我们使用Gi 一样，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 Retri：下一代智能检索范式
   什么是Multi-Modal Retri？ 它的核心含义是：在数据检索过程中，不再局限于某一种查询方式，而是融合结构化、半结构化、非结构化以及向量检索等多种方式，实现更智能、更全面的查询体验。这项能力对于AI应用尤其重要。因为Agent面对的问题往往不是“查一条信息或者一个向量”，而是需要对多个模态、多维数据进行理解、关联和调用——这就需要底层数据库具备原生的多模处理能力。
   以“智能城市”为例，如果我们需要在监控系统中搜索某辆车或某个人，最基础的方式可能仅涉及向量检索——比如通过图片或视频帧进行相似度匹配。但一旦我们引入更具体的查询条件，比如“某个十字路口”“某个下雨天”“某个时间段”，“和某个车的图片相似”的场景就会涉及到更多模态的信息：
   ·“十字路口”是位置标签；
   ·“下雨天”是环境标签；
   ·“时间段”是结构化数据；
   ·“车的图片”会被 embedding 成向量数据；
   这类查询就不再是单一模态的检索，而是需要同时融合结构化数据+标签信息+向量检索的Multi-Modal Retri（多模态检索）。再比如在社交推荐场景中，人与人之间的推荐可能通过 Embedding 大部分特征成为向量，再靠向量相似度检索来实现。但如果用户添加了“同一个城市”或“同一活动”的过滤条件，就引入了地理位置或事件标签，从而升级为真正的多模态检索任务。
多模态检索对架构提出了更高要求
实现Multi-Modal Retri，意味着系统必须同时处理：
   ·结构化数据；
   ·半结构化数据（如 JSON）；
   ·向量数据。
在传统架构中，不同类型的数据往往被存储在不同的系统中：
   ·结构化数据用关系数据库或数仓；
   ·半结构化数据的存储和检索用NoSQL；
   ·向量检索用向量数据库。
   这样的问题是当我们要执行一个Top 100推荐任务时，分布在多个系统中的结果很难直接进行Join操作，因为性能很差。于是，我们只能尝试从每个系统中提取大量结果（如Top 100万），再在应用层合并关联处理。这个过程不仅开销极大，而且也从理论上无法保障拿到最后正确的Top 100。这正是Hybrid Database（混合型数据库）登场的理由：将多种模态数据统一存储与检索，消除系统间的分割，让多模态查询变得自然、实时且可扩展。
AI Workflow的五个关键需求
   为了支撑真正的AI工作流，从数据获取到结果交付，系统必须满足以下五大核心能力：
   1.Fresh Data（数据新鲜性） 模型必须基于最新的数据进行推理，数据滞后将严重影响AI产出质量。
   2.Instant Retri（即时检索）需要毫秒级的数据访问能力，以满足实时响应和推荐需求。
   3.High Concurrency（高并发）特别是在面向C端或Agent场景中，系统需能支撑成千上万用户同时访问，具备高吞吐能力。
   4.Fast Analytics（快速分析）不仅要能存储数据，还要能快速完成聚合、过滤、排序等分析任务，为AI决策提供支持。
   5.Simplicity（易用性）整个系统要具备良好的开发者体验和管理简洁性，避免多工具链、多平台切换带来的复杂性。
   这些能力构成了现代AI应用工作流的基础保障。只有构建一个满足实时性、融合性、高并发与易用性的数据平台，才能真正释放大模型和Agent的智能潜力。
为什么传统数据库和数据仓库难以满足AI Workflow的全部需求？
   前面提到的那些产品之所以备受欢迎，本质上是它们各自解决了AI工作流中的关键痛点，但仍存在明显局限：
   ·数据库：擅长处理Fresh Data（数据新鲜性）和Instant Retri（即时检索），适用于实时写入和快速查询场景。但其大多基于单机或简单主从架构，难以支撑大规模的高并发访问。
   ·数据仓库（如 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）
 



作者简介：

   王绍翾，ProtonBase创始人兼CEO。曾在Facebook负责在线基础设施开发，并深度参与了Memcache，RocksDB和自研分布式图数据库TAO的开发，该数据库支撑了Facebook每秒几十亿次的海量数据查询。2015年加入阿里巴巴，先后负责两项核心工作：一是用Flink打造了搜索推荐相关的数据处理与AI机器学习平台，二是负责达摩院机器智能工程团队，包括视觉/语音/NLP等AI场景的模型训练，推理，以及向量检索技术。2021年开始创业，创立“小质科技”，推出了自研产品ProtonBase，一款融合数据库与数据仓库能力于一体的新一代Data Warebase（Data Warehouse+Database）。






 

标签：科技黑科技浏览器软件

【免责声明】：
   凡注明 “环球科技网” 字样的图片或文字内容均属于本网站专稿，如需转载图片请保留 “环球科技网” 水印，转载文字内容请注明来源“环球科技网”；凡本网注明“来源：XXX(非环球科技网)”的作品，均转载自其它媒体，转载目的在于传递更多信息，并不代表本网赞同其观点和对其作品内容的实质真实性负责，转载信息版权属于原媒体及作者。如转载内容涉及版权或者其他问题，请投诉至邮箱；1978751725@qq.com 
本网公告
环球科技网从不发布负面新闻资讯，也绝不会发布负面信息。如发现负面信息链接请甄别是否为环球科技网所发。
本网系北京伯乐传媒广告有限公司主办、所有。本网唯一域名（www.hqkjw.cn），其它域名链接均为假冒。望广大网民及企业主认真甄别。

咨询、采访、合作、投稿等请致电：13911566744（含微信）
     
 
 


 

相关新闻

  • 戴尔PowerFlex：软件定义的终极解决之道 戴尔PowerFlex：软件定义的终极解决之道 2025-01-13 15:59:55

       【环球科技网】随着数字化转型步伐的加速,数字化的作用不断提升,IT基础架构的重要性也随之水涨船高。企业都希望拥有一套稳定、易管、灵活扩展的IT基础架构,以应对日益复杂且快速变化的业务需求。    然而,现实和理想之间往往存在巨大的落差……    现实之中的数据中心大... [阅读]

  • “软件工程造价”跻身城建类职业院校课程体系 “软件工程造价”跻身城建类职业院校课程体系 2024-12-06 13:53:29

       【环球科技网】关内容设计、开发，被工信部纳入人才培养工程课程体系。至2024年9月底，共有超过20000人参加培训，16000余人通过考试并获得“软件工程造价师证书”。软件工程造价师熟练掌握了软件开发、运维等信息化项目投入工作量及工程造价的估算方法，能够相对科学合理地为信息化项目的概算编制、预算审批、工程结算... [阅读]

  • 英伟达RTX 5090 D显卡被曝和原版5090“在硬件上没有什么区别” 英伟达RTX 5090 D显卡被曝和原版5090“在硬件上没有什么区别” 2024-11-27 09:57:19

        11月26日，Chiphell论坛消息人士panzerlied昨今两日在回复有关英伟达GeForce RTX 5090 D显卡的帖子时表示“5090和 5090D在硬件上没有什么区别”，并认为两者在同频下游戏性能“没啥区别”。    这位消息人士还提到，英伟达将在... [阅读]

  • openEuler开源五年树立操作系统产业新里程碑，全球化发展再加速 openEuler开源五年树立操作系统产业新里程碑，全球化发展再加速 2024-11-15 20:19:20

       【环球科技网】11月15日， 以“以智能，致世界”为主题的操作系统大会2024在北京召开，本次大会由openEuler社区、全球计算联盟共同主办，旨在汇聚全球产业界力量，推动基础软件根技术持续创新，共建全球开源新生态。    openEuler开源五年，在商业、技术及生态上全面发展，202... [阅读]

新闻排行榜

热门新闻

推荐新闻