Iceberg 8 — Lakehouse ngân hàng: migrate & vận hành

Đóng series: từ format bảng đến nền tảng dữ liệu

Bảy bài trước đi từ tổng quan Iceberg, kiến trúc, ACID/time travel, evolution, catalog/engine, bảo trì tới streaming & CDC. Bài này ghép tất cả lại thành một quyết định kỹ thuật lẫn kinh doanh: khi nào một ngân hàng như NCB nên xây kho phân tích trên nền lakehouse Iceberg, migrate ra sao, và vận hành thế nào để vừa nhanh, rẻ, vừa tuân thủ NHNN. Đây là bài "thực chiến" — ít lý thuyết, nhiều lộ trình và cạm bẫy thật.

Khi nào ngân hàng nên chuyển sang lakehouse Iceberg

Không phải mọi ngân hàng, mọi bài toán đều cần lakehouse. Iceberg tỏa sáng khi hội đủ vài điều kiện:

• Dữ liệu lớn và đa nguồn: core banking, thẻ, CRM, kênh số, log giao dịch — hàng TB đến PB, nhiều schema, tốc độ tăng nhanh. Warehouse truyền thống bắt đầu đắt và cứng khi dữ liệu vượt vài chục TB.
• Cần đa engine (multi-engine) trên một bản dữ liệu: analyst chạy SQL BI, data scientist train ML, engineer làm ETL — tất cả trên cùng một bảng, không copy. Iceberg là "một sự thật chung" cho Trino, Spark, Flink, dbt.
• Giảm chi phí warehouse: tách storage (object storage rẻ) khỏi compute (bật/tắt theo nhu cầu). Không còn trả tiền cho cụm warehouse chạy 24/7 chỉ để lưu dữ liệu lạnh.
• Mở khóa ML/advanced analytics: dữ liệu thô + lịch sử đầy đủ (time travel) là nguyên liệu cho scoring rủi ro, phát hiện gian lận, churn, đề xuất sản phẩm — những thứ warehouse SQL thuần khó phục vụ.
• Tránh vendor lock-in: open table format + open catalog cho phép đổi engine, đổi cloud mà không migrate lại dữ liệu.

Khi nào warehouse truyền thống vẫn hợp lý (đừng chuyển vì trend):

Nguyên tắc: chọn lakehouse khi quy mô + đa dạng engine + chi phí cùng đẩy lên, không chọn vì công nghệ mới.

Migration: hai con đường

Con đường 1 — Từ Hive/Parquet (in-place, không copy)

Nếu NCB đã có data lake Hive/Parquet trên HDFS hoặc object storage, không cần copy lại petabyte dữ liệu. Iceberg cung cấp hai thủ tục Spark in-place:

• migrate: biến trực tiếp một bảng Hive hiện có thành bảng Iceberg. Iceberg quét các file Parquet sẵn có, sinh metadata (manifest, snapshot) trỏ tới chính những file đó tại chỗ, rồi thay định danh bảng trong catalog. Dữ liệu không di chuyển; chỉ metadata được tạo mới.
• add_files (hoặc snapshot để thử nghiệm không phá bảng gốc): thêm các file Parquet/ORC có sẵn vào một bảng Iceberg đã tạo, hữu ích khi muốn nạp dần nhiều partition.

Ví dụ minh họa (Spark SQL, cú pháp Iceberg — KHÔNG chạy trong sandbox):

-- MINH HOẠ: chuyển bảng Hive sang Iceberg tại chỗ, không copy dữ liệu
CALL catalog.system.migrate('legacy.transactions');

-- MINH HOẠ: nạp thêm file Parquet sẵn có vào bảng Iceberg
CALL catalog.system.add_files(
  table => 'lakehouse.bronze.card_txn',
  source_table => 'legacy.card_txn_parquet'
);

Ưu điểm: rẻ, nhanh, ít rủi ro — dữ liệu vật lý giữ nguyên. Lưu ý: sau migrate, bảng Hive gốc không nên ghi tiếp bằng đường cũ; và nên chạy snapshot (tạo bảng Iceberg tạm trỏ tới cùng file) để kiểm thử trước khi migrate thật.

