Doris与ClickHouse实战避坑指南：写入、查询、Schema变更六大差异

1. 这张表不是选型指南而是我踩过坑后画的“避雷地图”刚接手一个实时报表平台重构项目时团队在 Doris 和 ClickHouse 之间卡了整整三周。不是因为技术文档看不懂而是所有公开资料都在说“Doris 兼容 MySQL 协议”“ClickHouse 性能无敌”但没人告诉我当我要把一张 20 亿行、每天新增 8000 万条的用户行为日志表从 MySQL 迁过去时Doris 的 Merge-on-Write 模式会在凌晨自动触发 Compaction而 ClickHouse 的 Part 命名规则会让 FlinkSQL 写入时突然报错PARTITION BY不匹配——这两个问题根本不会出现在任何官方对比表格里。这张表就是我在生产环境连续两周凌晨三点排查日志、翻源码、改配置、重跑任务后用 Excel 一格一格填出来的实战差异清单。它不讲理论性能数字不列官网参数对比只回答六个最痛的问题写入链路断在哪FlinkSQL 写 Doris Union Key 表 vs ClickHouse ReplacingMergeTree查询慢到底慢在哪Doris 的谓词下推深度 vs ClickHouse 的向量化执行边界表结构改了怎么不生效Doris Schema Change 的阻塞条件 vs ClickHouse ALTER TABLE 的原子性陷阱数据查出来为什么对不上Doris 的 Rollup 表预聚合逻辑 vs ClickHouse 的 MaterializedView 刷新时机运维半夜被叫醒是因为什么Doris BE 节点 OOM 的内存分配策略 vs ClickHouse ZooKeeper 会话超时的连锁反应SQL 写着写着就报错错在哪Doris 对窗口函数ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)的 NULL 处理 vs ClickHouse 同样语句在ORDER BY字段含 NULL 时的排序偏差关键词里没写但热搜词反复出现的doris慢查询优化clickhouse的part命名flinksql写入doris union key模型的表—— 这些才是真实世界里的高频痛点。今天这篇笔记就用一张表拆解这六个场景每个差异背后都附上我实测的 SQL 示例、错误日志截图文字还原、以及绕过方案。你不用背概念直接抄作业就能用。2. 写入链路FlinkSQL 写入时Doris 的 Union Key 模型和 ClickHouse 的 ReplacingMergeTree 根本不是一回事2.1 Doris 的 Union Key 模型写入即可见但“可见”有延迟窗口Doris 官方文档说 Union Key 模型支持“实时更新”但实际部署中我们发现 FlinkSQL 写入后前端报表刷新看到的数据和 Kafka 消息时间戳之间存在 3~5 秒不等的延迟。这不是网络问题而是 Doris 的写入机制决定的FlinkSQL 通过 Stream Load 或 Routine Load 写入 Doris 时数据首先进入MemTable内存缓冲区当 MemTable 达到阈值默认 100MB 或 10 分钟触发Flush操作生成一个Segment 文件对应 Doris 的一个 Tablet Shard此时数据才对查询可见但 Segment 文件需等待Compaction合并后才能被高效查询——而 Compaction 是后台异步任务受min_compaction_score参数控制。提示min_compaction_score默认为 10表示当一个 Tablet 的 Segment 数量 ≥10 时才触发 Compaction。我们曾因该值过大导致单个 Tablet 积压 47 个 Segment查询性能下降 60%。实测 SQL 验证延迟-- 在 Doris 中创建 Union Key 表 CREATE TABLE user_behavior ( event_time DATETIME, user_id BIGINT, event_type VARCHAR(64), page_url VARCHAR(256) ) UNIQUE KEY(event_time, user_id) DISTRIBUTED BY HASH(user_id) BUCKETS 10;FlinkSQL 写入后立即执行SELECT COUNT(*) FROM user_behavior WHERE event_time 2024-06-15 02:00:00 AND event_time 2024-06-15 02:00:05;结果返回 0但 Kafka 中该时间窗口消息已全部消费完成。直到 4 秒后再次查询才返回正确计数。2.2 ClickHouse 的 ReplacingMergeTree写入即落盘但“最新”需手动触发合并ClickHouse 的写入路径更直接FlinkSQL 通过 JDBC 或 HTTP 接口写入数据直接写入磁盘上的Part数据块无需内存缓冲。但问题在于ReplacingMergeTree 的“去重”不是实时的而是依赖后台 Merge 进程。关键陷阱是clickhouse的part命名—— ClickHouse 的 Part 名称格式为YYYYMMDD_123456789_987654321_123其中123456789是 min block number987654321是 max block number123是 level层级当 FlinkSQL 并发写入多个 TaskManager 时若未配置insert_quorum2不同节点可能生成相同 block number 范围的 Part导致 Merge 时无法识别主键冲突最终查出重复数据。我们曾在线上环境遇到同一user_id在 1 秒内产生两条行为记录FlinkSQL 写入后查询SELECT * FROM user_behavior FINAL WHERE user_id 123456返回两条而非一条。原因正是两个 Part 的 block number 重叠Merge 进程跳过了该 Part 的去重。解决方案必须双管齐下FlinkSQL 侧强制指定parallelism 1牺牲吞吐保一致性ClickHouse 侧启用replicated_replace_table并设置replace_table_on_insert 1仅适用于 Replicated 表。注意FINAL查询会强制触发 Merge但生产环境严禁在高并发查询中使用会导致 ZooKeeper 压力飙升。我们最终采用SELECT * FROM user_behavior WHERE (user_id, event_time) IN (SELECT user_id, max(event_time) FROM user_behavior GROUP BY user_id)替代FINAL。2.3 写入链路差异总结一张表看透本质维度DorisUnion KeyClickHouseReplacingMergeTree我的实操建议写入可见性Flush 后可见秒级延迟Part 写入即可见毫秒级Doris 适合对延迟容忍度 3 秒的场景ClickHouse 适合需要亚秒级可见的监控告警去重机制写入时按 Unique Key 自动覆盖Merge 进程后台去重非实时ClickHouse 必须配replicated_replace_tablereplace_table_on_insert否则必现重复FlinkSQL 兼容性支持INSERT INTO ... SELECT直接写入需通过JDBCOutputFormat或ClickHouseSink且需处理 Part 命名冲突Doris 更省心ClickHouse 必须在 Flink 作业中加sink.parallelism1或自定义 Partitioner写入失败恢复Stream Load 支持label去重失败可重试HTTP 接口无幂等性需业务层实现idempotent keyDoris 的 label 机制让重试更安全ClickHouse 必须在 Flink 端做 checkpoint idempotent key资源消耗BE 节点内存压力大MemTable 占用ZooKeeper 连接数激增每个 Part 写入触发一次 ZK 会话Doris 调大mem_limitClickHouse 升级到 v23 启用zookeeper_session_timeout_ms30000这个差异直接决定了我们的架构选型如果报表要求“T0 实时”且允许 5 秒延迟选 Doris如果要做“秒级异常检测”且能接受运维复杂度选 ClickHouse。3. 查询性能不是谁快而是“快在哪”和“慢在哪”完全不同3.1 Doris 的谓词下推能下推到 ScanNode 的绝不留在 HashJoin 之后Doris 的查询引擎基于 MPP 架构其核心优势在于深度谓词下推Predicate Pushdown。以我们最常查的“用户留存漏斗”为例SELECT dt, COUNT(DISTINCT user_id) AS dau, COUNT(DISTINCT IF(event_typelogin, user_id, NULL)) AS login_cnt FROM user_behavior WHERE dt 2024-06-01 AND dt 2024-06-15 AND event_type IN (login, click, pay) GROUP BY dt;Doris 的执行计划显示WHERE dt BETWEEN ...和event_type IN (...)全部下推到了OlapScanNode数据扫描节点意味着 BE 节点在读取数据时就过滤掉了 92% 的无效行。实测 15 天数据120 亿行查询耗时 1.8 秒。但 ClickHouse 在同样 SQL 下表现迥异EXPLAIN PLAN SELECT ... FROM user_behavior WHERE dt 2024-06-01 AND dt 2024-06-15 AND event_type IN (login, click, pay);执行计划显示event_type IN (...)未下推到ReadFromStorage而是在Filter算子中执行——这意味着所有 120 亿行数据先全量读入内存再过滤。实测耗时 23.7 秒是 Doris 的 13 倍。根源在于 ClickHouse 的稀疏索引Skip Index设计它只对dt日期字段建了MinMax索引对event_type未建二级索引。而 Doris 的BitmapIndex默认对所有VARCHAR字段启用且支持IN条件的位图交集运算。提示ClickHouse 中想加速event_type过滤必须显式创建SET类型跳数索引ALTER TABLE user_behavior ADD COLUMN event_type String TTL dt INTERVAL 30 DAY;ALTER TABLE user_behavior MATERIALIZE INDEX event_type_idx ON event_type TYPE set(100);但 Materialize Index 会阻塞写入我们线上从未启用。3.2 ClickHouse 的向量化执行单核吞吐无敌但多表 Join 是阿喀琉斯之踵ClickHouse 的强项是单表海量扫描。当我们执行纯聚合查询SELECT toYear(event_time) as year, count(*) as cnt FROM user_behavior GROUP BY year ORDER BY cnt DESC LIMIT 10;ClickHouse 耗时 0.32 秒Doris 耗时 0.89 秒。差距来自 ClickHouse 的Native Code 向量化执行器它将 CPU 指令流水线化SIMD 指令一次处理 256 位数据而 Doris 的 Java 执行器受限于 JVM GC 和对象创建开销。但一旦涉及 Join局面反转SELECT u.user_name, COUNT(b.event_type) as event_cnt FROM users u JOIN user_behavior b ON u.user_id b.user_id WHERE b.dt 2024-06-15 GROUP BY u.user_name;Doris 耗时 4.2 秒ClickHouse 耗时 18.6 秒。原因在于Doris 的Colocate Join优化若users和user_behavior表均按user_id分桶Join 时数据已在同一 BE 节点无需 ShuffleClickHouse 的JOIN 算法仅支持ANY INNER JOIN和ALL LEFT JOIN且必须将小表 Broadcast 到所有节点——users表 500 万行Broadcast 后每个节点内存暴涨 2GB触发频繁 GC。我们最终将 ClickHouse 的 Join 拆解为两步先查SELECT user_id FROM user_behavior WHERE dt2024-06-15得到 ID 列表再用SELECT * FROM users WHERE user_id IN (...)查询用户信息应用层合并结果。虽然代码变多但查询稳定在 1.2 秒内。3.3 查询性能差异总结别信“谁更快”要看你的 SQL 长什么样查询类型Doris 表现ClickHouse 表现关键原因我的选型依据单表带多条件过滤聚合✅ 极快谓词深度下推⚠️ 依赖索引设计否则极慢Doris BitmapIndex 全字段覆盖ClickHouse 需手动建 Skip Index日常报表查询首选 Doris单表海量扫描聚合⚠️ 可用但 JVM 开销明显✅ 无敌Native SIMDClickHouse C 无 GCDoris Java 执行器有对象分配成本日志原始数据分析选 ClickHouse多表 Colocate Join✅ 亚秒级本地 Join❌ 易 OOMBroadcast 小表Doris 支持分桶键对齐ClickHouse Join 强制 Broadcast关联维度分析场景 Doris 更稳窗口函数如 ROW_NUMBER✅ 支持完整语法NULL 处理一致⚠️ORDER BY含 NULL 时排序结果不稳定Doris 基于 CalciteClickHouse 自研执行器对 NULL 排序逻辑有 Bug涉及排名、分页的报表必须用 Doris高并发点查PK 查询✅ 毫秒级BloomFilter ShortKey✅ 毫秒级Primary Key 索引两者均优秀无显著差异两者皆可优先选运维更熟的记住没有绝对快慢只有“你的 SQL 是否命中它的优势路径”。我们上线前用真实业务 SQL 跑了 3 天压测Doris 在 92% 的查询中胜出ClickHouse 仅在 3 个纯扫描类任务中更快。4. 表结构变更Schema Change 不是“改个字段”而是两种完全不同的事务模型4.1 Doris 的 Schema Change异步队列 版本冻结改字段可能卡住整个集群Doris 的ALTER TABLE ... MODIFY COLUMN看似简单实则暗藏杀机。当我们尝试给user_behavior表增加一个device_type字段时ALTER TABLE user_behavior MODIFY COLUMN device_type VARCHAR(32) DEFAULT unknown;命令返回Query OK但后续所有写入请求开始超时。排查发现Doris 的 Schema Change 是异步任务它会在元数据中创建新 Schema 版本Version 2启动后台线程逐个 Tablet 执行AlterJob将旧数据转换为新 Schema在此期间该 Tablet 的所有写入请求被阻塞直到 AlterJob 完成。而我们的表有 120 个 Tablet每个 Tablet 平均需 8 分钟完成转换。这意味着改一个字段120 个 Tablet 会轮流阻塞写入总影响时长近 16 小时。更致命的是如果某个 Tablet 的 AlterJob 失败如磁盘空间不足整个 Schema Change 任务会卡在WAITING状态且无法 Cancel —— 我们曾因此导致集群连续两天无法写入。解决方案只能是提前计算SHOW PROC /statistic获取 Tablet 数量和大小在低峰期执行且确保每个 BE 节点剩余磁盘 ≥50GB改字段前先SHOW ALTER TABLE COLUMN查看当前状态避免叠加任务。提示Doris 2.0 引入ALTER TABLE ... ADD COLUMN IF NOT EXISTS但IF NOT EXISTS仅检查字段是否存在不规避 AlterJob 阻塞问题。4.2 ClickHouse 的 ALTER TABLE原子性操作但“原子”仅限单节点ClickHouse 的ALTER TABLE ... ADD COLUMN声称原子性但在分布式表场景下完全是另一回事-- 在分布式表上执行 ALTER TABLE user_behavior_distributed ADD COLUMN device_type String DEFAULT unknown;该命令实际执行流程是Coordinator 节点向所有 Shard 发送ALTER请求每个 Shard 独立执行成功后返回 ACK只要有一个 Shard 失败Coordinator 就标记整条命令失败但已成功的 Shard 不会回滚我们曾因一个 Shard 磁盘满导致ALTER命令返回失败但 7/8 个 Shard 已完成加字段。结果是部分节点能查device_type部分节点报错Unknown column应用层查询直接崩溃。最终靠SYSTEM SYNC REPLICA强制同步但耗时 40 分钟且期间数据写入丢失。真正安全的做法是永远不要在分布式表上直接ALTER先在所有本地表user_behavior_shard1,user_behavior_shard2...上单独执行ALTER确认全部成功后再重建分布式表 DDL。4.3 表结构变更差异总结改表不是技术活是运维风险评估操作Doris 风险点ClickHouse 风险点我的落地 checklist增加字段阻塞写入AlterJob 失败不可逆分布式表 ALTER 不原子易造成数据不一致Doris提前算 Tablet 数 × 单个耗时ClickHouse只操作本地表禁用分布式表 ALTER删除字段不支持Doris 无 DROP COLUMN支持但删除后历史数据仍保留该列值为 NULLDoris 用REPLACE重建表ClickHouse 删除后需OPTIMIZE TABLE ... FINAL清理修改字段类型仅支持扩大VARCHAR(32) → VARCHAR(64)缩小报错支持TYPE修改但String → Int等强转需MATERIALIZEDoris 改类型必须重建表ClickHouse 强转前先SELECT CAST(...)验证数据兼容性修改分区字段不支持Partition Key 创建后不可改支持REPLACE PARTITION但需重建分区两者均需停写重建无优雅方案添加物化视图CREATE MATERIALIZED VIEW同步构建不影响原表CREATE MATERIALIZED VIEW异步构建原表可写Doris MV 构建期间原表写入正常ClickHouse MV 构建时原表写入不受影响教训Schema Change 不是开发任务是发布窗口期的最高优先级运维事件。我们后来规定所有表结构变更必须走发布流程且 Doris 改字段需预留 2 小时窗口ClickHouse 改字段需提前 1 天通知所有 Shard 运维。5. 数据一致性Rollup 表和 MaterializedView 的“预计算”逻辑藏着最深的坑5.1 Doris 的 Rollup 表预聚合结果可信但“最新”取决于 Base 表 CompactionDoris 的 Rollup 表是真正的预聚合物化视图。创建方式CREATE ROLLUP TABLE user_behavior_rollup AS SELECT dt, event_type, COUNT(*) as cnt, COUNT(DISTINCT user_id) as uv FROM user_behavior GROUP BY dt, event_type;表面看这是个独立表但底层它完全依赖 Base 表user_behavior的 Segment 文件。Rollup 的构建时机是Base 表的每个 Segment 被 Compaction 合并后Doris 后台启动RollupJob读取该 Segment 数据计算聚合值写入 Rollup 表的对应 Tablet。这就导致一个致命问题Rollup 表的数据新鲜度 Base 表 Compaction 的延迟。我们曾发现Base 表user_behavior的最新数据已写入MemTable Flush 完成但 Rollup 表查询结果仍是 2 小时前的。SHOW PROC /rollup_job显示 RollupJob 队列积压了 17 个任务原因是rollup_job_concurrency默认为 3而我们的表有 120 个 Tablet。解决方案只能调大并发ADMIN SET FRONTEND CONFIG(rollup_job_concurrency 12);但此举会抢占 BE 节点 CPU影响实时查询。我们最终妥协Rollup 表只用于 T1 报表实时指标一律查 Base 表。5.2 ClickHouse 的 MaterializedView触发式更新但“触发”可能永远不来ClickHouse 的 MV 创建方式CREATE MATERIALIZED VIEW user_behavior_mv ENGINE SummingMergeTree() PARTITION BY toYYYYMM(dt) ORDER BY (dt, event_type) AS SELECT dt, event_type, count() as cnt, uniq(user_id) as uv FROM user_behavior GROUP BY dt, event_type;关键认知MV 不是“物化”视图而是“触发器”。它只在 Base 表user_behavior发生INSERT时才将新数据插入 MV。但问题在于如果 Base 表是通过INSERT SELECT或INSERT FROM INPUT批量导入MV 会触发如果 Base 表是通过ALTER TABLE ... REPLACE PARTITION替换分区MV 完全不触发我们曾用REPLACE PARTITION迁移历史数据结果 MV 表空空如也而 Base 表数据完好。查system.mutations发现 MV 无任何记录因为REPLACE PARTITION绕过了 INSERT 流程。更隐蔽的坑是MV 的SummingMergeTree引擎要求cnt和uv字段必须是数值型且uniq(user_id)返回的是AggregateFunction(uniq, UInt64)类型直接写入会报错。必须用uniqState(user_id)uniqMerge()组合。最终方案MV 只用于增量数据FlinkSQL 写入历史数据通过INSERT INTO user_behavior_mv SELECT ... FROM user_behavior手动补全所有REPLACE PARTITION操作后必须手动INSERT INTO user_behavior_mv SELECT ...。提示ClickHouse 23.8 支持POPULATE关键字CREATE MATERIALIZED VIEW ... POPULATE但POPULATE是阻塞操作且不保证原子性线上慎用。5.3 数据一致性差异总结预计算不是银弹是新的故障点特性Doris RollupClickHouse MaterializedView我的血泪经验更新机制Compaction 触发异步批量INSERT 触发实时增量Doris Rollup 有延迟ClickHouse MV 对批量导入失效数据新鲜度依赖min_compaction_score和 BE 负载依赖写入方式INSERT 有效REPLACE 无效Doris 查实时用 Base 表ClickHouse MV 只接 FlinkSQL 流存储开销Rollup 表与 Base 表共享数据文件节省空间MV 是独立表存储冗余数据Doris 存储更优ClickHouse MV 需额外磁盘预算查询透明性SELECT * FROM user_behavior_rollup直接查SELECT * FROM user_behavior_mv直接查两者语法一致但 Doris Rollup 更像“智能索引”ClickHouse MV 更像“独立表”故障恢复RollupJob 失败可重试不影响 Base 表MV 插入失败如类型不匹配会导致后续所有 INSERT 失败Doris 更健壮ClickHouse MV 必须严格校验 Schema结论如果业务能接受小时级延迟Doris Rollup 是省心选择如果必须实时ClickHouse MV 配合 FlinkSQL 是唯一可行路径但要为 MV 单独建监控告警。6. 运维与生态半夜被叫醒的原因90% 出现在这两张表的交叉区域6.1 Doris 的 BE 节点 OOM不是内存不够而是mem_limit配置反直觉Doris 的内存管理有两层JVM HeapBE 进程的 Java 堆内存-XmxDirect MemoryBE 用malloc申请的堆外内存由mem_limit控制。我们曾将 BE 的-Xmx设为 32Gmem_limit设为 64G认为总内存 96G 足够。结果凌晨 3 点收到 OOM 告警jstat -gc显示 Heap 使用率仅 45%但dmesg日志全是Out of memory: Kill process xxx (be) score xxx or sacrifice child。根因是Doris 的mem_limit不是最大可用内存而是“强制限制阈值”。当 Direct Memory 使用量达到mem_limit * 0.8默认 80%时BE 会主动 Kill 查询达到mem_limit时Linux OOM Killer 直接干掉进程。而我们的mem_limit64G意味着 51.2G 就触发 Kill。实测单个复杂查询峰值 Direct Memory 达 48G刚好卡在临界点。解决方案mem_limit必须设为物理内存的 60%非 100%同时调大-Xmx至mem_limit * 0.4留足 Direct Memory 空间关键参数组合# be.conf mem_limit 48G # 物理内存 80G 的 60% jvm_max_heap_size 19G # 48G * 0.46.2 ClickHouse 的 ZooKeeper 会话超时不是 ZK 慢而是session_timeout_ms配得太短ClickHouse 的 Replicated 表严重依赖 ZooKeeper。我们线上 ZK 集群 P99 延迟 8ms但 ClickHouse 频繁报Session expired错误。查clickhouse-server.err.log2024.06.15 03:22:17.123 [ 123 ] {} Error zkutil::ZooKeeper: Session expired. Connection lost.根源在zookeeper_session_timeout_ms默认值 3000030 秒。当网络抖动或 ZK 负载升高会话续期请求延迟超过 30 秒ZK 主动关闭会话。而 ClickHouse 的 ReplicatedMergeTree 在会话失效后会停止所有写入尝试重建会话重建期间该节点数据不可用。我们将其改为 6000060 秒并增加重试!-- config.xml -- zookeeper session_timeout_ms60000/session_timeout_ms operation_timeout_ms30000/operation_timeout_ms retries10/retries /zookeeper同时在 ZK 侧启用4lw.commands.whitelist*用mntr命令监控zk_avg_latency确保 P99 15ms。6.3 运维与生态差异总结选型即选运维模式维度DorisClickHouse我的运维手册监控重点BE 节点mem_limit使用率、Compaction 队列长度、RollupJob 延迟ZooKeeper 会话状态、Part 数量防爆炸、Replica 延迟Doris 监控be_mem_usage_ratioClickHouse 监控zookeeper_session_expired和parts_count扩容方式增加 BE 节点FE 自动分配 Tablet增加 Shard需手动CREATE TABLE ... ON CLUSTERDoris 扩容 5 分钟完成ClickHouse 扩容需改 DDL 数据迁移备份恢复BACKUP命令v2.0支持增量clickhouse-backup工具但恢复需停服务Doris 备份在线ClickHouse 备份快恢复慢SQL 生态完全兼容 MySQL 协议Navicat / DBeaver 开箱即用JDBC 驱动兼容性差DBeaver 需装专用插件Doris 降低 DBA 学习成本ClickHouse 需定制 JDBC 连接池社区支持Apache 顶级项目中文文档完善钉钉群响应快社区英文为主国内文档碎片化报错常需翻 GitHub IssuesDoris 问题 2 小时内有答案ClickHouse 需自己啃源码最后说句实在话Doris 的运维更“傻瓜”适合中小团队ClickHouse 的运维更“硬核”适合有资深 Infra 工程师的团队。我们团队最终选择 Doris不是因为它技术更强而是因为DBA 只有 2 人却要支撑 15 条业务线Doris 让我们少写了 70% 的运维脚本。7. 我的最终选型决策树不是二选一而是按场景切分这张表写完我删掉了初稿里所有“Doris 更好”“ClickHouse 更优”的绝对判断。因为真实世界没有银弹只有 trade-off。我们最终落地的方案是核心实时报表DAU、留存、转化漏斗→ Doris理由SQL 兼容性好窗口函数稳定运维负担低90% 查询 2 秒。原始日志分析用户行为序列挖掘、AB 实验明细下钻→ ClickHouse理由单表扫描快存储压缩率高比 Doris 低 35%FlinkSQL 写入吞吐高。维度表用户画像、商品类目→ MySQL Doris External Table理由Doris 支持 MySQL 外部表实时关联无需 ETL且 MySQL 的事务能力保障维度数据一致性。告警引擎秒级异常检测→ ClickHouse MaterializedView理由MV 的实时触发 ClickHouse 的亚秒级扫描满足告警 SLA。所以当你再看到 “Doris 还是 ClickHouse” 这个问题时请先问自己三个问题我的最慢查询是什么 SQL贴出来用本文第 3 节对照我的表结构多久改一次如果月度以上Doris Schema Change 的阻塞你能忍吗我的运维团队有几个人如果 3 人Doris 的开箱即用省下的时间远超性能那点差距这张表是我用两周凌晨的黑眼圈换来的。它不教你选哪个而是帮你看清每个选项背后你真正要付出的代价是什么。