从核心银行系统到 Lakehouse：基于 ODS 与 Medallion 架构的现代银行数据架构

在 2026 年 11 月 3 日 Data Architecture Community 群组的分享中，作者 Data Engineer Kỹ sư dữ liệu（@cole.dataengineer）用五张架构图展示了银行数据架构的演进路线：从核心银行系统与交易渠道总览，经过 OLTP–OLAP 数据处理模型和传统数据仓库架构，到结合 ODS 与 Lakehouse 的现代架构——Lakehouse 以 Medallion 架构（Bronze–Silver–Gold）组织数据，底层采用 Apache Spark、Iceberg、Trino、Airflow、Kafka 和 MinIO/S3。本文按架构层次对全部内容做了系统梳理。

快速回答

• 所有银行交易——手机银行、ATM/POS、柜台——都经支付中枢和卡交换系统汇入核心银行系统，形成规模大、持续不断且类型多样的数据流。这是后端所有分析系统的原始数据来源。
• OLTP 与 OLAP 目标相反但互为补充。OLTP 以短小、精确的交易记录企业的当前状态；OLAP 读取汇总后的历史数据，用于分析和决策。
• 传统架构（ODS → ETL → 数据仓库 → 数据集市 → BI）做批量报表运行良好，但难以满足实时需求。数据要在多层之间复制，主要运行在 Oracle、IBM DB2、SQL Server 和 SAP 平台上。
• 现代架构保留 ODS 负责实时运营，并引入 Lakehouse 负责分析。Lakehouse 在 S3 对象存储上使用开源的 Apache Iceberg 表格式，并用 Medallion 架构把数据分成 Bronze、Silver、Gold 三层。
• 图中 Lakehouse 的六项核心技术是 Apache Spark、Apache Iceberg、Trino、Apache Airflow、Apache Kafka 和 MinIO/S3。每项技术只承担一个角色：计算、表格式、查询、编排、流处理和存储。

什么是 Lakehouse？

Lakehouse 是一种数据平台架构，结合了数据湖的优点（在对象存储上低成本、灵活存储）与数据仓库的治理能力（ACID 事务、Schema 管理、高性能分析查询）。在原帖的架构中，Lakehouse 并不取代现有的一切：它与负责实时运营的 ODS（操作型数据存储）并存，Lakehouse 本身承担大规模存储与分析，服务于报表、风险分析、交易监控和 AI/ML 应用。

什么是 Medallion 架构？

Medallion 架构把 Lakehouse 中的数据按质量递增分为三层。Bronze 层（原始/落地层）原样保存来源数据，不作修改，包括 CDC 和流式数据。Silver 层（清洗与规范化层）保存已清洗、去重并标准化的数据。Gold 层（精选层）是最高层：面向业务的数据模型与汇总数据集市，为 BI 优化且数据质量高。这种分层让每一次转换都可追溯，并让不同用户群体使用与需求匹配的数据层。

银行数据由哪些渠道产生？

根据本文开头的总览图，数据始于三个交易渠道：手机银行/网上银行、ATM/POS（卡交易）和柜台 Teller（现金存取、行内转账）。交易经两层中间层汇集——支付中枢（带欺诈/规则引擎、连接 NAPAS/SWIFT、采用 ISO 20022 标准）和卡交换系统（ISO 8583 标准、连接 Visa/Mastercard/NAPAS）——再进入核心银行系统：管理账户与余额、会计总账与对账，并强制要求实时入账（Realtime Posting）、ACID 事务和数据完整性。核心外围是外部系统（NAPAS、SWIFT、Visa/Mastercard、商户合作方）和支持系统（CRM/全渠道客户视图、KYC/eKYC、AML/CDD、通知、报表/MIS、数据仓库），全部运行在高可用、容灾、加密、访问控制和监控告警的基础设施之上。

基础数据处理模型如何运作？

