Day 2｜Apache Doris 全景：定位、能力、场景与边界

第一天建立了 OLTP、OLAP、HTAP、数据湖和实时分析的坐标系。今天把视角收拢到 Apache Doris，回答四个更具体的问题：Doris 解决什么问题，能力来自哪些技术，哪些场景适合，项目落地时需要守住哪些边界。

官方文档给出的性能范围用于描述产品能力上限与典型目标。实际项目仍需使用目标版本、真实数据、真实 SQL、真实并发和真实硬件完成 POC，任何单条基准数字都不能直接转换成生产承诺。

本日学习目标

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

1. 用准确、克制的语言解释 Apache Doris 的产品定位；
2. 说明“高性能、实时、统一、易用”分别由哪些能力支撑；
3. 掌握实时看板、即席分析、用户画像、日志检索、湖仓查询、CDC 更新六类典型场景；
4. 判断 Doris 与 MySQL、Kafka/Flink、数据湖、搜索引擎之间的职责关系；
5. 识别高频事务、复杂搜索、图计算、纯 KV 等场景中的技术边界；
6. 设计一份覆盖正确性、新鲜度、吞吐、尾延迟、资源与恢复能力的 POC 验收方案。

一、先把 Apache Doris 的定位说准确

1.1 一句话定义

Apache Doris 官方 4.x 文档将其定义为：基于 MPP 架构的高性能实时分析数据库。它面向海量数据分析，支持高吞吐复杂查询，也支持高并发点查；对外提供兼容 MySQL 协议的 SQL 接口，并把实时数据分析、湖仓分析、全文与向量检索等能力放进同一套产品体系。

这句话里有四个关键词。

第一，分析数据库。 Doris 的主战场是报表、多维分析、用户行为、画像圈选、日志分析、数据服务和湖仓查询。它具备更新、删除和主键语义，但核心账务、订单事务、支付记账等业务通常继续由 MySQL、PostgreSQL、Oracle 等 OLTP 数据库承担。

第二，实时。 Doris 支持持续接入 Kafka、Flink、CDC 和应用数据流，也支持 Unique Key 主键模型、部分列更新和秒级可见。实时能力要从业务事件发生一直测量到最终查询结果呈现，单看消费位点无法代表端到端新鲜度。

第三，高性能。 性能来自列式存储、编码压缩、分区分桶、数据裁剪、索引、MPP、向量化、Pipeline、CBO、物化视图和缓存等多层协作。建表方式、数据分布、统计信息、并发模型和资源配置都会影响最终结果。

第四，统一。 一套 Doris 可以承载高并发报表、复杂即席分析、主键点查、日志检索、湖仓联邦查询，并在 4.x 中延伸到混合搜索和 AI 数据栈。统一带来的主要价值是减少数据复制、缩短链路、统一权限与 SQL 入口，同时也要求团队做好资源隔离、工作负载治理和容量规划。

官方概览页列出了亚秒级查询、秒级写入、万级 QPS、PB 级规模等能力范围。理解这些数字时应关注前置条件：查询是否命中分区和索引，数据是否预聚合，冷热缓存状态如何，SQL 是否固定，单行点查与大规模 Join 属于完全不同的负载。生产验收应把这些前置条件写进测试报告。

1.2 Doris 在企业数据架构中的位置

可以把企业数据链路简化成四层：

1. 业务事实层：订单、账户、支付、库存、CRM、ERP 等系统持续产生数据；
2. 接入与加工层：CDC、Kafka、Flink、批处理任务负责搬运、清洗和转换；
3. 分析与服务层：Doris 保存或查询分析数据，执行聚合、关联、检索和数据服务；
4. 消费层：BI、经营看板、API、数据应用、搜索页面和 AI Agent 使用结果。

Doris 位于第三层，并通过 MySQL 协议、Connector、Catalog、Stream Load、Routine Load、Streaming Job 等能力向上下游延伸。它可以直接保存高价值热数据，也可以通过 Multi-Catalog 查询 Hive、Iceberg、Hudi、Paimon、JDBC 等外部数据源。企业因此拥有两条数据路径：高频访问数据进入 Doris 原生表，低频历史数据继续保留在开放数据湖；查询时按 SLA、成本和治理要求选择落点。

