Day 4｜架构与版本选择：存算一体、存算分离、Latest 与 Stable

Day 3 已经沿着一条 SQL 的生命周期认识了 FE、BE、MPP、列存、向量化与 Pipeline。今天把视角拉回到集群层，讨论数据放在哪里、计算资源怎样组织、集群如何扩容、版本怎样进入生产。

这些决定会影响未来数年的性能上限、成本结构、故障边界和升级难度。参数调优能够改善局部问题，架构形态会决定问题从哪里出现，以及团队有多少空间应对它。

本日学习目标

完成今天的学习后，你应当能够：

1. 准确说明 Doris 存算一体与存算分离的组件、数据路径和资源模型；
2. 理解 FE、Meta Service、Compute Group、共享存储与 File Cache 各自承担的职责；
3. 依据 P99 延迟、负载波动、数据增长、成本、基础设施和运维能力选择架构；
4. 区分存算分离、冷热分层和数据湖外表查询，避免把三个概念混在一起；
5. 理解 Latest、Stable、Major、Minor、Patch 的使用方式；
6. 建立生产升级所需的兼容测试、真实负载回归、备份和回滚门禁；
7. 输出一份可评审、可复查的《架构与版本选择 ADR》。

一、为什么架构形态要在参数调优之前确定

很多团队第一次部署分析数据库时，会先讨论内存参数、并发数、分桶数量和压缩算法。它们确实重要，但这些参数都运行在既定架构之上。架构形态一旦确定，数据持久化位置、扩容方式、故障恢复路径、硬件采购模式和运维职责也随之确定。

可以先看两个业务。

业务 A 是集团经营大屏。每天的查询模式相对稳定，工作日从早到晚保持较高并发，核心页面要求 P99 低于 300 毫秒。数据增长可预测，机房内有稳定的 NVMe 资源，平台团队希望系统组件尽量少。

业务 B 是日志与可观测平台。白天查询较多，夜间资源利用率很低，发布和故障期间会出现数倍流量峰值。数据每天增长几十 TB，需要保存数月，多个研发团队希望共享同一份数据，同时保留独立计算资源。

两类业务都能使用 Doris，最合适的资源模型却不相同。业务 A 更看重本地数据、低尾延迟和运维简洁度；业务 B 更看重独立扩缩、低成本持久化、计算隔离与共享数据。

架构决策可以拆成六个问题：

在这些问题没有答案时，任何“哪种架构更先进”的讨论都容易失焦。正确做法是先建立业务画像，再让架构承担明确目标。

二、先分清两个独立维度：架构形态与部署载体

Doris 的架构形态主要有两类：

• 存算一体（Integrated Storage-Compute）：BE 同时承担持久化存储和计算，数据保存在 BE 本地磁盘；
• 存算分离（Decoupled Storage-Compute）：持久化数据位于共享存储，BE 作为计算节点运行，本地磁盘主要承担 File Cache。

部署载体则包括物理机、虚拟机、容器、Kubernetes 和云服务。两组概念需要分开理解。

存算一体可以部署在物理机，也可以借助 Doris Operator 运行在 Kubernetes 上。存算分离可以运行在 Kubernetes，也可以按官方手册在 Linux 环境手工部署。Kubernetes 解决容器编排、声明式运维和故障拉起；存算分离解决持久化存储与计算资源的解耦。

另外还有两个常被混淆的概念。

2.1 冷热分层

冷热分层通常指同一张内部表的热数据保留在本地介质，冷数据按策略迁移到对象存储。它改善长期数据的存储成本，集群仍可能保持存算一体的副本与节点模型。

完整的存算分离架构从设计上就把共享存储作为持久化层，计算节点不持有唯一的持久化数据副本。扩缩计算组时无需迁移全部业务数据，缓存会随着访问或预热逐步建立。

2.2 数据湖外表查询

通过 Hive、Iceberg、Hudi、Paimon Catalog 查询外部数据，属于湖仓联邦分析。Doris 读取外部表文件和元数据，数据仍由外部系统管理。

存算分离内部表由 Doris 管理表、事务、Tablet、Rowset 和文件生命周期，只是持久化介质从 BE 本地盘转移到共享存储。两者都可能访问对象存储，元数据所有权和数据生命周期完全不同。

这三个概念放在一张表里会更清楚：

三、存算一体：本地数据与数据本地性

