Apache Doris 5.0：湖、仓、向量、JSON，凭什么塞进一条 SQL？
先讲一件小事，一件在很多公司每天都在发生、但没人愿意承认的小事。
你问客服机器人：「我上周买的那个东西还能退吗？」它秒回你一段热情洋溢的话，还贴心地附上了商品链接。你点进去——该商品已下架。
问题出在哪？模型没坏，SQL 没写错，检索也没超时。真正的原因是：下单状态和库存在 OLAP 里、商品文档在对象存储里、语义检索在向量库里、关键词在 ES 里。这四套系统各有各的更新时间、各有各的版本号、各有各的权限边界。向量库里那件商品的 embedding，是它还在售时算的。于是它被"过期召回"，然后大模型非常自信地把一个错误的答案，包装成了一段礼貌的话。
每套系统都解决了一个问题，却把数据一致性、版本对齐、权限治理和结果融合，统统留给了用户。
这句话不是我说的，是 Apache Doris 官方 2026 年 9 月 4 日那篇文章里的原话。而这篇文章抛出来的东西，就是今天的主角——Doris 5.0 的多模湖仓。
先把版本说清楚，不然容易被带偏
最近不少媒体写「9 月 4 日 Apache Doris 5.0 发布」。这话不严谨，我得先泼一盆冷水，不然你照着去下载会一脸问号。
截至 2026 年 9 月 10 日，Doris 官网下载页的真实情况是：
| 版本 | 状态 | 说明 |
|---|---|---|
| 4.1.3 | Latest | 当前最新，官方维护分支 |
| 4.0.8 | Stable | 上一个稳定分支 |
| 4.2 | 开发中 | 预计 2026 年 9 月底 GA |
| 5.0 | 开发中 | 预计 2026 年底（官方跟踪单写的是 2026-11） |
所以准确的说法是：9 月 4 日发布的是 Doris 5.0 多模湖仓的路线图与能力矩阵，不是一个可以 wget 下来的安装包。这个路线图由社区在 GitHub 上的 #66418 号跟踪单（2026 年 8 月 4 日由 morningman 发起）维护，明确列出了「现在已经支持什么、4.2 支持什么、5.0 支持什么」。
我个人其实更喜欢这种"先把路线图摊开给你看"的做法。数据库这种东西，最怕的不是功能少，而是你按今年的文档做了架构决策，明年它告诉你路线变了。
所以 Apache Doris 到底是个啥
一句话版本：一个基于 MPP 架构的、实时的分析型数据库，兼容 MySQL 协议。
它最早是百度搞的（内部叫 Palo，2018 年捐给 Apache），后来被美团、小米、快手、字节这些公司一路"用成了"国产 OLAP 的事实标准之一。官网现在的说法是服务 10,000+ 用户。
架构极简，只有两类进程：
- FE（Frontend）：接请求、解析 SQL、管元数据、管节点。生产环境多副本部署，有 Master / Follower / Observer 三种角色。
- BE（Backend）：存数据 + 执行查询，多副本。
部署形态有两个选项：存算一体（shared-nothing，FE/BE 混部，本地磁盘，延迟最低，运维最省事）和存算分离（无状态计算组 + S3/HDFS/OSS 共享存储，弹性伸缩、负载隔离）。官方给的建议很实在：规模可控、想省事就选存算一体；要弹性就选存算分离。
它的硬指标是：查询延迟 < 1 秒、数据导入 秒级、并发 10,000+ QPS、单集群 PB 级。
几个真正让它"快"的点
- 列式存储 + 高压缩比：按列编码压缩，只扫需要的列。针对 10,000+ 列的超宽表做了专门优化。
- 向量化执行引擎：内存结构全部列式布局，压低虚函数调用、提高 cache 命中、吃满 SIMD 指令。官方口径是宽表聚合场景 5~10 倍提升。
- MPP 并行：节点间、节点内双层并行，支持大表分布式 Shuffle Join。
- AQE + Runtime Filter：跑着跑着发现计划不对，动态改。
- Pipeline 执行引擎：把多核用满，同时限制线程数，避免线程膨胀把自己搞死。
- 三种存储模型：Duplicate（明细）、Aggregate（预聚合）、Unique（主键，支持行级更新）。
- 一堆索引：Sorted Compound Key、Min/Max、BloomFilter、倒排索引、向量索引。
最后这两个索引，是 Doris 这几年从"数仓"往"AI 数据栈"挪的关键。倒排索引管关键词，向量索引管语义召回，再配上 VARIANT 类型（原生吃动态 JSON，配合 Light Schema Change 秒级加字段），混合检索就成了。
5.0 到底要干嘛：四个开放格式，一条 SQL
这是本文的重点。Doris 5.0 的核心思路一句话就能说完：
统一的重点放在查询和执行，而不是要求所有数据进入同一种存储。
也就是说：数据你爱放哪放哪，Iceberg 放长期事实、Paimon 放实时更新、Lance 放 AI 数据集，我 Doris 负责在同一个 SQL 里把它们查明白。
能力矩阵（据 #66418 跟踪单与官方 9 月 4 日文）：
| 数据源 | 现在（≤ 4.1） | 4.2（2026-09） | 5.0（2026-11） |
|---|---|---|---|
| Iceberg | 完整读写：全类型 Catalog、V1/V2、Time Travel、系统表、INSERT/OVERWRITE/CTAS、DELETE/UPDATE/MERGE、分区与 Schema 演进，V3 部分支持（Row Lineage、Deletion Vector） | 新增 Variant 读写（覆盖 Iceberg V3 的 plain 与 shredded 两种布局） | — |
| Paimon | 只读：Catalog 访问、增量查询、Time Travel、Branch/Tag、系统表、Deletion Vector 读 | 完整 DML（INSERT / UPDATE / DELETE / MERGE / DDL）+ Variant 读写 | Paimon 索引读取（#65086） |
| Lance | — | 原生读取与检索：Catalog、并行扫描、列裁剪、谓词下推、向量与全文检索、向量索引管理（#66340） | — |
| Fluss | — | — | Fluss Catalog：日志表、主键表、分层表（Fluss 实时增量 + Paimon 历史 Union Read）（#66399） |
| ADBC | — | — | ADBC Catalog：通过 ADBC / Arrow Flight SQL 访问外部数据源（#66331） |
数据类型层面，Variant / Vector / GEO / Blob 进入统一执行。
翻译成人话，有三个变化最值得你记住：
第一，湖表从"能查"变成"能改"。 Paimon 在 4.1 里只能读，4.2 之后 INSERT、UPDATE、DELETE、MERGE、DDL 全都能写。这意味着你不用再"先落 Doris 内表，再额外建一条同步链路"了。实时业务事件、工具调用参数、模型结果，直接写成开放表资产。
第二，向量和全文检索下沉到湖里。 Lance 在 4.2 里拿到了向量检索和全文检索。以前你要检索多模态数据，得复制到一套专门的索引系统；现在不用了。
第三，实时和历史的边界被抹掉了。 Fluss 的 Union Read 让"刚刚发生的增量"和"分层到 Paimon 的历史"看起来像同一张表。对 Agent 来说，它拿到的上下文既有完整历史，也有刚刚发生的变化——这才是我开头那个"已下架商品"问题的正经解法。
顺带说一句，当前 4.1.3 版本本身也在往前走，几个新东西挺实用：支持 Python UDF/UDAF/UDTF（#63387）、Stream Load 支持 zstd 压缩、湖仓侧给 Iceberg/Hive 的 Parquet/ORC 写入加了 LZ4 压缩。
谁在用，以及用出了什么数
讲架构容易空，看数字最实在。以下是官方博客与公开分享里的真实案例。
快手：4 亿+ DAU 的短视频平台，广告数据分析原本是 ClickHouse + Elasticsearch 的混合架构，慢查询率飙到 35%、平均耗时 1.4 秒。换成 Doris 之后：查询性能提升 20%~90%、写入吞吐提升至 3 倍（单表 300 万行/秒）、存储效率提升 60%、慢查询率降到 < 5%、平均问题排查时间降低 80%，水平扩容效率比 ES 高 10 倍以上。
更狠的是 A/B 实验那一摊：快手把指标生产从 Spark 迁到 Doris，提速 145 倍，资源消耗下降 72%。顺手还刷新了全球最大单 Doris 集群的纪录——2000 节点、10 万核（2026 年 8 月 12 日官方博客）。
美团：用 Doris 替换掉 Hadoop + Kylin + Druid 的多引擎栈，统一到 300+ 集群、数十 PB 的规模（2026 年 7 月 31 日）。
小米：40+ 集群，每天 5000 万次查询，PB 级数据（2026 年 2 月 27 日）。
网易游戏：把 6 套专用系统合并到 Doris，日查询量 1500 万。
MiniMax：日志系统从 Grafana Loki 迁到 Doris，PB 级规模、99.9%+ 可用性，10 亿条日志的关键词与聚合查询 2 秒内返回，写入吞吐 10 GB/s，靠 5:1 压缩 + 分层存储把存储成本砍了 70%。
腾讯音乐：ES → Doris，整体运维成本降 80%，同一份数据从 697.7 GB 压到 195.4 GB（省 72%），写入快 4 倍，导入时长从 10+ 小时缩短到 3 小时内，告警从每天 20+ 次降到每月个位数。
字节跳动：用 Doris 4.0 的混合检索撑起 10 亿+ 向量的搜索系统。
这几个案例放在一起，能看到一条很清晰的主线：大家都在做减法。不是从 Doris 换到别的，而是从"五六套系统"收敛到"一套"。
初体验：先跑一条 SQL 感受一下
部署这块，站内已经有一篇 《Docker 部署 Doris》 讲得很细，这里不重复。单节点体验版也可以直接用官方镜像 apache/doris 起，具体参数以官方 Quick Start 为准。
起好之后，两件事：
- 浏览器打开
http://localhost:8030/进 Web UI，用户名root，密码为空。 - 用任意 MySQL 客户端连 9030 端口（Doris 兼容 MySQL 协议，这点对老 DBA 极其友好）：
mysql -h 127.0.0.1 -P 9030 -uroot然后跑一条"混合检索"的 SQL，感受一下 5.0 想做的事：
SELECT id, title, brand, sales_count
FROM products
WHERE category_id = 1 -- 结构化过滤
AND body MATCH '透气 轻量' -- 全文关键词
AND match(query_vector, '[0.12, -0.08, ...]') -- 向量语义召回
ORDER BY sales_count DESC
LIMIT 10;关键词、语义、结构化条件、聚合排序，全在一条 SQL 里。没有跨系统搬运，没有结果拼接，没有"这边的 ID 和那边的 ID 对不上"。
如果你手上有 Lance 数据集，5.0 之后（4.2 起 Lance 可读）还能这么玩：
SELECT episode_id, road_type, weather, model_version, _distance
FROM vector_search(
"table" = "lance_ai.autodrive.scene_episodes",
"column" = "scene_embedding",
"query_vector" = "[0.12, -0.08, 0.31, ...]",
"top_k" = "200",
"metric" = "cosine",
"filter" = "road_type = 'urban' AND event_time >= '2026-08-01'",
"use_index" = "true"
)
ORDER BY _distance ASC, episode_id;注意那个 filter——它是检索前过滤：先用业务条件把搜索空间收窄，再生成向量候选。这个顺序很重要，顺序反了，你召回的"相似场景"很可能业务上根本不相关。
几句我的看法
Doris 5.0 这个方向我认同，但有句话得说在前面："一张表 + 一个引擎搞定一切"是所有数据库厂商都在讲的故事，Snowflake、EDB、DuckDB Labs 今年也都在往同一个方向拐。这种合流说明方向大概率是对的，但不代表你可以无脑上。
我的建议是：如果你现在正被"向量库 + ES + 数仓 + 对象存储"四套系统的一致性折磨，那 4.2 / 5.0 这条线值得盯紧；如果你只是想跑个报表，4.1.3 老老实实用着就行，别为了追新版本把自己坑进去。
另外提醒一句：4.2 和 5.0 都还在开发中，跟踪单里明确写了「Scope may still change before release」。生产环境请等 GA，别拿路线图当排期表。
进阶
本文只是带你从"过期召回"这个现象出发，看清了 Doris 5.0 想解决的问题。想要深入下去，有几个方向值得继续：Iceberg V3 的 Variant 与 Deletion Vector 原理、Paimon 主键表的写入语义、Lance 向量索引的构建与调优，以及 Fluss Union Read 的实时性边界。
更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。