【OLAP 学习笔记】Doris：数据湖之上的分析查询引擎

Paimon 系列把订单链路铺到了数据怎么存这一步——Kafka 订单流经 Flink 流写进 Paimon湖内再由 Flink 流算Join 维表、窗口聚合和 Spark 批算T1 报表加工成 ADS 结果。链路最后还差一个出口ADS 层的结果怎么查得快——BI 报表要求亚秒响应分析师写一句 SQL 不能等 Spark 启动半分钟——这就是 OLAP 引擎的位置。这层是 OLAP 引擎的地盘。这篇以Doris为主线——百度 Palo 出身、Apache 顶级项目目前国内数仓报表场景的主流默认ClickHouseYandex2016 开源作为对照组出场——单表分析的老牌选手把它放在对照位上Doris 的取舍会看得更清楚。核心回答一个问题链路最后的查询出口什么场景选谁。一 为什么需要 OLAP 引擎数据湖不够吗Paimon、Iceberg 这些湖格式为扫描吞吐和流批一体优化——Parquet 列存大文件顺序读跑批效率很高。但回到订单链路看两类分析场景它们不擅长Ad-hoc 交互式查询分析师对着 DWD 订单宽表写一句SELECT city, SUM(amount) FROM dwd_orders GROUP BY city期望秒级出结果。走湖上引擎Spark SQL光任务启动调度就是几秒到几十秒高并发报表ADS 订单日报挂上 BI 看板几十上百人同时刷新湖格式及其执行引擎没有为高并发点查 聚合做过优化这里把第一个名词解释一下。Ad-hoc即席查询和预定义查询相对预定义查询SQL 是固定的——每天 8 点跑的日报、看板上的固定图表。查询模式已知可以提前优化预聚合、物化视图、索引全按已知 SQL 配好Ad-hoc 查询分析师临时想到什么查什么——今天查城市分布明天拆时段转化列组合、过滤条件、聚合方式都不固定。没法预计算引擎必须现场扫原始数据现场算交互式说的是使用姿势写一句 → 等结果 → 基于结果写下一句像对话一样迭代着逼近结论。延迟超过几秒思路就断了所以秒级返回是硬指标不是锦上添花。两个词合起来才是完整约束查询模式不可预知 人对延迟敏感。这正是湖上批处理引擎最不适配的组合——不可预知就没法提前准备延迟敏感又要求每次都现场算还得快。后文会反复看到这个词ClickHouse 的稀疏索引、Doris 的 Rollup取舍都和要扛住 Ad-hoc直接相关。OLAP 引擎补的就是这层数据加载进引擎自己的存储或以外表直查湖仓用专门的执行器把分析查询压到亚秒级。二 共同基因为什么两个都快Doris 和 ClickHouse 的技术路线不同但快的来源是同一套三件套列式存储分析查询只碰少数几列。订单宽表 50 列SUM(amount)只读 amount 一列——列存按列连续存放IO 只碰需要的列同列数据类型一致压缩率还高MPP大规模并行处理查询拆成子任务分发到多节点多核并行算中间结果逐级汇总。8 个分片就是 8 倍扫描能力向量化执行不按一行一行处理按一列一批处理一批几千行进 CPU缓存友好、能用 SIMD 指令一次算多个值三层叠加才有亚秒级分析。需要先澄清一个概念边界否则会和已知事实产生矛盾Paimon 也是列存。Paimon 的 LSM 树落盘文件就是 Parquet/ORC 列存所以单就列式存储这一层而言湖格式和 OLAP 引擎是对等的。LSM 和列存本是正交的两个层面LSM 负责写入如何攒批、多版本文件如何组织合并列存负责单个文件内部按行还是按列排布。Paimon 是LSM 组织 列存文件Doris 的 compaction 和 ClickHouse 的 MergeTreepart 后台合并同样是类 LSM 结构 列存文件——在这一点上三者并无本质差异。既然如此湖上跑 Ad-hoc 为什么仍然慢差距不在文件格式在三件套的后两件及其运行方式执行模型Spark 扫 Paimon 是来一个查询起一个作业调度、申请资源先烧掉几秒。OLAP 引擎常驻进程 数据在自己盘上SQL 进来直接进执行器裁剪粒度湖格式的裁剪靠文件级统计Paimon manifest 的 minKey/maxKey、Parquet footer 的 min/max粒度是跳过整个文件 / 整个 row groupOLAP 引擎在此之上叠了主键索引定位、页级 zone map、BloomFilter裁剪能压到文件内部归纳来看列存决定读得省MPP 向量化 常驻执行器 索引决定算得快、响应快——湖格式只具备前者OLAP 引擎则覆盖了全部。区别不在快不快而在于各自把优化重心放在了哪里——这也是 Doris 与 ClickHouse 的分岔点。三 Doris 核心机制把数仓报表做到开箱即用Doris 的出身是百度广告报表系统的 Palo 项目2017 开源、2018 捐给 Apache、2022 年毕业为顶级项目场景是实时报表 多维分析 高并发看板。官方定位中两个能力标签值得注意既能扛高并发点查报表看板也能扛高吞吐复杂分析Ad-hoc——两头都要是它和老牌单表引擎的取向差异。1 架构设计FE BE两种部署模式Doris 采用MySQL 协议接入BI 工具FineBI、Tableau、Superset和各类客户端当 MySQL 直接连接零适配成本。部署上按硬件环境与业务需求可选存算一体或存算分离两种架构。存算一体架构经典部署查询过程如下仅两类进程精简易维护FEFrontend接收用户请求、查询解析和规划、元数据管理、节点管理。生产环境部署多个 FE 节点做容灾每个 FE 维护完整元数据副本分三种角色Master负责元数据读写变更通过 BDB JE 协议同步Follower读元数据Master 故障时选主Observer只读扩查询并发不参与选主BEBackend存储 计算一体数据切分为分片Tablet多副本分布。扩缩容自动均衡——加节点Tablet 自动迁移FE 和 BE 均可横向扩展单集群支持数百台机器、数十 PB 存储通过一致性协议保证高可用和数据可靠。存算分离架构3.0 起可选Apache Doris 存算分离版使用统一的共享存储层作为数据存储空间。存储和计算分离后用户可以独立扩展存储容量和计算资源从而实现最佳性能和成本效益。存算分离架构分为以下三层查询过程如下数据放 S3/HDFS/OSS/COS/OBS/Minio/Ceph 等共享存储BE 变无状态计算组存储和计算独立扩缩。三层分工元数据层 负责请求规划、查询解析以及元数据的存储和管理。计算层 由多个计算组组成。每个计算组可以作为一个独立的租户承担业务计算。每个计算组包含多个无状态的 BE 节点可以随时弹性伸缩 BE 节点。存储层 可以使用 S3、HDFS、OSS、COS、OBS、Minio、Ceph 等共享存储来存放 Doris 的数据文件包括 Segment 文件和反向索引文件等。存算一体是经典部署方式存算分离则面向湖仓统一底座的新架构——数据在湖里一份不动计算资源按需拉起。2 三种数据模型建表时决定数据的合并语义Duplicate Key明细模型数据原样存只按排序键组织——对应订单链路的 DWD 订单宽表、埋点日志Aggregate Key聚合模型同 key 的数据写入时按聚合函数SUM/MIN/MAX/REPLACE合并——对应 DWS 城市日汇总这类预聚合报表Unique Key主键模型同 key 覆盖更新行级数据更新。MOWMerge-on-Write模式写入时就完成新旧版本合并读时直接取唯一版本——upsert 是原生强语义“写入即一致”。对应 ADS 订单日报这种结果会随上游变更反复刷新的表对照组的 ReplacingMergeTree下一章详述同样是同主键保留最新Doris 在写入路径上解决ClickHouse 推迟到后台 merge——这就是两者 upsert 语义强弱的根源。3 Rollup、物化视图与索引体系Rollup / 物化视图单表物化视图Rollup按不同维度组合预聚合存多份写入自动同步、查询自动路由到最省的一份——报表常用维度提前算好另有多表物化视图定时刷新降低建模复杂度索引体系按用途选Sorted Compound Key排序复合键索引最多 3 列复合排序数据裁剪主力高并发报表靠它Min/Max 索引数值列等值/范围过滤BloomFilter 索引高基数列等值裁剪Inverted Index倒排索引任意字段快速检索——日志检索场景的核心能力思路与 ClickHouse 的稀疏索引同源都为扫一片优化而非点查但 Doris 补充的索引类型更多点查和文本检索能力更全4 查询引擎的三个关键词官方文档中三个执行层名词了解其作用即可Pipeline 执行引擎查询拆成子任务流水线并行限制线程数防膨胀吃满多核Runtime FilterJoin 时在运行时生成过滤器In/Min-Max/BloomFilter推到 Probe 端 Scan 节点先过滤再关联——大表 Join 提速的关键手段自适应优化RBO CBO HBO规则优化谓词下推、子查询重写 代价优化Join Reorder 基于历史查询推荐计划5 强项与弱项强项Join 完整Shuffle Join / Broadcast Join / Colocate Join 齐备星型模型事实表 多维度表原生支持不用预拼宽表高并发面向报表场景优化千级 QPS 扛得住upsert 原生Unique Key MOW 写入即一致湖仓一体Multi-Catalog 直接查 Hive/Iceberg/Paimon/Hudi 外表联邦查询消除数据孤岛弱项单表极致扫描性能略逊 ClickHouse差距在持续缩小且只在超大单表 Ad-hoc 场景可感知四 ClickHouse把单表做到极致对照组与 Doris 相比ClickHouse 的取舍方向正好相反。ClickHouse 为 Yandex Metrica网站流量分析而生场景是海量事件追加写入、单表 Ad-hoc 分析。它并不追求数仓全链路顺手所有设计取舍都围绕一个目标把单表扫描/聚合做到极限——这也是它至今仍保持优势的领域。1 MergeTree写入即排序后台再合并每批写入落盘成一个 part数据按主键排序的独立文件集后台 merge 线程持续把小 part 合并成大 part。和 Paimon 的 LSM 形似——都是追加写 后台合并但目的不同MergeTree 的合并主要为减少 part 数量、提升压缩率不承担保证更新语义的职责这点下面详述。MergeTree 是一个引擎家族基础的 MergeTree 只管存储ReplacingMergeTree在后台 merge 时对同主键数据只保留最新一版SummingMergeTree / AggregatingMergeTree 在 merge 时做预聚合。2 稀疏主键索引为扫描优化不为点查ClickHouse 的主键索引不是 B 树每 8192 行一个 granule只记一个主键标记索引小到可以常驻内存。查WHERE order_id order_650时标记只能定位到哪几个 granule 区间可能含目标然后把这个区间的几万行扫出来过滤。对比 B 树精确定位单行稀疏索引是为大范围扫描设计的——Ad-hoc 分析绝大多数是按时间扫一段 聚合定位到区间就够了索引做到极致小换来的是全内存、零额外 IO。代价是点查不划算。3 分片与副本无中心手动管理分布式靠 Shard分片 Replica副本数据手动指定分片规则切开副本间靠 ZooKeeper/Keeper 同步。没有中心调度节点应用可以连任意节点查询。代价是扩缩容要手动重分布数据——加一个节点旧数据不会自动挪过去。4 强项与弱项强项单表扫描和聚合的性能极致。宽表几百列Ad-hoc 是它的优势场景弱项每一条都与为单表优化的取舍对应Join 弱多表关联尤其大表 Join缺乏完整的分布式关联优化生产上普遍写入前预拼宽表绕开 Join更新删除重UPDATE/DELETE 是 mutation 操作——异步重写整个 part一次小改动可能重写几十 GBupsert 语义弱ReplacingMergeTree 只在后台 merge 时去重merge 时机不确定merge 之前查询能读到同主键多个版本需要加FINAL或 GROUP BY 处理——“最终会一致而不是写入即一致”并发低单查询倾向吃满整机资源并发能力在几十 QPS 级别高并发需要外部队列/代理处理五 正面对比架构、模型、选型1 分布式架构对比ClickHouse 无中心节点分片手动规划、扩缩容手动重分布Doris FE/BE 分层扩缩容自动均衡。运维复杂度差异主要在这里。2 数据合并语义对比同样面对同主键两个版本ClickHouse 推迟到后台 merge时机不定查询需要 FINAL 处理Doris Unique Key MOW 写入时完成合并。upsert 语义强弱全在这条时间差里。3 对比总表维度ClickHouseDoris设计重心单表 Ad-hoc 极致数仓报表全链路Join 能力弱生产靠预拼宽表强星型模型原生upsertReplacingMergeTreemerge 时才去重弱语义Unique Key MOW写入即一致强语义更新删除mutation 异步重写 part重轻量并发能力低几十 QPS 级高千级 QPS接入协议自有 TCP / HTTPMySQL 协议BI 直连部署形态存算一体存算一体 / 存算分离3.0数据可放 S3/HDFS扩缩容手动重分布自动均衡湖仓外表支持但主流姿势是数据搬进内表Multi-Catalog联邦查询是主推能力SQL 兼容类 SQL 方言非标准 SQL标准 SQL兼容 MySQL 语法更新粒度整 part 重写行级更新支持部分列更新典型场景日志/行为分析、漏斗、超大宽表实时报表、BI 看板、多维分析、画像4 基准测试榜单数据怎么看官方技术对比页给出了四组基准测试数据值得参考但需要注意这是 Doris 官方发布的对比立场需要打折扣ClickBench单表宽表聚合ClickHouse 优势场景Doris 2022/2024 两次进前三与 ClickHouse 轮流领先——单表极限上两者已是同一量级SSB-Flat星型模型压平成大宽表同样聚焦单表互有胜负TPC-H22 条复杂查询ClickHouse 有 7 条没跑完OOMDoris 全量完成——复杂查询的稳定性差距TPC-DS99 条查询大量关联子查询测试时2024.09ClickHouse 约半数查询无法执行——关联子查询支持的代差怎么读这些数据单表场景两者打平复杂查询场景差距拉开——和前面的机制分析Join 能力、优化器、upsert 语义完全互证。同时注意 ClickBench 恰恰是为单表场景设计的榜单Doris 在对手优势场景打平说服力不弱。真实替换案例官方收录快手用 Doris 替换 ClickHouse 升级湖仓一体直查湖上数据、物化视图治理某日志平台 50 台服务器 2PB 数据全文检索提升 3~7 倍、峰值写入 6GB/s、500 并发较原 ClickHouse 集群提升 2 倍。5 既然 Doris 全面占优ClickHouse 还剩什么场景上面四组数据读下来一个自然的疑问是单表打平、复杂查询领先、upsert 和并发全面占优——那还选 ClickHouse 干什么几个现实原因存量与惯性ClickHouse 2016 年开源在行为分析/日志场景应用多年存量集群规模庞大。集群在稳定运行、团队有经验没有痛点就没有迁移动力单表极限仍是它的优势领域ClickBench 这类第三方榜单 ClickHouse 长期领先——轮流领先的另一面是 Doris 追平而非超越且上面的对比页是 Doris 官方发布的口径本身有立场极端单表场景应当自行压测验证部署轻单节点一个二进制就能跑嵌入式 chDB 甚至能进程内直接分析本地 Parquet 文件——小场景不用维护 FE BE 两类进程的集群生态配套Grafana 插件、Vector/Fluent Bit 等日志管道直连大量开源可观测方案默认后端就是它因此可以归纳为一个结论新建数仓、报表、多表分析Doris 是主流默认纯追加的日志行为单表、或团队已有 ClickHouse 存量继续用它也成立。两者不互斥生产上混部很常见。6 选型决策树四个问题按顺序问自己六 外表直查和数据进内表数据都在湖里了ADS 还要搬进 Doris 吗两条路都在用对应不想搬和要最快两种诉求。1 外表直查湖仓一体数据一份不动Doris 的 Multi-Catalog 可以把 Paimon 表挂载进来直接查——订单明细留在湖里Doris 只做查询入口。机制上四步建 Catalog一条CREATE CATALOG指向 Paimon 的 warehouse或对接 metastoreFE 由此拿到湖表的元数据入口库表结构自动同步不用逐张建外表规划时读湖的元数据查询进来FE 读 Paimon 当前 snapshot 的 manifest正是 Paimon 系列讲的 base delta 那套确定本次要读哪些数据文件并用 manifest 里的 minKey/maxKey 先做一轮文件级裁剪BE 直扫 ParquetBE 用内置向量化 Parquet reader 直接读湖上文件列裁剪、谓词下推都压到 reader 层BE 本地带 file cache热数据块缓存住重复查询不再拉远端存储全程不落盘Doris 内表里没有这份数据查的就是湖里那一份外表直查的性能优势来自哪里需要先明确对比基准不是 Doris 内表而是拉起批作业去查湖Spark SQL、Flink 批。差距的主要来源仍是第二节的分水岭——批引擎每查一次要申请资源、启动 driver/executor几十秒才能读到第一条数据Doris 的 FE/BE 进程常驻SQL 进来毫秒级规划完直接扫描常驻的是执行器进程不是把数据放内存。再叠加三层优化MPP 让所有 BE 并行分片扫描湖上文件而非单机 reader、file cache 将重复查询的热数据挡在远端存储之外、manifest 文件裁剪 reader 列裁剪两层压缩 IO——比批引擎查湖快一个数量级。顺带澄清一个概念不建 Doris 表节省的是存储冗余和同步链路维护成本那是架构收益不是性能来源。代价同样需要说明外表没有内表的索引、预聚合和 compaction数据不在 BE 本地盘、依赖远端存储带宽file cache 未命中时性能落差尤其明显——比内表慢一个量级。定位因此清晰比批引擎查湖快一个量级比内表慢一个量级。适合**探索性分析、低频报表、或者数据不方便 / 不愿意再存一份**的场景。2 热数据进内表主流高性能姿势很多团队的常规做法——把 Paimon 数据导入 Doris 再查——并没有被外表否定它本来就是对性能有要求时的正确选择正是 Paimon 系列讲的 changelog 流读的用武之地Flink 流式读 Paimon 表的 changelog实时 INSERT 进 Doris 内表Unique Key 模型消化 -U/U引擎自己的存储、索引、预聚合全力加速。湖做统一底座Doris 做加速层。两条路的关系外表直查管不想搬内表同步管要最快。生产上常见组合是——明细层外表直查做探索ADS 热数据进内表扛看板。七 小结OLAP 引擎补的是数据湖不擅长的两层亚秒级 Ad-hoc 查询和高并发报表。快的共同来源是列存 MPP 向量化真正的分水岭在执行模型常驻执行器 vs 按查询起作业和索引裁剪粒度Doris 是数仓分析的主流默认FE/BE 分层自动均衡、三种数据模型覆盖明细/预聚合/upsert、Unique Key MOW 写入即一致、Join 完整、千级 QPS、MySQL 协议接 BI、Multi-Catalog 直查湖仓——报表、多表、带更新的场景开箱即用ClickHouse 把单表做到极致日志/行为单表 Ad-hoc 仍有它的位置存量、轻量、生态代价是 Join 弱、mutation 重、upsert 弱语义、并发低回到订单链路湖做统一底座OLAP 做查询出口——外表直查管不想搬ADS 热数据进内表管要最快官方应用现状补充一个信心锚点Doris 已在 5000 中大型企业生产环境使用中国市值/估值前 50 的互联网公司超 80% 在用百度、美团、小米、京东、字节、阿里、腾讯等国内主要云厂商均有托管服务——选型的社区和生态风险基本可以忽略。参考Apache Doris 官网 Apache Doris 官方简介3.x Apache Doris vs ClickHouse 官方技术对比 ClickHouse 官网