存算一体是 Doris 经典的 FE + BE 架构。FE 负责连接、SQL 解析、查询优化、元数据与调度；BE 同时负责数据副本、存储引擎、向量化执行、Pipeline 调度和节点间 Shuffle。

3.1 数据如何落在本地

建表时，数据先按分区组织，再按分桶规则切成多个 Tablet。每个 Tablet 根据副本策略分布到若干 BE。写入任务由 FE 协调事务和路由，目标 BE 将数据写入内存结构，随后形成 Rowset 与 Segment，并在多个副本之间完成确认。

查询时，FE 根据分区、Tablet、健康副本和节点负载选择 Scan 位置。BE 从本地磁盘或本地缓存读取 Segment，完成索引裁剪、解压、过滤、Join 和聚合。只要查询的大部分数据位于执行节点本地，网络主要承载必要的 Exchange 与结果传输。

3.2 存算一体的主要价值

1. 延迟更容易预测

本地 SSD 的访问路径短，随机读取和高并发访问更容易获得稳定表现。对象存储的请求延迟、带宽限制和远端抖动对主查询路径影响较小。面向固定报表、在线数据服务和延迟敏感 API 时，这种确定性很有价值。

2. 架构组件较少

经典形态的核心进程是 FE 与 BE。团队主要维护元数据高可用、BE 副本、磁盘容量、网络、Compaction、Rebalance 和监控。对于人员较少、私有化环境较多的团队，组件数量直接影响故障定位速度。

3. 数据本地性清晰

Tablet 副本与具体 BE 绑定，查询计划可以结合副本位置选择执行节点。Colocate Join、分桶裁剪和本地聚合都能利用稳定的数据分布减少网络传输。

4. 适合持续高负载

当 CPU、内存和存储长期同时处于较高利用率，计算与存储一起采购不会产生明显浪费。稳定的大屏、固定报表、用户画像、订单服务和持续写入的实时数仓常见这一特点。

3.3 存算一体需要承担的代价

1. 计算和存储一起扩容

某些业务只缺 CPU，磁盘空间仍很充足；增加 BE 后，团队同时获得新的磁盘。另一类业务只缺容量，计算利用率却不高；扩容仍会增加 CPU 与内存。这种绑定会造成资源比例与实际需求不完全一致。

2. 扩容伴随数据迁移

新增 BE 后，FE 会通过 Rebalance 调整 Tablet 分布。迁移期间会消耗磁盘和网络带宽，大集群、超多 Tablet 或大促高峰期需要更谨慎地控制速度与窗口。

3. 本地磁盘成为容量治理重点

磁盘水位、盘间均衡、坏盘、文件句柄、Compaction、垃圾回收和副本修复都需要持续监控。高频小批写入会产生大量版本与小文件，后台合并速度跟不上时，读放大和磁盘压力会逐渐上升。

4. 多租户隔离更多依赖资源治理

多个业务共享同一批 BE 时，Workload Group、并发队列、内存限制和节点标签承担隔离职责。它们能解决大量问题，但各租户仍共享物理节点与部分后台任务。

3.4 适合存算一体的典型条件

满足以下条件越多，存算一体越值得优先验证：

• P99 延迟要求严格，冷查询也要稳定；
• 负载全天较平稳，CPU 和存储长期共同增长；
• 本地 NVMe 或 SSD 资源充足；
• 私有化、离线或网络受限环境较多；
• 团队希望减少外部组件和运维边界；
• 数据规模可通过常规水平扩展管理；
• 扩容与数据迁移有明确维护窗口。

四、存算分离：共享存储、计算组与数据层元数据

存算分离在 Doris 3.0 引入，Doris 4.x 已经形成更完整的三层结构：SQL 与控制层、计算层、共享存储层。官方架构中还增加了 Meta Service，用于管理数据层元数据和事务状态。

4.1 组件职责

FE

FE 继续作为用户入口，负责 MySQL 协议、SQL 解析、优化、调度、用户权限以及数据库和表结构等 SQL 层元数据。它依然决定一条查询怎样执行。

Meta Service

Meta Service 负责 Tablet、Rowset、版本、事务冲突和计算组资源相关的数据层元数据。服务本身可以无状态扩展，持久化元数据通常落在 FoundationDB。官方部署教程会把 FE、Meta Service、FoundationDB、Compute Group 和 Storage Vault 作为完整集群的关键组件。

Compute Group