Con đường 2 — Từ warehouse quan hệ (Oracle / SQL Server / Teradata)

Dữ liệu đang nằm trong warehouse/RDBMS thương mại thì không có file Parquet để trỏ tới — phải trích xuất dữ liệu ra. Hai chiến lược, thường kết hợp:

• Batch backfill (nạp lịch sử): dump toàn bộ bảng lịch sử (theo từng khoảng ngày) qua Spark/JDBC hoặc export file, ghi thành bảng Iceberg bronze. Chạy một lần cho phần "quá khứ".
• CDC streaming (bắt thay đổi): dùng Debezium/Kafka đọc redo/binlog của Oracle/SQL Server, đẩy thay đổi liên tục vào Iceberg qua Flink/Spark (chi tiết ở Iceberg streaming & CDC). Phần "hiện tại và tương lai" luôn cập nhật.

Schema mapping là điểm dễ đau: kiểu dữ liệu warehouse phải ánh xạ đúng sang kiểu Iceberg.

Chiến lược song song (dual-run) & đối soát

Không "big-bang" cắt warehouse trong một đêm. Chạy song song: warehouse cũ và lakehouse Iceberg cùng nhận dữ liệu, cùng phục vụ báo cáo trong một giai đoạn. Mỗi kỳ, đối soát (reconciliation) giữa hai bên: so số dòng, tổng số dư, tổng doanh số theo ngày/chi nhánh. Chỉ khi sai lệch ổn định về 0 (hoặc trong ngưỡng chấp nhận) mới chuyển tải chính thức và ngưng đường cũ. Time travel của Iceberg giúp đối soát tại đúng một snapshot thay vì "bắn vào mục tiêu di động".

Kiến trúc tham chiếu NCB

Sơ đồ trên là bản đồ; dưới đây là từng tầng.

1. Nguồn: core banking (tài khoản, giao dịch, sổ cái), hệ thống thẻ (authorization, settlement), CRM và kênh số (mobile/internet banking, log hành vi). Đặc điểm: đa dạng schema, nhiều tốc độ (batch cuối ngày vs event thời gian thực).

2. Ingest: hai kênh song hành. Batch cho backfill lịch sử và nguồn ít đổi (danh mục sản phẩm, chi nhánh). CDC streaming cho bảng nóng (giao dịch, số dư) qua Debezium → Kafka → Flink/Spark, ghi vào Iceberg near-real-time. Xem ice-07 cho pattern MERGE/upsert.

3. Iceberg trên object storage: một storage layer duy nhất (S3/GCS/MinIO on-prem). Tách compute khỏi storage — chi phí lưu trữ giảm mạnh so với warehouse.

4. Medallion — bronze/silver/gold: mô hình phân tầng chất lượng.

5. Engines theo vai trò: Trino cho analyst/BI (SQL tương tác, độ trễ thấp trên gold); Spark cho ML và ETL nặng trên silver; dbt điều phối transform bronze→silver→gold bằng SQL có kiểm thử. Cùng một bảng Iceberg, nhiều engine đọc — không nhân bản dữ liệu.

Governance & tuân thủ ngân hàng

Ngân hàng không chỉ cần dữ liệu nhanh, cần kiểm soát được để qua kiểm toán nội bộ và thanh tra NHNN.

