企业官网建设流程全解析

去年年底我们返利BI系统做了一次底层引擎的替换，把原来撑了快两年的MySQL汇总表方案换成了OLAP引擎。当时摆在面前的三条路是Doris、StarRocks和ClickHouse，经过两周压测和一个月并行试运行，最终圈定了Doris与StarRocks继续做深度选型评估。这篇文章就把我们当时做选型决策的思路、同一套返利数据集上的性能对比结果，以及迁移过程中几个典型的踩坑记录完整拆开来讲，希望能给正在做OLAP引擎选型或者准备把BI底层迁移到列式存储的同学一些参考。

需要说明的是，Doris和StarRocks本是同源产品，技术脉络纠缠得很深，网上很多文章喜欢分个高下，但我们实践下来的感受是：两者的差异更多体现在业务场景的匹配度上，而不是绝对性能的优劣。下面我会从业务痛点、架构差异、实测数据、建模细节和迁移踩坑五个方面展开，尽量把“为什么这样选”“实际用起来有什么差别”讲清楚。

1. 从业务痛点倒推技术选型：为什么返利BI需要OLAP引擎

1.1 返利系统最典型的分析查询长什么样

先交代一下我们系统的业务背景。电商返利本质上是一种按效果付费的联盟营销：用户通过推广链接下单，订单完成后平台给推广渠道计算并发放佣金。返利BI系统的核心就是围绕“订单—用户—商品—渠道—结算单”这几张表做多维分析。

表结构大概长这样：

CREATE TABLE refund_order_fact ( order_id BIGINT, user_id BIGINT, goods_id BIGINT, channel_id BIGINT, order_time DATETIME, settle_date DATE, order_amount DECIMAL(18,2), settle_amount DECIMAL(18,2), commission_rate DECIMAL(5,4), status TINYINT -- 1待结算 2已结算 3已失效 ) ENGINE = OLAP DUPLICATE KEY(order_id) DISTRIBUTED BY HASH(order_id) BUCKETS 24;

BI看板里最常见的查询是这几类：

• 按天、按渠道汇总佣金金额和订单量
• 指定时间窗口内的Top N商品排行
• 按用户首单率、复购率做漏斗分析
• 某个渠道的月度佣金环比、同比
• 财务结算前对账单明细做对账核对

这类查询有一个共性特征：单表扫描量大、聚合维度多、过滤条件随机组合。比如“统计最近30天每个渠道、每个一级类目下的有效佣金总额，并按照渠道分组对比上个月同期”，这条SQL在MySQL里要扫几千万行订单明细，再走临时表和文件排序，跑一次要几十秒。如果看板上有十几个图表同时刷新，数据库直接卡死。

1.2 MySQL加汇总表的极限在哪

我们早期的方案是“MySQL主库 + 定时任务 + 多张汇总表”。运营看板需要的每个指标组合，都提前用定时任务算好，写进一张带复合索引的汇总表，前端查询时只做简单group by，不碰明细。

这套方案在业务量小的时候很稳，但当维度组合多起来之后问题就暴露了：

第一，汇总表膨胀得非常快。渠道、商品类目、用户等级、时间周期，每增加一个分析维度，就要新建一组汇总表来预聚合，否则查询就得临时扫明细，性能立刻掉下来。后期我们光汇总表就有四十多张，ETL任务之间的依赖关系复杂到换个字段都要小心翼翼。

第二，口径经常对不上。定时任务先跑渠道维度、再跑商品维度，中间如果有一批返利记录发生状态变更（比如团长佣金比例调整导致结算单重算），不同汇总表之间的数据就会产生不一致。运营和财务各看一套数字，反复找人排查，非常内耗。

第三，实时性不满足。所有报表都是T+1，每天凌晨跑批。返利业务很依赖“今日实时佣金”这种指标，团长要看实时推广效果，运营要根据实时数据调整活动策略。T+1根本没法支撑。

所以我们决定引入OLAP引擎，核心诉求是：

• 明细数据直接入库，不再依赖多套预聚合汇总表
• 支持高并发多维即席查询，单条复杂聚集控制在秒级返回
• 能够处理返利记录的状态异步更新，而不是全量重刷
• 导入链路要简单，最好能兼容已有的数据管道

在这个前提下，Hive和Spark离线数仓虽然很成熟，但查询延迟和数据更新链路都太重，不适合放在BI看板后面直接面向运营。ClickHouse的单表扫描性能确实很强，但多表join优化、点更新和数据一致性方面有明显短板。最终进入决赛圈的就是Doris和StarRocks。