Compute Group 由一组 BE 计算节点组成。节点承担写入计算、查询执行和本地缓存，不保存唯一的持久化数据。多个计算组可以访问同一份共享数据，用于读写隔离、多租户隔离、不同硬件池或弹性伸缩。

Storage Vault 与共享存储

Storage Vault 描述 S3 兼容对象存储或 HDFS 等持久化后端。Segment 与索引文件持久化在共享存储中，容量扩展主要由存储系统承担。

File Cache

每个计算节点使用本地 SSD 缓存热数据、索引和部分元数据。对象存储适合低成本、海量持久化，本地缓存负责缩短高频查询路径。

4.2 存算分离的主要价值

1. 计算和存储独立扩展

业务高峰来临时可以增加计算节点，数据容量增长时可以扩展共享存储。资源采购更贴近真实瓶颈，特别适合数据保留期长、查询峰值短、日内波动大的平台。

2. 多计算组共享同一份数据

经营分析、数据科学、数据服务和离线加工可以使用不同计算组。每个计算组拥有独立缓存与计算资源，底层数据无需复制成多套。团队可以分别配置工作负载、维护窗口和扩缩策略。

3. 计算节点更容易替换

节点不承担唯一持久化副本，故障节点可以退出，新的计算节点通过共享存储与缓存逐步恢复服务。扩缩容不再依赖全量 Tablet 数据迁移。

4. 长期持久化成本更低

对象存储或共享文件系统适合 PB 级数据和长周期保留。日志、可观测、AI 语料、历史明细和归档分析通常具有“写入多、长期保存、热点集中”的特征，成本收益更明显。

5. 云原生环境适配更自然

公有云、Kubernetes、多可用区和弹性节点环境中，本地盘生命周期可能较短。把持久化数据交给共享存储后，计算实例可以按平台方式管理。

4.3 存算分离增加了哪些工程问题

1. 冷缓存会放大尾延迟

计算节点第一次访问某个 Segment 时，需要从远端拉取。远端访问包含网络往返、对象存储请求、带宽竞争和缓存写入。平均延迟可能仍然很好，p99 在冷启动、新节点扩容或热点切换时会明显波动。

2. 对共享存储和网络提出更高要求

对象存储有请求 QPS、带宽、并发和计费模型；HDFS 或 Ceph 有自身的容量与高可用治理。计算组扩得很快时，共享存储未必同步拥有足够吞吐。架构评估必须把远端读写能力纳入容量模型。

3. 元数据链路更长

FE、Meta Service、FoundationDB、Compute Group、Storage Vault 和 Recycler 等组件形成更完整的控制链路。每个组件都需要高可用、监控、备份和升级顺序。平台团队的成熟度会直接影响稳定性。

4. 缓存需要运营

缓存容量、淘汰策略、预热、命中率、热点变化、新 Rowset 和 Compaction 都会影响查询。只部署节点、不管理缓存，容易得到“平均很快、偶尔很慢”的体验。

5. 架构模式不能原地切换

官方升级文档明确说明，存算一体与存算分离之间不支持原地模式切换。计划从一种形态迁移到另一种形态时，通常需要建设目标集群，通过同步、导入、校验和切流完成迁移。这个约束应当在项目早期写进 ADR。

4.4 适合存算分离的典型条件

• 已有可靠对象存储、HDFS、Ceph 或兼容共享存储；
• 公有云或 Kubernetes 是主要运行环境；
• 查询负载有明显波峰波谷；
• 数据长期保存，容量增长快；
• 多团队需要共享数据并隔离算力；
• 团队具备 Meta Service、FoundationDB、缓存和共享存储运维能力；
• 能够接受通过预热和容量冗余控制冷查询；
• 架构价值足以覆盖新增组件的管理成本。

五、两种架构的读写路径到底差在哪里

把架构差异放进读写路径，会比记组件名称更容易理解。

5.1 存算一体写入

1. 客户端、Flink Connector、Routine Load 或 Stream Load 发起写入；
2. FE 创建事务、解析表结构、确定分区与 Tablet；
3. 数据发送到持有目标副本的 BE；
4. BE 完成内存排序、编码、Flush 和副本写入；
5. 事务 Commit 后，新版本对查询可见。

持久化数据落在 BE 本地磁盘。写入吞吐受目标 BE、磁盘、网络、副本数和 Compaction 能力影响。

5.2 存算一体读取

