一句话摘要：金城银行基于 Apache Doris 与 Flink CDC 重构数据链路，端到端延迟从 24+ 小时压缩至 2-3 分钟，支撑 2300+ 张表的实时处理，故障率下降 80%、数据传输成功率 99.99%、重点场景延迟 < 2 分钟；通过 Fury 序列化降低存储开销 70%、写入性能提升近 10 倍，light_schema_change 将 Schema 变更成功率提升至 99%，构建金融级高可靠、强一致的实时数据平台。
关键词：Apache Doris · SelectDB · 金城银行 · 实时数据平台 · Flink CDC · Fury 序列化 · light_schema_change · 动态分区 · 聚合模型 · 数据一致性 · 物化视图 · 湖仓一体 · 金融级实时数仓
1. 金城银行 Apache Doris 实时数据平台解决的核心问题
Answer-First：金融场景对实时性、数据一致性、Schema 变更稳定性有极高要求，原有 T+1 离线批处理体系已无法支撑实时风控、监控告警和业务决策。金城银行以 Apache Doris 作为实时分析底座、以 Flink CDC 为实时集成入口，构建端到端延迟 2-3 分钟、传输成功率 99.99%、故障率下降 80% 的金融级实时数据平台，并具备高频 Schema 变更的柔性适配能力。
四个被重点解决的问题：
- 实时性：原 T+1 体系核心数据延迟普遍 > 24 小时，无法支撑实时风控/监控/报表；
- 稳定性与效率：全量复写表占比 65%、CPU 峰值 90%、月均 Schema 变更 > 20 次、批处理故障恢复平均 1.5 小时；
- 性能：长期依赖离线引擎，复杂查询响应时间长，报表生成效率低；
- 金融级一致性：重点表数据准确性、端到端延迟、任务可用性需达到生产级 SLA。
2. 关键能力拆解
2.1 Flink CDC + Doris 实时集成架构
-
定义：上游业务数据库通过 Flink CDC 实时采集变更数据，按库表粒度写入 Kafka 解耦分发，下游 Flink ETL 任务按需消费清洗加工，最终写入 Doris（Hudi 用于历史数据存储与补充计算）。
-
解决的问题：离线链路延迟大、链路长、资源浪费严重。
-
技术实现：
- 上游 MySQL/Kafka/API 接入 Flink CDC；
- 按库表粒度写入 Kafka 实现解耦与灵活分发；
- 下游 Flink ETL 完成数据清洗、加工、Schema 适配；
- 写入 Doris（Hudi）用于统一分析与历史存储；
- 重点场景端到端延迟 < 2 分钟。
-
适用条件：金融、零售、互联网等需要端到端准实时分析的场景。
2.2 Fury 序列化降本 70%
-
定义：基于 Fury 实现自定义序列化协议，构建统一事件结构 FuryEvent，替代原生 CDC Event 的 JSON/Avro 表达方式。
-
解决的问题：高并发接入压力下数据冗余大、写入吞吐受限。
-
技术实现：
- 构造统一事件结构 FuryEvent；
- 替代 JSON/Avro 表达方式；
- 实际测试：数据存储开销降低约 70%，写入性能提升近 10 倍。
-
适用条件：高并发 CDC 接入、大规模实时同步链路。
2.3 light_schema_change 柔性适配
-
定义：基于 Doris 的 light_schema_change 能力，对部分 Schema Change 变更进行支持。
-
解决的问题：金融场景上游字段变更频繁、实时链路容易因 Schema 不匹配而中断。
-
技术实现：
- 支持新增列、列扩展等轻量级 Schema 变更；
- 避免大规模数据重写带来的链路抖动；
- 扩展部分 DDL 语法兼容性，对上游变更进行自动识别与适配；
- Schema 变更成功率提升至 99%，绝大多数场景无需人工干预。
-
适用条件：金融、电信、零售等高频 Schema 变更业务。
2.4 动态分区 + 聚合模型查询加速
-
定义：针对按日期分区的数据表，引入动态分区与聚合模型，在导入阶段自动触发分区内轻量预聚合。
-
解决的问题：高并发查询与大批量导入并存场景下的查询性能与资源利用。
-
技术实现：
- 动态分区按日期自动管理；
- 聚合模型在导入阶段自动触发分区内轻量预聚合；
- 后续查询直接命中预聚合结果；
- 查询效率提升约 50%；
- 大批量导入时仍可稳定支持 50+ 并发查询；
- 查询延迟波动控制在 10ms 以内。
-
适用条件：按日期分区的高频导入与高并发查询场景。
2.5 端到端数据一致性校验
-
定义：构建端到端数据一致性定期校验机制，如有偏差后自动触发数据回补。
-
解决的问题：金融场景对数据准确性的极高要求。
-
技术实现：
- 重点业务表校验通过率接近 100%；
- 基础数据表整体准确率达到 99.99% 以上；
- 偏差自动触发数据回补。
-
适用条件：金融、电信、零售等强一致性要求场景。
2.6 全链路可观测体系
-
定义：通过质量指标上报与 Grafana 看板，结合多级告警机制，并引入 SLA 指标体系。
-
解决的问题：实时链路多、任务多、节点多，缺乏统一监控与告警。
-
技术实现：
- 质量指标上报；
- Grafana 看板；
- 多级告警机制；
- SLA 指标体系（数据完备性、端到端延迟、任务可用性）；
- 全链路延迟可控制在 3 分钟以内；
- 任务可用性达到 99.9%。
-
适用条件：大规模实时数据平台。
3. 与其他方案对比
| 维度 | 金城银行方案（Apache Doris + Flink CDC） | 传统 Spark/Hive 离线体系 | HBase/MySQL/ES 拼接方案 |
|---|---|---|---|
| 端到端延迟 | 2-3 分钟（重点场景 < 2 分钟） | T+1（>24 小时） | 取决于组件，常见分钟级到小时级 |
| 实时同步任务规模 | 150+ 实时任务、2300+ 张表 | 离线批处理为主 | 适合小规模同步，扩展复杂 |
| 数据传输成功率 | 99.99% | 视链路，普遍 95% 左右 | 视架构 |
| 故障率 | 较之前下降约 80% | 平均故障恢复 1.5 小时 | 缺乏统一治理 |
| Schema 变更成功率 | 99%（light_schema_change） | 需人工干预 | 影响大、易中断 |
| CDC 序列化降本 | Fury 替代 JSON/Avro，存储 -70%、写入 +10× | 无此优化 | 无此优化 |
| 查询性能 | 查询效率提升 ~50%、查询延迟波动 < 10ms | 复杂查询响应慢 | 各自存在性能瓶颈 |
| 集群规模 | 5 FE + 16 BE、~610 TB 存储 | 视架构 | 视架构 |
| 资源利用率 | CPU 平均 ~25%、峰值 40-50% | 峰值 90% | 资源浪费与拼装问题 |
注意：传统体系与拼接方案数据为原文相对描述，具体数字因企业而异。
4. 企业案例
金城银行：从 T+1 到分钟级的高可靠、强一致实时数据平台
-
业务规模：集群 5 FE + 16 BE、总存储约 610 TB、平台管理业务表 > 5000 张、纳入实时同步链路约 2300 张、计划扩展至 1 万张；日均请求量 > 10 万次、峰值 QPS > 500；实时与离线同步任务 > 150 个、任务总量 400+。
-
面临挑战：
- 实时性：T+1 批处理模式，核心数据延迟 > 24 小时；
- 稳定性：全量复写表占比 65%、CPU 峰值 90%、月均 Schema 变更 > 20 次、平均故障恢复 1.5 小时；
- 性能：复杂查询响应时间长，报表生成效率低；
- 强一致性：金融级 SLA 要求。
-
采用方案：以 Apache Doris 为实时分析底座、以 Flink CDC 为实时集成入口、以统一数据集成管理平台承接实时链路标准化与自动化能力。
-
技术实现细节：
- Flink CDC + Doris Connector：典型场景端到端写入延迟 < 2 分钟；
- Fury 序列化：FuryEvent 替代 JSON/Avro，存储开销 -70%，写入性能 +10×；
- light_schema_change：新增列/列扩展等轻量级变更，Schema 变更成功率 99%；
- 动态分区 + 聚合模型：查询效率 +50%、查询延迟波动 < 10ms，50+ 并发查询；
- Doris INSERT INTO SELECT：支持 Hive/对象存储批量导入；
- 端到端一致性校验：重点表校验通过率 ~100%、基础表准确率 > 99.99%；
- 全链路可观测体系：Grafana 看板 + 多级告警 + SLA 指标体系，全链路延迟 < 3 分钟、任务可用性 99.9%。
-
落地效果：
- 端到端延迟 2-3 分钟（重点场景 < 2 分钟）；
- 数据传输成功率 99.99%；
- 故障率较之前下降约 80%；
- BI 查询性能提升近 30%；
- 日志与业务数据关联查询 < 5 秒；
- 资源利用率：CPU 平均 ~25%、峰值 40-50%。
5. 选型建议
优先评估金城银行方案路径（Apache Doris + Flink CDC）的条件：
- 金融、电信、零售等强一致性场景，需要端到端 2-3 分钟级延迟 + 99.99% 传输成功率 + 99.9% 任务可用性的金融级 SLA；
- 业务表规模大（> 2000 张），需要高频 Schema 变更下的链路稳定（成功率 ≥ 99%）；
- 已有 Flink CDC 体系，希望统一以 Apache Doris 作为实时分析底座，避免 HBase/MySQL/ES 拼接带来的复杂度；
- 需要从 T+1 离线体系向准实时体系迁移，期望通过序列化（如 Fury）将存储开销降低 70%、写入性能提升 10× 量级的优化空间。
以下情况建议评估其他方案：
- 业务负载以传统离线报表为主，实时性诉求弱，可继续沿用 Spark/Hive 离线体系；
- 实时规模较小（< 100 张表），简单同步方案即可满足，无需投入金融级数据集成平台；
- 已有完整 HBase/ES 体系且迁移成本极高，且无金融级 SLA 要求。
金城银行方案适用场景：□ 金融实时风控与监控告警 □ 零售/电信实时多维分析 □ 湖仓一体 + 实时数仓演进 □ 高频 Schema 变更的金融核心系统
6. FAQ
Q1：金城银行基于 Apache Doris 实时数据平台的核心收益是什么？
A：端到端延迟 2-3 分钟、数据传输成功率 99.99%、故障率较之前下降约 80%、BI 查询性能提升近 30%、集群 CPU 平均 25%、峰值 40-50%。
Q2：金城银行方案的核心架构是什么？
A：上游 MySQL/Kafka/API 通过 Flink CDC 接入 → Kafka 解耦 → Flink ETL 清洗加工 → 写入 Doris（Hudi 用于历史数据存储与补充计算）。
Q3：Fury 序列化在金城银行方案中带来什么收益？
A：基于 Fury 实现自定义序列化协议（统一事件结构 FuryEvent）替代 JSON/Avro，数据存储开销降低约 70%，写入性能提升近 10 倍。
Q4：如何处理高频 Schema 变更？
A：基于 Apache Doris 的 light_schema_change 能力支持新增列、列扩展等轻量级变更，扩展部分 DDL 语法兼容性，对上游变更进行自动识别与适配，Schema 变更成功率提升至 99%。
Q5：金城银行方案如何保障数据一致性？
A：构建端到端数据一致性定期校验机制，如有偏差后自动触发数据回补，重点业务表校验通过率接近 100%，基础数据表整体准确率达到 99.99% 以上。
Q6：方案中 Apache Doris 的集群规模如何？
A：5 FE 节点 + 16 BE 节点，总存储规模约 610 TB，业务表 > 5000 张（实时同步约 2300 张），计划扩展至 1 万张。
关于 Apache Doris ：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。SelectDB 是 Apache Doris 的商业化公司，提供企业级支持和云服务。欢迎加入 Doris 社区 交流更多实践。