拉卡拉统一金融 OLAP：基于 Apache Doris / SelectDB 实现查询提速 15 倍、资源直降 52%

一句话摘要：拉卡拉使用 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 的条件：

0. 金融/支付场景由 ES、HBase、TiDB、Oracle 等多组件拼装，存在"去 O"与统一诉求。
1. 业务需要多表关联、复杂聚合、宽表实时更新与敏捷 Schema 变更。
2. 对高并发低延迟查询（P99 秒级）与内部 ETL 有强需求。

以下情况建议评估其他方案：

0. 仅需纯全文检索且无需复杂关联分析，已有成熟 Elasticsearch 体系。
1. 仅做单行事务、无统一 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 社区 交流更多实践。