1. FE 完成分区与 Tablet 裁剪，选择健康副本；
2. 目标 BE 读取本地 Segment 或本地缓存；
3. Scan、Join、Agg、Sort 等算子在 BE 运行；
4. Exchange 只传输需要重新分布的中间数据；
5. Coordinator 汇总结果并返回客户端。

数据本地性是这条路径的核心优势。

5.3 存算分离写入

1. FE 接收任务并生成计划；
2. Meta Service 参与事务、版本与数据层元数据管理；
3. 计算组完成数据处理、排序、编码和文件生成；
4. Segment 与索引文件写入 Storage Vault 对应的共享存储；
5. 新版本元数据发布后，其他计算组可以看到该版本。

写入计算与持久化存储分别承担资源压力。共享存储吞吐和元数据服务能力需要一起规划。

5.4 存算分离读取

1. FE 生成查询计划并选择计算组；
2. 计算节点检查本地 File Cache；
3. 命中时直接从本地 SSD 读取；
4. 未命中时从共享存储拉取文件块，并按策略写入缓存；
5. 后续算子仍使用 Doris 的向量化与 Pipeline 引擎执行。

存算分离没有放弃本地盘。本地盘的角色从持久化副本转为性能缓存，容量和可靠性目标也随之变化。

六、File Cache：存算分离能否稳定的关键

官方 File Cache 文档把远端存储带来的问题归纳为三类：访问延迟、QPS/带宽限制和按请求或流量产生的成本。File Cache 用本地 SSD 缓存 Segment、倒排索引和相关元数据，减少重复远端访问。

6.1 冷查询与热查询

冷查询访问的文件尚未在本地缓存。计算节点需要从对象存储读取，等待远端返回，再进入解码和计算。冷查询延迟包含存储服务与网络波动。

热查询命中本地缓存。数据路径接近本地盘读取，延迟更稳定。业务中经常出现 20% 的热数据承担 80% 查询流量，合理的缓存容量能够覆盖这部分热点。

架构测试必须同时记录冷、温、热三种状态。只在连续压测后统计平均值，会把缓存建立过程隐藏掉。

6.2 哪些操作会让缓存失效或变冷

• 新增计算节点，节点本地没有历史缓存；
• 数据导入产生新的 Rowset；
• Compaction 合并旧文件并生成新文件；
• Schema Change 生成新的数据文件；
• 业务热点从旧分区切换到新分区；
• 缓存空间不足，热点文件被淘汰；
• 读写分离时，写计算组已经缓存新文件，只读计算组尚未建立缓存。

因此，缓存命中率要与版本发布、导入、Compaction、扩缩容和业务峰值放在同一张时间线上观察。

6.3 缓存预热

Doris 4.x 支持按表或分区进行缓存预热。常见做法包括：

1. 新计算组加入后，先预热核心表的最近分区；
2. 大促前预热固定报表和用户画像涉及的热点数据；
3. 读写分离架构中，在新 Rowset 对外承载高并发读取前完成预热；
4. 观察预热速度、对象存储带宽和缓存占用，避免预热任务挤占在线请求。

6.4 缓存容量怎样估算

可以从下列公式开始：

目标缓存容量
≈ 热点数据压缩后大小
+ 热点索引大小
+ 近期新增 Rowset 缓冲
+ 扩缩容与热点漂移冗余

假设最近 7 天数据压缩后为 12 TB，真正高频查询集中在最近 2 天，相关倒排索引和 Footer 占 1.5 TB，再预留 30% 冗余，则一个计算组需要覆盖的有效缓存约为：

12 TB × 2 / 7 + 1.5 TB ≈ 4.93 TB
4.93 TB × 1.3 ≈ 6.4 TB

这只是起点。多节点缓存是否均匀、单次查询访问范围、Compaction 频率和热点分布都会改变结果。POC 需要用真实访问日志验证。

6.5 需要持续观察的指标

• File Cache 命中率；
• 远端读取字节数与请求次数；
• 冷查询与热查询的 p95、p99 差值；
• 预热任务耗时与吞吐；
• 本地缓存磁盘水位与淘汰量；
• 对象存储错误、限流和尾延迟；
• 新 Rowset 发布后只读计算组的性能变化。

存算分离的稳定性能来自共享存储、本地缓存、网络和工作负载共同配合。任何单点数据都不足以解释整体表现。

七、性能、成本、弹性和复杂度的完整比较

下面给出一张更完整的比较表。表中的“高”与“低”表示常见倾向，实际结果需要结合硬件、缓存、对象存储、数据分布和版本验证。