1.3 从 Palo 到 Apache 顶级项目

Doris 最早源于百度广告报表业务中的 Palo 项目，面向高并发、多维度、低延迟的广告分析需求。项目在 2017 年正式开源，2018 年进入 Apache 孵化器，2022 年 6 月毕业成为 Apache 顶级项目。

这段历史解释了产品长期以来的几个倾向：

• 对实时经营报表和多维分析投入很深；
• 重视简单架构和 MySQL 协议兼容，降低业务接入成本；
• 同时追求复杂查询吞吐和面向应用的高并发查询；
• 持续扩展数据模型、更新、湖仓、检索、资源治理和云原生能力。

截至 2026 年 8 月 16 日，官方下载页将 4.1.3 标记为 Latest，4.0.8 标记为 Stable。本系列以 4.x 的产品能力为基线，生产环境仍应结合组织的升级节奏、已知问题、Connector 兼容矩阵和回滚方案选择具体版本。

二、核心能力全景：四个产品价值由六组技术能力支撑

2.1 实时写入与更新

实时分析首先需要稳定的数据入口。Doris 4.x 的导入体系覆盖多种链路：

• Stream Load 通过 HTTP 接收批量或微批数据；
• Routine Load 持续消费 Kafka；
• Doris Kafka Connector 由 Kafka 侧主动推送；
• Flink Doris Connector 接收流计算结果；
• Flink CDC、DataX 或内置 Streaming Job 同步事务数据库变化；
• Group Commit 合并高频小批提交，减少事务与文件开销；
• Broker Load、TVF、INSERT INTO SELECT 处理对象存储和 HDFS 文件。

更新能力主要围绕 Unique Key 模型展开。相同主键的新数据会覆盖旧数据，Merge-on-Write 在写入阶段处理主键冲突，使查询直接读取可见版本。部分列更新可以只提供主键和发生变化的字段，适合订单状态、用户画像和多源宽表装配。

这里需要注意两个成本。

其一，更新在列式存储中通常涉及读取旧值、补齐缺失列、写入新 Rowset 和维护 Delete Bitmap。高频修改超宽表中的少数字段会带来读写放大，SSD、Row Store、批量写入和合理的表设计都很重要。

其二，标准 UPDATE 更适合低频批量修改。官方文档明确提示，同一主键上的高并发 UPDATE 无法提供事务数据库式的隔离保障。CDC 和高频更新应优先使用导入式 UPSERT，并通过 Sequence Column 等机制处理乱序。

2.2 MPP、向量化与 Pipeline 执行

一条复杂 SQL 可能扫描多个分区，关联数张表，再完成聚合、排序和窗口计算。Doris 的 MPP 架构会把物理计划切分成多个 Plan Fragment，调度到多台 BE 并行执行。每台机器扫描本地 Tablet，必要时通过 Exchange 在节点之间 Shuffle 数据。

向量化执行让算子按列式 Block 处理一批数据，减少逐行虚函数调用和对象开销，更容易利用 CPU Cache 与 SIMD。Pipeline 把查询拆成可调度任务，固定线程池持续运行可执行任务，在 I/O 等待、网络阻塞或下游背压时让出线程，提高多核利用率并控制线程数量。

MPP 解决“如何把工作分到多台机器”，向量化解决“单个算子如何高效处理一批数据”，Pipeline 解决“多算子、多查询如何共享 CPU”。三者分别作用于分布式并行、数据处理和任务调度。

2.3 列式存储、数据组织与数据裁剪

分析查询通常只读取少量列，却扫描大量行。列式存储可以只读取参与计算的列，并对同类型数据使用字典编码、RLE、BitShuffle、LZ4 或 ZSTD 等方式压缩。数据更小，磁盘 I/O、网络传输和 CPU 解压成本也会随之变化。

Doris 的查询性能还依赖多级裁剪：

