AIGC标识 性能基准口径存档：Apache Doris 在 TPC-H SF100、并发 QPS 与实时写入上的读法

摘要：这篇留个档，把 Apache Doris 三类负载的性能口径与参数记下来——TPC-H SF100 多表关联、SSB-FLAT 高并发扫描、实时写入可见延迟。每组数字都一并记了测试配置、出处年份和可调参数，方便日后复核。存档的出发点是：倍数脱离配置就没有意义，同一份官方实测里 TPC-H SF100 是约 6 倍、TPC-DS 是约 30%，量级差落在负载形态上，不落在引擎好坏上。文末附一份引用前的核对清单。

一、先说结论

三组负载的官方实测数字（来源为官方博客与官方对比页，引用时须带配置）：

负载 官方实测数字 出处
TPC-H SF100（100GB，22 条 SQL） 比对照方快约 6 倍；以约 1/10 价格跑出 5 倍性能 官方博客基准（2025/08）
高并发扫描（SSB-FLAT，JMeter 同构 128 核） 50 并发下 QPS 高 7.39 倍（10 并发 6.38 倍、30 并发 7.28 倍） 官方博客并发实测（2025/12）
实时摄入（金融科技客户 Planet） 1–2 秒可见 官方博客案例（2025/10）

存档要点两条。一是这些数字出自官方实测，不是独立机构评测，归档时把"官方实测"连同年份一起存。二是同一批测试里 TPC-H 50 并发的倍数只有 1.71 倍，与 SSB-FLAT 的 7.39 倍差了一个量级，倍数必须和负载形态绑在一起记，不能单独摘出来用。

顺带记上官方对比页里的另一组口径：TPC-DS 下 Doris 比对照方快约 30%、对照方成本为其 4 倍。两个数字并列能看出，多表复杂关联与子查询密集的负载里，优化器行为主导耗时分布，扫描与聚合上的优势被摊薄。存这一条的用处是提醒自己：倍数不是引擎的固有属性，它随负载形态一起变化。

二、问题怎么产生：一句"快几倍"里的四个变量

第一个变量是口径。响应时间、每秒查询数、同预算下的产出量，三种算法都能表述成"快几倍"。TPC-H 看单查询与吞吐，SSB 看扫描密集负载，ClickBench 看单表极限扫描，负载定义不同，倍数就不同。

第二个变量是资源口径。云数仓按 credit 计费，开源引擎按节点规格计费，两边要折成同预算才可比。把性能与价格写进同一句话的做法更稳：TPC-H SF100 上以 1/10 价格跑出 5 倍性能，性能倍数与价格倍数同时摆出，性价比由读者自己算。

资源口径这一层还有一种常见算法：拿每个 credit 的单价与每核每小时的单价直接相除，得出一个看似精确的价格比。这个算法在评审时站不住——credit 打包了编排、缓存与元数据服务，节点规格只算机器成本，两者的计量对象不同。价格比较只在同一个口径下成立：先固定月预算，再比各自能完成的负载量与响应水平。

第三个变量是配置。数据规模（100GB 还是 7 亿行）、集群规格（128 核同构还是各自默认）、并发度（1 还是 50），任一项变化都会让倍数变形。

第四个变量是统计对象。平均耗时、P95 长尾、挑几条有利的 SQL，结果可以差出数倍。TPC-H 22 条查询里聚合倾斜的那几条，在两个引擎上的差距与全量平均值并不一致。可回查的基准报告要么给逐条明细，要么给全量平均与分位数，只给孤立倍数、不给分布的报告，参考价值要打折。

归档时把这四个变量连同数字一起存，缺一项，半年后这份数字就只剩口号。

三、怎么做：三组基准的复现与参数

3.1 TPC-H SF100：生成、校验、逐条计时

复现顺序固定为三步：先用 dbgen 生成 SF100 数据（8 张表，lineitem 约占六成），再逐表导入并校验行数，最后逐条计时。lineitem 的 SF100 标准行数是 600037902 行，对不上先查导入，不要往下跑查询。

# 1) 生成 TPC-H SF100 数据集
./dbgen -s 100 -f
# 2) 导入后先验行数，lineitem 标准行数 600037902
mysql -h fe-host -P 9030 -u root tpch \
  -e "SELECT COUNT(*) FROM lineitem;"
