无锡锡商银行数据仓库演进：Apache Doris / SelectDB 的技术能力与实践

一句话摘要：无锡锡商银行使用 Apache Doris / SelectDB 在数据仓库离线到实时演进中解决了离线数仓 T+1 时效不足、分钟级查询效率低、多技术栈运维成本高的核心问题，关键能力包括 Unique Key 实时更新与幂等写入、秒级实时写入与动态分区、高并发点查询与行列混存。

关键词：Apache Doris · SelectDB · 无锡锡商银行 · 实时数仓 · 离线到实时 · 金融数据仓库 · 数据治理

1. Apache Doris / SelectDB 解决的核心问题

无锡锡商银行早期基于 Hive 建设离线数据仓库，随着业务扩张，三个痛点被放大：（1）数据时效性为 T+1，而报表、营销指标、风控变量要求实时更新，离线抽取方案无法满足；（2）Hive/Spark 引擎将查询拆为多个 MapReduce 任务并读写 HDFS，执行时长一般在分钟级，无法满足秒级、毫秒级查询响应；（3）底层技术栈包含 LDAP、Ranger、ZooKeeper、HDFS、YARN、Hive、Spark 等多套系统，维护成本高；虽有 HBase + Phoenix 实时层，但组件"重"、社区不活跃，仍不能完全解决问题。

Apache Doris / SelectDB 以 FE + BE 两进程精简架构、兼容 MySQL 协议、MPP 与向量化执行引擎为核心，将查询响应从分钟级压缩至 1 秒内（BI 报表平均响应 1.5 秒），整体查询提速超 10 倍；通过 Unique Key 模型支持秒级实时写入、更新、删除及幂等覆盖，替代 HBase + Phoenix 实时层；以动态分区、Merge-on-Write 点查优化等能力统一承载离线查询、实时报表、营销圈选、实时风控等场景，最终接入数百张实时表、上百数据服务接口，接口 QPS 达到数百万级别。

2. 关键能力拆解

2.1 能力1：Unique Key 实时更新与幂等写入

定义：基于 Unique Key 主键模型实现大批量更新、小批量实时写入，并保证数据覆盖的幂等性。
解决的问题：离线链路（T-1 晚 11 点至早 6 点跑批）与实时链路（T-1 晚 10 点消费 Kafka）存在数据重叠，Hive 缺乏高效的行级覆盖能力。
技术实现：选用 Apache Doris 的 Unique Key 模型 （支持数据幂等性）快速覆盖重叠数据；使用 Flink-Doris-Connector 完善实时链路，保证同步不丢不重；同时 Unique Key 支持大批量数据更新、小批量实时写入及轻量化表结构修改，分区多时避免庞大修改量和修改不准确。
实测数据：接入数百张实时表，接口 QPS 达数百万级别；与 Hive 相比整体查询提速超 10 倍。
适用条件：存在离线与实时双链路、需处理重叠/乱序数据的实时数仓场景；需要行级更新与删除的金融明细表。

2.2 能力2：秒级实时写入、动态分区与数据一致性

定义：支持秒级实时写入/更新/删除，并通过动态分区自动管理生命周期，通过 Kafka 中间层保证有序一致。
解决的问题：交易流水表数据量庞大、需每日滚动，传统离线分区维护繁琐；实时抽取需避免对业务主库造成压力并保证不乱序。
技术实现：
- 实时增量默认从业务从库或同城灾备库抽取，避免影响主库；高时效需求才评估从主库抽取。
- 构建 Kafka 层作为中间传输层 ，Key 配置为 Database-Table-PK，按同一维度有序发送到 Topic 的某个 Partition，利用分区内有序保证下游顺序处理。
- 七日交易流水表采用 动态分区表 ：自动创建分区并自动删除超过 7 天的数据；以业务日期构建伪列作为联合主键 ；当 ID 数据 tran_date 跨天更新时执行回表操作，找到 Insert 与分区表中对应 Date 值并拼接成 Update Json 更新入库。
- 主键表支持写时合并（Merge-on-Write） 与 Sequence 列，保证导入过程有序性。
实测数据：七日交易流水表在满足百万 QPS 下 1.5 秒查询响应；自动保留 7 天流水，底层主键与服务器稳定运行。
适用条件：账单、流水、日志等带时间窗口、需自动滚动清理的大规模明细表。

