Apache Doris 核心原理

共 20 题
📑 题目列表 20 题
#
★★★

1. Doris 的 MPP 架构、Aggregate/Unique/Duplicate 三种表模型的适用场景与区别?

Doris 的 MPP 架构是怎样的?Aggregate、Unique、Duplicate 三种表模型分别适用于什么场景,有什么区别?

  • MPP 架构中 FE 与 BE 的分工
  • 三种表模型的数据组织与更新语义
  • 按写入与查询模式选型

Doris 是 MPP(Massively Parallel Processing)分析型数据库:FE(Frontend)负责元数据管理、SQL 解析与分布式执行计划生成,BE(Backend)负责数据存储与查询执行,查询被切分为分布式计划在多个 BE 并行执行并汇总结果,配合向量化执行提升吞吐。三种表模型:Duplicate 明细模型保留所有导入行,无去重无聚合,适合日志、事实明细等无需更新的场景;Aggregate 聚合模型按聚合键预聚合(SUM/MAX/MIN/REPLACE 等),导入时部分聚合,查询命中预聚合结果,适合高频统计报表;Unique 唯一键模型按主键去重,后导入的数据覆盖旧值(upsert 语义),适合订单、用户状态等可变数据。

区别与选型:Duplicate 最灵活但无更新语义;Aggregate 把聚合下推到存储、查询快,但只能按预定义聚合键查询且无法精确查明细;Unique 支持实时 upsert 但查询需合并版本(MOR)。选型口诀:需要明细可查选 Duplicate,高频汇总统计选 Aggregate,主键更新场景选 Unique。

三种模型本质是"数据组织与更新语义"的三种选择:保留全部、预聚合、主键覆盖。先讲 MPP 架构定基调,再按模型语义与场景展开,最后给出选型结论。

-- 三种表模型建表示例
CREATE TABLE dup_log (                 -- 明细模型
  event_time DATETIME, user_id BIGINT, page STRING
) DUPLICATE KEY(event_time)
DISTRIBUTED BY HASH(user_id) BUCKETS 10;

CREATE TABLE agg_sale (                -- 聚合模型
  dt DATE, channel STRING, gmv DECIMAL(14,2) SUM
) AGGREGATE KEY(dt, channel)
DISTRIBUTED BY HASH(channel) BUCKETS 10;