作者的第二张图描述了所有数据架构的根基层：由客户与各类活动（购物、转账、配送、生产）组成的现实世界，被 Web/手机应用、核心银行系统、订单管理、CRM、库存等业务系统记录进 OLTP 数据库。OLTP 以规范化的关系表（客户、账户、交易、分支机构、员工）保存企业的当前状态，保证 ACID 并支持多用户并发。正如作者在图中标注的：在大数据、AI 或 Lakehouse 出现之前，企业只需要一种方式来记录正在发生的事情——而 OLTP 正是这种方式。

OLTP 与 OLAP 有何区别？

对比项	OLTP（运营）	OLAP（分析）
目标	系统运营：快速、准确地处理交易	决策支持：分析、汇总、报表
数据	当前数据、明细、短小简单的交易	历史数据、已汇总、复杂查询
数据变更	频繁：持续插入/更新/删除	较少：以读取为主，偶尔追加
数据模型	规范化（3NF）	维度模型 / 星型模型
性能优化方向	写入快、并发交易	大数据量读取快

两个系统之间是数据基础层，包含三层存储（原始数据、整合数据、精选数据）以及覆盖质量、安全、合规和血缘的数据治理（Data Governance）。二者关系是明确的单向流动：OLTP 是数据源，数据被采集和存储、被组织和准备，然后由 OLAP 从中挖掘价值。

传统企业数据架构包含哪些层？

第三张图描述了多年来在银行和大型企业中普遍采用的架构：数据源（Oracle 上的核心银行系统、IBM DB2 上的卡系统、SQL Server 上的电子渠道、人事/财务/总账系统及外部数据源）被加载到 ODS/暂存区，经 ETL 层（Oracle Data Integrator、IBM InfoSphere DataStage、Microsoft SSIS、SAP Data Services）抽取、转换并加载到中央数据仓库（EDW）。再从 EDW 按主题分发到数据集市——零售银行、风险、财务、合规——最终到达 BI/报表层（Oracle BI、Power BI、IBM Cognos、Excel），服务管理层、分析师和审计人员。这套架构稳定且经过验证，但整个流程是按固定 ETL 调度的批处理，数据要在多个昂贵的存储层间复制，几乎不具备实时分析能力。

现代 ODS + Lakehouse 架构如何组织？

第四张图是作者提出的目标架构，从左到右包含以下主要模块：

• 数据源：核心银行系统（交易、账户、客户、贷款）、卡系统（授权、交易、清算、拒付）、第三方（征信中心、KYC/AML、支付网关）、手机应用（点击流、事件、行为）以及日志/文件。
• 接入与编排（Ingestion & Orchestration）：Apache Airflow 编排 DAG 并负责监控、重试和告警；批量接入使用 Apache Spark 结合 ELT；流式接入使用 Apache Kafka、GoldenGate 和 Debezium 的 CDC（变更数据捕获）机制。
• 实时 ODS：Oracle Exadata 或 SingleStore，提供高吞吐接入、ACID 事务和低延迟；同时配套 API Hub/服务层，为运营应用、实时仪表盘和运营报表提供标准化 API。
• Lakehouse：本地或 Dell ECS 上的 S3 兼容存储，使用 Apache Iceberg 作为表格式（ACID、Schema 演进、时间旅行、隐藏分区），目录采用 Hive Metastore 或 Gravitino，按 Medallion 架构组织，计算使用 Apache Spark（批）和 Apache Flink（流）。
• 查询与服务层：带 Iceberg 连接器的 Trino 和 Apache Doris（MPP OLAP、物化视图）为从数据分析师、数据科学家到监管机构的各类用户提供仪表盘、报表和即席分析。
• 平台运维：在 Kubernetes 上用 Prometheus、Grafana、Alertmanager、Loki、OpenTelemetry 做监控；Kerberos 与 LDAP/Active Directory 做认证；Apache Ranger 做授权；Apache Atlas 做治理与目录（元数据、血缘、数据分类）。

Lakehouse 的六项核心技术是什么？