• 分区裁剪决定哪些时间段或业务范围无需扫描；
• 分桶裁剪减少需要访问的 Tablet；
• 前缀索引利用排序键快速定位数据块；
• ZoneMap 根据页级 Min/Max/Null 跳过不可能命中的数据页；
• Bloom Filter 适合高基数等值或 IN 查询；
• 倒排索引支持字符串、全文、数组和部分数值条件的快速过滤；
• Runtime Filter 在 Join 执行过程中把构建侧信息传给扫描侧，提前减少数据量。

因此，Doris 的高性能通常从建表阶段开始。数据模型、Key 顺序、分区字段、分桶键、Bucket 数和索引会共同决定扫描上限。上线后再依靠参数调优，很难完全弥补早期建模错误。

2.4 优化器、统计信息与分布式计划

Nereids 优化器负责把逻辑计划转换成物理计划，并选择 Join 顺序、Join 算法、数据分布和并行方式。规则优化负责谓词下推、常量折叠、表达式简化等确定性改写，代价优化依赖行数、NDV、Min/Max、Null Count 等统计信息估算不同计划的成本。

统计信息缺失或过期时，优化器可能低估一张大表，把它放到 Hash Join 的 Build 侧，造成内存暴涨；也可能错误选择 Broadcast，导致网络拥塞。Doris 提供自动统计信息收集，重要表在大批量导入、数据分布变化或性能回归后仍应主动检查统计信息与 EXPLAIN 结果。

优化器提高了通用 SQL 的可用性，人工设计依然有价值。高频固定查询可以通过合理分区、Colocate、物化视图和预聚合进一步降低成本；极端数据倾斜也需要结合 Profile 处理热点 Key。

2.5 物化视图与多级缓存

许多经营报表每天重复计算相同口径。物化视图把计算逻辑和结果一同保存，查询可以直接访问，也可以由优化器透明改写。

同步物化视图与基表保持强一致，适合高新鲜度的单表聚合和排序组织；异步物化视图支持多表 Join、分区增量刷新和定时刷新，适合通用 BI、数据分层和湖仓加速。设计物化视图时应先明确四件事：加速目标、数据新鲜度、涉及表数、刷新方式。

缓存负责复用近期访问的数据或计算结果。不同架构和场景会涉及页面缓存、结果缓存、行存/Row Cache、远端文件缓存等。缓存可以显著改善热点访问，冷启动、缓存失效和长尾查询仍需要真实验证。POC 应同时测试冷缓存与热缓存，避免只展示第二次执行结果。

2.6 点查、全文检索、湖仓与 AI 扩展

Doris 通过 Unique Key、Prepared Statement、短路执行、Row Store/Row Cache 等能力支持高并发主键点查，适合订单详情、用户信息、商品属性等分析型数据服务。

倒排索引把全文过滤、字符串等值和部分复杂条件融入 SQL。日志平台可以先检索文本，再按服务、机房、版本、错误码做聚合和关联，减少搜索系统与 OLAP 系统之间的数据复制。全文相关性、复杂分词、搜索产品特性和写入成本仍需按业务逐项评估。

Multi-Catalog 让 Doris 直接访问湖上表和外部数据库。对重复访问的热点数据，可结合谓词下推、文件裁剪、Data Cache 和物化视图加速。对于只访问一次的大范围扫描，缓存收益可能有限，网络、对象存储吞吐和文件布局会成为主要因素。

4.x 官方产品定位还纳入了向量检索、混合搜索、AI Functions 和 MCP。它们会在第 28–29 天展开。当前阶段只需建立一个认识：Doris 的能力边界正在从传统 OLAP 向“结构化分析 + 全文检索 + 向量检索 + Agent 数据访问”扩展，具体项目需要按版本成熟度和业务质量指标单独验收。

三、六类典型场景：从业务问题理解 Doris

3.1 实时经营看板

业务问题

管理层、运营团队、门店或 C 端用户希望持续查看 GMV、订单量、转化率、库存、履约和风险指标。数据需要快速更新，页面还可能被大量用户反复刷新。

为什么 Doris 合适