这里多说一句选型的思考方式。不要一上来就比性能跑分，性能只是入场券。真正重要的是先把自己的查询特征、数据更新模式、运维能力边界列清楚，再拿产品和自己的场景匹配。性能对比是最后一步的验证，而不是第一步的筛选条件。

2. Doris与StarRocks同源不同路：架构差异如何影响查询表现

2.1 同源分支的时间线

Doris和StarRocks的关系，很多刚接触的同学容易搞混。Doris的前身是百度开源的Palo，后来捐献给Apache基金会成为Apache Doris。StarRocks则是2018年前后从Doris早期版本分叉出去、独立发展起来的另一个分支，所以两者在基础理念上有大量相似之处：都是MPP架构、列式存储、向量化执行、支持MySQL协议、使用FE和BE的两层无共享架构。

但在分叉之后，两个项目走了不一样的技术路线。StarRocks更激进，从1.x版本就开始强调全面向量化执行和自研的CBO优化器，2.x之后又重点做主键表和物化视图；Doris则更偏向稳扎稳打，2.0版本才完成查询执行器的全面向量化，但社区生态更庞大，周边工具和大厂案例更多。

所以选型时很多人会问“Doris和StarRocks到底谁强”，这个提问本身没法回答。更准确的问法是：以我们当前的业务场景，哪个产品的架构取舍更接近我们的需求。

2.2 查询引擎与优化器的关键差异

先说执行引擎。StarRocks从1.19开始就把向量化执行作为默认执行方式，Doris在2.0之后也全面向量化了，两者在单条大SQL的扫描和聚合能力上差距已经不大。但在复杂查询、多表join的执行计划选择上，StarRocks的自研CBO在统计信息收集和代价估算上做得更细，尤其在多表关联、子查询解构这类场景中，误选执行计划的概率明显更小。

我们的实测程序员也能直观感受到这一点。同样的“渠道、商品类目、用户等级三维关联聚合”查询，Doris偶尔会把join顺序排错，导致中间结果集膨胀，内存和耗时飙升；StarRocks整体上更稳定一些，大多数情况下执行计划都比较合理。

另外，StarRocks有一个很贴近BI场景的特性——查询并发度管理。Doris默认的查询并发能力并不差，但在高并发小查询场景下，StarRocks的Pipeline执行引擎配合资源组限制，能把不同部门、不同优先级的查询做资源隔离，避免运营那边一个跑大聚合的看板查询把财务对账用的核心查询拖垮。这一点我们在两个引擎的对比测试里体会非常明显。

2.3 数据模型与更新能力：返利场景的关键差异

返利BI有个很特殊的数据特征：订单明细不是生成后就不变的。用户在确认收货前订单可能取消，退款之后返利要回收，结算周期到了佣金状态要从“待结算”变成“已结算”，甚至运营调整某个渠道的佣金比例后，历史佣金要重算回滚。

这就要求OLAP引擎具备比较高效的更新能力。Doris提供的模型有三种：Duplicate、Aggregate、Unique。Unique模型通过Merge-On-Read实现更新，但在高并发小批量更新场景下性能表现比较一般。StarRocks除了这三种模型之外，还做了一张主键表（Primary Key表），通过删除标记加写入新版本的方式更新，底层实际上把Merge操作尽可能推迟到读取阶段，并且支持了实时更新场景的写入优化。

在我们的返利佣金重算场景里，每天大概有几十万到几百万条结算单状态更新。如果使用Doris的Unique模型，重算时段的查询经常出现读放大，明细查询变慢；换到StarRocks主键表之后，同样的更新负载下查询稳定性明显改善。如果你的业务里像“订单状态频繁流转”这种实时更新需求很强，这一点值得重点测试，甚至应该提前设计好压测场景。

2.4 物化视图与外表查询的取舍

原本我们是打算用物化视图解决一部分高并发报表问题的，所以在对比时对两边的物化视图也做了关注。

Doris在2.1版本之前提供同步物化视图，使用起来相对简单，创建后写入时自动维护，但限制也比较多，比如不能有join、聚合函数支持有限。StarRocks的物化视图属于异步刷新模式，支持多表join、支持分区刷新，同时还能在查询时自动改写匹配，功能上更像传统数仓的物化视图，灵活度高不少。

