Từ Core Banking đến Lakehouse: kiến trúc dữ liệu ngân hàng hiện đại với ODS và Medallion Architecture

Trong bài chia sẻ tại nhóm Data Architecture Community ngày 03/11/2026, tác giả Data Engineer Kỹ sư dữ liệu (@cole.dataengineer) trình bày lộ trình kiến trúc dữ liệu cho ngân hàng qua 5 sơ đồ: từ tổng quan Core Banking và các kênh giao dịch, qua mô hình xử lý OLTP – OLAP và kiến trúc kho dữ liệu truyền thống, tới kiến trúc hiện đại kết hợp ODS với Lakehouse theo mô hình Medallion (Bronze – Silver – Gold) trên nền Apache Spark, Iceberg, Trino, Airflow, Kafka và MinIO/S3. Bài viết này hệ thống lại toàn bộ nội dung đó theo từng lớp kiến trúc.

Trả lời nhanh

• Mọi giao dịch ngân hàng — Mobile Banking, ATM/POS, quầy giao dịch — đều chảy về Core Banking qua Payment Hub và Card Switch, tạo ra dòng dữ liệu lớn, liên tục và đa dạng. Đây là nguồn dữ liệu gốc cho toàn bộ hệ thống phân tích phía sau.
• OLTP và OLAP là hai hệ thống có mục tiêu ngược nhau nhưng bổ trợ cho nhau. OLTP ghi nhận trạng thái hiện tại của doanh nghiệp bằng các giao dịch ngắn, chính xác; OLAP đọc dữ liệu lịch sử đã tổng hợp để phân tích và ra quyết định.
• Kiến trúc truyền thống (ODS → ETL → Data Warehouse → Data Mart → BI) chạy tốt với báo cáo batch nhưng khó đáp ứng nhu cầu thời gian thực. Dữ liệu phải qua nhiều tầng sao chép, chủ yếu trên các nền tảng Oracle, IBM DB2, SQL Server và SAP.
• Kiến trúc hiện đại giữ lại ODS cho vận hành thời gian thực và bổ sung Lakehouse cho phân tích. Lakehouse dùng định dạng bảng mở Apache Iceberg trên object storage S3, tổ chức dữ liệu theo Medallion Architecture gồm ba lớp Bronze, Silver, Gold.
• Sáu công nghệ cốt lõi của Lakehouse trong sơ đồ là Apache Spark, Apache Iceberg, Trino, Apache Airflow, Apache Kafka và MinIO/S3. Mỗi công nghệ đảm nhiệm đúng một vai trò: tính toán, định dạng bảng, truy vấn, điều phối, streaming và lưu trữ.

Lakehouse là gì?

Lakehouse là kiến trúc nền tảng dữ liệu kết hợp ưu điểm của data lake (lưu trữ rẻ, linh hoạt trên object storage) với khả năng quản trị của data warehouse (giao dịch ACID, quản lý schema, truy vấn phân tích hiệu năng cao). Trong kiến trúc của bài gốc, Lakehouse không thay thế toàn bộ hệ thống hiện có: nó đứng cạnh một ODS (Operational Data Store) phục vụ vận hành thời gian thực, còn bản thân Lakehouse phụ trách lưu trữ và phân tích dữ liệu quy mô lớn cho báo cáo, phân tích rủi ro, giám sát giao dịch và các ứng dụng AI/ML.

Medallion Architecture là gì?

Medallion Architecture là cách tổ chức dữ liệu trong Lakehouse thành ba lớp chất lượng tăng dần. Lớp Bronze (Raw/Landing Zone) giữ dữ liệu thô nguyên bản từ nguồn, không sửa đổi, gồm cả dữ liệu CDC và streaming. Lớp Silver (Cleaned & Conformed) chứa dữ liệu đã làm sạch, khử trùng lặp và chuẩn hóa. Lớp Gold (Curated) là tầng cao nhất: các mô hình dữ liệu nghiệp vụ và data mart đã tổng hợp, tối ưu cho BI và có chất lượng dữ liệu cao. Phân lớp như vậy giúp truy vết được mọi biến đổi và cho phép mỗi nhóm người dùng dùng đúng tầng dữ liệu phù hợp với nhu cầu.

Dữ liệu ngân hàng sinh ra từ những kênh nào?