• Phân quyền qua catalog: catalog (REST/Glue/Polaris) là điểm áp policy tập trung — cấp quyền theo schema/bảng/cột, tách quyền theo vai trò (analyst chỉ đọc gold, kỹ sư ghi silver). Không rải quyền lẻ tẻ ở từng engine. Xem thêm access & crypto.
• Cột nhạy cảm/PII: gắn tag cho cột chứa CMND/CCCD, số thẻ, số điện thoại; áp masking/column-level security tại engine; cân nhắc mã hóa hoặc tách bảng nhạy cảm. Chi tiết ở quyền riêng tư & tuân thủ.
• Chất lượng dữ liệu: kiểm thử tại ranh giới silver/gold (not-null, uniqueness, referential, ngưỡng nghiệp vụ) — dbt tests hoặc Great Expectations. Xem data quality. Dữ liệu sai đắt hơn dữ liệu chậm.
• Audit qua snapshot/time travel: mỗi commit là một snapshot bất biến ghi lại "bảng trông thế nào tại thời điểm X". Đây là món quà cho tuân thủ: tái tạo đúng số liệu đã báo cáo cho NHNN kỳ trước, chứng minh dữ liệu không bị sửa lén, điều tra khi số liệu lệch. Kết hợp branch/tag để "đóng băng" bản báo cáo cuối kỳ.
• Lineage: truy vết dữ liệu đi từ nguồn nào qua transform nào tới báo cáo — bắt buộc khi thanh tra hỏi "con số này từ đâu ra". dbt sinh lineage graph tự động; kết hợp data governance tổng quan.

Vận hành lakehouse

Lakehouse "chạy được" chưa đủ; phải vận hành để nhanh và rẻ lâu dài (chi tiết kỹ thuật ở bảo trì Iceberg).

• Bảo trì định kỳ: rewrite_data_files (compaction gộp small files từ CDC streaming), expire_snapshots (dọn snapshot cũ giải phóng dung lượng — nhưng giữ đủ lâu cho yêu cầu audit, ví dụ ≥ số ngày quy định lưu vết), remove_orphan_files. Lên lịch qua Airflow.
• Giám sát chi phí: theo dõi storage (dung lượng theo tầng, tỉ lệ dữ liệu lạnh nên chuyển sang storage class rẻ hơn) và compute (giờ chạy Spark/Trino). Đặt cảnh báo khi số file/partition phình bất thường.
• DR & backup metadata: metadata Iceberg (metadata.json, manifest) là "bản đồ" của toàn bộ dữ liệu — mất nó, dữ liệu vẫn còn nhưng khó đọc. Bật versioning + cross-region replication cho cả data lẫn metadata; sao lưu catalog (thường là DB) theo lịch. Test khôi phục định kỳ.
• Versioning & rollback: sự cố ghi hỏng? Rollback bảng về snapshot tốt trước đó — cơ chế an toàn mà warehouse truyền thống không có sẵn.

Lộ trình áp dụng theo giai đoạn

Chuyển đổi ngân hàng là marathon, không sprint. Đề xuất bốn giai đoạn:

1. Pilot (2–3 tháng): chọn một domain rủi ro thấp, giá trị rõ (ví dụ báo cáo giao dịch thẻ). Migrate in-place phần Parquet sẵn có hoặc backfill một bảng, dựng bronze/silver/gold nhỏ, một dashboard Trino. Mục tiêu: đội ngũ học công cụ, chứng minh giá trị.
2. Mở rộng nguồn (3–6 tháng): thêm CDC cho bảng nóng, thêm 3–5 domain, thiết lập catalog + phân quyền + data quality làm chuẩn chung.
3. Song song & đối soát: chạy dual-run với warehouse cũ trên các báo cáo trọng yếu tới khi đối soát ổn định.
4. Chuyển tải chính & tối ưu: ngưng đường cũ theo từng domain, chuẩn hóa bảo trì tự động, tối ưu chi phí.

Rủi ro & cách giảm:

Use case thực tế

Bối cảnh (số liệu ước lượng, minh họa cho NCB): Kho phân tích cũ trên một warehouse thương mại, ~18 nguồn (core, thẻ, CRM, kênh số, sổ cái...), tổng ~40 TB dữ liệu nóng và ~300 TB lịch sử lạnh. Cụm warehouse chạy 24/7 tốn kém; các query báo cáo cuối tháng chạy 8–15 phút; đội ML phải export dữ liệu ra ngoài để train (trùng lặp, trễ).

Lộ trình đã đề xuất:

• Pilot với domain giao dịch thẻ: 6 TB Parquet sẵn có trên object storage được migrate in-place sang Iceberg trong ~2 ngày (chỉ sinh metadata, không copy) thay vì hàng tuần nếu phải reload. Dựng silver/gold + 4 dashboard Trino.
• Mở rộng: bật CDC (Debezium→Kafka→Flink) cho bảng giao dịch core và số dư; backfill batch cho 12 nguồn còn lại theo từng khoảng ngày. Toàn bộ đưa về medallion, transform bằng dbt với ~60 test chất lượng.
• Dual-run 3 tháng: đối soát tổng số dư và doanh số theo chi nhánh mỗi ngày tại một snapshot cố định; sai lệch hội tụ về 0 sau 6 tuần tinh chỉnh schema mapping (chủ yếu ở cột NUMBER→decimal).

Kết quả ước lượng sau chuyển đổi:

Các con số trên là ước lượng minh họa để định cỡ kỳ vọng, không phải số đo thực tế đã kiểm chứng.

Một truy vấn tổng hợp kiểu "mart nghiệp vụ" trên dữ liệu tương tự (ở đây minh họa trên schema PostgreSQL của sandbox, không phải bảng gold thật):

-- ▶ Chạy được
SELECT c.city,
       COUNT(DISTINCT a.id)                AS so_tai_khoan,
       ROUND(SUM(t.amount)::numeric, 2)    AS tong_giao_dich
FROM customers c
JOIN accounts a     ON a.customer_id = c.id
JOIN transactions t ON t.account_id = a.id
GROUP BY c.city
ORDER BY tong_giao_dich DESC;

Ghi nhớ

• Chọn lakehouse Iceberg khi dữ liệu lớn/đa nguồn + cần đa engine + muốn giảm chi phí warehouse + mở khóa ML. Dữ liệu nhỏ, đội ngũ mỏng, hay bài toán OLTP thì warehouse/PostgreSQL truyền thống vẫn hợp lý hơn.
• Migrate hai đường: từ Hive/Parquet dùng migrate/add_files in-place, không copy (nhanh, rẻ); từ warehouse (Oracle/SQL Server/Teradata) dùng batch backfill + CDC streaming, chú ý schema mapping (NUMBER→decimal giữ chính xác tiền).
• Đừng big-bang: chạy dual-run song song với hệ cũ và đối soát tại một snapshot trước khi cắt.
• Kiến trúc NCB: nguồn (core/thẻ/CRM) → ingest (batch + CDC) → Iceberg trên object storage → medallion bronze/silver/gold → engines theo vai trò (Trino/BI, Spark/ML, dbt/transform) trên cùng một bản dữ liệu.
• Governance là bắt buộc ngân hàng: phân quyền qua catalog, tag & bảo vệ PII, data quality tại ranh giới tầng, audit qua snapshot/time travel, lineage để trả lời "số này từ đâu" cho NHNN.
• Vận hành: compaction + expire_snapshots (giữ đủ lâu cho audit), giám sát chi phí storage/compute, backup metadata & DR, rollback bằng snapshot.
• Lộ trình: pilot domain nhỏ → mở rộng nguồn → dual-run/đối soát → chuyển tải chính. Giảm rủi ro bằng compaction sớm, bảo vệ PII từ đầu, đào tạo kỹ năng.

Nguồn tham khảo

• Apache Iceberg Documentation — Table Migration (chiến lược in-place vs. shadow migration từ Hive/Parquet)
• Apache Iceberg Documentation — Spark Procedures (các procedure migrate, snapshot, add_files, expire_snapshots, rewrite_data_files, remove_orphan_files)
• Apache Iceberg Documentation — Branching and Tagging (đóng băng snapshot cuối kỳ phục vụ audit)
• Apache Iceberg Documentation — Maintenance (compaction, dọn snapshot/orphan files)
• Debezium Documentation (CDC từ Oracle/SQL Server qua redo/binlog → Kafka)
• dbt Documentation (transform bronze→silver→gold, tests, lineage)