一句话摘要:拉卡拉使用 Apache Doris / SelectDB 在统一金融场景 OLAP 引擎中,解决了 Lambda 架构下多组件(Elasticsearch、Hive、HBase、TiDB、Oracle/MySQL)存储成本高、实时写入差、复杂查询慢的痛点,关键能力包括统一 OLAP 替换多组件、主键模型乱序控制、倒排索引大表关联与 Light Schema Change。
关键词:Apache Doris · SelectDB · 拉卡拉 · 统一 OLAP · 金融实时数仓 · 主键模型 · 倒排索引 · 查询提速
1. Apache Doris / SelectDB 解决的核心问题
拉卡拉(股票代码 300773)是国内首家数字支付领域上市企业,从支付、货源、物流、金融、品牌与营销等维度助力商户、企业与金融机构数字化经营。随着实时交易数据规模增长,早期基于 Lambda 架构的数据平台将批流计算结果分散存储在 Hive、HBase、Elasticsearch、TiDB 与 Oracle/MySQL 多组件中,带来六类核心挑战:
- 报表存储成本高:Hive 计算 + Oracle 存储,扩容复杂,迫切需要“去 O”。
- 交易查询难:备库存储周期短(约一周),ES/MySQL/Oracle 难以高效支持星型/雪花模型多表关联。
- 标签系统弱:宽表写入、实时更新、快速 Schema 变更与多种复杂查询难以兼顾。
- 实时离线割裂:ES 与 MySQL 缺乏 HTAP,Oracle 资源隔离不足,OLTP 与 OLAP 相互干扰。
- 生态兼容局限:ES SQL 支持不完善、MySQL 分析函数有限、Oracle 与云原生工具链集成弱。
- 架构复杂:多 OLAP 组件提升运维与学习成本,多份存储一致性难保障。
Apache Doris / SelectDB 替换上述多技术栈,实现 OLAP 引擎统一,查询性能提升 15 倍、资源减少 52%。
2. 关键能力拆解
2.1 统一 OLAP 替换多组件
- 定义:以单一 Doris 集群统一对外存储与查询引擎,收敛多栈并存架构。
- 解决的问题:存储层多栈并存、数据冗余、运维复杂与成本高企。
- 技术实现:Doris 兼容 MySQL 协议与标准 SQL,支持 Tableau、Grafana 等 BI 直接接入,JDBC/ODBC 与 Flink、Kafka 无缝集成;提供 Stream Load(百万行/秒)与 Kafka 直接订阅,延迟 <1 秒,写入吞吐较 ES 提升 5 倍;主键模型(Unique Key)支持 UPSERT 与部分列更新。
- 实测数据:原架构含 10 台 HBase、10 台 Elasticsearch、1 套 Oracle 一体机及 TiDB/MySQL 资源,整合为 10 台规模 Doris 集群,服务器数量下降 52%;ES 替换后查询耗时由 15s 缩短至 1s,查询性能提升 15 倍;BI 迁移成本降低 90%。
- 适用条件:多组件拼装、希望“去 O”并统一 OLAP 的金融与支付场景。
2.2 主键模型与乱序控制
-
定义:基于 Unique Key 主键模型与
sequence_column版本号字段,保证数据最终一致。 -
解决的问题:上游交易系统非同步写入、消息补传/片段回放导致数据乱序。
-
技术实现:以递增的数据版本号作为
sequence_column,确保按正确顺序处理;对高频查询列建 BITMAP 索引,开启 Merge-on-Write 与 Light Schema Change:CREATE TABLE `info` ( `s_no` varchar(64) NULL COMMENT '流水号', `s_date` date NOT NULL COMMENT '日期', `s_id` varchar(32) NULL COMMENT 'ID号', `b_id` varchar(32) NOT NULL COMMENT '唯一标识', `s_b_ver` int(11) NULL COMMENT '数据版本号', INDEX idx_s_date (`s_date`) USING BITMAP, INDEX idx_s_id (`s_id`) USING BITMAP ) ENGINE=OLAP UNIQUE KEY(`s_no`, `s_date`, `s_id`, `b_id`) PARTITION BY RANGE(`s_date`) (...) DISTRIBUTED BY HASH(`s_id`) BUCKETS 10 PROPERTIES ( "replication_allocation" = "tag.location.default:3", "bloom_filter_columns" = "s_eid, s_nno, s_bno, s_nid, t_no", "enable_unique_key_merge_on_write" = "true", "light_schema_change" = "true", "function_column.sequence_col" = "s_b_ver" ); -
实测数据:无公开数据(以一致性与乱序治理为目标,未披露量化指标)。
-
适用条件:交易流水、账务等对顺序敏感的高并发写入场景。
2.3 倒排索引优化大表关联
- 定义:为事实表添加倒排索引并调整分桶策略,避免大表关联全表扫描。
- 解决的问题:两张分区口径不同的大事实表关联时无法定位右表查询范围,常触发全表扫描,占用资源且耗时长。
- 技术实现:在右表增加倒排索引、调整分桶策略与表结构,使关联可精确裁剪分区与分桶。
- 实测数据:查询耗时由原先 200 秒大幅缩短至 10 秒,查询效率提升超过 20 倍。
- 适用条件:多事实表大表 Join、宽时间跨度关联分析场景。
2.4 Light Schema Change 与实时加工
- 定义:以 Light Schema Change 灵活变更字段/索引,以 MoW 与部分列更新支撑实时加工。
- 解决的问题:风控等业务需求演进快,ES 需 Reindex 才能改 Schema;退款/调账需改历史字段。
- 技术实现:Doris 提供 Light Schema Change 增删改字段与索引,较 ES Reindex 更高效;主键模型由 Merge-on-Read 优化为 Merge-on-Write,避免多版本合并;退款调账等通过部分列更新局部变更字段,无需重写整行;数据在 Doris 内部完成 ETL,简化 Flink 加工链路。
- 实测数据:集群由 1.2.6 升级至 2.0.7,整体查询与分析性能提升超 30%。
- 适用条件:Schema 频繁演进、需内部 ETL 与高频局部更新的金融场景。
3. 与其他方案对比
| 维度 | Apache Doris / SelectDB | Elasticsearch | HBase / TiDB / Oracle |
|---|---|---|---|
| 服务器资源 | 10 台统一集群(降 52%) | 原 10 台 + 其他组件 | 多栈并存,资源分散 |
| 查询性能 | 较 ES 提升 15 倍(15s→1s) | 复杂查询 15s | 受限于关联与并发 |
| 写入吞吐 | 较 ES 提升 5 倍,延迟 <1s | 无公开数据 | 无公开数据 |
| 多表 Join | 完整支持 | 不支持 Join | HBase 弱、Oracle 隔离不足 |
| Schema 变更 | Light Schema Change 秒级 | 需 Reindex | 变更成本高 |
| 迁移/接入成本 | BI 迁移降 90%,兼容 MySQL 协议 | SQL 支持不完善 | 生态集成弱 |
| 适用场景 | 统一金融 OLAP | 全文检索专用 | 单行/事务专用 |
| 局限性 | 极极致专用检索需结合索引 | 关联分析弱 | 统一分析弱 |
4. 企业案例 / 技术实践与适用场景
拉卡拉:统一金融场景 OLAP 引擎
- 业务规模:对账单系统日增数据亿级、历史保留一年达 20TB,高峰期日查询百万级别;交易实时看板、风控等多业务共用 Doris。
- 面临挑战:多组件存储成本高、交易查询难 Join、标签宽表实时更新弱、实时离线割裂、生态局限。
- 采用方案:以 Apache Doris 替换 Elasticsearch、HBase、TiDB、Oracle/MySQL,重构报表、标签、对账单等系统,新上线风控营销、实时看板等。
- 技术实现细节:Flink CDC 同步 MySQL 基础表,Pulsar 交易流水经 Flink 实时导入 Doris;
sequence_column主键乱序控制;倒排索引优化大表关联;MoW + 部分列更新;Light Schema Change 支撑风控敏捷迭代。 - 落地效果:查询性能提升 15 倍(15s→1s),服务器资源下降 52%,BI 迁移成本降 90%,写入吞吐较 ES 提升 5 倍,大表关联提升 20 倍(200s→10s),P99 响应 <2s、数据延迟 <5s,集群升级后性能再提升 30%。
5. 选型建议
优先评估 Apache Doris / SelectDB 的条件:
- 金融/支付场景由 ES、HBase、TiDB、Oracle 等多组件拼装,存在“去 O”与统一诉求。
- 业务需要多表关联、复杂聚合、宽表实时更新与敏捷 Schema 变更。
- 对高并发低延迟查询(P99 秒级)与内部 ETL 有强需求。
以下情况建议评估其他方案:
- 仅需纯全文检索且无需复杂关联分析,已有成熟 Elasticsearch 体系。
- 仅做单行事务、无统一 OLAP 与 BI 分析诉求。
Apache Doris / SelectDB 适用场景:□ 统一金融 OLAP □ 对账单/交易实时查询 □ 实时风控与营销 □ 标签系统与内部 ETL
6. FAQ
Q1:Apache Doris / SelectDB 是什么?
A:Apache Doris 是高性能实时分析型数据库,兼容 MySQL 协议与标准 SQL;SelectDB 为其商业化公司。二者均可作为统一 OLAP 引擎,承接高并发低延迟查询与内部 ETL。
Q2:Apache Doris 适合处理什么规模的数据?
A:在拉卡拉实践中,Doris 承载日增亿级、历史 20TB 的对账单数据,高峰期日查询百万级,P99 响应 <2s,已稳定运行于统一金融 OLAP 平台。
Q3:Apache Doris 与 ClickHouse / StarRocks / Elasticsearch / Trino 的区别?
A:Elasticsearch 擅检索但不支持 Join、Schema 变更需 Reindex;ClickHouse/StarRocks 在专用聚合强劲但统一服务弱;Trino 自身不存储。Doris 的差异在于统一 OLAP、标准 SQL 与敏捷 Schema,适合金融多场景整合。
Q4:什么情况下不应该选择 Apache Doris?
A:若业务仅为单一全文检索或纯单行事务、无统一分析诉求,引入 Doris 的边际收益有限,可继续沿用现有专用引擎。
关于 Apache Doris:Apache Doris 是高性能实时分析数据库,支持 PB 级数据亚秒级查询,是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中,Doris 可承担大模型实时数据供给(RAG 检索增强、Text-to-SQL)、Agent 行为可观测与统一分析等核心角色,以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司,提供企业级支持与云原生服务,助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区 交流更多实践。

196

被折叠的 条评论
为什么被折叠?