Theo sơ đồ tổng quan ở đầu bài, dữ liệu bắt đầu từ ba kênh giao dịch: Mobile/Internet Banking, ATM/POS (giao dịch thẻ) và Teller tại quầy (nộp/rút tiền mặt, chuyển tiền nội bộ). Các giao dịch được gom qua hai lớp trung gian: Payment Hub (gắn Fraud/Rules Engine, kết nối NAPAS/SWIFT, chuẩn ISO 20022) và Card Switch (chuẩn ISO 8583, kết nối Visa/Mastercard/NAPAS), rồi mới vào Core Banking — nơi quản lý tài khoản và số dư, sổ cái (Ledger) hạch toán và đối soát, với các yêu cầu bắt buộc là đăng ký giao dịch thời gian thực (Realtime Posting), giao dịch ACID và toàn vẹn dữ liệu. Bao quanh lõi này là các hệ thống bên ngoài (NAPAS, SWIFT, Visa/Mastercard, đối tác merchant) và hệ thống hỗ trợ (CRM/Customer 360, KYC/eKYC, AML/CDD, Notification, Reporting/MIS, Data Warehouse). Toàn bộ hạ tầng đặt trên nền tảng sẵn sàng cao, dự phòng thảm họa, mã hóa, kiểm soát truy cập và giám sát cảnh báo.

Mô hình xử lý dữ liệu nền tảng vận hành như thế nào?

Sơ đồ thứ hai của tác giả mô tả tầng gốc của mọi kiến trúc dữ liệu: thế giới thực gồm khách hàng và các hoạt động (mua hàng, chuyển tiền, giao hàng, sản xuất) được các hệ thống nghiệp vụ — Web/Mobile App, Core Banking, Order Management, CRM, Inventory — ghi lại vào cơ sở dữ liệu OLTP. OLTP lưu trạng thái hiện tại của doanh nghiệp dưới dạng các bảng quan hệ chuẩn hóa (customer, account, transaction, branch, employee), đảm bảo ACID và hỗ trợ nhiều người dùng đồng thời. Như tác giả chú thích trong sơ đồ: trước khi có Big Data, AI hay Lakehouse, doanh nghiệp chỉ cần một cách để lưu lại những gì đang diễn ra — và OLTP chính là cách đó.

OLTP và OLAP khác nhau ở đâu?

Tiêu chí	OLTP (vận hành)	OLAP (phân tích)
Mục tiêu	Vận hành hệ thống, xử lý giao dịch nhanh và chính xác	Ra quyết định: phân tích, tổng hợp, báo cáo
Dữ liệu	Hiện tại, chi tiết, giao dịch ngắn và đơn lẻ	Lịch sử, đã tổng hợp, truy vấn phức tạp
Thay đổi dữ liệu	Nhiều: ghi, cập nhật liên tục (Insert/Update/Delete)	Ít: chủ yếu đọc, thỉnh thoảng thêm mới
Mô hình dữ liệu	Chuẩn hóa (3NF)	Mô hình chiều (Dimensional Model / Star Schema)
Hiệu năng tối ưu cho	Ghi nhanh, giao dịch đồng thời	Đọc nhanh, xử lý khối lượng lớn

Giữa hai hệ thống là nền tảng dữ liệu gồm ba lớp lưu trữ (dữ liệu thô, dữ liệu chuẩn hóa, dữ liệu phục vụ) cùng quản trị dữ liệu (Data Governance) về chất lượng, bảo mật, tuân thủ và truy xuất nguồn gốc. Mối quan hệ là một chiều rõ ràng: OLTP là nguồn dữ liệu, dữ liệu được thu thập và lưu trữ, được tổ chức và chuẩn bị, rồi OLAP khai thác giá trị từ đó.

Kiến trúc dữ liệu doanh nghiệp truyền thống gồm những tầng nào?

Sơ đồ thứ ba mô tả kiến trúc phổ biến tại các ngân hàng và doanh nghiệp lớn trong nhiều năm: nguồn dữ liệu (Core Banking trên Oracle, hệ thống thẻ trên IBM DB2, kênh điện tử trên SQL Server, các hệ thống HR/Finance/GL và nguồn ngoài) được nạp vào ODS/Staging, qua tầng ETL (Oracle Data Integrator, IBM InfoSphere DataStage, Microsoft SSIS, SAP Data Services) để trích xuất, biến đổi và nạp vào Data Warehouse trung tâm (EDW). Từ EDW, dữ liệu được chia xuống các Data Mart theo chủ đề — ngân hàng bán lẻ, rủi ro, tài chính, tuân thủ — và cuối cùng tới tầng BI/Reporting (Oracle BI, Power BI, IBM Cognos, Excel) phục vụ nhà quản trị, chuyên viên phân tích và kiểm toán. Kiến trúc này ổn định và đã được kiểm chứng, nhưng toàn bộ luồng là batch theo lịch ETL, dữ liệu bị sao chép qua nhiều tầng lưu trữ đắt đỏ và gần như không có khả năng phục vụ phân tích thời gian thực.