技术	角色	原帖列出的核心能力
Apache Spark	计算引擎	大规模批处理与流处理
Apache Iceberg	开源表格式	ACID 事务、时间旅行、Schema 演进、隐藏分区
Trino / Presto	查询引擎	对所有数据源的快速交互式 SQL 查询
Apache Airflow	编排	管道调度与协调、监控、重试、告警
Apache Kafka	流平台	事件、日志、实时接入的消息中间件
MinIO / S3	对象存储	持久化表存储、S3 兼容、低成本

传统架构与 ODS + Lakehouse 架构有何不同？

对比项	传统架构（EDW）	现代架构（ODS + Lakehouse）
存储	封闭的关系型系统（Oracle、DB2），单位容量成本高	S3 兼容对象存储，开源的 Iceberg 表格式
数据接入	按固定调度的批量 ETL	批量 + 实时流/CDC（Kafka、Debezium）
数据延迟	小时级到天级	ODS 与 Lakehouse 均为秒级到分钟级
数据组织	从 EDW 直接建主题数据集市	Medallion：Bronze 原始、Silver 清洗、Gold 服务
查询服务	以 BI/报表为主	BI、即席分析、交易监控、AI/ML
扩展方式	专用硬件升级	存储与计算分离，各自独立扩展

Lakehouse 能为银行带来什么价值？

作者认为，核心价值是用一个统一的数据平台取代多个互不连通的数据孤岛：同一条交易数据流既通过 ODS 服务实时运营，又在 Lakehouse 中被标准化，用于管理报表、风险分析、交易监控和异常检测，并逐步支撑 AI/ML 应用。换言之，Lakehouse 不只是存储方案——它是帮助银行从"基于数据运营"迈向"用数据创造业务价值"的平台。

常见问题

Lakehouse 与传统数据仓库有何区别？

传统数据仓库把数据存放在封闭的关系型系统中，加载前必须定义 Schema 并完成转换（ETL），存储成本高。Lakehouse 把数据存放在廉价的对象存储上，使用 Apache Iceberg 等开源表格式，同时具备仓库式的 ACID 与 Schema 管理能力，可同时接入批处理和流式数据，并同时服务 BI 与 AI/ML。

为什么现代架构保留 ODS 而不是只用 Lakehouse？

ODS 服务的是对延迟要求极低、且需要在最新数据上做 ACID 事务的运营需求：运营应用、实时仪表盘和告警。Lakehouse 则为大规模存储和分析优化。两者并存让每类负载使用合适的工具，而不是强迫一个系统做所有事。

Bronze 层的数据发现错误后可以修改吗？

不可以。按原帖的 Medallion 模型，Bronze 是不可变的原始层，原样保存来源数据，包括 CDC 和流式数据。清洗、去重和标准化在 Silver 层完成，面向业务的成果放在 Gold 层——因此每一次转换都可追溯、可重演。

Apache Iceberg 相比普通文件格式好在哪里？

Iceberg 是表格式而不只是文件格式：它在对象存储上提供 ACID 事务、Schema 演进（无需重写数据）、时间旅行（查询数据的历史版本），以及隐藏分区，让用户在查询时不必手动管理分区目录。

银行迁往 Lakehouse 必须放弃现有的 Oracle/DB2 系统吗？

不需要。原帖的架构是本地部署并按集成思路设计的：Oracle 上的核心银行系统、IBM DB2 上的卡系统等源系统照常运行，数据通过批处理和 CDC 搬运过来。即使在现代架构中，ODS 也可以继续跑在 Oracle Exadata 上。这是分步演进，而不是整体替换。

原始出处

本文根据作者 Data Engineer Kỹ sư dữ liệu（@cole.dataengineer）2026 年 11 月 3 日在 Facebook 的 Data Architecture Community 群组发布的帖子整理并重新梳理：Facebook 原帖。原帖相册中的全部 5 张架构图均收录于本文；架构内容与技术选型为原作者的专业观点。