这类查询通常具有较稳定的指标口径和时间窗口，可以使用分区裁剪、同步物化视图、异步物化视图、结果缓存和高并发执行降低成本。实时链路把订单、支付和库存变化持续写入 Doris，报表直接查询最新可见版本。

验收重点

• 业务事件到页面展示的端到端 P95 新鲜度；
• 正常并发与峰值并发下的 P99；
• 数据持续写入时查询是否抖动；
• 指标口径与交易库、财务口径能否对账；
• 缓存失效、物化视图刷新和分区切换时的表现。

3.2 灵活即席分析

业务问题

分析师会临时组合区域、渠道、商品、用户、活动和时间等维度，SQL 随问题变化。传统 Cube 需要提前确定维度组合，面对大量变化时维护成本很高。

为什么 Doris 合适

MPP 把扫描、Join 和聚合分散到多台节点；CBO 根据统计信息调整 Join 顺序；Runtime Filter 把构建侧过滤信息传递到扫描侧；分区、ZoneMap、Bloom Filter 和倒排索引减少实际读取量。复杂查询内存不足时，Spill 可以用磁盘换取稳定性。

验收重点

• 选择 20–50 条代表性 SQL，覆盖单表聚合、多表 Join、窗口函数、TopN 和高基数去重；
• 记录冷缓存、热缓存、单并发和目标并发的 p50/p95/p99；
• 检查扫描行数、扫描字节、Exchange 数据量和算子耗时；
• 验证数据倾斜、统计信息过期和超大 Join 下的稳定性。

3.3 用户画像与人群圈选

业务问题

用户画像包含基础属性、行为标签、交易标签和模型分数。营销系统需要按“近 7 天活跃、位于某区域、消费等级高、未参加某活动”等条件做交、并、差和去重，结果可能直接用于广告投放或触达。

为什么 Doris 合适

BITMAP 适合保存 ID 集合并执行精确交并补，HLL 适合允许小比例误差的近似去重，Unique Key 和部分列更新支持画像字段持续变化，宽表、复杂类型和物化视图可以组织多源标签。

验收重点

• 圈选结果与离线基准对账；
• 常见标签组合与极端高基数组合的响应时间；
• Bitmap 构建、更新和存储成本；
• 多源更新乱序、晚到数据和重复数据处理；
• 圈选结果导出或下发链路的整体耗时。

BITMAP 的价值取决于数据建模。将每个用户属性机械地转换成独立 Bitmap，可能产生大量对象和维护成本。应根据标签基数、更新频率、组合方式和查询模式设计聚合粒度。

3.4 日志全文检索与可观测分析

业务问题

日志平台既要按关键词、错误栈、Trace ID、接口名检索，也要按应用、版本、机房、错误码、耗时区间进行聚合、趋势和关联分析。日志量大、字段变化快、保留周期长，存储成本和写入吞吐同样重要。

为什么 Doris 合适

Duplicate Key 适合追加日志，Variant 支持半结构化字段，倒排索引加速文本和多维过滤，列式存储与聚合引擎支持趋势分析。结构化指标、日志和 Trace 数据进入同一 SQL 体系后，故障排查可以直接关联服务元数据和业务维度。

验收重点

• 峰值写入、批次大小、索引构建对 CPU 和磁盘的影响；
• 关键词、短语、范围、多字段组合的检索延迟；
• 检索后聚合、排序和 Join 的整体性能；
• 热数据与冷数据的保留策略；
• 分词、相关性、模糊匹配和高亮等产品需求是否满足。

全文索引会占用额外存储，并增加写入和 Compaction 成本。字段选择、分词器和查询模式应在测试数据上验证，避免给所有字符串列统一建立索引。

3.5 湖仓联邦查询

业务问题

企业已经在 Hive、Iceberg、Hudi 或 Paimon 中保存大量历史数据。全部搬入新的数仓成本高，数据治理和权限体系也可能重复建设。业务希望使用统一 SQL 查询湖上历史数据，并与 Doris 热数据关联。

为什么 Doris 合适

