做OLAP选型这件事我见过太多团队把时间花在争论“ClickHouse和StarRocks到底谁更强”上结果上线三个月后才发现瓶颈根本不在查询引擎而是底层存储方案从一开始就没匹配好负载特征。大数据领域的OLAP分布式存储系统选型本质上不是一个“选哪个软件”的单一选择题而是一套“分层组合 按负载定方案”的方法论。这里先把结论放在前面OLAP存储选型先分层再选品。HDFS、对象存储、Iceberg、ClickHouse、Doris这些名词其实根本不在同一个技术层级把它们放在同一个维度里硬比只会越比越乱。这篇文章要做的是把存储层、表格式、查询引擎这三个概念彻底拆开再给出一套能直接落地的选型流程和避坑清单。写这篇东西的直接起因是最近好几个朋友都在问同一件事公司数据量已经到了几十TBBI报表越来越多原来的MySQL和行存数仓扛不住聚合查询了下一步到底往哪走。是换ClickHouse还是上一套数据湖还是直接迁到云数仓说实话没有标准答案但有标准流程。你只要按流程走一遍最后得出的结论通常不会太离谱。1. OLAP场景的存储需求和你想的不一样1.1 OLAP负载的两大典型特征扫描为主与数据不可变想选好存储得先搞明白OLAP到底在跑什么活儿。OLTP是高频小事务特点是点查多、更新多、并发高每次操作只涉及几行数据OLAP正好相反一次查询往往要扫几十亿行只取其中少数几列参与聚合、关联、排序。这个差异直接决定了存储层的设计取向——OLTP的存储基本是行式的因为要高频按主键拿一整行OLAP的存储则几乎都是列式的因为要把某个列连续读出来参与计算列存配合压缩IO量能比行存少一个数量级。另一个容易被忽视的特征是数据不可变。分析场景里的数据一般只追加、很少就地修改。你看到某条数据被“更新”了底层往往是insert新版本、标记旧版本失效而不是原地覆盖。这个特性让存储方案可以大胆做顺序写、做压缩、做分区裁剪把读性能压到极致。如果你选型时还在按照OLTP的思路纠结“更新性能好不好”“事务隔离级别强不强”方向就偏了OLAP存储的核心指标永远是“大查询跑多快、批量写入多稳、扩展多方便”。1.2 记忆地图把名词分成三层再对比这里我给出一张心智地图帮你把常见技术名词归位。HDFS、MinIO、S3、OSS、COS属于文件/对象存储层管的是“文件放哪里、怎么冗余、怎么弹性扩展”Iceberg、Hudi、Delta Lake属于表格式层管的是“一张表对应哪些文件、事务怎么提交、快照怎么隔离”ClickHouse、Doris、StarRocks属于查询引擎层但它们自带存储实现不依赖外部表格式所以你也可以把它们理解为“存储与查询一体化引擎”。很多人纠结“HDFS好还是ClickHouse好”其实这俩根本不在一层。你完全可以用HDFS或对象存储存原始数据再用ClickHouse存加速计算后的结果数据也可以用Iceberg加查询引擎的方式让同一套表格式同时喂给Spark批处理和Presto即席查询。理解了分层脑袋里的混乱立刻消失一半。选型的本质不是选“一个东西”而是组合“多个层级”每一层选一个最合适的组件再把它们串起来。1.3 先回答三个问题再谈具体方案在动手对比任何一款产品之前先回答三个实际问题数据是给人看报表还是给算法做特征响应时间是秒级还是分钟级数据是批量化T1还是要求实时可见。这三个问题的答案基本决定了你要不要做实时数仓、要不要做存算分离、要不要引入表格式层。建议把这三点写在纸上因为后面所有对比和决策都要回到这三个答案上否则很容易被厂商的宣传材料带偏。2. 主流方案全景文件、对象、湖格式与数仓2.1 文件系统与对象存储数据底座的基本盘HDFS是大数据生态里的老牌文件系统简单、可靠副本机制成熟跑Spark、Hive、MapReduce都很顺手。它的短板也很明显NameNode有单点压力海量小文件会让内存和心跳不堪重负弹性扩缩容不如对象存储自然。如果你的Hadoop集群已经稳定跑了多年完全没有必要为了“换新”而换掉HDFS它仍然是批处理场景里非常靠谱的底座。对象存储是这几年的“标准答案”。S3、MinIO、阿里云OSS、腾讯云COS这类产品几乎成了存放数仓底层数据的默认选择。优点是高可用、无单点瓶颈、扩容完全透明、存储成本低特别适合放原始日志、Parquet文件、备份数据、Iceberg表数据。实际使用中要留意一致性模型主流的云对象存储和MinIO已经能提供强一致或接近强一致的能力但自建Ceph这类方案需要额外评估。对象存储的劣势是延迟比本地盘高不适合高频小IO查询所以它更适合当“冷底座”而不是“热查询层”。2.2 表格式让数据湖真正“像数仓”的关键对象存储里的文件只是文件本身没有“表”的概念。这正是Iceberg、Hudi、Delta Lake这类表格式存在的意义在一堆文件之上补上元数据管理、事务提交、快照隔离、分区演进能力。有了表格式你才能在对象存储上跑ACID操作才能实现“Spark写完的数据Presto立即可见”。这类方案最大的价值是让数据湖具备了数仓的语义所以也被称为湖仓一体。从选型角度讲三者的差别主要体现在生态和更新语义上。Iceberg的社区最活跃对多种引擎的支持最均衡适合希望“一套表被多个引擎共用”的团队Hudi在流式摄入和增量更新上积累更深适合有较多upsert需求的场景Delta Lake与Spark同源如果你绝大部分计算都在Spark上它最顺手。我自己的倾向是默认评估Iceberg除非团队有强烈的Flink流式更新诉求或纯Spark生态依赖。表格式层也不是必须的——如果你直接用Doris或ClickHouse它们自己管理元数据不需要额外套一层表格式。2.3 OLAP数据库开箱即用的“全家桶”如果嫌自己组装存储层太麻烦直接用OLAP数据库是更常见的路线。ClickHouse的单表扫描和聚合能力是出了名的强几十亿行秒级出结果是家常便饭但它在高并发点查、多表复杂Join上不算擅长运维对merge和节点均衡的要求也不低。Doris和StarRocks则是在明细查询、预聚合、高并发场景下更均衡的选择特别是StarRocks在实时写入和点查能力上做了很多优化社区迭代也很活跃。云数仓则是另一条路。Snowflake、Redshift这类产品把存算分离做到了产品级你只管开仓、写SQL、看账单存储和计算都能独立扩展。这种方案的优点是运维成本极低按量付费让初期成本可控缺点是不适合极端定制和本地化部署数据量非常大时账单也可能失控。选这条路的团队通常不是“没能力自建”而是“没必要自建”尤其是中小团队和云原生公司用云数仓可以省下整整一个基础架构组的人力。3. 选型判定的四个核心维度3.1 查询性能先定义“快到什么程度”性能是比较容易量化但最容易被误导的维度。选型前先定义清楚自己的性能目标是支持10以内秒级的即席查询还是毫秒级的高并发在线服务是单用户跑大SQL还是500个并发同时看仪表盘。Clickhouse跑单个大查询确实很强但并发一旦上去CPU和内存立刻吃紧Doris和StarRocks在设计上就更看重并发场景自带多副本查询路由和缓存机制适合内部多团队共用的一套数仓。我建议在选型清单里明确写一条“P95查询时间”指标并且拿自己的真实查询样本去测。不要只看官网的benchmark场景不一样结果天差地别。比如一个团队的核心查询是“按天聚合10亿条日志”另一个团队的核心查询是“筛选100个用户ID的最近100条行为”这两个查询会在完全不同的引擎上表现不同前者适合列存大扫描后者需要二级索引或partition裁剪能力突出的引擎。3.2 数据新鲜度批量和实时是分岔路口存储方案选型和数据延迟要求强绑定。如果你的ETL是T1的数据每天凌晨批量导入那么HDFS加Hive或Spark这套经典组合依然很能打成本也低。如果你希望数据延迟压缩到分钟级甚至秒级那么“准实时数仓”的架构就是必须考虑的上游通过Flink或Kafka实时处理结果落到Doris、StarRocks或ClickHouse这类支持高频导入的引擎中。这里有一个经常被忽略的问题实时导入会带来大量小文件批量摄入则会周期性产生大文件二者对存储层的影响完全不同。数据湖和对象存储都怕无休止的小文件因为元数据膨胀会拖垮整个查询规划OLAP数据库虽然有compaction机制但导入频率太高也需要你在分区数、写入批次之间做平衡。所以选型时不仅要问“数据库支持不支持实时写入”还要问“你打算怎么控制小文件产生”。3.3 扩缩容与存算关系一体还是分离存算一体和存算分离的选择决定的是你未来的运维模型和成本模型。ClickHouse、传统数仓都是存算一体本地盘或者挂载云盘扩容通常需要迁移数据不太灵活Doris和StarRocks虽然可以做到计算节点和存储节点分离部署但本质上还是靠副本和分片来扩展和真正的对象存储存算分离不同。Snowflake、Redshift这类产品则把计算和存储彻底解耦计算集群可以秒级拉起、空闲时直接挂起存储层完全由云厂商托管。如果你的业务有明显的波峰波谷比如白天BI查询量大、凌晨只有批处理任务存算分离的云数仓能省下大笔闲置计算成本如果你的业务负载全年稳定且对数据本地性和延迟要求很高存算一体的自建OLAP数据库反而更省心。另外还要考虑数据迁移和副本策略存算一体方案一般会有多副本机制磁盘占用是数据量的两到三倍规划容量时务必把这一点算进去。3.4 成本账别只盯着服务器报价选型成本不只是服务器采购费用还包括运维人力、存储副本开销、网络带宽和未来的迁移成本。举个具体例子一套三副本的本地方案每TB有效数据实际占用3TB磁盘还要留出20%左右的余量做compaction和临时文件如果换成对象存储存储本身按量计费便宜很多但每次查询都要把数据从远端拉取到计算节点网络流量费用是大头。很多团队做完POC只看了查询延迟没算全成本结果上线后账单吓人。建议在做最终决策前估算三年总成本按数据量每年增长一倍预测分别算自建方案和云方案的存储、计算、网络、运维四块费用。另外还要把人力成本算进去包括你团队是否养得起一个专职的OLAP运维工程师。很多时候云数仓“贵”的那部分恰恰是在买你团队的安心。4. 一套可以直接抄的选型流程4.1 第一步画出你的查询画像选型前先做一次查询画像统计收集过去两周所有SQL的样本按类型打标大聚合报表类、明细点查类、关联Join类、即席探索类分别统计占比和平均扫描行数。这一步不需要任何工具只要让业务方和数据分析师列一下日常查询就行。很多团队到这个环节会发现自己口口声声说“实时大屏”很重要实际上80%的查询仍是凌晨跑批和上午的报表查询真正的实时查询不到10%这个发现能帮你避免整套架构过度设计。4.2 第二步估算数据规模与增长曲线数据规模决定了你在哪一层做取舍。10TB级别单机或两三台ClickHouse节点就能解决没必要引入数据湖100TB级别需要考虑分区分桶、压缩策略和存储配额建议引入对象存储处理底层数据配合OLAP数据库做结果加速PB级别数据湖几乎成为必然你必须有清晰的存储分层策略并且认真对待小文件和元数据治理问题。4.3 第三步按场景对号入座这里给一个我自己常用的场景决策表不一定适合所有团队但可以作为起点。场景特征推荐路线核心理由数据量小于20TB以T1批报为主ClickHouse或Doris单集群组件少运维简单性能足够快数据量50TB以上依赖Spark做复杂ETL需要多引擎共享数据对象存储/HDFS Iceberg Presto/Spark存算分离避免引擎锁定湖仓一体扩展性好实时报表、大屏、高并发明细查询StarRocks或Doris实时摄入和并发查询能力均衡运维比ClickHouse省心中小团队不想自建云原生优先Snowflake、Redshift或云厂商数仓存算分离省人力弹性扩缩容成本可控已有稳定HDFS集群主要是批处理继续用HDFS Hive/Spark评估是否需要引入Doris做加速不折腾增量优化优于推倒重来4.4 一个典型的落地架构长什么样结合前面所有讨论我给你画一个很多团队最终会走到的参考架构纯文字描述最底层是对象存储存放原始日志和中间结果文件所有数据作为“冷底座”在对象存储之上如果有多引擎共享需求引入Iceberg表格式让Presto和Spark共用一套表再往上用Flink做实时ETL把明细结果写入Doris或StarRocks由它承接BI报表和实时查询最上层的即席分析可以通过Trino/Presto直接查Iceberg也可以把热点数据落到Doris中加速。这个结构兼顾了成本和体验冷数据在对象存储里便宜热数据在OLAP数据库里快。唯一的代价是要维护两套查询接口对团队有一定要求。如果团队规模小可以砍掉Iceberg让Spark直接计算后结果写入Doris或ClickHouse结构更简单只是缺少实时共享表的灵活性。架构本身是服务于团队能力和业务诉求的不要为了“先进”而引入自己养不动的组件。5. 真实环境里最常见的坑5.1 小文件一切性能问题的根源使用对象存储加数据湖时如果每天写入几万个小的Parquet文件查询性能会断崖式下降元数据读取和文件列表开销比真正扫描数据耗时还多。解决的方法无非是控制写入频率、在写入端做文件合并或用Iceberg的表维护功能自动跑compaction。这个问题在POC阶段很难暴露因为测试数据就几GB等到生产环境数据量翻倍才开始爆炸所以选型时一定要在方案里预留小文件治理的措施。5.2 排序键与压缩格式低成本高收益的调优OLAP数据库的性能差异很多时候不是引擎本身的问题而是表设计的问题。ClickHouse的排序键决定分区裁剪和index加速选错排序键会让你的查询退化为全表扫描Doris和StarRocks的分桶键、前缀索引也有类似影响。建议把高频查询的where条件字段放在排序键前面并且测试不同的排序键组合。压缩格式同样重要ZSTD压缩率高适合单次大扫描LZ4解压快适合频繁读取的数据。很多团队贪图压缩率全表选ZSTD结果高并发场景下CPU被打满反而是负优化。5.3 存算分离之后的远程读延迟存算分离听起来美好但实际运行中会踩到远程读延迟的坑。特别是当你的计算引擎需要频繁访问对象存储时每次shuffle、每次扫描都要经过网络拉取数据延迟比本地盘高好几个数量级。解决方案是引入缓存层或者将最热的数据表“物化”一部分到计算节点的本地盘。我见过不少团队把整个数仓全放到对象存储上结果即席查询慢到不可用最后不得不在计算侧加了一层Redis或本地缓存。搞存算分离没错但一定要配合冷热数据分层别让所有查询都直接打对象存储。5.4 常见问题速查表问题常见原因排查/解决思路查询总是超时排序键设计不合理数据倾斜并发过高检查执行计划评估是否需要重建表限制大查询并发写入很慢且磁盘占用飞涨小文件过多compaction跟不上降低摄入频率开启批量写入手动触发合并导入实时数据后查不到表格式快照隔离或引擎内存导入尚未提交确认提交机制检查事务状态区分“存储可见”和“查询可见”存算分离后查询延迟明显变大远程读未缓存增加本地缓存层或把热表物化到计算节点多引擎查同一张表结果不一致表格式与引擎版本不匹配或缓存未刷新统一版本关闭不必要时一致性要求低的缓存最后分享一个我自己的经验OLAP存储选型这件事选型和架构设计只占三分剩下七分是持续调优和治理。不管最终选了ClickHouse、StarRocks还是Iceberg加对象存储的组合真正决定项目成败的往往是你有没有一套稳定的数据导入流程、小文件治理机制、查询监控和容量规划体系。选型时留出20%的余量上线后密切观察真实查询的执行计划保持用数据做调优的习惯远比一开始就追求“完美架构”更实际。如果后面再遇到类似选型问题记得先画查询画像再分层对比别被某款产品的宣传指标冲昏了头脑。