做OLAP数据库选型最怕的就是厂商自己掏出来的那份压测报告——查询速度一个比一个快资源占用一个比一个省真到自己业务上一跑数据量一上去才发现根本不是那么回事。所以我一直坚持拿统一的标准来测TPC-DS就是目前行业里公认比较能还原真实数仓分析场景的基准测试。这篇文章把我用TPC-DS分别测ClickHouse和Doris的完整过程、踩过的坑、以及最终对比结果都整理出来给正在做数据库选型或者刚好要搭离线/实时分析平台的朋友一个参考。文章不会只贴结论重点是讲清楚每一步为什么这么做以及那些标准文档里不会告诉你的细节。1. 测试方案整体设计1.1 为什么是TPC-DS而不是TPC-H或自建场景很多人一提起数据库性能测试第一反应就是TPC-H因为网上资料多、工具也顺手。但TPC-H的数据模型是一个相对简单的星形结构表之间关联关系有限查询模板也更偏向传统的报表型SQL它对当下OLAP引擎的参考价值已经打了折扣。TPC-DS就不一样它模拟的是零售行业数仓的完整业务链路包含7张事实表、17张维度表整体拉出一个雪花模型查询涉及复杂的多表join、子查询嵌套、窗口函数叠加、大量CASE WHEN逻辑还有近似查询、半结构化数据解析等场景。可以说现实数仓中会遇到的SQL复杂度TPC-DS基本都覆盖到了。我最初也考虑过用业务自建场景来压测但自建场景存在两个问题一是SQL是业务方自己定的很难做到客观二是测试脚本和数据规模都不可控复现性差。TPC-DS的好处在于数据生成工具和查询模板都是公开的数据量可以通过参数自由伸缩SQL预置了99条只要把环境搭好、把数据灌进去大家跑的就是同一套标准改不了也逃不掉。所以拿它来衡量ClickHouse和Doris的查询能力公平性是有保障的。1.2 测试环境与数据规模选型测试环境这块我用的是一台中等配置的物理服务器固定不变地跑两组测试避免因为环境差异导致结果失真。具体配置如下配置项参数CPU2路每路32核心支持超线程内存256 GB DDR4存储4块NVMe SSD组RAID-10容量2 TB操作系统64位Linux内核5.4数据库版本ClickHouse 24.x / Doris 2.1.x数据规模我选的是SF-100也就是100GB原始数据经过建模压缩之后实际落盘会比这个小一些。为什么不上SF-1000因为100GB已经足够让两个引擎在分布式、列存压缩、向量化执行上拉开差距而1TB数据对环境的压力主要集中在存储带宽和内存容量上对于中等配置的机器反而会掩盖查询引擎本身的计算能力差异。如果条件允许建议至少跑一遍SF-100小于这个规模的数据量差异很容易被内存缓存抹平测出来的性能曲线参考价值不大。1.3 工具链与测试流程规划需要准备的东西有tpcds-kitTPC官方数据生成与查询模板工具、对应数据库的客户端、以及一套用来穿插查询的计时脚本。我用的是tpcds-kit自带的dss工具生成数据数据格式为标准CSV再用脚本统计每张表的行数做校验防止生成中断导致的数据缺失。测试流程拆成四个阶段第一步建库建表第二步批量导入数据并记录耗时第三步逐条跑SQL同时记录单查询耗时和失败率第四步分析结果对比资源消耗。这里有一点必须提醒查询模板不能一股脑跑完就算完事每次跑之前要把系统缓存清理掉确保冷缓存下真实反映磁盘读取和计算能力避免后面一次查询的结果被缓存撑起来、看起来漂亮但实际业务场景中根本复现不了。2. 数据准备与导入过程2.1 数据生成细节与校验数据生成使用的是tpcds-kit工具它的核心指令比较简单指定缩放因子和目录就能生成整套CSV文件。实际耗时取决于单机并行度SF-100在32线程下大概跑了40分钟左右。生成过程中有两个容易忽略的点第一生成数据时建议用一致性参数把数据分布固定下来保证两张库读到的是同一套数据而不是各自随机生成一番那样对比就没有意义了。第二落到磁盘上的CSV文件不需要做清洗保持原始格式因为TPC-DS的schema设计里本身就包含空值和不规则字段这些数据正好用来测试两个引擎对脏数据的容忍度。数据生成完之后一定要做行数校验不能想当然认为工具跑完就一定完整。我当时的做法是把每张表CSV的行数统计出来和官方文档里的row count对照表核对。实际踩过一个坑中途磁盘空间满了工具自动退出但没报错小表生成了一部分就停了导入时才发现数据缺了一大块。这种问题在导入后排查很痛苦所以前置校验这个步骤不能省。2.2 两张库的建表差异ClickHouse和Doris虽然都是分析型数据库但建表思维完全不在一个频道上。ClickHouse走的是MergeTree家族建表时需要显式指定排序键和分区键数据按照排序键物理有序地落盘Doris走的是Unique/ Aggregate / Duplicate三种模型需要根据表的更新特征选择合适的模型再指定分桶键和分桶数。举个例子TPC-DS里最大的事实表store_sales在ClickHouse中我建表时排序键选了业务日期和主键的组合分区键选了月份字段这样按日期过滤的查询只会扫描对应月分区的数据。在Doris中同样一张表我用Duplicate模型分桶键选主键分桶数按总数据量和单分桶建议的1-2GB来估算。这里必须提醒分桶数不是越大越好我一开始图省事直接设成100个分桶结果小查询调度开销比计算开销还大后面调回合理区间才正常。另一个值得注意的点是字段类型映射。TPC-DS原始schema里不少字段是decimal和char变长类型ClickHouse对decimal支持没有问题但char类型需要转成FixedString或者String来规避尾部空格填充问题Doris对char类型支持较好但超大宽表的char类型会产生存储放大实际建表时我会把这部分也统计进去。表结构设计直接影响导入和查询性能这块建议在导入前就精心打磨而不是导入后再反复调整。2.3 数据导入方案与耗时对比ClickHouse的导入方式很多常规CSV导入走INSERT SELECT或者clickhouse-client本地文件方式我使用的是clickhouse-client配合FORMAT CSV按表分批导入。这里性能瓶颈集中在磁盘I/O和MergeTree的写放大导入过程会有后台mergeCPU占用率会有一个明显的波峰。SF-100整体导入耗时在三个小时内能完成主表整体规模和并发压力下会有波动但比传统行存导入快很多。Doris这边我用的是Stream Load机制这是它主推的导入方式支持HTTP协议提交文件任务。Stream Load的优点是能边导入边做聚合和索引构建但需要控制导入任务的文件大小我习惯把一张大表拆成多个文件并行提交不然单任务内存压力会比较高。实测下来导入耗时两者相差不大但在并发和负载均衡上Doris的调度更平滑而ClickHouse的导入对CPU有阶段性冲击。导入耗时本身不是重点重点是导入后表的segment大小、分桶分布是否均匀这些直接决定了后续查询性能我会在导入完成后用系统表检查一下数据分布有严重不均匀就手动进行一轮table optimize。3. 查询适配与改造3.1 99条SQL的兼容性硬伤TPC-DS的99条查询模板是标准SQL规范下的产物但实际跑起来没有哪个OLAP引擎能宣称100%兼容。我这次测试把99条SQL先在标准MySQL或PostgreSQL方言下过一遍再分别往ClickHouse和Doris里跑记录每个查询是直接通过、改SQL后通过、还是不通过。实测下来Doris的SQL兼容性明显更贴近传统数据库尤其是对多表join、子查询、窗口函数的支持比较完整99条SQL里大部分可以直接跑通需要修改的集中在函数细节和join语法上。ClickHouse这边情况就复杂一些它的SQL方言有自己的优化方式很多标准SQL写法它能跑但效率不高需要用带方言色彩的改写让它走进良好的执行计划。比如ClickHouse对某些大表join的限制比较严格需要显式指定join算法否则会退化成低效的hash join甚至直接报内存溢出。我在测试时碰到最头疼的一类问题是隐式类型转换。TPC-DS查询模板里大量存在int和decimal之间的比较、字符串和日期之间的隐式转换这两个引擎对这类转换的处理逻辑不一样Doris会按传统数据库的规则自动转换而ClickHouse更倾向于报类型错误或者用意外的规则截断。类似问题在跑数仓查询时经常出现所以适配阶段要专门花时间把这些隐式转换手动改成显式CAST。3.2 典型的SQL适配问题实录具体适配过程中我遇到了几个高频率问题列出来供参考日期函数差异TPC-DS模板里大量使用日期加减和区间判断。ClickHouse的日期加减语法是INTERVAL子句而模板里很多地方写的是DATE_ADD这种传统函数需要在改写时统一。Doris对传统函数支持更好改动少一些。窗口函数写法TPC-DS第7条、第14条这种带多位排序和累积窗口的查询在Doris上基本能直接跑ClickHouse则对窗口的PARTITION BY和ORDER BY条件要求比较严格需要拆成子查询才能稳定执行。子查询物化语义TPC-DS里面很多派生表derived table的场景ClickHouse对派生表关联的优化相对保守有时需要手动把子查询结果集通过临时表或with子句先行物化。这个改动看似不改变业务语义但实际执行计划差异很大测试前必须仔细核对结果数据一致性。3.3 统一测试口径的方法为了让对比结果公平我设定了一个原则能用原生SQL跑就用原生SQL确实因方言限制需要改写的尽量用等价的改写而不是绕过核心逻辑并且在博文里记录每次查询属于“原生可用”还是“适配后可用”。这样出来的性能对比才有说服力。我也准备了三个查询场景集合第一组是简单聚合加过滤模拟常规BI报表第二组是复杂多表关联加嵌套子查询模拟深度分析第三组是窗口函数和排名类查询模拟业务上的动态排序和留存分析。每个场景挑出有代表性的TPC-DS查询两类库各跑三遍取中位数最大程度降低偶发波动的影响。4. 测试结果与性能差异分析4.1 数据加载与压缩对比指标ClickHouseDorisSF-100导入总耗时约130分钟约145分钟落盘数据大小约55GB约72GB压缩比约1.8x约1.4xClickHouse在压缩率上优势明显这源于它默认的高压缩算法和列存特性。Doris落盘稍大但它提供了可选的压缩方式和降基词典针对短字符串字段可以进一步优化。这里要补充一句落盘大小差异不是越快越好还要看压缩率是否影响查询效率压缩率高通常意味着I/O减少但如果解压开销过大反而会拖慢CPU敏感型查询。4.2 查询耗时分类对比我将99条查询按响应速度分成了三档快速查询2秒以内、中等查询2到10秒、慢查询超过10秒。从整体分布看ClickHouse在纯列存扫描、单表聚合、大范围过滤场景中表现非常突出很多典型的报表查询都能在1秒出头返回。优势来自向量化执行引擎和非常激进的并行扫描策略。Doris在单表聚合性能上略落后一点但落后幅度有限真正拉开差距的场景是多表join和复杂子查询。TPC-DS里面凡是涉及三张以上表关联的Doris的执行器优化更好多数查询能稳定在10秒以内而ClickHouse有些查询会因为join策略选择不佳冲到20秒开外甚至需要使用改写才能收敛。整体看测试期间两个引擎都无法做到99条全部低延迟通过但Doris的稳定性明显更好——它几乎没有出现单条查询因资源限制而中断的情况ClickHouse则在几条高复杂度join查询上出现过内存保护触发的问题。4.3 并发与资源消耗表现我额外测试了20并发下的查询吞吐。ClickHouse的高并发能力很强纯分析型查询在并发下CPU利用率能稳定跑到80%以上但并发一高I/O调度会出现排队个别查询延迟会被放大。Doris在并发控制上有自己的资源组机制常用队列模型限制大查询所以整体延迟曲线更平滑尤其是复杂join查询在并发场景下的失败率比ClickHouse低很多。内存占用方面ClickHouse的大join查询峰值内存较高遇到数据膨胀时容易触碰内存限制Doris对join内存控制更精细小表广播、大表分桶执行的策略更稳妥。如果你的场景是团队内多业务同时跑复杂分析Doris的资源隔离优势会比较明显如果场景是高并发简单报表ClickHouse的延迟优势更能打。4.4 硬件与调优空间分析两类数据库在新硬件上都支持较多的核心数但调优方向不同。ClickHouse主要通过调整线程数和内存限制参数来提升单查询性能它的并行度几乎可以线性扩展。Doris则需要重点调分桶数、副本数和join内存策略调优得当的Doris能在大宽表场景中表现出色但调优路径更长得理解它的MPP执行模型才能调准。5. 常见问题与排查技巧实录5.1 SQL改写的边界问题在测试过程中我经常需要在“保持语义不变”和“让引擎跑得快”之间折中。一位数据开发曾经跟我说过压测的时候别为了性能毫无边界地改写SQL比如有些团队会把连接谓词直接抽到临时表里减少join参与表的数据量这在业务上线时往往不可维护。我的建议是压测时用于调优的SQL改写可以大胆但最终交付的业务SQL必须保留原始语义并且把改写方案沉淀成一份规范方便后续排查。5.2 内存溢出与查询异常高频出现的内存溢出场景集中在两个地方一个是不等值join另一个是全局排序。简单表关联可以在Doris里通过分桶裁剪解决但遇到极端数据倾斜某个键值占比特别高时单分桶数据会超过内存阈值。我的排查路径是通过explain看分桶扫描行数再对倾斜键做单独处理。ClickHouse侧则容易在子查询返回结果集过大时出现问题解法是用全局字典或者构造视图来减少中间结果集写入内存。这类问题在标准压测里表现为查询失败率但在真实业务中就是线上事故必须提前摸底。5.3 数据一致性与结果校验跑性能测试不能只看耗时还得看结果对不对。TPC-DS官方提供了结果一致性校验思路但实际操作中我们更常用的是把关键查询的结果集算一个校验值在两个库中分别执行后对比。我在测试中遇到过一次自己发现的严重问题某条带窗口函数的查询在改写后性能不错但结果数和标准模板差了几行原因是ClickHouse对排序边界值的处理和一个隐藏的NULL排序规则差异有关后来显式指定了NULL的排序方向才一致。6. 最后再分享一些个人经验测试做完整整一遍我的感受是没有绝对的“谁更强”只有“谁更适合你的业务”。ClickHouse更适合海量明细数据的高频过滤和聚合统计它的吞吐量在同价位硬件上很有竞争力但复杂join和子查询需要花时间做SQL适配Doris在复杂分析、多表关联、实时更新场景下更省心对SQL开发人员也更友好团队上手成本低。如果在选型时拿不准强烈建议把TPC-DS跑通一遍并且不要只看SQL执行时间把导入时间、压缩率、并发稳定性、内存峰值这些指标都放到一张表里综合评估。我这套测试流程和数据分析模板完全可以作为你选型评估的起点即使你面对的不是ClickHouse和Doris换成其他分析型数据库也一样适用。