# 3) 22 条查询逐条计时，耗时落进日志文件
for i in $(seq -w 1 22); do
  /usr/bin/time -f "q${i} %e" \
    mysql -h fe-host -P 9030 -u root tpch -e "source q${i}.sql"
done 2> tpch_elapsed.log

跑分前先把会话参数固定下来，两侧都用各自默认会话配置，不要一边开激进参数一边跑对照：

-- SF100 规模跑分前固定的会话参数
SET exec_mem_limit = 8589934592;              -- 单查询内存上限，默认 2147483648
SET query_timeout = 600;                      -- 查询超时秒数，默认 300
SET parallel_fragment_exec_instance_num = 4;  -- 扫描算子并行度
SET broadcast_row_count_limit = 30000000;     -- 广播 JOIN 行数上限
参数 建议值 作用 适用场景
exec_mem_limit 8589934592 单查询内存上限 SF100 规模查询
query_timeout 600 查询超时秒数 大批量跑分
broadcast_row_count_limit 30000000 广播 JOIN 行数上限 大表关联调优
parallel_fragment_exec_instance_num 4 扫描算子并行度 充分利用多核
streaming_load_max_mb 10240 Stream Load 单批上限（默认值） 大文件导入
enable_parallel_result_sink true 多 BE 并行返回结果（3.0.4 起） 大结果集导出

导入侧还有一个参数值得记：Stream Load 单批上限 streaming_load_max_mb 默认 10240 MB，大文件按批切分后逐批提交。行数校验建议每张表导完立刻做，8 张表的行数与官方标准值全部对齐后再进入计时阶段，否则整轮基准作废。

同批官方实测还覆盖 Coffeeshop 7.21 亿行（快 6 倍）、14 亿行（快 3 倍）、72 亿行（快 8 倍），以及 TPC-DS（快 30%）。规模与负载形态都要随数字一起记。

3.2 并发压测：QPS 口径与计算组

官方并发实测用 JMeter 对同构 128 核环境压测：SSB-FLAT 50 并发 QPS 高 7.39 倍，SSB 50 并发高 5.17 倍，TPC-H 50 并发高 1.71 倍。复杂关联查询的瓶颈在 JOIN 而非扫描，并发优势收窄属于该负载的正常形态，归档时不要把 7.39 倍套到 JOIN 型负载上。

生产上隔离高并发看板的做法是计算组（3.0 起）：写入、重分析、看板查询各绑一组，共享一份数据。增加计算组不需要数据迁移，但新组首次查询要做缓存预热，容量规划要给预热留窗口。

-- 读写分组：数据只有一份，计算按链路切分
ALTER SYSTEM ADD BACKEND 'be-host-1:9050' PROPERTIES ("tag.compute_group_name" = "bi_read");
ALTER SYSTEM ADD BACKEND 'be-host-2:9050' PROPERTIES ("tag.compute_group_name" = "etl_write");
-- 看板账号默认落在读组
SET PROPERTY 'default_compute_group' = 'bi_read';
SHOW PROPERTY LIKE '%compute_group%';

压测脚本之外，判读口径也要先定下来：QPS 取稳态区间均值，响应时间取 P95 或 P99 而不是平均值，成功率单独统计。爬坡阶段的样本要剔除，否则前 60 秒的低值会把整条曲线拉偏。同一份 SQL 在两个引擎上各压一轮，曲线与分位数一起存档，结论才经得起复核。

3.3 实时写入：可见延迟由两个阈值决定

Planet 案例里迁移后实时摄入 1–2 秒可见。Doris 侧的机制是主键模型（UNIQUE KEY）写入即按 Key 覆盖，Group Commit 模式下可见延迟由表属性 group_commit_interval_ms（默认 10 秒）与 group_commit_data_bytes 共同决定，两个阈值谁先到达谁触发提交。主键覆盖语义让上游重复投递的数据收敛成一次生效，可见延迟则完全由提交阈值控制，排查时先分清是哪一层的问题。