实际使用下来，我们最终没有大规模依赖物化视图，主要原因是返利明细的更新方式太灵活，维护异步物化视图的刷新逻辑需要额外的成本。最终我们选择“明细表 + 定时DWS层轻汇总 + 查询侧改写”的组合。但如果你团队对物化视图模式驾轻就熟，且业务更新模式相对固定，StarRocks在这方面会有更好的可玩性。

再提一点外表查询。两个产品都支持通过Catalog方式访问外部数据源，可以跨源查询MySQL、Hive、Iceberg等。对我们来说，BI底表进OLAP后仍需要跟MySQL里的维表做关联，Doris和StarRocks都支持外表关联，实际体验差别不大。这个能力能减轻迁移初期的压力，不用一口气把所有表都搬进来。

3. 实测对比：同一套返利数据集上的查询性能与稳定性

3.1 测试环境与数据集构造

选型阶段我们在同一个测试集群上部署了两套引擎，测试配置保持一致：

测试数据取了我们线上近18个月的返利订单明细，共5.2亿行，压缩后约80GB，导入完成后包含订单维度、用户维度、商品维度、渠道维度、结算单维度共5张表，其中最大的一张返利明细表对应了典型的星型模型。

导入方式统一使用Stream Load，每个文件约512MB，并发导入。

测试口径上我们做了三组：冷查询（先执行一次预热查询绕开文件页缓存）、热查询（连续执行取后10次的平均值）、以及并发混合场景（模拟BI看板上8种查询同时刷新，用户并发数分别为10、30、50）。

3.2 关键SQL与耗时对比

下面列出测试结果最典型的四条SQL，都是返利BI看板上真实在用的：

查询A：按天统计有效佣金总额和订单量

SELECT settle_date, SUM(settle_amount) AS valid_commission, COUNT(DISTINCT order_id) AS order_cnt FROM refund_order_fact WHERE status = 2 GROUP BY settle_date ORDER BY settle_date;

查询B：某时间段内各渠道+类目的佣金排行

SELECT channel_id, goods_category, SUM(settle_amount) AS commission FROM refund_order_fact WHERE settle_date >= '2025-01-01' AND settle_date < '2025-04-01' AND status IN (1, 2) GROUP BY channel_id, goods_category ORDER BY commission DESC LIMIT 100;

查询C：跨表join，统计每个渠道近半年的首单用户数和二次复购率

SELECT f.channel_id, COUNT(DISTINCT f.user_id) AS first_order_users, SUM(CASE WHEN r.rebuy_flag = 1 THEN 1 ELSE 0 END) AS rebuy_users FROM refund_order_fact f LEFT JOIN dim_channel c ON f.channel_id = c.channel_id LEFT JOIN rebuy_summary r ON f.user_id = r.user_id WHERE f.settle_date >= '2024-10-01' GROUP BY f.channel_id;

查询D：高并发下重复执行查询B，模拟同一时间多个运营人员并发查看。

热查询的平均耗时数据如下：

从数据上看，单表扫描场景Doris和StarRocks差距并不大，简单聚合时差距在20%到30%之间，但一旦涉及多表join，或者并发压力上来，StarRocks的领先幅度就拉大了。原因还是前面说的CBO和Pipeline执行引擎的差异。

值得注意的是，这些数据和测试集群配置、数据分布强相关，不代表所有场景下的结论。如果你的业务大量集中在单表大查询、不怎么做多表join，那这两者之间可能不会拉开这么明显的差距。

3.3 并发、稳定性与资源占用

除了耗时，我们还重点看了并发和稳定性。

50并发混合场景下，Doris出现了一次因内存不足触发的查询失败，BE节点内存使用率飙到92%，部分查询直接报错；StarRocks在同样的并发下内存使用率稳定在75%左右，虽然没有报错，但P95延迟也明显上涨。这个结果给我们一个重要提示：如果BI系统会面向比较多运营人员同时使用，最好一开始就按并发需求做资源规划，不要只看单条SQL耗时。

平台顺手测了导入和压缩率。同样5.2亿行数据，Doris压缩后约82GB，StarRocks约76GB。导入性能方面，Stream Load并发12个文件，两者吞吐都在120MB/s以上，日常使用感知不到明显差异。

