AI 这一年模型卷完卷 AgentAgent 卷完卷数据现在终于卷到数据库头上了。最近两周数据库圈子发生了一件挺有意思的事。6 月 16 号Databricks 在 DataAI Summit 上高调发布了 LTAP 架构CEO Ali Ghodsi 说他解决了一个 40 年的老问题把事务处理和数据分析统一到湖上的一份数据里。13 天后的 6 月 29 号OceanBase 发布了湖库一体的 AI 数据库。CTO 杨传辉的表述更直接“AI 数据库的一体化不是某一类数据库胜出而是所有数据库都在向交易分析搜索向量AI 的统一平台收敛。”两家几乎同时亮牌都在讲湖库一体都在讲 Agent 时代都在讲消除数据搬运。但仔细看完两边的技术方案之后我发现它们走的是两条完全不同的路。一个从湖出发往库走一个从库出发往湖走。出发点不同骨子里的能力结构也不一样。这篇文章聊一聊这两条路到底差在哪儿以及对于真正要落生产的企业 AI 来说哪些能力是绕不过去的。数据库的用户正在从人变成 Agent在拆两家的方案之前有一个背景变化必须先讲清楚因为它直接决定了我们用什么标准来评价一个 AI 数据库。过去数据库是给人用的。工程师写 SQL 查一条订单分析师跑一张报表DBA 做个备份恢复。这些操作是确定性的、低频的、有人看着的。现在变了。Agent 成了数据库的主要消费者它们的行为跟人完全不一样全天候不间断地调数据不是上班时间查一下是 7×24 持续读写。混合检索不是只查结构化字段而是同时检索文本、向量、JSON、图一次拿到完整上下文。会犯错而且犯错的方式是直接改了线上数据。数量爆炸蚂蚁的灵光平台几个月就承载了 3000 多万个闪应用妙思在内部上线了上万个应用平均每个只有百来行数据。Databricks CEO Ali Ghodsi 自己也说了一个数据他们平台上现在大约 80% 的数据库实例是被 Agent 创建的不是人创建的。所以评价一个 AI 数据库得看它能不能同时回答好这几个问题数据一致性在 Agent 高并发读写下能不能扛住多模态数据能不能统一管理Agent 试错会不会搞坏生产环境海量小库能不能低成本共存这些能力有没有经过生产环境的真实验证带着这几个问题来看两家的方案。Databricks LTAP从湖出发给湖加上事务引擎Databricks 的路线非常清晰。它原来就是做湖仓的Spark、Delta Lake、Unity Catalog 是它的地基。LTAP 是在这个地基上加了一个事务引擎 Lakebase。Lakebase 是什么简单说就是一个跑在对象存储上的 Serverless Postgres。Databricks 去年花了大约 10 亿美金收购了 Neon一家做 Serverless Postgres 的公司然后把 Neon 的存算分离架构和自己的 Lakehouse 做了集成。LTAP 的核心设计思路是在存储层统一而不是在引擎层统一。Postgres 负责事务Lakehouse 引擎负责分析两个引擎共享一份底层数据Delta/Iceberg 格式存在对象存储上不再需要 CDC 管道在中间搬数据。这个思路很聪明让每种负载用最合适的引擎处理通过共享存储层消除数据搬运。公平地说Databricks LTAP 有几个点做得确实不错存算分离和 Scale-to-Zero。这个对 Agent 场景很关键。每天 1200 万次数据库启动闲时资源归零这个弹性能力很强。Git 风格的分支。最新版 Lakebase 也支持数据库分支和快照了可以从生产库拉一个分支做实验。开放格式。数据以 Delta 和 Iceberg 格式存储不被锁定在某一家的专有系统里。Lakehouse//RT。新出的实时查询引擎在 Delta/Iceberg 表上做到亚秒级延迟解决了分析层的低延迟问题。这些能力对于数据分析、BI 看板、轻量级应用后端是够用的。但问题来了。两条路线天然的能力侧重不同Databricks 从湖出发OceanBase 从库出发。出发点不同天然擅长的东西就不同。Databricks 的底子是湖仓。它做数据分析、做 ETL、做机器学习训练全球范围确实是标杆。事务处理这一块是它通过收购 Neon、推出 Lakebase 之后才补上的能力时间还不长。这不是好坏的问题而是每条路线都有自己的起点。几个维度上的差异值得注意事务架构不同。Lakebase 基于 PostgresPostgres 是优秀的单机事务数据库ACID 能力成熟。但它不是原生分布式的。当 Agent 需要跨多个分片做强一致的事务操作时单机事务语义和分布式事务语义的差异就会显现出来。多模态能力的深度不同。Lakebase 新增了向量搜索和全文搜索能力但底层仍然是 Postgres 的表结构。像结构化字段、文本、图片、音视频、向量在同一张表里统一存储、统一事务、统一权限这种原生多模态的设计思路两家走的方向不一样。生产场景的积累不同。Databricks 的强项在数据分析和 AI 训练场景Lakebase 目前的客户主要是互联网应用后端。而 OceanBase 在金融核心系统、大型银行、保险、证券这些对一致性和可靠性要求最苛刻的场景里已经积累了十几年。这些差异不是谁好谁差而是从湖出发和从库出发这两条路线的天然起点不同。OceanBase 湖库一体从库出发把湖的能力长进来OceanBase 走的是相反的路线。它原来就是做数据库的而且是在中国最严苛的金融场景里被打磨出来的数据库。15 年来做的核心事情就是事务一致性、分布式可靠性、弹性扩展这些底层能力。现在它要做的是在这些已经验证过的能力之上把数据湖的开放、海量、多模态能力加进来。从技术架构上看OceanBase Lakebase 的设计跟 Databricks 有一个根本区别它是在引擎层做融合不只是在存储层。具体来说有几个能力我觉得值得单独拎出来看多模表。这个我觉得是这次最值得关注的设计。一张表里可以同时放结构化字段、JSON、文本、图片、音视频LOB、向量。用户看到的还是一张表但背后非结构化数据跟结构化数据在同一套事务、权限、元数据、版本管理体系里。你想想一张合同表里能同时存合同编号、合同 PDF、正文摘要、关键条款 JSON、摘要向量、风险标签。这些过去散落在业务库、对象存储、搜索引擎、向量库里的东西现在在一张表里搞定了。AI 列。在多模表基础上还有一个 AI 列的概念。数据写入后可以在库内直接生成摘要、标签、向量等结果不需要把数据导出到外部做 Embedding 再写回来。更重要的是它保证了事务一致性一批数据的向量化要么全部成功要么全部失败。做过 RAG 的人应该对这个深有体会向量化任务跑一半挂了一半旧向量一半新向量后面召回质量就变得很玄学。混合搜索。关系过滤、全文搜索、向量搜索、图搜索在引擎层统一完成一条 SQL 组合执行。数据库先缩小范围做粗排模型只处理高价值候选。在 VectorDB Benchmark 上同等召回率下向量搜索性能领先 Milvus、PGVector 和 Elasticsearch。混合搜索用 MSMARCO 数据集测性能比 Elasticsearch 好 30% 以上。Fork Database。这个能力跟 Databricks 的 Git-style 分支思路类似但在生产场景里验证得更深。蚂蚁的阿福服务上亿用户的 AI 健康应用在做 Agent 评测的时候需要十几个 feature 分支以周为单位并行迭代每个分支都需要完整的数据环境做评测。Branch 能力可以毫秒级创建数据沙箱5 分钟拉齐一个评测环境用完直接销毁。Agent 改错了丢掉分支从主干重新拉就行。海量逻辑表。这个是针对小库太多问题给出的特有方案。灵光 3000 多万个闪应用每个应用只有百行数据如果每个都建物理表schema 直接爆炸。逻辑表让每个 Agent 看到的是独立的表底层收敛到共享物理表里配合闲时归零、按需唤醒解决海量小库的成本和隔离问题。核心差异事务一致性和生产验证说了这么多两家最大的差异到底在哪儿我觉得就两个词事务一致性和生产验证。事务一致性方面OceanBase 是原生分布式架构十几年的金融级事务能力不是从 Postgres 那里借来的。它在分布式多副本之间保持强一致在多模态数据的写入和检索之间保持事务语义在多个计算引擎共享数据的时候通过 Unified Catalog 做统一权限控制。Databricks Lakebase 底层是 PostgresPostgres 的 ACID 当然没问题但那是单机语义。当业务真的跑在分布式环境里需要跨节点事务、需要多模态数据的一致性保证、需要 Agent 在隔离沙箱里操作而不影响生产这些场景下原生分布式的 ACID 和 Postgres 套壳的 ACID 是不一样的。生产验证方面OceanBase 已经服务了 4000 多家客户包括超过 400 家金融机构近七成万亿级资产规模的银行把核心系统建在它上面。同时它是唯一同时刷新 TPC-C 和 TPC-H 世界纪录的数据库。这个不是 PPT 数字是真实生产环境里沉淀下来的能力。Databricks Lakebase GA 才几个月LTAP 发布才两周。它的分析能力毋庸置疑但事务处理能力和企业核心系统的生产验证确实需要更多时间去积累。如果说 Databricks 的 LTAP 像是为敏捷开发量身定做的快刀那 OceanBase 更像是在复杂系统里锻造出来的盾牌。对于金融级场景数据的正确性、ACID 的严格保证以及在高频并发下的极端稳定这些是没法通过单机引擎拼凑出来的得在分布式内核中一点一点长出来。一体化 vs 分层组合两种设计哲学这两家的路线之争其实也反映了数据库设计上一个很经典的哲学分歧。Databricks 选择的是分层组合。存储层统一引擎层保持独立每种负载用最合适的引擎。这个设计的好处是灵活但问题是当不同引擎之间需要共享状态、保持一致性的时候接缝处的复杂度会上来。OceanBase 选择的是引擎层融合。在一套引擎里同时处理 TP、AP、搜索、AI 计算。好处是一致性天然有保障缺点是引擎本身的工程复杂度极高。哪种更好我觉得不能脱离场景空谈。如果你的核心需求是在已有的 Databricks 生态里快速搭一个应用后端Lakebase 确实很方便。但如果你的 Agent 要进核心业务系统要碰交易数据、风控规则、合规流程数据不能错、系统不能断、故障要秒级恢复。这些场景下从库出发的路线天然有优势因为这些能力本来就是它的老本行。产品体系不止是一个引擎顺便说一下OceanBase 这次发的不只是 Lakebase 引擎而是一整套产品家族Lakebase 是底层湖库引擎。DataStudio 是数据开发治理平台覆盖数据集成、加工、治理、服务发布和资产管理。DataPilot 是面向业务人员的数据智能 Agent可以用自然语言做经营分析、归因分析、报告生成。再加上之前发布的 PowerMemAgent 记忆体、PowerRAG企业知识库和 seekdb开源 AI 混合搜索数据库形成了从底层引擎到上层应用的完整链路。写在最后湖库一体这个方向两家的判断是一致的AI 时代企业不可能继续维护一堆割裂的系统来服务 Agent。但路线不同。Databricks 从湖出发加事务OceanBase 从库出发加湖。方向一样起点不同短板也不同。对企业来说选哪条路取决于你最不能妥协的是什么。如果是分析生态和开放格式Databricks 的积累确实深厚。如果是事务一致性、生产级可靠性、和金融级场景验证这些在 Agent 进入核心业务之后只会变得更重要的东西OceanBase 的底子更厚。我个人的判断是当 Agent 真正开始接手企业的核心生产任务不只是回答问题、不只是查查数据而是写数据、改流程、做决策的时候那些在金融场景里被锤炼了十几年的能力会变得前所未有地重要。因为 Agent 不像人。人会犹豫Agent 会直接开干。这时候数据库的底线能力就是企业 AI 的安全边界。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
