背景
数环通iPaaS平台每天处理千万级流程执行，每个流程会产生两类日志：流程运行日志（记录整体执行状态、耗时、成败）和步骤日志（记录每个节点的输入输出数据）。随着业务增长，日志数据量达到了每天数亿条的规模。
最初我们用Elasticsearch做日志的存储和检索。ES在早期确实好用------全文检索能力强，写入性能也还行，配合Kibana做运维分析很顺手。但随着数据量上来，问题逐渐暴露了。
Elasticsearch遇到的瓶颈
ES跑了两年多，几个问题越来越明显：
存储成本偏高。 ES的存储膨胀是公认的问题。原始数据10GB，ES存下来可能需要30-40GB。倒排索引、Doc Values、_source三份数据叠加，再算上副本，整体存储成本是原始数据的3-5倍。日志这种写多读少的场景，花这么大成本维持全文索引，性价比确实不高。
写入稳定性不够。 日志写入量跟流程执行量直接挂钩。流量高峰时------比如整点有大量定时任务同时触发，或者某个大客户做批量数据同步------瞬间涌入的日志量是平时的几十倍。这种情况下ES的写入延迟会飙高，主要原因是后台的Segment Merge跟前台写入争抢I/O资源。调过translog的flush策略和merge并发度，有缓解但没法根治。
查询模式跟ES的优势不匹配。 我们的日志查询90%以上是结构化条件查询：按组织ID、按流程ID、按时间范围筛选，然后做聚合统计（成功率、平均耗时、调用趋势）。真正用到全文检索的场景很少。相当于买了一把瑞士军刀只用来切菜，大材小用。
运维复杂度高。 ES集群的日常维护说实话挺重的。分片规划、节点扩缩容、索引生命周期管理、冷热数据分层......每一项都要投人力。对于我们这种规模的团队，花太多精力在存储层运维上不太划算。
为什么考虑过ClickHouse
ES的问题明确之后，团队开始调研替代方案。ClickHouse是第一个进入视野的选择，原因很直接------它在OLAP查询场景下的性能口碑非常好，列式存储对日志聚合分析天然友好。
我们做了一轮ClickHouse的POC测试，确实快。同样的聚合查询，ClickHouse比ES快5-10倍不是问题。列式压缩对日志场景也很合适，存储空间大概只有ES的1/5到1/3。
但最终没选ClickHouse，主要有几个顾虑：
Update支持弱。 ClickHouse的设计哲学是"写入即不变"，不擅长做数据更新。但我们的流程日志有一个特殊需求：流程开始执行时写入一条"运行中"的记录，执行结束后要更新这条记录的状态、耗时、错误信息。这意味着每条日志至少要被更新一次。ClickHouse虽然有ReplacingMergeTree可以做类似Upsert的操作，但它的合并时机不可控，查询时可能读到过期数据，业务上需要额外处理去重逻辑。
并发查询能力有限。 ClickHouse的单条查询性能极强，但并发能力相对一般。它更适合少量复杂查询的场景（比如BI报表），不太适合大量用户同时在前端看自己流程日志的场景。我们的用户后台是多租户的，高峰时可能有几百个用户同时在查日志，这对并发有要求。
生态和周边工具。 ClickHouse的运维工具链相比ES和MySQL系生态还是薄一些。集群管理、监控告警、备份恢复这些事情，需要团队自己搭建或者用第三方工具拼凑。
私有化部署门槛。 数环通需要支持私有化交付，客户环境千差万别。ClickHouse的部署和调优对运维人员的要求偏高，不太适合"交付给客户自己运维"的场景。
为什么最终选了Doris
Apache Doris进入评估视野之后，我们发现它几乎刚好解决了上面列出的所有问题：
原生支持Update。 Doris有Unique Key模型，天然支持按主键Upsert。流程开始时插入一条记录，结束时再用相同主键写入更新后的数据，Doris在compaction时自动合并。查询时始终能读到最新状态，不需要业务层做额外去重。
并发查询能力好。 Doris的MPP架构在处理大量并发短查询时表现不错。几百个用户同时按各自组织ID查日志，Doris处理起来比ClickHouse轻松。它的设计本来就兼顾了OLAP和高并发点查的场景。
MySQL协议兼容。 Doris对外暴露的是MySQL协议，现有的JDBC驱动、连接池、ORM框架都能直接对接，改造成本很低。我们的middleware-log模块原来用MyBatis写的Mapper，切换到Doris只需要改一下SQL方言的细节（主要是分页语法），大部分代码不用动。
运维简单。 相比ES集群和ClickHouse集群，Doris的运维复杂度明显低一档。FE+BE的架构清晰，扩缩容方便，对运维人员的技能要求不算高。这对私有化交付场景很重要。
StreamLoad批量写入性能好。 Doris提供了StreamLoad接口，支持HTTP协议直接推送大批量数据。我们实测单次StreamLoad写入几万条日志，耗时在秒级以内。配合批量攒攒再写的策略，写入吞吐完全够用。
压缩比优秀。 列式存储加上ZSTD压缩，日志数据在Doris里的实际存储空间大约是原始JSON数据的1/5到1/8。存储成本相比ES下降了80%以上。
实际迁移方案
迁移过程中我们做了一些具体的工程设计：
写入链路
引擎执行流程时，通过RocketMQ异步发送日志消息到middleware服务。middleware的日志模块消费消息后，走如下路径：
- 日志进入内存BatchQueue，攒够一批（或到达时间窗口）后批量写入Doris
- 如果BatchQueue负载超过80%（高并发场景），自动降级为文件写入模式------先落盘为CSV/JSON文件
- 后台定时任务（每5分钟）扫描本地文件，通过Doris StreamLoad批量同步到集群
- 同步成功后清理本地文件
这套"队列优先 + 文件兜底"的策略，保证了即使Doris临时不可用或写入阻塞，日志也不会丢失。
集群高可用
StreamLoad客户端内置了负载均衡器，支持多FE节点轮询。某个节点响应异常时自动标记为不健康并跳过，等恢复后自动回到轮询池。生产环境配3个FE节点，任何一个挂掉不影响写入。
存储策略
通过Nacos动态配置log.storage.type参数，支持在doris、mysql、ads三种存储后端之间切换。私有化客户如果数据量不大，可以直接用MySQL存日志，不强制依赖Doris集群。SaaS环境统一用Doris。
查询兼容
由于Doris兼容MySQL协议，查询层几乎不需要改动。只是Doris不支持MySQL的某些语法（比如部分子查询写法），以及Update语句需要适配Unique Key模型的行为。我们在Mapper层做了olapSelectByParam和selectByParam两套查询实现，通过配置决定走哪条路径。
迁移前后对比
说几个实际的数字：
- 存储空间：同样30天的日志数据，ES占用约1.2TB，Doris占用约180GB
- 写入延迟：高峰期P99写入延迟从ES的800ms降到了Doris的150ms以内
- 聚合查询：按组织维度统计7天流程成功率，ES约3-5秒，Doris约200-500ms
- 运维人力：ES集群日常运维需要约0.5人力，Doris降到了大约0.1人力
一些踩坑记录
迁移过程也不是一帆风顺的，记几个实际遇到的坑：
StreamLoad的数据格式问题。 最初我们用CSV格式做StreamLoad，遇到了字段内含有逗号和换行符的情况（步骤日志里的JSON数据）。换成JSON行格式（read_json_by_line=true）之后问题解决，但要注意每行必须是合法的JSON对象。
ID生成。 Doris不支持自增ID（Unique Key模型要求写入时就确定主键）。我们用了内部的Sequence服务统一生成分布式ID，写入前就给每条记录分配好。
大字段处理。 步骤日志里的输入输出数据可能很大（几十KB甚至更大），直接存Doris的VARCHAR列会有长度限制。我们做了截断处理，超长数据只存摘要，完整数据落到对象存储。
批量写入失败的重试。 StreamLoad是原子操作------一批数据要么全部成功，要么全部失败。如果某一批里有一条数据格式有问题，整批都会被拒绝。我们配置了max_filter_ratio=0.3容忍30%的脏数据，同时在日志里记录被过滤的行数，方便事后排查。
总结
从ES迁移到Doris这个决策，核心逻辑是：让存储引擎的能力跟实际查询模式匹配。
ES的核心优势在全文检索，但日志场景的查询绝大多数是结构化的。Doris的列式存储+MPP架构+MySQL协议兼容，正好对应了我们"大批量写入、结构化查询、多租户并发"的需求组合。ClickHouse在性能上也能满足，但Update支持和并发能力上跟我们的场景有差距。
选型没有标准答案，关键是想清楚自己的数据特征和查询模式。如果你的日志场景也是"写多读少、结构化查询为主、有数据更新需求"，Doris值得认真评估一下。
关键词：日志存储选型、Elasticsearch迁移、Apache Doris、ClickHouse对比、StreamLoad、OLAP日志分析、iPaaS运行日志