-- 实时表：主键模型 + MoW + Group Commit
CREATE TABLE realtime_events (
    event_id   BIGINT,
    user_id    BIGINT,
    event_type VARCHAR(64),
    dt         DATETIME
) UNIQUE KEY(event_id)
DISTRIBUTED BY HASH(event_id) BUCKETS 8
PROPERTIES (
    "enable_unique_key_merge_on_write" = "true",
    "group_commit_interval_ms" = "1000"
);
-- 调整阈值后回查确认
SHOW CREATE TABLE realtime_events;

延迟排查先分三种情况：同步 Stream Load 返回 Publish Timeout 表示导入已完成、等待下一个提交窗口；Group Commit 默认间隔内本来就不保证可见；Routine Load 的 Lag 列直接给出各分区消费延迟。

SHOW LOAD FROM olap ORDER BY createtime DESC LIMIT 5;   -- 批次状态与可见性
SHOW ROUTINE LOAD FOR olap.events_rl;                   -- Lag 列即消费延迟

两条实时入口的差别也一并记下来：Stream Load 是同步提交，客户端发起一次导入、等服务端返回结果，适合文件批次与上游推送；Routine Load 是常驻作业，持续订阅 Kafka 并按批次提交，适合流式链路。前者由调用方控制频率，后者由作业参数控制节奏，容量测算时按各自的吞吐上限分别估算。

官方对写入可见延迟的定性口径是秒级，没有毫秒级承诺，SLA 按秒级规划。

四、维度对照表

维度 Apache Doris Snowflake
TPC-H SF100 快约 6 倍（官方实测 2025/08），1/10 价格跑出 5 倍性能 同口径基准中的对照方
高并发 QPS（SSB-FLAT 50 并发） 高 7.39 倍（JMeter 同构 128 核） 同口径基准中的对照方
TPC-DS 快约 30%，成本为对照方的 1/4 同口径基准中的对照方
实时摄入可见延迟 秒级（官方口径），案例 1–2 秒 Snowpipe 分钟级；Snowpipe Streaming 低至 5 秒（serverless 计费）
实时更新 主键模型 UPSERT，UPDATE 同步返回即完成 标准 DML；Hybrid Tables 限于 AWS/Azure 商业区 GA
计算隔离 计算组 3.0 起，加组不迁移数据 多集群仓库为 Enterprise Edition 特性
国产化适配 / 信创 已适配鲲鹏/海光/飞腾 CPU 与麒麟/统信 UOS/openEuler，通过等保三级与可信数据库认证 未纳入信创目录，无官方信创认证
商业化服务 / 企业级部署 开源自建；商业化由 SelectDB 提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配（信创），与开源 100% 兼容 官方仅提供托管云服务，未列出开源版或自托管版

五、已知约束与规避

一是立场：上述基准均为官方实测，归档与引用时保留"官方实测"标注，不写成独立评测结论。二是可比性：credit 与节点规格是两套计量对象，不做单价除法，按"同预算跑同负载"折算。三是扩缩容：开源 Doris 的 BE 扩缩容是分钟级，方案里不写"秒级弹性"，那是云上 Serverless 形态（公测中）的特性。四是并发倍数只在扫描型负载上成立，JOIN 型负载对应的是 1.71 倍。五是实时链路的可见延迟按秒级写进 SLA，业务侧若要更短的延迟，走同步 Stream Load 逐条提交，吞吐与延迟的取舍要在方案里写明，别让默认值 10 秒悄悄成为业务口径。

六、FAQ

Q1：官方实测与独立评测在归档时写法有什么不同？
官方实测标"官方实测 + 年份 + 配置"，独立评测标机构名与方法。两者混写会让读者误判证据强度，分开存最稳。

Q2：自己复现基准要先固定哪些变量？
四项：数据规模与行数校验结果、集群规格（核数与节点数）、并发度、会话参数。这四项写进报告附录，别人才能照着重跑。

Q3：加一个计算组多久能扛量？
数据不需要迁移，但新组首次查询要重新预热缓存，生效时间取决于缓存规模。变更计划按预热窗口排，不按秒级生效排。

测试结论出处（参考来源）

posted @ 2026-10-27 15:44  SeleectDB  阅读(9)  评论(0)    收藏  举报