跑完这些测试之后，我们的判断是：Doris完全能满足业务的大部分场景，性能也够用；StarRocks在复杂查询和并发场景表现更好，而这两点恰恰是电商返利BI在运营看板高负载时最容易被投诉的点。所以最终选定StarRocks作为生产引擎，同时保留了Doris的对比环境继续跟踪版本进展。

4. 数据导入、分桶策略与字段演进：决定长期体验的实操细节

4.1 Stream Load的两种方式与Java调用细节

决定用StarRocks之后，第一批要解决的就是数据导入。我们从MySQL binlog解析出数据变更，经过Kafka、Flink做实时清洗，再通过Stream Load写入StarRocks。相比Broker Load，Stream Load更适合实时、大批次高频导入，不需要Hadoop集群依赖，直接通过HTTP接口发送数据。

Java调用Stream Load的标准写法大概是这样的：

String url = "http://fe_host:8030/api/db_name/refund_order_fact/_stream_load"; HttpPut put = new HttpPut(url); put.setHeader("Authorization", "Basic " + base64Encode("user:password")); put.setHeader("Expect", "100-continue"); put.setHeader("Content-Type", "application/json"); put.setHeader("format", "json"); put.setHeader("strip_outer_array", "true"); put.setHeader("label", "load_label_" + System.currentTimeMillis()); JSONArray dataArray = new JSONArray(); // 组装一批数据，比如每批10000条 for (RefundOrder order : batchList) { dataArray.put(order.toJsonObject()); } StringEntity entity = new StringEntity(dataArray.toString(), "UTF-8"); put.setEntity(entity); try (CloseableHttpResponse response = httpClient.execute(put)) { String respBody = EntityUtils.toString(response.getEntity(), "UTF-8"); JSONObject result = JSON.parseObject(respBody); if (result.getIntValue("Status") != 200) { // 处理失败，读取错误URL日志排查 } }

这里有几个容易踩的细节：

第一，label一定要设置，而且要保证集群内唯一。Stream Load的label是幂等标识，如果导入过程中网络超时导致客户端没收到响应，你可以拿着同一个label重试导入，引擎会自动去重。如果省略label，重试时就会产生重复数据，对返利金额这种敏感指标是绝对不能接受的。

第二，每批数据量要控制好。我们测试下来的经验是单批JSON大小在10MB到50MB之间比较稳，超过100MB后导入失败重试的成本会明显上升。数据量太小时导入吞吐上不去，造成大量小事务合并压力。这个值也和集群磁盘IO能力有关，需要实测调整。

第三，从Flink写入时不要每个checkpoint都触发一次Stream Load，根据业务容忍的延迟合理设置flush间隔。我们线上设置的是每5秒或每10万条flush一次，兼顾了实时性和导入性能。

补充一点，如果是启动阶段要做历史数据回填，建议直接用Broker Load把HDFS上的历史文件批量导入，比Stream Load一条条推更高效。我们回填5.2亿行历史数据，用Broker Load并发拉起12个任务，大概一个半小时导完。

4.2 分桶数怎么定：几MB数据要不要分桶

分桶是网上问得很频繁的一个问题，尤其是“我数据只有几MB，是不是不需要分桶”。很多新手在这个环节会走进两个极端：要么每个表都照搬默认分桶数，要么觉得数据小就不设分桶。

先说结论：分桶不是为了“把数据拆开好看”，而是为了三个目的——控制单个Tablet的体积、提供并行扫描的粒度、保证数据在BE节点间的均衡分布。所以“数据小就不分桶”的想法不完全对，但也确实不需要为了分桶而分桶。

分桶数的经验估算公式，社区里比较一致的做法是：

• 单Tablet数据量控制在300MB到1GB之间比较合适
• 分桶数建议取BE节点数的整数倍，这样能让数据均匀分布到所有BE

假设你机器上数据总量大约80GB，副本3份，那实际上底层存储约240GB，除以500MB的Tablet目标大小，大约480个Tablet。如果集群有6个BE节点，分桶数取480或512都可以，既能保证每个Tablet不过大，又能让并行度足够。

但如果你整个表只有几MB，强制分成几十个桶反而有害。每个Tablet都有独立的元数据，Tablet多了元数据管理成本上升，导入时会产生大量小文件，查询时并行扫描的优势又发挥不出来。对于这种小数据量，建议直接建表时分1到3个桶，甚至不设置分桶让引擎按默认策略处理。