CREATE TABLE uni_order (               -- 唯一键模型
  order_id BIGINT, status STRING, amount DECIMAL(12,2)
) UNIQUE KEY(order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 10;
#
★★★

2. Doris 的 Rollup、物化视图与查询改写(Query Rewrite)如何加速报表?

Doris 的 Rollup 与物化视图如何实现预聚合?查询改写(Query Rewrite)的命中条件是什么?

  • Rollup 的维度前缀预聚合原理
  • 物化视图与 Rollup 的区别
  • 查询改写的命中条件与监控

Rollup 是基于基表的预聚合索引:按更少的维度组合对明细/聚合表预计算,查询匹配 Rollup 维度前缀时自动改写命中,减少扫描与聚合计算量。物化视图则是把"查询结果"物化存储,支持更复杂的预聚合(多表 Join、表达式、过滤),由后台任务异步刷新,查询时优化器自动改写复用。二者都是"以空间换时间"的预聚合手段。

查询改写条件:查询的维度、聚合函数、谓词必须是 Rollup/物化视图定义的子集,命中则扫描小数据量,未命中回退基表。实践要点:对高频报表的维度组合建 Rollup/物化视图,监控命中率与存储开销,避免物化对象过多导致存储放大与刷新成本上升。

加速本质是"预聚合 + 自动改写",回答讲清 Rollup 与物化视图的机制差异、改写命中条件与运维注意点。

#
★★★

3. Doris 的 Runtime Filter(IN/MIN-MAX/Bloom)在 Join 优化中的作用

Doris 的 Runtime Filter 在 Join 优化中起什么作用?IN、MIN-MAX、Bloom 三种类型各自适用什么场景?

  • Runtime Filter 的生成与下推原理
  • 三种类型的适用条件与误判
  • 对扫描量的裁剪收益

Runtime Filter 在 Join 执行过程中,用驱动侧(build 侧,通常是小表)的实际值集合构造过滤条件,运行时下发给被驱动侧(probe 侧,大表)的扫描层,提前过滤不参与 Join 的行,减少大表扫描与 Shuffle 的数据量。三种类型:IN Filter 精确列举值,适合驱动侧值较少(NDV 小)的场景;Bloom Filter 用位图近似判断"可能存在",适合值较多(NDV 大)的场景,存在少量误判但能过滤绝大多数不匹配数据;MIN/MAX Filter 用值域范围过滤,适合有序列的等值或范围 Join。

适用原则:小表驱动大表时收益最大;优化器根据驱动侧 NDV 自动选择类型,也可通过 Hint 手动指定;Runtime Filter 的下推需要扫描层支持(配合 ZoneMap、索引),过滤率低时会引入额外开销,需要监控过滤率与命中收益。

Runtime Filter 是"运行期统计驱动的数据裁剪",回答讲清原理、三类类型的特点与适用场景,以及收益与开销的权衡。

#
★★★

4. Doris 的四种 Join 策略(Broadcast、Shuffle、Colocate、Bucket Shuffle)各自适用什么数据分布?Colocate Join 为什么要求同分桶键?

Doris 的 Broadcast、Shuffle、Colocate、Bucket Shuffle 四种 Join 策略分别适用什么数据分布?Colocate Join 为什么要求两表分桶键一致?

  • 四种 Join 策略的原理与适用条件
  • Colocate 同分桶键的原因
  • 策略选择与数据倾斜的影响

四种策略的本质是"让 Join Key 相同的数据落到同一节点进行关联":Broadcast 把小表复制到所有 BE 与各分片大表本地关联,适合小表 Join 大表,代价是广播内存占用;Shuffle 将两表按 Join Key 哈希重分布到相同的 BE 集合,通用但网络代价大;Colocate 要求两表分桶键与分桶数完全一致且分布在同一 BE 组,相同 Key 的数据天然落在同一 BE,Join 时本地关联、无网络 Shuffle;Bucket Shuffle 适用于单表已按 Join Key 分桶的场景,另一侧按桶裁剪重分布,减少 Shuffle 量。

Colocate Join 要求同分桶键,是因为分桶哈希决定数据分布:只有分桶键一致、桶数一致,相同 Key 才会被哈希到同一 BE 的同一桶,才能实现本地 Join;分桶键不一致则相同 Key 落在不同节点,必须退化为 Shuffle。实践:小表用 Broadcast,两张大表且分桶规划一致用 Colocate,无约束用 Shuffle,单表已按 Join Key 分桶用 Bucket Shuffle;建 Colocate 表组时需提前规划分桶键与桶数,并注意数据倾斜。

四种策略对应"如何把相同 Key 的数据聚合到同一节点"的四种做法:复制、重分布、预先共置、部分裁剪。回答按数据分布对应策略,并解释同分桶键的必要性。

#
★★★

5. Doris 的 Segment 存储结构与 ZoneMap、前缀索引(Short Key Index)如何协同加速点查与范围扫描?

Doris 的 Segment 存储结构是怎样的?ZoneMap 与前缀索引(Short Key Index)如何协同加速点查与范围扫描?

  • Segment 的列式存储与两级索引
  • ZoneMap 的块级裁剪原理
  • 前缀索引的定位机制与协同

Segment 是 Doris 的基本数据文件单元,内部按列存储:每列编码压缩后按数据块(Page)组织,并携带两级索引——列级索引(ZoneMap、BloomFilter)与行级索引(前缀索引/Short Key)。ZoneMap 记录每列每个数据块的 min/max 值,查询时先比较谓词与 ZoneMap,跳过不满足条件的数据块,实现块级裁剪,对等值与范围查询都有效。

前缀索引(Short Key Index)取表的前 36 字节中的前序列(最多 3 列)建立稀疏索引,记录起始行号,加速点查与范围扫描的起始定位。协同过程:谓词先经前缀索引定位到起始行,再经 ZoneMap 逐块裁剪,配合列裁剪只读所需列,最终只扫描极少数据。注意:前缀索引只对前缀列生效,查询条件不含前缀列时退化为全扫描加 ZoneMap 过滤,因此高频查询列应尽量前置。

加速链路 = 前缀索引定位起点 + ZoneMap 裁剪数据块 + 列式只读所需列,回答讲清两级索引的分工与协同,并点出前缀索引的适用边界。

#
★★

6. Doris 的分区分桶策略与数据倾斜治理(Bucket 数、分桶键选择)?

Doris 的分区与分桶策略如何设计?分桶键与桶数如何选择,数据倾斜如何治理?

  • 分区与分桶的职责划分
  • 分桶键与桶数的选择原则
  • 数据倾斜的定位与治理手段

分区通常按时间(天/月)划分,用于分区裁剪与生命周期管理;分桶按分桶键哈希分布数据,决定数据分布与查询并行度。桶数建议取集群 BE 数的整数倍,过大增加元数据与调度开销,过小并行度不足;分桶键应选择高基数列且是查询等值条件常用列,避免选择低基数或时间列(时间列已用于分区)。

数据倾斜治理:分桶键低基数或热点 Key 导致单桶数据量大,查询单桶扫描慢、并行不均。手段:换高基数分桶键、热点 Key 加盐(Salt)扩展、调整桶数重新分桶、利用 Colocate 组均衡分布;同时监控各桶数据量分布,定位倾斜桶并针对处理。分区裁剪与分桶分布共同决定查询扫描量,是性能调优的基础。

分区管"裁剪",分桶管"分布与并行",倾斜治理核心是"高基数分桶键 + 合理桶数 + 热点检测",回答按职责与治理展开。

#
★★

7. Doris 的导入方式(Stream Load/Broker Load/Routine Load)与 Exactly-Once 语义?

Doris 的 Stream Load、Broker Load、Routine Load 三种导入方式分别适用什么场景?Exactly-Once 语义如何保证?

  • 三种导入方式的特点与选型
  • label 幂等与两阶段提交
  • 与 Flink 协同的端到端一致性

Stream Load:同步 HTTP 导入,面向高频小批量实时数据(Flink/程序直接调用),返回导入结果,适合实时链路;Broker Load:异步导入,通过 Broker 读取 HDFS/S3 等文件系统上的文件,适合大规模离线批量文件;Routine Load:常驻任务自动消费 Kafka 消息导入,自动管理消费位点,适合实时流数据持续接入。选型按数据源与批量大小:程序直推用 Stream Load,文件批量用 Broker Load,Kafka 流用 Routine Load。

Exactly-Once 语义:每次导入生成唯一 label,同一 label 重复提交自动去重(幂等),失败重试沿用原 label 不产生重复;配合 Flink 两阶段提交(Stream Load 事务接口)实现端到端 Exactly-Once,Routine Load 的位点管理与 Flink checkpoint 协同,保证故障恢复后不丢不重。

导入 = 通道(HTTP/文件/Kafka)+ 语义(label 幂等 + 事务),回答按三种方式的特点选型,再讲清楚 Exactly-Once 的 label 机制与 Flink 协同。

# Stream Load 示例:curl 提交,label 唯一用于幂等
curl -X PUT -u user:pass \
  -H "label: import_20260804_0001" \
  -H "Expect: 100-continue" \
  -T /data/orders.csv \
  "http://fe_host:8030/api/db/orders/_stream_load"
#
★★

8. Doris 的 Unique Key 模型实现,MOR(Merge on Read)与部分列更新对实时写入与查询性能的影响?

Doris 的 Unique Key 模型如何通过 MOR(Merge on Read)实现去重?部分列更新对实时写入与查询性能有什么影响?

  • MOR 的写入追加与查询合并原理
  • 部分列更新的语义与收益
  • 版本数对查询的影响与优化

Unique 模型按主键去重,传统实现为 MOR(Merge on Read):写入时直接追加新版本数据(不立即合并),查询时按主键合并同 Key 的多版本取最新值。优点是写入快、实时可见性强,但查询需要合并版本,版本数越多合并开销越大;新版支持部分列更新:更新语句只更新指定列,配合写入标记,避免整行重写,适合宽表局部字段频繁变更的场景。

性能影响:MOR 是"写入快、查询有合并成本"的权衡,导入频率过高会产生大量小版本,导致查询变慢、Compaction 压力增大;治理手段:控制导入频率与批次、定期 Compaction 合并版本、监控版本数与查询延迟;高频更新且查询性能敏感的场景可考虑持久化索引式主键模型(如 StarRocks Primary)或对热表做合并优化。

MOR 的核心权衡是"写入只追加、查询时合并",部分列更新减少写入放大,回答讲清机制、代价与治理手段。

#
★★

9. Doris 的查询引擎,MPP 执行、向量化与 CBO 如何协同,Pipeline 执行引擎解决了什么问题?

Doris 的 CBO、MPP 执行与向量化如何协同?Pipeline 执行引擎解决了什么问题?

  • CBO、MPP、向量化的分层职责
  • Pipeline 执行引擎解决的问题
  • 协同机制与收益

三层协同:CBO 基于统计信息生成最优执行计划(Join 顺序、Join 策略、Runtime Filter 等);MPP 把计划分布到多个 BE 并行执行,通过数据本地化与 Shuffle 协同;向量化执行按批处理列数据,利用 CPU 缓存与 SIMD 指令,减少逐行解释与虚函数调用,吞吐远高于传统火山模型。CBO 定计划、MPP 定分布、向量化定执行效率。

Pipeline 执行引擎解决的问题:传统执行器算子间数据交互与线程调度开销大,并发查询的资源利用不均。Pipeline 把算子流水线化,算子间以流水方式拉取数据,减少中间物化与线程切换,配合 DAG 调度与动态并行度,提升多查询并发下的资源利用率与整体吞吐。回答时按"优化、分布、执行、调度"四个层次讲清各自职责与配合。

四者分层清晰:CBO 优化计划、MPP 分布并行、向量化批量执行、Pipeline 优化调度,回答按层展开并说明 Pipeline 解决的具体问题。

#
★★

10. Doris 的架构,FE(前端)与 BE(后端)的职责划分?

Doris 架构中 FE(Frontend)与 BE(Backend)的职责分别是什么?二者如何协同与保障高可用?

  • FE 的元数据与查询计划职责
  • BE 的存储与执行职责
  • 两者协同与高可用机制

FE(Frontend):负责元数据管理(库表、分区、副本元数据)、SQL 解析/优化/执行计划生成、导入任务协调、权限管理与集群管理,对外提供 MySQL 协议 SQL 入口;多个 FE 通过 BDB JE(Berkeley DB Java Edition)选举主 FE,主 FE 写元数据日志并同步到从 FE,主 FE 故障自动切换,从 FE 提供只读服务与负载均衡。BE(Backend):负责数据存储与查询执行——Segment/Tablet 存储、Compaction、向量化执行、扫描过滤(ZoneMap/索引)、数据导入执行;BE 无状态(元数据在 FE),多 BE 横向扩展,故障后由 FE 调度副本修复。

协同机制:FE 生成分布式执行计划,BE 按计划执行并把结果汇聚回 FE;FE 通过心跳感知 BE 状态,调度副本均衡与修复;导入任务由 FE 协调、BE 执行并返回 label 状态。整体是典型的 MPP shared-nothing 架构加中心化元数据。

FE 管"脑"(元数据与计划),BE 管"手"(存储与执行),回答讲清职责边界、协同通信与高可用机制。

#
★★

11. Doris 的 tablet 副本机制与数据修复(副本均衡、校验)

Doris 的 tablet 副本机制是怎样的?副本均衡、故障修复与一致性校验如何实现?

  • tablet 与副本的分布原则
  • 副本修复与均衡的调度主体
  • 一致性校验机制

表数据按分区分桶划分成 tablet,每个 tablet 有多个副本(默认 3 个)分布在不同的 BE 上,由 FE 根据集群拓扑调度,保证同一 tablet 的副本分布在不同的 BE(甚至机架),支撑高可用与负载均衡;查询时选择最优副本(本地优先、延迟低者优先),副本故障不影响可用性。

修复与均衡:BE 故障或副本落后时,FE 检测到副本不可用,调度在其他健康 BE 上补建副本(从健康副本克隆数据);集群增减 BE 或数据分布不均时,FE 执行 tablet 迁移实现均衡。一致性校验:周期性对副本做 checksum 校验,发现静默损坏后重克隆修复。运维上关注副本健康度、均衡度与修复积压指标。

副本 = 可用性保障,均衡 = 性能保障,修复/校验机制实现"自我恢复",回答讲清调度主体(FE)与各动作,以及运维关注点。

#
★★

12. Apache Doris 的 BloomFilter 索引、Bitmap 索引与倒排索引三种二级索引分别加速什么查询?为什么 BloomFilter 索引适合高基数列的等值过滤(=、IN)但存在误判,Bitmap 索引适合低基数列的精确去重(count distinct),它们与内建前缀索引/ZoneMap 如何协同?

Doris 的 BloomFilter 索引、Bitmap 索引与倒排索引分别加速什么查询?它们与内建前缀索引、ZoneMap 如何协同?

  • 三种二级索引的加速对象与原理
  • BloomFilter 误判与适用基数、Bitmap 的精确去重
  • 多级索引的协同过滤链路

BloomFilter 索引为列建位图,用来判断"值一定不存在",存在少量误判但不会漏判:适合高基数列的等值过滤(=、IN),先用位图过滤绝大多数不匹配的数据块,再对可能命中的块逐行确认,减少扫描量。Bitmap 索引为每个值建立行位图,精确匹配与位图交集/并集运算高效,适合低基数列的等值过滤与精确去重(count distinct)、多维组合过滤。倒排索引按词/值建立倒排表,加速文本检索、字符串前缀与全文匹配(LIKE、分词查询)。

协同机制:前缀索引(Short Key)定位起始行,ZoneMap 按数据块 min/max 裁剪,BloomFilter 做块级"可能命中"过滤,Bitmap/倒排索引做行级精确匹配,多级索引逐层收窄扫描范围。选择原则:高基数等值过滤用 BloomFilter,低基数精确去重与多维过滤用 Bitmap,文本搜索用倒排索引。

三类索引 = 三种数据结构(概率过滤器/位图/倒排表),回答按"加速什么查询 + 适用基数 + 协同位置"组织,重点解释 BloomFilter 误判与 Bitmap 精确性的差异。

-- 建表时配置二级索引
CREATE TABLE t_user (
  user_id BIGINT, name STRING, city STRING
) DUPLICATE KEY(user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 10
PROPERTIES (
  "bloom_filter_columns" = "user_id"
);
CREATE INDEX idx_name ON t_user (name) USING INVERTED;
CREATE INDEX idx_city ON t_user (city) USING BITMAP;
#
★★

13. Doris 的 Cumulative 与 Base Compaction 如何控制版本数?版本过多对查询与导入的影响是什么?

Doris 的 Cumulative 与 Base Compaction 如何控制版本数?版本过多对查询与导入有什么影响?

  • 两级 Compaction 的分工
  • 版本过多的后果
  • 版本治理与参数调优

每次导入会生成新版本(rowset),Doris 用两级 Compaction 控制版本数:Cumulative Compaction 把近期产生的多个小版本合并成中等版本,将活跃版本数维持在可控阈值内;Base Compaction 把历史版本与基础数据合并成大版本,周期性处理积压。两级配合使在线版本数保持平稳,兼顾写入频率与合并成本。

版本过多的影响:查询需要合并/扫描更多版本,延迟上升;导入可能被 Compaction 触发而变慢;元数据膨胀、调度与磁盘 IO 压力增大。治理手段:监控版本数与 Compaction 积压,调优 Cumulative 合并阈值与调度间隔,避免导入过于零碎(攒批导入),必要时手动触发 Compaction。

Compaction 是"合并小版本降低版本数"的异步后台机制,两级分层平衡写入频率与合并成本,回答讲清分工、影响与治理。

#
★★

14. Doris 的 Schema Change 为什么加列是轻量操作而删列或改类型是重量操作?两种路径分别如何影响查询与副本?

Doris 的 Schema Change 中为什么加列是轻量操作、删列或改类型是重量操作?两种路径分别如何影响查询与副本?

  • 加列只改元数据与默认值补齐
  • 删列/改类型需重写数据
  • 两种路径对查询与副本的影响

加列是轻量操作:新列带默认值,无需重写已有数据,只更新元数据并在新写入数据中填充,旧 Segment 查询时按默认值补齐,秒级完成,对查询与副本几乎无影响。删列或改类型是重量操作:需要重写全部历史数据(新旧结构转换),生成新版本并在后台异步执行,期间占用 IO 与空间,涉及所有副本,执行时间与数据量成正比。

影响与运维:重量操作执行期间查询可能变慢、导入受限,需规划在低峰期执行,可通过限制并发与速度控制影响;实践中频繁加列没有问题,删列/改类型要评审,优先考虑新建表加数据迁移的方式规避风险。

轻 vs 重的本质是"是否重写数据":加列只改元数据加默认值补齐,删改需全量重写,回答讲清原理与运维影响。

#

15. Doris 存算分离(Compute-Storage Separation)在云原生场景的演进?

Doris 的存算分离(Compute-Storage Separation)架构如何演进?在云原生场景下有什么收益与挑战?

  • 存算分离的架构组成
  • 云原生场景的收益
  • 缓存与元数据的挑战

传统 Doris 存算一体,BE 本地盘存数据,扩容需要数据迁移;存算分离(Doris 2.x Cloud 模式/SelectDB Cloud)把数据放到对象存储(S3/OSS)或 HDFS,计算节点(BE)本地只缓存热数据(Cache),元数据与目录服务独立部署,形成"共享存储 + 无状态计算"的架构。

收益:存储与计算独立扩缩容,计算弹性按需拉起与释放;存储用低成本对象存储,多集群可共享同一份数据;适合云原生 Serverless 化与按量计费。挑战:本地缓存命中率决定查询性能,冷数据访问有网络延迟,需要缓存预热与调度感知;对象存储的请求成本与带宽需规划。演进方向是 Serverless、多租户隔离与按量计费。

存算分离的本质是"数据入对象存储 + 计算弹性 + 缓存加速",收益与缓存代价并存,回答按架构、收益、挑战展开。

#

16. Doris 的物化视图与 Rollup,预聚合的查询改写?

Doris 的物化视图与 Rollup 在预聚合与查询改写上有什么区别?各自的使用场景是什么?

  • Rollup 与物化视图的机制区别
  • 查询改写的命中条件
  • 使用场景与运维注意

Rollup 是基表维度的预聚合索引,只能基于单表,按维度组合预聚合,命中条件要求查询维度是 Rollup 维度前缀;物化视图基于任意查询(多表 Join、表达式、过滤)物化结果,由后台任务异步刷新,支持的预聚合形式更丰富。二者都以空间换时间,查询时优化器自动改写命中预聚合对象。

改写条件:查询的维度、聚合与谓词必须是物化对象的子集,命中则扫描小数据,未命中回退基表。实践:高频报表的固定维度组合优先用 Rollup,复杂多表聚合用物化视图;监控命中率与存储开销,避免物化对象过多造成存储放大。

Rollup 是"维度前缀预聚合",物化视图是"查询结果物化",同属改写加速,按复杂度选择,回答讲清区别与命中条件。

#

17. Doris 的查询优化,CBO、向量化与 Runtime Filter?

Doris 的 CBO、向量化执行与 Runtime Filter 在查询优化中如何配合?

  • 三者的职责与协同
  • 查询优化的关键手段
  • 调优实践

CBO:基于统计信息(行数、基数、直方图)选择 Join 顺序、Join 策略(Broadcast/Shuffle/Colocate)与索引利用,生成最优执行计划;向量化:列式批处理执行,SIMD 加速扫描、过滤与聚合计算;Runtime Filter:运行期用 Join 小表的实际值动态过滤大表,减少扫描与 Shuffle 数据量。三者形成"计划-执行-动态裁剪"的优化链路。

调优实践:定期更新统计信息保证 CBO 决策准确;合理设计表模型、分区分桶与索引;监控 Runtime Filter 过滤率与 Join 策略选择;用 Query Profile 定位扫描量、Join 与聚合瓶颈,针对性调整。回答按层讲清各自职责与配合关系。

三者是"计划优化、执行加速、运行期裁剪"三个层次,回答体现层次关系与调优落点。

#

18. Doris 的高可用,FE 选举与 BE 多副本?

Doris 的高可用如何实现?FE 选举与 BE 多副本各自的作用是什么?

  • FE 的 BDB JE 选举与元数据同步
  • BE 多副本与自动修复
  • 故障切换流程

FE 高可用:部署多个 FE 节点,通过 BDB JE(Berkeley DB Java Edition)选举主 FE,主 FE 写元数据日志并同步到从 FE,主 FE 故障时自动切换,元数据不丢失;从 FE 提供只读查询服务与连接负载均衡,客户端无感知。BE 高可用:数据多副本分布在多个 BE,单 BE 故障时 FE 感知并调度副本补建与均衡,查询自动规避故障 BE。

导入侧 label 幂等支持重试,整体形成"控制面无单点 + 数据面多副本自愈"的高可用体系。运维关注 FE 选举状态、BE 心跳、副本健康度与均衡度。

高可用 = 控制面(FE BDB JE 选举)+ 数据面(BE 副本自愈),回答分两面讲清机制与切换流程。

#

19. Doris 与 StarRocks 的生态差异,社区、运维与商业支持?

Doris 与 StarRocks 在社区、运维与商业支持上有哪些生态差异?选型时如何权衡?

  • 两引擎的开源与商业化路线
  • 运维与特性兼容性差异
  • 按生态需求选型

两引擎同源(StarRocks 源自 Doris 早期分支),后续独立发展:Doris 由 Apache 基金会孵化,社区驱动,版本迭代快,周边连接器与文档生态丰富;StarRocks 早期商业化主导(后期开源),阿里云 EMR 等云厂商托管集成成熟,商业支持与技术支持体系完善,企业级服务更成熟。

运维与兼容:两者架构相似(FE/BE、分区分桶、副本),运维方式接近,但特性有差异(主键模型、物化视图、SQL 语法细节),迁移需评估兼容性。选型:偏好 Apache 开源生态与社区驱动选 Doris;需要强商业支持、云托管与技术支持保障选 StarRocks;综合评估社区活跃度、版本稳定性、周边工具与团队运维能力。

生态差异本质是"社区开源 vs 商业化"的路线差异,回答按社区、运维、商业支持三个维度展开并给出选型建议。

#

20. Doris 的查询内存控制(执行内存限制、Spill 落盘)与慢查询定位

Doris 如何通过执行内存限制与 Spill 落盘控制查询内存?慢查询如何定位与优化?

  • 执行内存限制与查询队列
  • Spill 落盘的机制与代价
  • 慢查询定位与优化手段

内存控制:BE 有执行内存上限(exec_mem_limit),查询内存超限会被拒绝或降级,支持内存超卖配置与查询队列,高峰时排队保护集群稳定;Spill 落盘:大查询的中间结果、排序、Join 数据可溢出到磁盘,避免 OOM,但落盘读写会显著降低性能,按需启用并监控落盘量。

慢查询定位:通过 Query Profile 查看每个算子的耗时、扫描行数、内存占用,结合慢查询日志与审计定位瓶颈;常见原因:扫描量大(分区裁剪/索引未命中)、Join 策略不当(未走 Colocate/Broadcast)、过滤率低、并发过高。优化手段:调整分区分桶、补充索引与 BloomFilter、改 Join 顺序与策略、限制并发与队列、建 Rollup/物化视图预聚合。

内存治理 = 限额 + 溢出 + 队列,慢查询 = Profile 定位 + 针对性优化,回答给出完整闭环。