7.1 不能只看平均响应时间

POC 中最容易出现的误判，是连续跑同一组 SQL，然后用平均耗时得出结论。存算分离在缓存完全热起来后可能表现很好，生产中的新节点、热点变化和新 Rowset 会重新制造冷读。

至少应记录：

• 第一次查询；
• 第二次查询；
• 缓存稳定后的多轮查询；
• 节点扩容后的第一次查询；
• Compaction 后的查询；
• 共享存储限速或网络抖动时的查询；
• 并发读写混合时的 p99。

7.2 不能只比较机器数量

存算一体的本地盘同时承担持久化与查询，存算分离的本地盘承担缓存。两边的磁盘可靠性、容量冗余和副本成本不同。完整 TCO 应包含：

计算成本
+ 本地盘或缓存盘成本
+ 共享存储容量与请求成本
+ 网络流量
+ 备份与容灾
+ 运维人力
+ 扩容迁移期间的资源冗余
+ 故障和性能波动带来的业务成本

八、五类典型业务如何选择

场景一：稳定高负载经营大屏

特征：SQL 相对固定，工作日长时间保持高并发，P99 要求严格，数据规模数十 TB 到数百 TB，查询主要集中在最近数据。

建议：优先验证存算一体。使用本地 NVMe、合理分区分桶、物化视图、缓存和 Workload Group，重点检查高并发下的尾延迟与写入干扰。

当大屏只在少数时间段活跃、数据保留期极长、团队已有成熟对象存储时，也可以评估存算分离。验证重点应放在扩容后的预热时间和峰值到来前的准备流程。

场景二：日志与可观测平台

特征：每天写入量大，数据保留期长，全文检索与聚合并存，热点集中在最近数小时或数天，发布和故障期间流量陡增。

建议：存算分离通常更有吸引力。共享存储承载历史数据，多个计算组可以服务查询、写入和离线分析。File Cache 覆盖最近热点分区，倒排索引文件也要纳入缓存容量。

若运行环境缺少可靠共享存储，团队规模较小，可以先使用存算一体加冷热分层，待平台能力成熟后再建设新集群迁移。

场景三：SaaS 多租户分析

特征：多个租户或业务团队共享相同数据底座，各自并发和查询模式差异很大，部分租户需要独立扩容，资源隔离和成本归属很重要。

建议：优先评估多个 Compute Group。租户可按业务等级、地域、读写类型或硬件需求划分计算组，再在组内使用 Workload Group 管理 CPU、内存和并发。

需要提前设计默认计算组、连接路由、缓存容量、热点数据共享方式和租户成本核算。计算组数量过多也会增加缓存重复和运维开销。

场景四：私有化、离线或边缘环境

特征：网络访问受限，云服务不可用，对象存储能力有限，运维人员较少，硬件采购相对固定。

建议：存算一体更直接。FE 与 BE 架构清晰，本地数据路径短，故障依赖较少。容量规划要保留副本、Compaction、备份和扩容空间。

场景五：AI 语料、向量与长上下文平台

特征：文本、Embedding、Agent Trace、会话上下文和结构化属性共同增长，搜索与分析需要融合，数据规模可能快速扩大。

建议：根据访问模式选择。高频在线检索且规模可控时，存算一体能够提供稳定本地性能；超大规模向量、长期语料、多计算组共享数据时，存算分离更有成本与弹性优势。Doris 4.1 的 IVF_ON_DISK 就明确利用内存缓存、本地文件缓存与存算分离协同处理大规模向量检索。

九、Latest、Stable 与 X.Y.Z：版本名称代表什么

截至 2026 年 8 月 16 日，Apache Doris 官网下载页显示：

• 4.1.3：Latest
• 4.0.8：Stable

这是一张时间快照。Web 学习站应从版本数据源生成徽标和提示，避免把版本号永久写进正文。

9.1 X.Y.Z 的含义

Doris 官方版本说明使用三段式版本号：

Patch 版本原则上不引入新的大功能，主要用于修复缺陷和改善性能。生产环境在确定 Minor 分支后，通常应跟进经过验证的较新 Patch，减少已知问题暴露时间。

9.2 Latest 的用途

官方把 Latest 定位于 POC、性能测试和新特性体验。它包含最新能力，也可能存在尚未充分覆盖的边界。

适合 Latest 的任务包括：