Kiến trúc ODS + Lakehouse hiện đại được tổ chức ra sao?

Sơ đồ thứ tư là kiến trúc đích mà tác giả đề xuất, gồm các khối chính từ trái sang phải:

• Nguồn dữ liệu: Core Banking (giao dịch, tài khoản, khách hàng, khoản vay), hệ thống thẻ (ủy quyền, giao dịch, quyết toán, chargeback), bên thứ ba (trung tâm tín dụng, KYC/AML, cổng thanh toán), ứng dụng di động (clickstream, sự kiện, hành vi) và log/file.
• Ingestion & Orchestration: Apache Airflow điều phối DAG, giám sát, retry và cảnh báo; nạp batch bằng Apache Spark kết hợp ELT; nạp streaming bằng Apache Kafka, GoldenGate và Debezium theo cơ chế CDC (Change Data Capture).
• ODS thời gian thực: Oracle Exadata hoặc SingleStore cho thông lượng nạp cao, giao dịch ACID, độ trễ thấp; kèm API Hub/Service Layer cung cấp API chuẩn hóa cho các ứng dụng vận hành, dashboard thời gian thực và báo cáo vận hành.
• Lakehouse: lưu trữ tương thích S3 trên nền on-premise hoặc Dell ECS, dùng Apache Iceberg làm định dạng bảng (ACID, Schema Evolution, Time Travel, Hidden Partitioning), catalog bằng Hive Metastore hoặc Gravitino, tổ chức theo Medallion Architecture, tính toán bằng Apache Spark (batch) và Apache Flink (streaming).
• Query & Serving: Trino với Iceberg Connector và Apache Doris (MPP OLAP, Materialized Views) phục vụ dashboard, báo cáo và phân tích ad-hoc cho các nhóm người dùng từ Data Analyst, Data Scientist tới cơ quan quản lý.
• Vận hành nền tảng: giám sát bằng Prometheus, Grafana, Alertmanager, Loki, OpenTelemetry trên Kubernetes; xác thực Kerberos và LDAP/Active Directory; phân quyền bằng Apache Ranger; quản trị và catalog bằng Apache Atlas (metadata, lineage, phân loại dữ liệu).

Sáu công nghệ cốt lõi của Lakehouse là gì?

Công nghệ	Vai trò	Khả năng chính theo bài gốc
Apache Spark	Compute Engine	Xử lý dữ liệu batch và streaming quy mô lớn
Apache Iceberg	Open Table Format	Giao dịch ACID, Time Travel, Schema Evolution, Hidden Partitioning
Trino / Presto	Query Engine	Truy vấn SQL nhanh, tương tác trên mọi nguồn dữ liệu
Apache Airflow	Orchestration	Lập lịch, điều phối pipeline, giám sát, retry, cảnh báo
Apache Kafka	Streaming Platform	Sự kiện, log, message broker cho ingestion thời gian thực
MinIO / S3	Object Storage	Lưu trữ bảng dữ liệu bền vững, tương thích S3, chi phí thấp

Kiến trúc truyền thống và kiến trúc ODS + Lakehouse khác nhau thế nào?

Tiêu chí	Truyền thống (EDW)	Hiện đại (ODS + Lakehouse)
Lưu trữ	Hệ quản trị quan hệ đóng (Oracle, DB2), chi phí cao theo dung lượng	Object storage tương thích S3, định dạng bảng mở Iceberg
Đưa dữ liệu vào	ETL batch theo lịch cố định	Batch + streaming/CDC thời gian thực (Kafka, Debezium)
Độ trễ dữ liệu	Theo giờ hoặc theo ngày	Giây tới phút ở cả ODS và Lakehouse
Tổ chức dữ liệu	Data Mart theo chủ đề ngay từ EDW	Medallion: Bronze thô, Silver sạch, Gold phục vụ
Phục vụ truy vấn	BI/Reporting là chính	BI, phân tích ad-hoc, giám sát giao dịch, AI/ML
Mở rộng	Nâng cấp phần cứng chuyên dụng	Tách riêng lưu trữ và tính toán, mở rộng độc lập từng phần