Multi-Catalog 映射外部元数据，Nereids 负责跨源计划，Parquet/ORC Footer、分区目录和谓词下推减少文件扫描，Data Cache 缓存热点远端数据，物化视图可以把高频湖上查询结果落到更适合服务的结构中。

验收重点

• Catalog 元数据刷新与一致性；
• 分区裁剪、文件裁剪和谓词下推是否生效；
• 冷缓存与热缓存差异；
• 对象存储请求次数、远端读取字节和网络带宽；
• 小文件、分区过多、Schema 演进和权限认证；
• 跨源 Join 的数据移动和资源消耗。

湖仓查询的性能上限常由文件组织、远端存储和网络共同决定。Doris 可以改善计算和缓存路径，源端存在的大量小文件、无效分区和糟糕统计信息仍需治理。

3.6 实时更新与 CDC

业务问题

订单状态、会员等级、商品信息和用户画像会持续更新。企业希望把上游事务库变化在秒级同步到分析系统，查询始终看到每个主键的最新状态。

为什么 Doris 合适

Unique Key 模型提供主键 UPSERT，Merge-on-Write 在写入时维护可见版本，Flink CDC、DataX 或内置 Streaming Job 负责持续同步，Sequence Column 处理乱序，删除标记承接上游 DELETE。Group Commit 可以合并高频小提交。

验收重点

• 全量 + 增量切换期间是否丢数、重数；
• INSERT、UPDATE、DELETE、DDL 演进的覆盖范围；
• 事务边界、Exactly-once 或 At-least-once 语义；
• 乱序、重放、网络中断和任务重启后的结果；
• 写入吞吐、版本数量、Compaction Score 和查询波动；
• 上游高峰写入时的背压和恢复速度。

CDC 项目首先要确认业务接受的语义。单表主键状态同步、跨表事务一致性、全库 DDL 同步属于不同难度，测试方案也应分别设计。

四、Doris 与 MySQL、流处理、数据湖、搜索引擎如何协作

一个稳定的企业架构通常保留多种系统，让它们承担互补职责。

Doris 项目常见的收益来自链路收敛。例如，原架构可能把同一份日志分别写入搜索系统和数仓，一套供检索，一套供聚合。若 Doris 的倒排索引、检索语义和延迟满足需求，可以减少一份数据副本和一条同步链路。若搜索页面依赖复杂相关性、定制分词、Suggest、高亮和成熟搜索生态，专用搜索系统继续保留也很合理。

类似地，湖上数据无需全部迁移。高频报表和 API 数据可以进入 Doris 原生表，长尾历史数据保持开放格式，临时查询通过 Catalog 访问。统一指的是入口、计算与治理能够协同，系统边界仍由业务负载决定。

五、四项核心优势，以及对应的工程代价

5.1 高性能：多层协作决定上限

Doris 的性能路径可以概括为：

1. 表模型、分区、分桶和排序键先缩小扫描范围；
2. 列式存储、编码和压缩减少 I/O；
3. ZoneMap、Bloom、倒排和 Runtime Filter 跳过数据；
4. Nereids 选择 Join 顺序、分布方式与并行计划；
5. MPP、向量化和 Pipeline 使用多机多核执行；
6. 物化视图和缓存复用历史计算。

任何一层出现问题都可能拖慢查询。分桶键造成数据倾斜时，其他节点空闲，热点节点仍会成为瓶颈；统计信息过期时，优化器可能选择错误 Join；物化视图未命中时，查询会回到基表；缓存不足时，远端文件查询会增加网络读取。

所以，高性能是一项端到端工程。POC 需要保留 EXPLAIN、Profile、扫描字节、Exchange 数据量、CPU、内存和磁盘指标，才能解释结果并评估可重复性。

5.2 实时：从数据变化到业务看到结果

实时链路包含采集、传输、加工、提交、发布、查询和展示。每一层都可能积压。企业应定义一个统一时间戳链路，例如：

source_event_time
→ cdc_capture_time
→ doris_commit_time
→ query_visible_time
→ dashboard_render_time

