REAL-TIME BANKING DATA PIPELINE: TỪ GIAO DỊCH ĐẾN INSIGHT KINH DOANH

 

REAL-TIME BANKING DATA PIPELINE: TỪ GIAO DỊCH ĐẾN INSIGHT KINH DOANH

End-to-End Streaming • Data Warehouse • Orchestration • Analytics

Trong hệ thống ngân hàng, một giao dịch mới không chỉ tạo ra một bản ghi trong database. Nó còn có thể làm thay đổi số dư tài khoản, lịch sử giao dịch và các chỉ số phục vụ hoạt động kinh doanh.

Làm thế nào để những thay đổi này được truyền đến Data Warehouse nhanh chóng, mà vẫn đảm bảo dữ liệu nhất quán và có thể truy vết?

Đó là bài toán của Real-Time Banking Data Pipeline — một kiến trúc kết hợp CDC, Kafka, Snowflake, dbt và Apache Airflow để kết nối hệ thống giao dịch với nền tảng phân tích.

1. CDC & Kafka: Thu thập thay đổi thay vì quét lại toàn bộ dữ liệu

Pipeline bắt đầu từ PostgreSQL, mô phỏng hệ thống OLTP với các bảng customers, accounts và transactions.

Thay vì liên tục truy vấn toàn bộ bảng để tìm bản ghi mới, Change Data Capture (CDC) cho phép ghi nhận những thay đổi phát sinh trong database.

Trong kiến trúc này, Debezium đọc transaction log của PostgreSQL để capture các thao tác INSERT, UPDATE và DELETE, sau đó phát các sự kiện thay đổi vào Kafka. Kafka tiếp nhận và lưu giữ các message để những thành phần downstream có thể xử lý độc lập.

Tuy nhiên, CDC không tự đảm bảo dữ liệu downstream luôn đúng. Một sự kiện có thể được gửi lại, đến muộn hoặc được xử lý không đúng thứ tự mong muốn. Vì vậy, Data Engineer cần thiết kế cơ chế deduplication, xác định thứ tự sự kiện và xử lý dữ liệu idempotently để việc chạy lại không tạo ra kết quả sai lệch.

2. S3 & Snowflake: Từ dữ liệu thô đến dữ liệu sẵn sàng phân tích

Sau khi được capture, dữ liệu streaming được ghi vào S3-compatible object storage như một vùng lưu trữ trung gian trước khi nạp vào Snowflake.

Lớp lưu trữ này giúp tách biệt quá trình thu thập dữ liệu khỏi quá trình xử lý trong warehouse, đồng thời tạo điều kiện lưu giữ và nạp lại dữ liệu khi cần. Khi chuyển dữ liệu sang Parquet, cần bảo toàn metadata cần thiết để downstream có thể diễn giải đúng các thay đổi.

Trong Snowflake, dữ liệu được tổ chức theo Medallion Architecture với ba lớp:

Bronze — Raw data: Lưu dữ liệu thô, trong thiết kế này là JSON trong cột VARIANT. Cách tiếp cận này giúp tiếp nhận dữ liệu linh hoạt trước khi áp dụng các quy tắc chuẩn hóa.
Silver — Cleaned data: Chuyển đổi kiểu dữ liệu, chuẩn hóa cấu trúc, xử lý bản ghi trùng và hợp nhất các sự kiện CDC để tạo ra dữ liệu nhất quán.
Gold — Business-ready data: Xây dựng mô hình phân tích, thường sử dụng Fact Table và Dimension Table theo Star Schema, để phục vụ báo cáo và BI.

Medallion Architecture không chỉ là cách chia dữ liệu thành ba lớp. Mỗi lớp đại diện cho một mức độ hoàn thiện khác nhau, giúp kiểm soát chất lượng và truy vết quá trình biến đổi dữ liệu dễ dàng hơn.

3. dbt & SCD Type 2: Vì sao dữ liệu phân tích cần lưu lịch sử?