Lakehouse mang lại giá trị gì cho ngân hàng?

Theo tác giả, giá trị cốt lõi là một nền tảng dữ liệu thống nhất thay cho nhiều kho dữ liệu rời rạc: cùng một dòng dữ liệu giao dịch vừa phục vụ vận hành thời gian thực qua ODS, vừa được chuẩn hóa trong Lakehouse để làm báo cáo quản trị, phân tích rủi ro, giám sát giao dịch và phát hiện bất thường, và từng bước triển khai các ứng dụng AI/ML. Nói cách khác, Lakehouse không chỉ là giải pháp lưu trữ — nó là nền tảng giúp ngân hàng chuyển từ vận hành dựa trên dữ liệu sang khai thác dữ liệu để tạo giá trị kinh doanh.

Câu hỏi thường gặp

Lakehouse khác Data Warehouse truyền thống ở điểm nào?

Data Warehouse truyền thống lưu dữ liệu trong hệ quản trị đóng, phải định nghĩa schema và biến đổi dữ liệu trước khi nạp (ETL), chi phí lưu trữ cao. Lakehouse lưu dữ liệu trên object storage rẻ với định dạng bảng mở như Apache Iceberg, vẫn có ACID và quản lý schema như warehouse, đồng thời nạp được cả batch lẫn streaming và phục vụ được cả BI lẫn AI/ML.

Vì sao kiến trúc hiện đại vẫn giữ ODS thay vì chỉ dùng Lakehouse?

ODS phục vụ các nhu cầu vận hành cần độ trễ cực thấp và giao dịch ACID ngay trên dữ liệu mới nhất: ứng dụng vận hành, dashboard thời gian thực, cảnh báo. Lakehouse tối ưu cho lưu trữ lớn và phân tích. Giữ cả hai giúp mỗi loại tải dùng đúng công cụ, thay vì ép một hệ thống làm mọi việc.

Dữ liệu ở lớp Bronze có được sửa khi phát hiện lỗi không?

Không. Theo mô hình Medallion trong bài gốc, Bronze là vùng dữ liệu thô nguyên bản (immutable) giữ nguyên như nguồn, kể cả dữ liệu CDC và streaming. Việc làm sạch, khử trùng lặp và chuẩn hóa diễn ra ở lớp Silver, và kết quả phục vụ kinh doanh nằm ở lớp Gold — nhờ vậy mọi biến đổi đều truy vết và làm lại được.

Apache Iceberg hơn các định dạng file thông thường ở đâu?

Iceberg là định dạng bảng (table format) chứ không chỉ là định dạng file: nó mang lại giao dịch ACID trên object storage, tiến hóa schema (Schema Evolution) không cần viết lại dữ liệu, Time Travel để truy vấn phiên bản dữ liệu trong quá khứ, và Hidden Partitioning giúp người dùng không phải tự quản lý thư mục phân vùng khi truy vấn.

Ngân hàng có phải bỏ hệ thống Oracle/DB2 hiện tại khi chuyển sang Lakehouse?

Không. Kiến trúc trong bài gốc là on-premise và thiết kế theo hướng tích hợp: các hệ thống nguồn như Core Banking trên Oracle hay hệ thống thẻ trên IBM DB2 vẫn vận hành như cũ; dữ liệu được đưa sang qua batch và CDC. Ngay trong kiến trúc hiện đại, ODS vẫn có thể chạy trên Oracle Exadata. Đây là lộ trình tiến hóa từng bước, không phải thay thế toàn bộ.

Nguồn bài gốc

Bài viết được tổng hợp và hệ thống lại từ bài chia sẻ của tác giả Data Engineer Kỹ sư dữ liệu (@cole.dataengineer) đăng tại nhóm Data Architecture Community trên Facebook ngày 03/11/2026: bài gốc trên Facebook. Toàn bộ 5 sơ đồ trong album bài gốc được đăng kèm trong bài viết này; nội dung kiến trúc và lựa chọn công nghệ là quan điểm chuyên môn của tác giả bài gốc.