• 验证 4.1 新增的 IVF、IVF_ON_DISK、量化和混合检索；
• 评估宽表、随机读和高并发优化；
• 提前发现 SQL 行为、连接器和运维工具兼容问题；
• 构建下一次生产升级的测试资产；
• 小流量、可回退场景的灰度试点。

Latest 不应直接等同于“不能生产”。是否可用取决于版本成熟度、业务风险、验证深度和支持能力。官方的通用建议仍然是生产选择 Stable。

9.3 Stable 的用途

Stable 分支持续接收缺陷修复，面向生产稳定性。常规生产集群、核心经营报表、金融分析、客户数据平台和高 SLA 服务应优先从 Stable 分支选择。

Stable 也需要测试。业务 SQL、UDF、Connector、Catalog、权限、时区、数据类型和升级路径都有企业自己的上下文，官方标签无法替代内部验证。

9.4 4.0 与 4.1 的能力主线

Doris 4.0 的主线包括：

• HNSW 向量索引与向量检索；
• AI Functions；
• 结构化过滤、全文检索和向量检索组合；
• SEARCH()、BM25 与更强全文检索；
• Spill Disk 保障大型 ETL/ELT；
• TopN、SQL Cache、JSON 等性能和行为改进。

Doris 4.1 在此基础上继续推进：

• IVF 与 IVF_ON_DISK；
• INT8、INT4、PQ 等量化方式；
• 向量 Index Only Scan；
• search() 与混合检索增强；
• 超宽表、随机读、聚合分析和高并发能力优化；
• AI 观测、长上下文和大规模搜索场景增强。

学习站可以把 4.0 作为稳定生产基线讲解，把 4.1 新能力放入“新特性与验证”模块。每个知识点都要标明首次引入版本、推荐版本、成熟度和最后核验时间。

十、生产升级：版本选择完成后，还要建立门禁

官方升级文档支持滚动升级，FE 与 BE 逐台替换可以降低整体停机时间。滚动升级仍然需要完整准备，节点重启会影响正在执行的查询与导入，跨版本行为也可能发生变化。

10.1 升级前六项检查

1. 阅读目标版本 Release Notes

关注新增能力、行为变化、配置变化、已知问题、被移除能力和兼容说明。只看“性能提升”摘要会遗漏 SQL 语义、函数、数据类型和默认值变化。

2. 备份数据与元数据

确认 FE 元数据备份位置、备份可用性、数据副本和外部备份。备份完成后还要验证恢复步骤和所需时间。

3. 执行元数据兼容测试

官方建议每次升级都验证新版本能否加载现有元数据。单 FE 集群风险更高，生产通常应先建设至少 3 FE 的高可用配置。

4. 用真实负载回归

准备真实表结构、统计信息、物化视图、权限、Catalog、导入任务和关键 SQL。回归指标至少包括结果一致性、p95/p99、写入延迟、内存、Spill、Compaction 和错误率。

5. 验证生态组件

Flink、Spark、Kafka Connector、Doris Operator、JDBC 驱动、BI 工具、dbt、MCP Server 和监控面板都可能有独立版本。建立兼容矩阵，避免核心集群升级后外围链路无法工作。

6. 定义回滚边界

Patch 级回退相对简单；Minor 与 Major 回退受元数据和数据格式限制。存算分离升级还涉及 Meta Service、Recycler、FE、BE 和 FoundationDB 等组件的顺序。回滚方案必须写到可执行命令和责任人层面。

10.2 升级顺序不能靠记忆

旧培训资料常给出一句固定顺序。当前集群形态、目标版本和官方文档会影响具体流程。实施前应以目标版本的升级手册为准，记录每个组件的前置检查、重启顺序、观察指标和停止条件。

10.3 生产版本策略示例

可以建立三套环境：

版本治理的目标是形成持续流水线。每次升级积累的 SQL、数据集、故障脚本和验收阈值都应保留下来，下一次升级可以直接复用。

十一、部署载体怎样选择

架构形态确定后，再选择物理机、虚拟机或 Kubernetes。

11.1 物理机与虚拟机

适合追求稳定性能、拥有固定资源池和成熟主机运维体系的团队。存算一体在本地 NVMe 环境下通常更容易发挥数据本地性。虚拟化环境要关注 CPU 超分、NUMA、网络和云盘抖动。

11.2 Kubernetes 与 Doris Operator