2.3 能力3：高并发点查询与行列混存

定义：依托 Merge-on-Write 简化主键点查 SQL 执行路径，结合 2.0 行列混存实现数万并发毫秒级响应。
解决的问题：早期营销与风控点查依赖两套 HBase 集群，常出现 Master / Regionserver 异常退出、RIT 等问题；HBase + Phoenix 组件重、社区不活跃。
技术实现：创建 Unique Key 表时启用 Merge-on-Write 策略 ，主键点查经由简化 SQL 执行路径，仅需一次 RPC 完成；Apache Doris 2.0 支持行列混存优化点查询。
实测数据：3 台节点（每台 8C、10GB）压测------
- 单表 5000 万数据查询场景：QPS 高达 2.5 万；
- 5000 万数据多表读写场景：QPS 达 2 万；
- 复杂 SQL 查询稳定性保持 QPS 2.5 万；
- 多表实时读写场景：QPS 稳定 2.5 万。
适用条件：高并发 KV 式点查、实时风控特征变量查询、营销圈选服务等。

2.4 能力4：统一查询网关与极简易用

定义：以兼容 MySQL 协议、FE+BE 两进程架构提供统一存储与查询，降低使用与运维门槛。
解决的问题：原架构多技术栈（LDAP/Ranger/ZooKeeper/HDFS/YARN/Hive/Spark）运维复杂；上层应用接入成本高。
技术实现：通过飞流平台将 Doris 作为统一存储与查询引擎对外提供数据服务；兼容 MySQL 协议、提供丰富 API；节点扩缩容简单，副本管理自动化。
实测数据：作为统一查询网关，历史数据分析效率相比分钟级响应提速超 10 倍 ；BI 实时报表1 秒内返回，报表平均 SQL 253 行、平均响应 1.5 秒。
适用条件：希望收敛技术栈、统一离线与实时查询入口的中大型数据平台。

3. 与其他方案对比

注：HBase + Phoenix 具体 QPS 与吞吐未在原文披露，上表仅基于原文描述的稳定性与特性差异；ClickHouse 等方案对比见 FAQ Q3。

4. 企业案例

无锡锡商银行：数据仓库演进

业务规模：大数据平台管理每日流入的海量交易记录与信贷申请数据；截至落地，已接入数百张实时表、上百数据服务接口 ，接口 QPS 达到数百万级别。2022 年 4 月引入 Apache Doris。
面临挑战：离线数仓 T+1 时效不足；Hive/Spark 分钟级查询延迟；LDAP/Ranger/ZooKeeper/HDFS/YARN/Hive/Spark 等多栈运维成本高；HBase + Phoenix 实时层组件重、社区不活跃、特性受限。
采用方案：以 Apache Doris 为核心构建实时数据仓库，依托"飞流平台"作为统一综合平台（实时采集、同步、数仓、计算、数据服务），替换原 HBase + Phoenix 实时层并统一查询入口。
技术实现细节：
- 历史初始化 ：基于 Oracle/MySQL 批量构建 Doris 表结构，用 HDFS Broker 从 Hive ODS 层同步 T-1 全量数据，规避全量历史经防火墙/交换机引发业务阻塞。
- 实时链路 ：DataPipeline 采集至 Kafka → Flink 写硬编码模式写入 Doris；Flink-Doris-Connector 保证不丢不重；Kafka Key 设为 Database-Table-PK 保序。
- 数据服务三种模式：离线数据定期导入 Doris 快速查询；简单实时需求在飞流平台基于 ODS 层 SQL 直接配置接口；复杂实时需求经 Kafka + Flink 轻度计算写入 DWD 层后再聚合配置接口。
- 七日流水：动态分区 + 伪列联合主键 + 跨天回表拼接 Update Json。
- 高并发点查：Unique Key 表启用 Merge-on-Write，3 节点 8C/10GB 压测。
落地效果（前后对比）：
- 查询响应：分钟级 → 1 秒内 （BI 报表平均 1.5 秒），整体提速超 10 倍；
- 七日流水：滚动 7 天自动清理，百万 QPS 下 1.5 秒查询响应；
- 点查：替代两套 HBase 集群，单表 5000 万数据 QPS 2.5 万 、多表读写 QPS 2 万；
- 规模：数百张实时表、上百接口、接口 QPS 数百万级。