我们的一个实际经验是：返利明细这种增长很快的大表，要提前按未来一年的数据量估算分桶数；而维度表这种基本不增长的表，保持小分桶数即可。如果后续发现某些Tablet过大或查询热点集中在个别桶上，还可以通过动态分桶或重建表的方案调整。

另外要注意分桶列的选取。我们返利明细表选的是order_id，因为查询几乎都会带订单维度过滤，而且order_id的分布足够离散。如果你按user_id分桶，某个大渠道的用户容易被哈希到同一个桶，造成数据倾斜，影响并行扫描效果。

4.3 字段变更、资源分配与日常管理

迁移过程中还处理了不少建表之外的管理工作。

字段改名是经常遇到的需求。StarRocks里可以用一条命令完成：

ALTER TABLE db_name.refund_order_fact RENAME COLUMN goods_category TO category_name;

要注意的是，改名操作会有短暂的元数据变更锁，如果表正在被高频查询，最好安排在低峰期执行。Doris也有类似语法，但版本之间有差异，上线前先在小表上验证一次比较稳妥。

“用户资源分配”也是我们重点配置的功能。StarRocks的资源组（WorkGroup）可以把不同查询映射到不同的CPU和内存配额：

CREATE WORKGROUP wg_bi_big_query WITH ( cpu_core_limit = 8, mem_limit = 30% );

我们给运营看板的大聚合查询设置了独立的资源组，并把内存限制压在30%以内，这样即使有人写了个慢查询，也不会把整个集群拖死。

日常运维上，Doris和StarRocks类似，FE负责元数据和查询规划，BE负责数据存储和查询执行。部署时建议FE节点至少3台做高可用，BE节点单独部署，不要和FE混部，避免资源竞争。磁盘方面，BE节点的数据目录最好规划独立分区，日志目录和数据目录分开，避免日志涨满导致BE异常退出。

如果是从Doris迁移到StarRocks，特别是用了他家生态工具的同学，要留意版本兼容问题。SelectDB、DataX等周边工具的版本要跟StarRocks版本匹配好，否则可能出现连接异常或协议不兼容，这个我们后面专门排查过。

5. 从踩坑到收益：迁移过程中的典型问题与优化建议

5.1 跨引擎查询的missing相关错误排查

迁移期间最让人头疼的一类报错，是跨引擎查询时出现类似“missing xxx”的错误提示。不是Doris本身报错，而是我们通过Presto连接Doris的Catalog做联邦查询时，偶尔会抛出找不到列、找不到函数的异常。

这类问题的排查链路值得记录一下。

现象：Presto查询Doris外表时，偶尔报“Column 'goods_category' cannot be resolved”或“Function 'date_format' is missing”。

初步定位：先确认Doris源表里的字段和Presto提交的SQL字段是否完全一致。我们遇到的一个真实问题就是源表里字段叫goods_category，但Presto侧缓存了旧的元数据，认为是goods_cat，两者对不上。

进一步排查：Presto和Doris之间走的是Catalog方式映射，涉及元数据同步。如果源表做过字段变更，而Presto的元数据缓存没有刷新，就容易出现missing类错误。解决方法是刷新Presto侧的Catalog缓存，或者在Doris侧通过INVALIDATE METADATA强制刷新。

还有一个很容易被忽略的原因是大小写敏感。Doris默认把表名字段名存储为小写，Presto的SQL如果写了大写字段名，在某些连接器配置下会直接无法解析。我们后来统一约定：跨引擎查询的SQL字段全部小写，并且写完SQL先在Doris客户端原样执行一遍，确认没问题再到Presto里跑。

遇到这类报错时，建议按这个顺序排查：

1. 确认字段名、表名是否完全匹配，排除大小写问题
2. 刷新源端和目标端的元数据缓存
3. 查引擎日志，确认是优化器阶段报错还是执行阶段报错
4. 检查函数兼容性，不要在所有引擎里使用同样的SQL方言

跨引擎联邦查询虽然方便，但每引入一个引擎，就多一层元数据一致性风险。如果你的BI报表对稳定性要求很高，建议尽量把核心数据完整导入OLAP引擎，不要长期依赖跨引擎实时关联。

5.2 返利状态频繁更新导致的查询结果不准

第二个坑是返利状态频繁变化导致的查询结果不准。这个问题一开始出现在我们并行试运行阶段。