适合已有统一容器平台、需要声明式管理和自动化运维的团队。Operator 可以帮助管理 FE、BE、Meta Service 和计算组等资源。使用 StatefulSet 或持久卷时，仍要理解具体架构的数据持久化方式。

Kubernetes 不能替代容量规划。CPU Limit、内存 Limit、Local PV、网络、Pod 反亲和、节点污点、滚动策略和故障域都会影响 Doris。

11.3 托管云服务

适合希望减少底层运维、快速获得弹性与云生态集成的团队。选型时仍需确认版本、兼容性、网络、对象存储、资源隔离、备份恢复、成本模型和可迁移性。

十二、POC：用真实业务验证架构

架构 POC 的目标是回答“在我们的数据、查询、并发和故障条件下，哪种形态更可控”。单条 benchmark 很难覆盖这个问题。

12.1 准备真实工作负载

至少选取：

• 5 条固定报表 SQL；
• 5 条多表 Join 与聚合 SQL；
• 3 条高并发点查；
• 3 条日志或文本检索；
• 2 条大查询或 ETL；
• 真实写入链路和更新模式；
• 典型日流量与峰值流量。

12.2 两种架构都要测试的指标

• 数据正确性与对账；
• 数据可见时延；
• p50、p95、p99；
• 峰值 QPS 与错误率；
• CPU、内存、磁盘、网络；
• 写入与查询相互影响；
• 节点故障与恢复；
• 扩容耗时与业务影响；
• 24–72 小时稳定性；
• 单位数据与单位查询成本。

12.3 存算一体专属验证

• 新增 BE 后 Rebalance 的网络、磁盘和耗时；
• Tablet 分布和数据倾斜；
• 磁盘水位与副本修复；
• 高写入时 Compaction Score；
• 单盘故障、单 BE 故障和 FE 选主；
• 计算需求单独增长时的资源浪费比例。

12.4 存算分离专属验证

• 冷、温、热缓存三组延迟；
• 新计算组预热时间；
• 新 Rowset、Compaction 和 Schema Change 后的首查；
• 对象存储限流、错误和带宽不足；
• Meta Service 与 FoundationDB 故障；
• 计算组扩缩和 Cloud Rebalance；
• 多计算组共享数据时的缓存重复；
• 远端请求与流量成本。

12.5 验收阈值示例

数字需要根据业务设定。重要的是提前写清楚，避免测试结束后根据结果临时改变标准。

十三、今日实践：完成《架构与版本选择 ADR》

今天选择两个练习场景：

场景 A：稳定高负载报表

• 120 TB 明细数据；
• 每天新增 1.5 TB；
• 08:00–22:00 持续高负载；
• 3,000 QPS 点查，300 QPS 聚合；
• 核心查询 P99 300 毫秒；
• 私有化机房，有 NVMe，平台团队 3 人。

场景 B：波峰波谷日志平台

• 600 TB 历史数据；
• 每天新增 20 TB；
• 90% 查询访问最近 3 天；
• 日常 200 QPS，故障期间峰值 2,000 QPS；
• 已有 S3 兼容对象存储和 Kubernetes；
• 研发、运维、安全三个团队共享数据。

为每个场景输出：

1. 选择的架构形态；
2. 选择理由与关键假设；
3. FE、BE/Compute Group、存储与缓存的初始拓扑；
4. 当前推荐版本分支；
5. POC SQL、数据量和并发；
6. 冷缓存、热缓存和故障测试；
7. 上线门槛；
8. 主要风险与补偿措施；
9. 需要在什么条件下重新评审。

推荐使用下面的 ADR 结构：

# ADR-004：Doris 架构与版本选择

## 背景
业务规模、SLA、负载、数据保留、基础设施与团队情况。

## 决策
选择存算一体 / 存算分离；选择 Stable / Latest 的具体用途。

## 关键依据
性能、成本、弹性、复杂度、组织能力的评分与证据。

## POC 计划
数据集、SQL、并发、冷/热缓存、扩缩容与故障场景。

## 风险与补偿
缓存冷启动、Rebalance、共享存储限流、升级兼容、回滚边界。

## 上线条件
验收阈值、监控、备份、负责人、变更窗口。

## 复审条件
数据增长、SLA、基础设施、团队或版本主线发生重大变化。

十四、Knowledge Check

题目 1

存算一体架构中，BE 的核心职责是什么？

答案要点： BE 同时保存 Tablet 数据副本并执行查询、导入、Compaction 和 Exchange；本地磁盘属于持久化数据路径。

