从 OpenSearch 到 Apache Doris：领创集团日志系统升级实践，降本 45%
随着业务全球化扩展与数字化运营的深入推进，日志系统的规模和复杂度不断攀升，原有基于 OpenSearch 的日志平台逐渐难以满足成本控制、性能保障和可维护性等多维需求。为应对持续增长的数据压力和更灵活的分析场景，领创集团技术团队启动了日志系统的架构升级实践，并最终选择 Apache Doris 作为新一代日志系统的核心。实现了综合成本下降超 45%、查询性能提升 5 倍、日志写入达到准实时以及灵活的运维策略等一系列显著收益。
一、业务背景
领创集团（Advance Intelligence Group）成立于 2016 年，是 AI 技术驱动的科技独角兽企业，致力于建立以 AI 为核心的金融+数据平台，让每个人都能更轻松、公平地获得优质的金融产品与服务。
集团总部位于新加坡，集团旗下拥有两大业务线，ADVANCE.AI 是全球领先的人工智能与金融科技企业，提供数字身份验证、KYC/KYB、合规、风险管理和信用信息等服务。目前，已与银行、金融服务、金融科技、跨境支付、交易平台、零售和电商等行业客户建立了合作伙伴关系，服务遍布六大洲；Atome Financial 是东南亚领先的数字金融平台，为消费者搭建多产品的数字金融服务，实现普惠金融，目前已服务超过 5300 万消费者，累计 GMV 超过 80 亿美元。
集团发展至今拥有超过 1400 名员工，业务遍及六大洲的 80 个国家，已完成 D 轮融资。
二、早期架构及痛点
随着公司业务规模的迅猛扩张，系统日志的生成量呈指数级增长，原有基于 OpenSearch 的日志分析平台逐渐暴露出一系列结构性瓶颈，难以支撑日益复杂和高频的日志处理需求，具体体现在以下几个方面：
- 成本飙升快：随着日志量持续增长，计算和存储压力显著增加，服务器资源消耗、对象存储开销以及节点本地存储需求叠加，导致整体数据成本居高不下。
- 查询性能慢：在高并发、复杂多维度查询场景下，OpenSearch 的响应速度明显下降，严重影响业务的实时性与运营效率。
- 运维复杂度高：每次系统扩容不仅带来更多的资源消耗，还进一步加剧了运维的复杂性，提升了维护成本和风险。
在此背景下，我们启动了日志系统重构项目，目标是在降低总体拥有成本的同时，保证日志系统的高可用性、实时性和查询性能。
三、选型与对比
在技术选型阶段，我们评估了多种日志系统解决方案，包括 ClickHouse、Doris、StarRocks 等。经过技术评估与实际测试，最终选择 Doris 作为新一代日志分析平台的核心组件，主要基于 Doris 的高效的列式压缩、准实时写入、灵活的扩缩容机制、强大的查询能力、兼容性好、运维成本低等关键优势。
以下是我们在 OpenSearch 与 Doris 之间进行全面技术对比的核心结论：
四、迁移实施步骤
日志系统的迁移不仅涉及数据和服务迁移，还需要对查询方式和运维流程进行调整。
我们整体分为以下步骤：
- 数据模型设计与映射 ：将原有 JSON 日志结构化，设计对应 Doris 表结构，并结合日志种类进行规范化建模（例如：msg、logger、level 等）。
- 日志采集通道改造 ：原使用 Kafka → Logstash → OpenSearch 采集链路，我们替换为 Kafka → Logstash → Doris Stream Load，实现高吞吐、低延迟的数据写入。
- 查询语句替换 ：将原 Kibana 上的 DSL 查询语句转换为 SQL 语句，并结合 Doris 的分区裁剪、列裁剪、谓词下推等机制优化执行计划。
- 系统压测与灰度切换 ：在测试环境对比查询性能与写入压力，验证稳定性后，分阶段迁移各日志模块，最终实现全量替换。
五、成本优化效果
迁移前后在节点规模、对象存储和查询性能方面均实现显著优化：
此外，Doris 支持灵活的弹性扩缩容，并具备高效的数据压缩机制。即便未来日志数据量持续增长，也能显著降低存储与运维成本。
六、日志系统迁移挑战与经验分享
01 查询语义转换
OpenSearch 支持 DSL 语法和全文搜索，Doris 目前只支持 SQL 语法。
解决方案：与业务团队协作，将现有的 DSL 查询统一修改为 SQL 查询。
02 Doris 查询 UI 缺少日志分析视图
相较于 OpenSearch + Dashboards 的成熟可视化，Doris 原生缺少日志分析视图。
解决方案：内部开发了日志查询页面替代 Kibana 查询页面。
社区目前对 Kibana 的支持：
考虑到用户对 Kibana 的强依赖，社区经评估后推出了 es2doris 工具。该工具实现了从 Elasticsearch 的 DSL 到 Doris SQL 的自动转换，使得原本调用 Elasticsearch 接口的应用程序（如 Kibana）无需任何改动，即可通过 es2doris 间接访问 Doris。用户可直接将现有的 Kibana 连接至 es2doris 服务，无缝延续使用体验。
03 扩容期间负载倾斜
Doris 扩容时会涉及 Tablet Schedule 和 Balance，若节点过少或数据不均可能短时导致查询卡顿。
解决方案：在进行扩容时候，需要结合当前的机器负载情况，提前进行资源预估，如果机器负载比较高，在进行 Tablet 迁移的时候可能会占用部分资源，导致节点资源紧张，出现读写性能变面的情况，需要结合调度限流策略和后台迁移节奏控制，避免高峰期触发重负载影响生产业务。
七、总结与展望
本次日志系统迁移从 OpenSearch 到 Apache Doris，不仅达成了显著的成本节省目标，更为未来系统扩展、查询效率、可运维性打下了坚实基础。
核心收益包括：
- 大幅减少服务器和对象存储支出，综合成本下降超 45%；
- 查询响应时间缩短至原系统的 1/5 以下；
- 日志写入几乎实时，支持更及时的业务反馈；
- 系统架构更简单、可维护性更强，支持更灵活的运维策略。
通过这次实践，我们验证了在日志系统中"结构化 + 列式存储 + MPP 查询"模式的巨大潜力。在追求性能和成本平衡的场景下，Doris 提供了一条可行且高效的替代路径，为企业日志平台建设提供了新的思路与方向。