Một Data Warehouse không chỉ cần biết trạng thái hiện tại của khách hàng, mà đôi khi còn phải trả lời: Thông tin của khách hàng đã thay đổi như thế nào tại thời điểm một giao dịch xảy ra?

Slowly Changing Dimension Type 2 (SCD Type 2) giải quyết vấn đề này bằng cách tạo phiên bản mới khi thuộc tính được theo dõi thay đổi, thay vì ghi đè hoàn toàn phiên bản cũ.

Thông thường, bản ghi cũ được đánh dấu không còn hiệu lực hiện tại, bản ghi mới được thêm vào và các cột thời gian hiệu lực được sử dụng để xác định mỗi phiên bản có hiệu lực trong giai đoạn nào.

Nhờ đó, hệ thống có thể giữ lại lịch sử thay đổi và hỗ trợ phân tích theo thời gian.

Trong dự án, dbt đảm nhiệm việc tổ chức các bước biến đổi SQL, xây dựng staging models, kiểm tra dữ liệu và triển khai logic snapshot phục vụ SCD Type 2.

4. Apache Airflow: Điều phối pipeline, không thay thế streaming

Khi có nhiều bước xử lý phụ thuộc lẫn nhau, việc chạy từng script riêng lẻ sẽ khó đảm bảo tính nhất quán và khả năng vận hành.

Apache Airflow giải quyết bài toán orchestration bằng cách quản lý thứ tự thực thi, dependency, lịch chạy và trạng thái của các tác vụ. Trong dự án, Airflow điều phối các bước nạp dữ liệu từ S3 vào Snowflake, kích hoạt dbt transformations và chạy các tác vụ snapshot theo cấu hình.

Tuy nhiên, cần phân biệt rõ hai khái niệm:

Streaming: Kafka và Debezium ghi nhận, truyền các sự kiện thay đổi liên tục.
Orchestration: Airflow điều phối các workflow và tác vụ xử lý.

Một pipeline có CDC không đồng nghĩa toàn bộ dữ liệu đã xuất hiện trên dashboard ngay lập tức. Nếu bước nạp S3 vào Snowflake hoặc bước cập nhật mô hình Gold chỉ chạy theo lịch, dữ liệu vẫn có thể bị trễ.

5. CI/CD & Power BI: Đưa pipeline vào vận hành

Một pipeline hoạt động trên máy cá nhân chưa chắc đã sẵn sàng cho môi trường production. Code cần được quản lý phiên bản, kiểm tra trước khi triển khai và bảo vệ thông tin xác thực.

Dự án sử dụng Docker để đóng gói các thành phần như PostgreSQL, Kafka, Debezium, Airflow và MinIO; GitHub Actions hỗ trợ tự động hóa các bước CI/CD. Các thông tin nhạy cảm được quản lý thông qua biến môi trường và GitHub Secrets thay vì lưu trực tiếp trong repository.

Ở đầu ra, Power BI kết nối với Snowflake thông qua DirectQuery để truy vấn dữ liệu và xây dựng dashboard theo dõi số lượng khách hàng, số dư tài khoản, xu hướng giao dịch và các mẫu hoạt động bất thường.

Tuy nhiên, DirectQuery không đồng nghĩa với real-time tuyệt đối. Độ mới của dữ liệu còn phụ thuộc vào toàn bộ pipeline, cơ chế làm mới và thời điểm truy vấn. Tương tự, các mẫu giao dịch bất thường là tín hiệu cần điều tra, không tự động chứng minh có gian lận.

Kết luận

Kiến trúc của dự án có thể tóm tắt như sau:

PostgreSQL → Debezium & Kafka → S3 → Snowflake Bronze/Silver/Gold → Power BI

Trong đó, dbt hỗ trợ biến đổi và mô hình hóa dữ liệu, Airflow điều phối workflow, còn Docker và GitHub Actions hỗ trợ triển khai.