现象：运营看到的当日佣金总额，和财务结算系统跑出来的数字差了十几万。排查发现，有一部分订单在当天凌晨生成时状态为待结算，BI表里已经累计过一次佣金；上午用户又申请退款，订单取消，结算状态变为失效，但BI表是Duplicate模型，旧版本的明细行没有删除，新版本的状态更新又插入了一条新行。这样累计计算时，一个订单被算了两次，多出来十几万。

根因就是数据模型没选对、更新逻辑没做完整。我们最初为了追求查询性能，把返利明细表建成了Duplicate模型，依赖Flink任务在状态变更时修改订单状态，但Duplicate模型本身不支持真正的更新，实际是追加写入，所以查询结果必然重复。

解决方式是改成Aggregate模型或者StarRocks主键表，按照订单ID做去重和版本覆盖，并在查询SQL中通过状态字段过滤，只统计有效状态的行。换到主键表后，我们对订单状态字段做了二次校验，导入时只允许同一订单ID的最新版本覆盖旧版本，彻底解决了重复计算问题。

这个坑提醒我们：OLAP引擎的更新能力差距，不是看文档上的介绍，而是要拿自己的业务变更模式去压测。电商领域里“状态频繁流转、历史版本叠加”的场景非常常见，选错模型会让报表数据失真，比慢查询严重得多。

5.3 和ClickHouse对比的一点点补充

网上很多人会把Doris、StarRocks和ClickHouse放在一起选型，这里简单说说我们当时的对比结论，给还在纠结的人一个参考。

ClickHouse在单表大聚合场景确实有非常强的扫描性能，部署运维也简单，如果业务形态是“日志分析、事件分析、单表明细查询”，ClickHouse是非常好的选择。但它有几个点在我们场景里不太合适：

• 多表join能力相对弱，虽然最近版本一直在改进，但BI系统星型模型关联查询很多，这是个硬伤
• Update/Delete能力较弱，返利状态更新这种需求很难优雅实现
• 对事务语义支持也有限，数据一致性和可靠性保障不如Doris/StarRocks

反过来，ClickHouse的数据压缩率、单表扫描速度以及生态熟悉度在很多团队里是优势。所以我的建议是：先看你们业务模型的复杂度。如果业务查询90%以上都是单表聚合、不需要频繁更新，ClickHouse值得优先考虑；如果像我们这样大量多表关联、有状态更新、还要兼容MySQL协议，Doris和StarRocks会更省心。

5.4 选型落地后的优化清单

最后整理一份我们落地后一直在用的优化清单，算是对前面内容的补充收口：

• 建表模型优先按业务更新类型选，不要默认Duplicate；订单明细建议主键表，维表用Duplicate即可
• 分桶数不要照抄模板，按数据量增长预期和BE数量估算，定期检查Tablet大小是否均衡
• 统计信息一定要定期刷新。StarRocks的CBO很依赖统计信息，常量更新频繁的大表如果统计信息过期，执行计划会退化，常见的表现就是join顺序错乱、查询突然变慢
• 慢查询和资源组监控要尽早接入，不要等运营反馈才排查。我们上线后第一个月的慢查询日志帮我们发现了很多低效SQL
• 大查询和小查询做好资源隔离，宁可小查询慢一点，也不要让大查询把集群内存打爆
• 历史数据回填用Broker Load，实时数据用Stream Load，两套导入策略分开，避免互相干扰

把引擎换完之后，我们BI看板绝大部分报表查询都从十秒以上降到了两秒以内，多表join场景也能稳定在五秒内返回。更重要的是，返利财务对账的效率提升了一大截，运营可以随时看实时佣金数据，不再每天等凌晨跑批。

我自己在实际操作中最大的体会是：选型这件事，产品能力文档和社区评价只是参考，真正要把自己业务里最难的那几个查询，拿到测试环境里用真实数据跑一遍，看内存、看延迟、看并发，再做决定。Doris和StarRocks没有绝对的高下，关键看你业务模型里“更新强度”和“查询复杂度”这两块更偏向哪边。如果团队排查能力一般、又特别依赖社区文档和周边工具，Doris的生态会让你少走很多弯路；如果复杂查询和并发性能是硬指标，StarRocks的表现会更值回票价。

最后再分享一个小技巧：无论选哪个引擎，上线前一定要做一次完整链路的数据一致性校验，用一张大表同时从原MySQL和新的OLAP引擎跑同一条聚合SQL做对比，看数字是否完全一致。这一步能帮你提前发现很多模型选择和数据清洗层面的隐患，等运营和财务找上门再排查，就真的晚了。