播面

传统上，Apache Doris 被广泛认知为一款优秀的 OLAP（在线分析处理）引擎，主要擅长处理海量数据的复杂分析、聚合和多表关联（Join）。然而，随着架构的演进（特别是从 1.2 和 2.0 版本开始），Doris 在架构层面进行了大量针对性的重构和优化，使其不仅能做大宽表的复杂分析，还能完美胜任高并发的点查询（Point Query），即“Data Serving”场景。

之所以说 Doris 的架构非常适合实现高并发点查询，核心在于它打破了传统列式存储引擎的局限，引入了以下几个关键的架构设计和优化：

1. 引入行存引擎（Row Store），解决列存拼装开销

• 传统列存的痛点：在传统的纯列式存储中，一条记录的几十个字段被分散存储在不同的数据块中。如果执行 SELECT * FROM table WHERE id = 123，存储层需要分别去磁盘读取几十个列的数据块，然后在内存中重新拼接（Tuple Reconstruction），这在极高并发下会导致严重的 CPU 和 I/O 放大。
• Doris 的架构解法：Doris 引入了行列混存的架构。用户可以在建表时开启 light_schema_change 并配置开启行存。Doris 会在底层自动将整行数据序列化后，以一个隐藏列（Hidden Column）的形式存储。当发生主键点查询时，Doris 直接定位到该行，只需一次 I/O 就能将整行数据读出，彻底消除了列拼接的开销。

2. 短路径查询执行计划（Short-Circuit Plan）

• 传统 MPP 架构的痛点：通常的查询需要经过 FE（Frontend）的 SQL 解析、语法分析、优化器生成分布式执行计划、将 Fragment 下发给多个 BE（Backend）、BE 启动复杂的执行算子流水线、最后汇总结果。这个链路对于点查询来说太重了，调度开销远大于实际的数据读取时间。
• Doris 的架构解法：Doris 为点查询开辟了“绿色通道”（Short-Circuit）。当 FE 识别到查询是基于主键或唯一键的精准匹配（如 WHERE pk = ?）时，会直接跳过复杂的优化器和查询调度逻辑。FE 直接计算出该主键所在的 Tablet（分片）和具体的 BE 节点，然后通过极其轻量级的 RPC 请求直接向目标 BE 发送获取单行数据的指令，大幅降低了 CPU 消耗和查询延迟。

3. 高性能的行缓存机制（Row Cache）

• 为了支撑数万甚至十万级的并发 QPS，单纯依赖磁盘 I/O 是不够的。
• Doris 在 BE 节点引入了专门的 Row Cache（行缓存）。当基于主键的查询命中 BE 时，会优先查找 Row Cache。如果命中，数据直接从内存返回，完全不涉及底层存储引擎的查找，使得点查询的延迟可以稳定在亚毫秒级（< 1ms）。

4. 预编译语句（Prepared Statement）的支持

• 在高并发场景下，前端 FE 解析 SQL 字符串的开销会成为系统的瓶颈。
• Doris 支持 MySQL 协议的 Prepared Statement。客户端可以预先编译 SQL 模板，后续的高并发请求只需要传输二进制的参数（而不是长串的 SQL 文本）。FE 会缓存这些预编译的 Plan，从而省去了绝大部分的 SQL 解析和规划开销，极大提升了 FE 处理极高并发连接的吞吐量。

5. 优化的主键索引（Primary Key Index）

• Doris 的 Unique Key 模型在 2.0 版本之后引入了更加高效的主键索引。
• 通过在内存中维护主键到具体文件的位置映射（甚至支持持久化的主键索引），Doris 可以在 $O(1)$ 或 $O(\log N)$ 的时间复杂度内极其快速地判定主键是否存在，并精准定位到数据所在的具体 Block。避免了传统 OLAP 引擎利用 Bloom Filter 和 Min/Max 索引进行模糊过滤带来的额外开销。

6. 轻量级 RPC 与高并发连接处理

• 为了应对数据服务场景下海量的并发连接，Doris 的 FE 和 BE 底层的网络通信模块进行了深度优化，基于 Netty 实现了高性能的异步网络框架。
• 特别是在点查询的短路径中，使用了更为精简的 RPC 协议结构，减少了序列化/反序列化的代价。

---

总结

传统的数据库往往面临“鱼与熊掌不可兼得”的困境：

• 用 MySQL/HBase 做高并发点查，但无法做大规模复杂分析；
• 用 ClickHouse/Greenplum 做分析，但在高并发点查时 CPU 瞬间打满。

说 Doris 架构非常适合点查询，是因为它在不破坏原有 MPP 列存分析能力的前提下，"内嵌" 了一套类似于 KV 存储的执行路径：
「Prepared Statement (降解析开销) -> FE 路由直达 (降调度开销) -> BE 行缓存命中 (降 I/O) -> 底层行存读取 (降拼装开销)」。

这套架构使得 Doris 能够在一套系统内同时满足 复杂报表分析 (OLAP) 和 高并发业务数据服务 (Data Serving)，极大地简化了企业的数据架构（例如不再需要将 Doris 中的数据再同步到 HBase 或 Redis 中对外提供高并发查询）。