用这些时间戳计算端到端延迟分布，才能区分瓶颈发生在上游 CDC、Flink Checkpoint、Doris 导入、物化视图刷新还是 BI 缓存。

更新模型也会影响实时性。Duplicate Key 追加最直接；Unique Key 需要维护主键状态；异步物化视图按刷新策略提供最终一致结果。业务对“最新”的定义应与数据模型保持一致。

5.3 统一：减少复制与治理碎片，同时控制工作负载干扰

统一平台可以减少数据副本、同步任务、权限重复配置和指标口径漂移。分析师使用同一套 SQL，运维团队统一监控，应用可以通过相同协议访问数据。

工作负载差异越大，治理要求越高。高并发小查询、长时间 ETL、多表 Join、日志写入和物化视图刷新会竞争 CPU、内存、磁盘与网络。生产环境通常需要 Workload Group、查询队列、内存限制、Spill、并发控制、资源标签或独立集群/Compute Group。统一数据入口不等于所有负载必须挤在同一资源池。

5.4 易用：降低接入门槛，仍需严肃对待生产运维

存算一体架构的核心进程是 FE 和 BE。FE 负责接入、元数据、优化与调度，BE 负责存储和执行，基础部署无需 ZooKeeper。MySQL 协议让 MySQL Client、JDBC、BI 工具和许多数据开发工具可以直接连接。

存算分离架构引入 Meta Service、共享存储和无状态计算节点，计算与存储可以独立扩缩容，适合云原生、多计算集群共享数据和明显波峰波谷的场景。它也增加了对象存储、缓存、网络、元数据服务和平台运维要求。架构选择应结合性能、弹性、成本和团队能力，第四天会专门展开。

“简单”主要体现在组件模型、SQL 接口和常用操作路径。生产系统仍然需要高可用、备份恢复、监控告警、容量规划、升级演练、权限治理和故障处置。

六、边界判断：哪些场景需要谨慎，哪些场景应优先选择其他系统

6.1 核心账务与复杂事务

Doris 支持单次导入事务、主键更新、SQL UPDATE 和 DELETE，这些能力服务于分析数据的持续变化。涉及多表事务、复杂隔离级别、外键约束、触发器、存储过程和核心账务一致性的系统，应继续使用成熟事务数据库或分布式事务系统。

6.2 同一主键高并发修改

订单状态 CDC 和批量 UPSERT 很适合 Unique Key。大量线程同时修改同一批主键、要求严格隔离时，冲突、锁和写放大会快速上升。应减少单行高频提交，采用批量导入、Group Commit、Sequence Column，并评估是否需要将写热点保留在 OLTP 层。

6.3 纯 KV 与极端低延迟

Doris 的点查能力适合分析型数据服务，尤其当系统还需要聚合、检索和大范围分析。若数据规模很小、访问模式只有 GET key、延迟目标极端严格，Redis、RocksDB、HBase 或专用 KV 系统通常更直接。

6.4 搜索优先型产品

日志检索和分析非常适合 Doris。若产品核心竞争力来自复杂相关性、搜索召回、定制分词、Suggest、Highlight、地理检索或成熟搜索插件，需要把这些功能逐项列入 POC。SQL 聚合能力强，无法自动覆盖所有搜索产品体验。

6.5 图遍历与路径计算

多跳关系、最短路径、社区发现和图模式匹配通常由图数据库或图计算引擎处理。Doris 可以保存图结果、节点属性和聚合指标，也可以完成有限层数的关系 Join；深度遍历和路径算法不属于其核心优势。

6.6 只有离线批处理且现有系统满足 SLA

如果业务每天只需要一次结果，Hive/Spark 已经稳定运行，数据量、成本和运维都能接受，引入新的实时分析数据库未必产生足够收益。选型应从业务价值出发，避免为了技术升级增加系统数量。

6.7 团队与组织边界

技术能力需要组织能力配套。缺少数据模型负责人、容量规划、监控告警和变更流程时，任何分布式数据库都可能演变成新的风险点。Doris 项目应明确四类责任：