题目 2

存算分离中，Meta Service 与 FE 的职责怎样划分？

答案要点： FE 负责用户入口、SQL 解析规划和 SQL 层元数据；Meta Service 负责事务、Tablet、Rowset、版本与计算组相关的数据层元数据。

题目 3

存算分离为什么仍然需要本地 SSD？

答案要点： 本地 SSD 用作 File Cache，缓存 Segment、索引和元数据，减少对象存储延迟、请求次数和带宽压力。

题目 4

存算分离与数据湖 Catalog 的区别是什么？

答案要点： 存算分离内部表仍由 Doris 管理事务和数据生命周期；Catalog 查询的数据由外部湖系统管理。

题目 5

官网的 Latest 与 Stable 应怎样使用？

答案要点： Stable 优先用于生产；Latest 用于 POC、性能测试、新特性验证和提前建立升级经验。两者都需要企业内部回归。

题目 6

为什么不能只用热缓存压测结果判断存算分离性能？

答案要点： 新节点、新 Rowset、Compaction、Schema Change 和热点切换都会产生冷读，生产 P99 取决于这些状态。

题目 7

Doris 两种架构可以直接原地切换吗？

答案要点： 官方文档明确说明不支持原地模式切换。迁移通常需要新建目标集群、同步数据、校验并切流。

题目 8

生产升级前最关键的验证有哪些？

答案要点： Release Notes、数据和元数据备份、元数据兼容测试、真实负载回归、Connector/BI 兼容、滚动升级步骤和回滚边界。

十五、本日总结

今天建立了 Doris 集群层的架构地图。

存算一体把计算、持久化数据与本地磁盘放在 BE 上，数据本地性强，低延迟更容易预测，组件和运维边界较少。计算与存储资源同步扩展，扩容会伴随 Tablet 迁移，磁盘与副本治理是长期重点。

存算分离把持久化数据放在共享存储，FE 保留 SQL 入口与规划职责，Meta Service 管理数据层元数据，Compute Group 提供可独立扩缩的计算能力，File Cache 负责热数据性能。它适合云原生、多租户、波动负载和长期海量数据，同时要求团队具备共享存储、网络、缓存、Meta Service 与 FoundationDB 的运维能力。

架构选择需要围绕 P99、负载波动、数据增长、成本、基础设施和组织能力评分，再用真实数据验证冷/热缓存、扩缩容和故障。版本治理则要把 Latest 放进实验与预研轨道，把 Stable 放进生产轨道，并通过 Release Notes、兼容测试、真实负载回归、备份和回滚形成持续流程。

明天进入 Day 5：从零部署、连接、建表、导入与第一次查询。我们会建立一个可反复使用的 Doris 实验环境，把前四天的概念真正落到命令和结果上。

官方资料

1. Apache Doris 4.x：System Architecture
   https://doris.apache.org/docs/4.x/features-architecture/system-architecture/
2. Apache Doris 4.x：Version Notes
   https://doris.apache.org/docs/4.x/features-architecture/versioning/
3. Apache Doris：Download
   https://doris.apache.org/download/
4. Apache Doris 4.x：File Cache Configuration and Usage Guide
   https://doris.apache.org/docs/4.x/compute-storage-decoupled/file-cache/
5. Apache Doris 4.x：Compute Group Management
   https://doris.apache.org/docs/4.x/compute-storage-decoupled/managing-compute-cluster/
6. Apache Doris 4.x：Cluster Upgrade
   https://doris.apache.org/docs/4.x/admin-manual/cluster-management/upgrade/
7. Apache Doris 4.x：Compute-Storage Decoupled Cluster Upgrade Guide
   https://doris.apache.org/docs/4.x/compute-storage-decoupled/upgrade/
8. Apache Doris 4.0 Release Notes
   https://doris.apache.org/releases/v4.0/release-4.0.0/
9. Apache Doris 4.1 Release Notes
   https://doris.apache.org/releases/v4.1/release-4.1.0/
10. Apache Doris 4.x：Deploying a Complete Compute-Storage Decoupled Cluster
    https://doris.apache.org/docs/4.x/install/deploy-on-kubernetes/separating-storage-compute/install-doris-cluster/

资料核对日期：2026-08-16。官网当前显示 4.1.3 为 Latest、4.0.8 为 Stable。正式 Web 站应把版本号、状态和核验日期作为动态元数据维护。