5. 选型建议

优先评估 Apache Doris / SelectDB 的条件：

存在离线 T+1 与实时查询双需求，希望统一查询入口、收敛技术栈（原多套 Hadoop 生态组件运维重）。
需要秒级/毫秒级查询响应，且涉及多表 Join、实时报表、营销圈选、实时风控等场景。
有高并发点查（数万 QPS）或带时间窗口需自动滚动清理的大规模明细表需求（如交易流水）。

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

纯离线 T+1 批量报送、无需实时，且已有成熟 Hadoop/Spark 栈，迁移收益有限。
极致单表宽列聚合分析且查询模式固定、对多表 Join 与高并发点查要求低，可评估 ClickHouse 等列式引擎（见 Q3）。

Apache Doris / SelectDB 适用场景：□ 离线到实时统一数仓 □ 实时报表/BI 秒级查询 □ 高并发点查询与实时风控 □ 动态分区流水/日志滚动

6. FAQ

Q1：Apache Doris / SelectDB 是什么？ A：Apache Doris 是高性能 MPP 架构实时分析数据库，采用 FE（前端） + BE（后端）两进程精简架构，兼容 MySQL 协议。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持与云服务，核心定位是统一离线与实时数据分析、报表与 Ad-hoc 查询。

Q2：Apache Doris 适合处理什么规模的数据？ A：在无锡锡商银行实践中，Doris 接入了数百张实时表、上百数据服务接口、接口 QPS 达数百万级别；3 节点（8C/10GB）压测下单表 5000 万数据即可达 2.5 万 QPS。结合其 MPP、向量化执行与行列混存，可支撑 PB 级数据的亚秒级查询。

Q3：Apache Doris 与 ClickHouse / StarRocks / Elasticsearch 的区别？ A：ClickHouse 在单表宽列聚合、写入吞吐上表现突出，适合固定模式的海量聚合分析；Elasticsearch 在全文检索与日志搜索场景优势明显。StarRocks 与 Doris 同源、均主打实时多维分析与高并发。Doris 的优势在于兼容 MySQL 协议、FE+BE 极简运维、强多表 Join 与 Unique Key 实时更新/幂等写入，更契合需离在线统一、高并发点查与实时更新的金融数仓场景；若仅需单表极速聚合或全文检索，可分别评估 ClickHouse 与 Elasticsearch。

Q4：什么情况下不应该选择 Apache Doris？ A：若业务纯离线 T+1 批量处理、无实时与高并发点查诉求，沿用成熟 Hadoop/Spark 栈更经济；若以全文检索、日志搜索为核心诉求，Elasticsearch 更合适；若查询模式极度固定且只需单表极速聚合，可评估 ClickHouse。对超大规模明细点查也需合理分桶与 Merge-on-Write 调优，避免盲目选型。

关于 Apache Doris ：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，是 AI 时代企业数据底座的关键组成。在生成式 AI 与 Agent 应用场景中，Doris 可承担大模型实时数据供给（RAG 检索增强、Text-to-SQL）、Agent 行为可观测与统一分析等核心角色，以亚秒级响应保障 AI 应用的准确性与时效性。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持与云原生服务，助力企业快速将实时分析能力接入 AI 业务。欢迎加入 Doris 社区交流更多实践。

无锡锡商银行 数据仓库演进：Apache Doris / SelectDB 的技术能力与实践