• 谁定义指标口径与数据质量；
• 谁维护同步链路和表结构；
• 谁负责集群、资源和版本；
• 谁拥有 POC、上线和回滚决策权。

七、POC：用生产问题验证产品价值

7.1 先写验收标准，再搭环境

一个有效 POC 应从业务 SLA 开始。建议先完成下面这张表：

目标值需要结合业务等级制定。内部运营看板、面向客户的 API、风控决策和离线分析拥有不同 SLA，不能使用同一组门槛。

7.2 数据集必须接近生产

使用过于整齐的随机数据，可能掩盖数据倾斜、长字符串、空值、热点 Key、晚到数据和小文件问题。POC 数据应尽量保留以下特征：

• 分区规模和每日增量；
• 真实字段宽度、基数和 Null 比例；
• 热点用户、热点商品和热点区域；
• 真实更新、删除、乱序和重复比例；
• 真实文件数量和对象存储目录结构；
• 真实查询中的 Join 关系与过滤选择率。

无法使用生产数据时，可以脱敏后抽样，再按真实分布扩容。扩容过程应保留热点与倾斜，简单复制相同行数据会产生失真的压缩率和缓存命中率。

7.3 查询集要覆盖三类负载

固定高频查询用于验证看板、API 和点查；复杂分析查询用于验证 Join、聚合、窗口和高基数去重；长尾随机查询用于验证分析师临时探索。

每条查询至少记录：

• SQL 文本和业务意义；
• 返回行数与正确结果；
• 扫描分区、Tablet、行数和字节；
• p50、p95、p99；
• CPU、内存、磁盘与网络；
• 是否命中索引、物化视图和缓存；
• Profile 中最慢的算子。

测试顺序应包含冷缓存、热缓存、单并发、目标并发、峰值并发和读写混合。只跑单条 SQL 的最佳结果，无法回答生产容量问题。

7.4 写入测试要观察积压与后台任务

持续写入会生成版本和文件，后台 Compaction 需要消化这些增量。短时间压测可能看起来很快，数小时后版本堆积、Compaction Score 上升，查询开始抖动。

建议至少执行 24–72 小时稳定性测试，并持续记录：

• Stream Load / Routine Load / Connector 成功率；
• 写入批次大小和事务数量；
• 导入延迟、过滤行、错误 URL；
• Tablet 版本数和 Compaction Score；
• BE 内存、磁盘利用率和 I/O；
• 查询 p99 与写入吞吐的相互影响。

7.5 故障测试决定上线可信度

生产 POC 应主动制造故障：停止一个 BE、重启 FE、模拟网络抖动、让同步任务中断后恢复、扩容节点并观察 Rebalance。重点验证数据是否重复或丢失、查询是否降级、任务是否自动恢复、恢复时间是否达到 RTO。

对于 CDC，还要测试上游 Binlog/WAL 保留不足、Checkpoint 回退、Schema 变化、删除重放和全量重建。正确性测试的优先级高于漂亮的 QPS 数字。

7.6 形成可决策的 POC 报告

最终报告建议包含：

1. 业务目标与范围；
2. 目标版本、硬件与配置；
3. 数据模型和 DDL；
4. 数据规模与分布；
5. 导入链路和一致性语义；
6. 查询集与测试方法；
7. 正确性、性能、并发、稳定性结果；
8. 资源使用和三年成本估算；
9. 已知风险、规避方案和未验证项；
10. 上线、扩容、回滚与验收条件。

POC 的结论可以分成“适合上线”“需要补充验证”“当前不建议”三类。未达标的指标要解释瓶颈来源，避免用平均值覆盖尾延迟，也避免用热缓存结果替代冷启动表现。

八、动手实验：改造一套现有 MySQL / Hive / ES 架构

选择你熟悉的一套系统，画出改造前后的数据链路。实验不要求把所有组件移除，重点是说明每个组件为什么保留、为什么调整。

8.1 改造前信息收集

填写以下问题：

• MySQL 中有哪些分析 SQL 正在影响交易性能？
• Hive 中哪些数据只做低频历史查询，哪些指标需要实时服务？
• ES 中哪些查询以全文检索为主，哪些查询以聚合分析为主？
• Kafka/Flink 当前承担搬运、清洗、Join 还是业务规则？
• 数据端到端延迟、P99、峰值 QPS 和每日增量是多少？
• 现有系统的机器、存储、副本和运维成本是多少？

8.2 画出目标架构

建议采用以下原则：

• 核心交易保留在 OLTP 数据库；
• 实时分析数据通过 CDC、Kafka 或内置 Streaming Job 进入 Doris；
• 高频报表、即席分析、画像和分析型 API 使用 Doris 原生表；
• 低频历史数据继续保存在湖上，通过 Catalog 查询；
• 日志检索先按搜索语义和聚合需求评估，再决定 Doris 与专用搜索系统的分工；
• 流处理中的复杂事件、窗口和状态计算继续由 Flink 承担；
• 权限、指标口径、监控和数据质量统一设计。

8.3 今日交付物：《Doris 场景适配与边界说明》

推荐目录：

# Doris 场景适配与边界说明

## 1. 业务背景与现状
## 2. 当前系统与主要痛点
## 3. 数据规模、写入和查询画像
## 4. Doris 适用场景
## 5. 需要谨慎验证的场景
## 6. 明确排除的场景
## 7. 目标架构与保留组件
## 8. POC 指标、测试集和验收标准
## 9. 风险、容量与回滚条件
## 10. 最终建议

九、Knowledge Check

问题 1：Doris 的“统一”主要覆盖哪些工作负载？

参考答案： 高并发点查、实时看板、复杂即席分析、用户画像、日志检索、湖仓联邦查询，以及 4.x 中逐步增强的全文、向量和 AI 数据访问能力。具体项目要按资源、版本和业务 SLA 决定是否共用集群。

问题 2：用户画像为什么常使用 BITMAP？

参考答案： BITMAP 可以紧凑表示 ID 集合，并高效执行交、并、差、精确去重和计数。它适合亿级用户标签组合，但要根据标签基数、更新频率和聚合粒度设计，不能机械地把所有字段转换成 Bitmap。

问题 3：日志检索为什么仍需关注倒排索引成本？

参考答案： 倒排索引会增加存储、写入 CPU、内存与 Compaction 开销。分词器、索引列和查询方式也会影响效果。应使用真实日志验证写入吞吐、索引大小、检索延迟和聚合性能。

问题 4：一个合格的 Doris POC 至少要覆盖哪些维度？

参考答案： 正确性、端到端数据新鲜度、查询 p50/p95/p99、峰值并发、写入吞吐、读写混合、资源与成本、24–72 小时稳定性、节点故障与恢复，以及上线和回滚条件。

十、本日总结

今天形成了 Apache Doris 的完整产品地图：

• Doris 的核心定位是高性能实时分析数据库；
• 高性能来自存储、裁剪、优化、执行、预计算和缓存的协同；
• 实时能力贯穿数据接入、更新、发布和查询；
• 统一能力覆盖看板、即席分析、画像、检索、湖仓和分析型服务；
• MySQL、Flink/Kafka、数据湖、搜索系统与 Doris 经常共同组成企业数据平台；
• 事务、搜索、KV、图计算和团队能力决定了项目边界；
• 选型最终要落到真实 POC，重点验证正确性、尾延迟、混合负载和稳定恢复。

第三天将进入 Doris 架构内部，沿着一条 SQL 的执行链路理解 FE、BE、MPP、列式存储、向量化和 Pipeline，解释 Doris 如何把这些能力组合成可扩展的分布式查询系统。

官方资料与版本说明

本文基于 Apache Doris 官方 4.x 文档整理，功能和参数会随版本演进。生产选型请核对目标版本文档、Release Notes、Connector 版本矩阵与已知问题。

1. Apache Doris Overview
2. System Architecture
3. MPP Architecture
4. Load Overview
5. Data Update Overview
6. Materialized View Overview
7. BITMAP
8. Lakehouse Overview
9. AI Overview
10. Apache Doris Download