Giới thiệu dự án

Trong bối cảnh chuyển đổi số ngành tài chính - ngân hàng, khối lượng giao dịch điện tử và thanh toán không dùng tiền mặt tại Việt Nam ghi nhận sự bùng nổ mạnh mẽ. Theo số liệu thống kê từ Công ty Cổ phần Thanh toán Quốc gia Việt Nam (NAPAS), tổng số lượng giao dịch qua hệ thống xử lý tăng trưởng vượt bậc đạt 94% về số lượng giao dịch, đồng thời tỷ lệ rút tiền mặt tại ATM giảm hơn 5% trong cùng kỳ. Tại Ngân hàng TMCP Quân Đội (MBBank), khối lượng dữ liệu phát sinh từ khách hàng giai đoạn 2017–2021 đã tăng gấp 3 lần so với tổng lượng dữ liệu tích lũy của toàn bộ 22 năm trước đó (1994–2016). Sự gia tăng đột biến này đặt ra bài toán cấp bách về năng lực xử lý, đồng bộ và phân tích dữ liệu quy mô lớn theo thời gian thực.

                    +------------------------------------------+
                    |  CoreBanking Temenos T24 (OLTP Source)   |
                    +------------------------------------------+
                                         |
                       [Realtime Events / Batch Sync]
                                         v
                    +------------------------------------------+
                    |  Integration: Oracle GoldenGate / Kafka  |
                    +------------------------------------------+
                                         |
                                [ELT Engine: ODI 12c]
                                         v
                    +------------------------------------------+
                    |  ODS Layer: Stage -> Detail -> Summary   |
                    +------------------------------------------+
                                         |
               +-------------------------+-------------------------+
               |                                                   |
               v                                                   v
+-----------------------------+                     +-----------------------------+
| Downstream: MB App / CRM    |                     | Oracle Analytics Publisher  |
| (REST API / Microservices)  |                     | (Realtime Ops Reports <=30s)|
+-----------------------------+                     +-----------------------------+

Hệ thống lưu trữ và xử lý giao dịch truyền thống (CoreBanking Temenos T24) hoạt động như một hệ thống xử lý giao dịch trực tuyến (OLTP - Online Transaction Processing), được tối ưu hóa cho ghi chép đơn lẻ nhưng gặp nhiều hạn chế khi phải đồng thời phục vụ các truy vấn phức tạp từ các hệ thống khai thác dữ liệu vệ tinh (Downstream Systems) như MB App, CRM, Smart RM và hệ thống báo cáo quản trị. Hệ thống kho dữ liệu trung gian Operational Reference Store (ORS) triển khai từ năm 2012 bộc lộ các điểm nghẽn nghiêm trọng:

  • Dữ liệu tích hợp theo cơ chế xử lý theo lô (Batch Processing) với độ trễ $T+1$, không đáp ứng được yêu cầu phản hồi tức thời của các dịch vụ số hóa.
  • Tồn tại tình trạng dư thừa, phân mảnh dữ liệu giữa các bảng không có tài liệu từ điển dữ liệu (Data Dictionary) chuẩn hóa.
  • Cấu trúc trường dữ liệu bán cấu trúc (XML/Dynamic fields) trong CoreBanking T24 chưa được bóc tách hiệu quả sang dạng bảng quan hệ (Relational Schema), gây suy giảm hiệu năng truy vấn trên diện rộng.

Để giải quyết triệt để các tồn đọng trên, đồ án tập trung hoàn thành các mục tiêu cụ thể:

  1. Thiết kế và chuẩn hóa kiến trúc dữ liệu đa phân vùng cho hệ thống Cơ sở dữ liệu hoạt động (ODS - Operational Data Store).
  2. Xây dựng quy trình Trích xuất - Chuyển đổi - Nạp (ETL/ELT) tự động hóa bằng công cụ Oracle Data Integrator (ODI 12c) kết hợp giải pháp chụp dữ liệu thay đổi (CDC - Change Data Capture) từ Oracle GoldenGate và nền tảng truyền tải thông điệp Apache Kafka.
  3. Phát triển thuật ngữ xử lý và chuyển đổi định dạng XML phức tạp từ bảng nguồn T24_CUSTOMER sang mô hình dữ liệu quan hệ chuẩn hóa (PARTY_PHONE, PARTY_IDENTIFICATION, CUSTOMER_INFO).
  4. Thiết lập cơ chế kiểm soát chất lượng, xử lý ngoại lệ (Exception Handling) và quản lý phân tầng lưu trữ (Hot, Warm, Cold Storage) tối ưu hóa chi phí phần cứng.
  5. Đảm bảo các chỉ số đo lường hiệu năng cốt lõi: độ trễ tích hợp thời gian thực (Realtime Latency) $\le 5$ giây, tích hợp cận thời gian thực (Near-realtime) $\le 10$ giây, xử lý đóng sổ cuối ngày (COB - Completion of Business Batch) dưới 30 phút, và thời gian sinh báo cáo vận hành $\le 30$ giây.

Phạm vi nghiên cứu tập trung vào phân hệ Dữ liệu Khách hàng (Party Domain) – cấu phần đóng vai trò cốt lõi trong hệ sinh thái MBBank, kết nối trực tiếp với hơn 50 triệu tài khoản và hỗ trợ lưu lượng xử lý đạt mức 1.000 giao dịch/giây (TPS - Transactions Per Second).

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trước khi triển khai hệ thống ODS, kiến trúc tích hợp dữ liệu tại MBBank chủ yếu dựa trên hệ thống trung gian ORS vận hành theo mô hình đồng bộ Batch truyền thống qua Database Links và các thủ tục PL/SQL định kỳ.

Tiêu chí phân tích Hệ thống ORS cũ (Hiện trạng) Hệ thống Kho dữ liệu (DWH) Hệ thống ODS đề xuất
Độ trễ tích hợp $T+1$ (Độ trễ 24 giờ) Theo ngày, tuần, tháng Thời gian thực ($\le 5\text{s}$) & Near-realtime ($\le 10\text{s}$)
Độ chi tiết dữ liệu Tổng hợp mức độ vừa, phân mảnh Dữ liệu tổng hợp lịch sử đa chiều Dữ liệu chi tiết giao dịch cấp nguyên tử
Mục đích sử dụng Báo cáo vận hành cuối ngày Phân tích chiến lược (BI/OLAP) Vận hành tác nghiệp, phục vụ MB App/CRM
Tác động tới Core Rủi ro treo lock bảng khi quét lô Trích xuất theo lịch ngoài giờ Sử dụng CDC/Kafka log, không tác động Core
Cấu trúc lưu trữ Bảng quan hệ không đồng nhất Star Schema / Snowflake Schema 4 phân vùng chuẩn hóa (Stage, Detail, Summary, Inquiry)

Yêu cầu người dùng và nghiệp vụ được phân loại theo mô hình MoSCoW:

  • Must-have (Bắt buộc): Đồng bộ dữ liệu khách hàng từ T24 về ODS với độ trễ $\le 5$ giây; bóc tách tự động các trường XML sang bảng quan hệ; phân vùng dữ liệu Hot/Warm/Cold; cơ chế ghi log và cảnh báo lỗi tự động.
  • Should-have (Nên có): Tự động tái kích hoạt (Auto-retry) các gói xử lý ETL thất bại; tích hợp REST API cho ứng dụng đầu cuối; lưu vết lịch sử thay đổi thông tin định danh khách hàng.
  • Could-have (Có thể có): Giao diện đồ họa giám sát trạng thái luồng dữ liệu (Data Pipeline Monitoring Dashboard) trên nền tảng web.
  • Won't-have (Chưa thực hiện): Tích hợp các thuật toán học máy dự đoán hành vi khách hàng trực tiếp trên tầng ODS (chuyển tiếp sang phạm vi của DWH/Data Lake).

Thách thức kỹ thuật lớn nhất nằm ở cấu trúc dữ liệu của CoreBanking Temenos T24. Hệ thống này đóng gói nhiều thông tin đa trị (Multi-value fields) như danh sách số điện thoại, giấy tờ tùy thân, địa chỉ liên lạc vào trong các chuỗi định dạng XML hoặc chuỗi phân tách ký tự đặc biệt lưu trữ tại một trường đơn lẻ (XML_RECORD). Do đó, quy trình ETL đòi hỏi giải pháp bóc tách (XML Parsing) hiệu năng cao, đảm bảo không gây suy hao bộ nhớ hệ thống khi xử lý đồng thời hàng triệu bản ghi.

Thiết kế hệ thống

Kiến trúc tổng thể hệ thống ODS được thiết kế gồm 4 tầng xử lý dữ liệu vật lý và logic:

graph TD
    subgraph CoreBanking["Nguồn Dữ Liệu"]
        T24["Temenos T24 CoreBanking"]
    end

    subgraph Ingestion["Tầng Thu Thập & Đẩy Sự Kiện"]
        Kafka["Apache Kafka Event Bus"]
        OGG["Oracle GoldenGate 19c"]
    end

    subgraph ODS["Hệ Thống Cơ Sở Dữ Liệu ODS (Oracle 19c Enterprise)"]
        subgraph StageLayer["Vùng STAGE"]
            STG_Audit["STG_AUDIT / STG_JOURNAL"]
            STG_Table["Bảng Phản Chiếu T24 (1:1)"]
        end
        subgraph CoreDataLayer["Vùng INQUIRY"]
            DetailLayer["Vùng DETAIL (Chuẩn hóa 3NF)"]
            SummaryLayer["Vùng SUMMARY (Dữ liệu tổng hợp)"]
        end
    end

    subgraph Processing["Công Cụ Xử Lý & Chuyển Đổi"]
        ODI["Oracle Data Integrator 12c (ELT Engine)"]
    end

    subgraph Downstream["Hệ Thống Thụ Hưởng"]
        MBApp["MB App / Microservices (REST API)"]
        CRM["CRM / Smart RM"]
        BIPublisher["Oracle Analytics Publisher (Reports)"]
        DWH["Data Warehouse"]
    end

    T24 -->|T24 Event Stream| Kafka
    T24 -->|CDC Database Redo Logs| OGG
    Kafka -->|Kafka Listener Service| STG_Audit
    OGG -->|Replicate 1:1| STG_Table
    STG_Audit -->|ODI Interface/Package| STG_Table
    STG_Table -->|ODI Mapping & Parsing Engine| DetailLayer
    DetailLayer -->|Aggregation Engine| SummaryLayer
    DetailLayer -->|REST API / SQL| MBApp
    DetailLayer -->|Direct Data Stream| CRM
    SummaryLayer -->|Operational Query| BIPublisher
    DetailLayer -->|Batch Export| DWH
    ODI -.->|Orchestration & Control| StageLayer
    ODI -.->|Orchestration & Control| CoreDataLayer

Ngăn xếp công nghệ sử dụng

  • Cơ sở dữ liệu nguồn: Temenos T24 CoreBanking Release R18 trên nền tảng Oracle Database.
  • Cơ sở dữ liệu đích: Oracle Database 19c Enterprise Edition, hỗ trợ Partitioning và Advanced Compression.
  • Nền tảng tích hợp dữ liệu (ELT): Oracle Data Integrator (ODI) phiên bản 12c (12.2.1.4.0).
  • Công cụ đồng bộ thời gian thực: Oracle GoldenGate (OGG) 19c & Apache Kafka 2.8.0.
  • Môi trường phát triển thủ tục: PL/SQL Developer v14.0+, Oracle SQL Developer.
  • Hệ thống báo cáo vận hành: Oracle Analytics Publisher (BI Publisher) 12c.

Thiết kế phân vùng dữ liệu và lưu trữ

Hệ thống phân định 4 vùng dữ liệu logic trong CSDL ODS:

  1. Stage (STG): Lưu trữ bảng nguồn theo tỷ lệ $1:1$, đóng vai trò vùng đệm tiếp nhận dữ liệu từ Kafka và OGG.
  2. Detail: Mô hình hóa dữ liệu chi tiết ở dạng quan hệ chuẩn hóa bậc 3 (3NF). Dữ liệu chỉ được nạp từ vùng Stage sau khi hoàn tất bóc tách XML và làm sạch.
  3. Summary: Chứa các chỉ số tính toán, tổng hợp phục vụ truy xuất nhanh (ví dụ: tổng hạn mức khả dụng, tổng số dư theo khách hàng). Dữ liệu được tính toán từ vùng Detail hoặc nhận từ các engine nghiệp vụ, tuyệt đối không lấy trực tiếp từ Stage.
  4. Inquiry: Vùng lõi phục vụ truy vấn của các ứng dụng thụ hưởng, bao gồm cả Detail và Summary.

Chiến lược phân tầng phần cứng lưu trữ (Storage Tiering):

  • Hot Tier: Sử dụng phân vùng đĩa SSD NVMe hiệu năng cao, lưu trữ dữ liệu hiện tại trong chu kỳ 30 ngày gần nhất nhằm đáp ứng tần suất truy cập liên tục.
  • Warm Tier: Sử dụng phân vùng đĩa SAS/SATA (10k RPM), lưu trữ dữ liệu từ 31 ngày đến 12 tháng phục vụ các báo cáo vận hành định kỳ.
  • Cold Tier: Lưu trữ dữ liệu lịch sử trên 1 năm dưới dạng nén sâu (Compress High) trên hệ thống SAN/Tape lưu trữ dài hạn để phục vụ công tác thanh tra, kiểm toán.

Methodology

Quy trình phát triển tích hợp phương pháp tiếp cận Agile Scrum kết hợp quy chuẩn quản lý kiểm soát thay đổi nghiêm ngặt của lĩnh vực ngân hàng:

  • Chu kỳ Sprint: 2 tuần/Sprint, tập trung phát triển cuốn chiếu theo từng nhóm Package nghiệp vụ (Customer Master Data, Identification, Phone/Address References, Branch/Location Catalogs).
  • Tiến độ dự án: Hoàn thành trong 24 tuần làm việc từ khâu khảo sát thực địa, phân tích ánh xạ dữ liệu (Data Mapping Sheet), lập trình Package ODI, đến kiểm thử tích hợp hệ thống (SIT) và kiểm thử chấp nhận người dùng (UAT).
Ma trận đánh giá rủi ro Xác suất Mức độ tác động Giải pháp giảm thiểu
CoreBanking quá tải do truy vấn ETL Thấp Nghiêm trọng Sử dụng cơ chế chụp log OGG/Kafka, không SELECT trực tiếp vào bảng giao dịch T24
Sai lệch cấu trúc XML khi T24 nâng cấp Trung bình Cao Xây dựng Exception Handler động, cô lập bản ghi lỗi vào bảng ERR_LOG và cảnh báo tự động
Tắc nghẽn mạng giữa DC và DR Thấp Cao Thiết lập cơ chế nén gói tin (Network Compression) và cơ chế bộ đệm Kafka Queue
Xung đột khóa chính trong quá trình nạp song song Trung bình Trung bình Sử dụng kỹ thuật phát sinh Surrogate Key bằng Oracle Sequence kết hợp cơ chế Locking mức bản ghi

Implementation và kết quả

Development process

Quá trình triển khai tập trung vào việc hiện thực hóa các Package tích hợp trên ODI 12c, cấu hình luồng dữ liệu song song (Multi-threading Parsing) để xử lý lượng lớn dữ liệu khách hàng từ bảng nguồn T24_T24CORE_CUSTOMER.

                       [T24_CUSTOMER (STG)]
                                 |
                     (Multi-threading Reader)
                                 |
                                 v
                 +-------------------------------+
                 |  XML Parsing Engine (PL/SQL)  |
                 |  extractvalue / XMLTable      |
                 +-------------------------------+
                                 |
        +------------------------+------------------------+
        |                                                 |
        v                                                 v
+-------------------------------+ +-------------------------------+
| DETAIL_PARTY_PHONE            | | DETAIL_PARTY_IDENTIFICATION   |
| (CIF, Phone_No, Phone_Type)   | | (CIF, ID_Number, Issue_Date)  |
+-------------------------------+ +-------------------------------+
        |                                                 |
        +------------------------+------------------------+
                                 |
                                 v
                 +-------------------------------+
                 |  Merge / Upsert into INQUIRY  |
                 +-------------------------------+

Quy trình bóc tách chuỗi XML từ bảng nguồn T24_CUSTOMER sang bảng đích quan hệ PARTY_PHONE được thực thi thông qua thủ tục PL/SQL tối ưu hóa bằng câu lệnh XMLTABLE và xử lý con trỏ theo khối (BULK COLLECT / FORALL):

CREATE OR REPLACE PROCEDURE PRC_ETL_PARSE_CUSTOMER_PHONE (
    p_batch_id       IN  VARCHAR2,
    p_thread_no      IN  NUMBER,
    p_total_threads  IN  NUMBER,
    p_records_parsed OUT NUMBER
) IS
    TYPE t_phone_rec IS RECORD (
        cif_id          VARCHAR2(35),
        phone_type      VARCHAR2(10),
        phone_number    VARCHAR2(50),
        is_primary      VARCHAR2(1),
        created_date    DATE
    );
    TYPE t_phone_list IS TABLE OF t_phone_rec;
    l_phones t_phone_list;
    l_row_count NUMBER := 0;
BEGIN
    -- Trích xuất dữ liệu XML đa trị từ bảng đệm Stage sử dụng XMLTable
    SELECT 
        src.cif_id,
        NVL(x.phone_type, 'MOBILE'),
        x.phone_val,
        CASE WHEN x.seq = 1 THEN 'Y' ELSE 'N' END,
        SYSDATE
    BULK COLLECT INTO l_phones
    FROM STG_T24_CUSTOMER src,
         XMLTABLE(
            '/ROW/PHONE_DETAILS'
            PASSING XMLTYPE(src.xml_record)
            COLUMNS 
                seq        FOR ORDINALITY,
                phone_type VARCHAR2(10) PATH 'TYPE',
                phone_val  VARCHAR2(50) PATH 'NUMBER'
         ) x
    WHERE MOD(ORA_HASH(src.cif_id), p_total_threads) = p_thread_no
      AND src.process_status = 'PENDING';

    -- Nạp dữ liệu vào bảng chi tiết tầng Detail bằng kỹ thuật FORALL MERGE
    FORALL i IN 1..l_phones.COUNT
        MERGE INTO DETAIL_PARTY_PHONE dest
        USING (SELECT l_phones(i).cif_id AS cif, 
                      l_phones(i).phone_number AS phone 
               FROM DUAL) s
        ON (dest.cif_id = s.cif AND dest.phone_number = s.phone)
        WHEN MATCHED THEN
            UPDATE SET dest.phone_type = l_phones(i).phone_type,
                       dest.updated_date = SYSDATE
        WHEN NOT MATCHED THEN
            INSERT (phone_id, cif_id, phone_type, phone_number, is_primary, created_date)
            VALUES (SEQ_PARTY_PHONE.NEXTVAL, l_phones(i).cif_id, 
                    l_phones(i).phone_type, l_phones(i).phone_number, 
                    l_phones(i).is_primary, l_phones(i).created_date);

    p_records_parsed := l_phones.COUNT;
    COMMIT;
EXCEPTION
    WHEN OTHERS THEN
        ROLLBACK;
        INSERT INTO ETL_ERROR_LOG (batch_id, error_code, error_message, error_timestamp)
        VALUES (p_batch_id, SQLCODE, SUBSTR(SQLERRM, 1, 4000), SYSDATE);
        COMMIT;
        RAISE;
END PRC_ETL_PARSE_CUSTOMER_PHONE;
/

Trong Oracle Data Integrator (ODI), cấu trúc triển khai gồm các Package chính:

  • PKG_PARTY_ONLINE: Quản lý luồng tiếp nhận sự kiện thay đổi thông tin khách hàng từ Kafka/OGG, kích hoạt Interface ánh xạ dữ liệu và đẩy vào bảng DETAIL_PARTY.
  • PKG_REFERENCE_CATALOGS: Chuỗi các Package đồng bộ danh mục tham chiếu: PKG_BRANCH_REF, PKG_CURRENCY_REF, PKG_SECTOR_REF, PKG_COUNTRY_REF, PKG_LOCATION_REF.
  • PKG_EXCEPTION_HANDLER: Giám sát thực thi, ghi nhận các bản ghi không đạt chuẩn kiểm tra ràng buộc toàn vẹn, gửi cảnh báo qua hệ thống giám sát ngân hàng.

Testing và validation

Quá trình kiểm thử được tiến hành trên môi trường mô phỏng tải tương đương quy mô sản xuất (Production-like UAT Environment) với các kịch bản kiểm thử áp lực cao:

[Load Generator: 1,500 TPS] ---> [Kafka Queue] ---> [ODI ELT Engine] ---> [ODS Inquiry Layer]
                                                           |
                                                (Performance Verified)
                                                - End-to-end Latency: 3.2s (Pass)
                                                - Error Rate: 0.0001% (Pass)
  1. Kiểm thử hiệu năng thời gian thực (Realtime Load Testing): Đẩy thông điệp liên tục với tải tăng dần từ 500 TPS đến 1.500 TPS vào hàng đợi Kafka. Hệ thống duy trì độ trễ đồng bộ trung bình từ nguồn T24 sang bảng INQUIRY_PARTY ở mức 3,2 giây (đạt yêu cầu $\le 5$ giây).
  2. Kiểm thử bóc tách XML hàng loạt (Batch Parsing Benchmark): Thực hiện phân tích cú pháp cho 5.000.000 bản ghi khách hàng chứa dữ liệu XML đa nhánh.
    • Kết quả: Sử dụng cấu hình 8 luồng song song (p_total_threads = 8), thời gian xử lý toàn bộ hoàn tất trong 14 phút 22 giây, đạt tốc độ trung bình ~5.800 bản ghi/giây.
  3. Kiểm thử tính toàn vẹn dữ liệu (Data Reconciliation Test): So sánh đối soát 100% dữ liệu giữa Core T24 và ODS sau chu kỳ đóng sổ cuối ngày (COB).
    • Tỷ lệ khớp đúng: $99,9999%$. Toàn bộ 12 bản ghi lệch định dạng do ký tự đặc biệt được ghi nhận chính xác tại bảng lỗi ETL_ERROR_LOG và được xử lý tự động sau khi chuẩn hóa.
  4. Kiểm thử trích xuất báo cáo vận hành: Đánh giá 5 mẫu báo cáo vận hành trên Oracle Analytics Publisher kết nối trực tiếp vào phân vùng Inquiry. Thời gian trả kết quả trung bình cho tập dữ liệu 10 triệu bản ghi là 8,4 giây (đáp ứng tiêu chuẩn $\le 30$ giây).

Kết quả đạt được

Mục tiêu thiết kế ban đầu Kết quả triển khai thực tế Trạng thái nghiệm thu
Tích hợp thời gian thực $\le 5\text{s}$ Duy trì ổn định ở mức $3,2\text{s} - 4,1\text{s}$ Đạt
Tích hợp Near-realtime $\le 10\text{s}$ Đạt mức $6,5\text{s}$ Đạt
Thời gian chạy Batch COB $\le 30$ phút Hoàn thành trong $18\text{,5}$ phút Đạt
Độ trễ tạo báo cáo vận hành $\le 30\text{s}$ Trả kết quả trung bình $8\text{,4}$ giây Đạt
Chuẩn hóa bóc tách trường XML $100%$ trường đa trị chuyển đổi thành bảng quan hệ Đạt
Phân vùng lưu trữ Hot/Warm/Cold Triển khai hoàn chỉnh trên Storage Engine Đạt

Đổi mới và đóng góp

Đồ án mang lại các giá trị đổi mới kỹ thuật và đóng góp thực tiễn cho hạ tầng kiến trúc dữ liệu ngân hàng:

[Mô hình Cũ: ETL Truyền thống qua DB Links]
Core T24 ---> [Staging Server (Transform)] ---> [Target ORS]  ==> Nghẽn I/O, Trễ T+1

[Mô hình Mới: Event-Driven ELT với Kafka & ODI]
Core T24 ---> [Kafka Log Stream] ---> [ODS Engine (Set-based Transform)] ==> Trễ <=5s, Không nghẽn Core
  • Chuyển đổi từ mô hình ETL sang ELT tối ưu hóa phần cứng: Thay vì trích xuất dữ liệu ra một máy chủ trung gian để xử lý (Transform) rồi nạp lại vào CSDL đích, giải pháp tận dụng trực tiếp sức mạnh tính toán song song của CSDL Oracle 19c (In-Database Transformation) thông qua ODI 12c, giảm $65%$ lưu lượng mạng và thời gian khóa bảng.
  • Kiến trúc tích hợp hướng sự kiện lai (Hybrid Event-Driven Architecture): Kết hợp linh hoạt giữa cơ chế bắt log giao dịch từ GoldenGate cho các bảng danh mục quan hệ và streaming sự kiện qua Apache Kafka cho các bảng biến động số dư, thông tin khách hàng, giúp hệ thống không bị phụ thuộc vào một kênh truyền duy nhất.
  • Giải pháp bóc tách XML theo luồng băm song song (Parallel Hash Parsing): Kỹ thuật sử dụng hàm băm ORA_HASH chia tải tự động thành $N$ luồng độc lập giúp xử lý dữ liệu bán cấu trúc từ T24 với tốc độ tăng trưởng tuyến tính theo năng lực CPU.
Giải pháp so sánh Hệ thống ORS cũ (MBBank 2012) ETL Batch truyền thống (Informatica/SSIS) Hệ thống ODS mới (Đề tài nghiên cứu)
Cơ chế truyền tải Batch định kỳ qua DB Link File trích xuất / Batch định kỳ Streaming Event (Kafka) & Log CDC (OGG)
Tốc độ xử lý XML Thủ tục tuần tự, chậm Cần plugin mở rộng phức tạp XMLTABLE tối ưu nội tại trên Oracle Engine
Tải trên CoreBanking Cao trong thời gian quét Trung bình Gần như bằng 0 (Đọc redo log)
Tính sẵn sàng dữ liệu $T+1$ $T+1$ hoặc hàng giờ Thời gian thực ($\le 5\text{s}$)
Mở rộng quy mô Khó mở rộng theo chiều ngang Tăng cấu hình máy chủ ETL Mở rộng theo cụm Kafka & DB Partitioning

Ứng dụng thực tế và triển khai

Hệ thống sau khi hoàn thiện được đưa vào vận hành thực tế tại MBBank, giải quyết trực tiếp các bài toán nghiệp vụ trọng yếu:

                                +---------------------------+
                                |  Hệ Thống ODS Hoàn Thiện  |
                                +---------------------------+
                                              |
                     +------------------------+------------------------+
                     |                                                 |
                     v                                                 v
+-----------------------------------------+       +-----------------------------------------+
|     Trường Hợp 1: Ứng Dụng MB App       |       |       Trường Hợp 2: CRM & Smart RM      |
| Khách hàng cập nhật CCCD/SĐT qua eKYC   |       | Cung cấp 360 độ góc nhìn khách hàng     |
| -> Đồng bộ về ODS trong 3,2 giây        |       | -> Cảnh báo tài chính tức thời          |
+-----------------------------------------+       +-----------------------------------------+
  1. Trường hợp 1: Phục vụ tức thời cho ứng dụng MB App: Khi khách hàng cập nhật thông tin định danh (CCCD gắn chip, số điện thoại) qua kênh số eKYC trên MB App, dữ liệu được ghi nhận vào T24 và đồng bộ ngược lại tầng Inquiry của ODS trong 3,2 giây. Các dịch vụ vệ tinh (thanh toán hóa đơn, chuyển khoản liên ngân hàng) ngay lập tức nhận diện được thông tin hợp lệ mà không cần chờ chu kỳ chốt sổ ngày.
  2. Trường hợp 2: Hệ thống quản trị quan hệ khách hàng (CRM & Smart RM): Cung cấp góc nhìn 360 độ về khách hàng cho các chuyên viên quan hệ khách hàng tại chi nhánh. Thông tin dư nợ, tiền gửi, nhóm ngành nghề kinh tế (SECTOR_REF) được cập nhật chuẩn xác theo thời gian thực, hỗ trợ phê duyệt hạn mức tín dụng nhanh chóng.

Yêu cầu triển khai hệ thống (System Requirements)

  • Hạ tầng máy chủ Cơ sở dữ liệu (ODS DB Server):
    • CPU: $2\times \text{Intel Xeon Gold 6248R}$ (48 Cores, 3.0 GHz).
    • RAM: 256 GB ECC DDR4.
    • Ổ cứng: $4\times 1.92\text{TB NVMe SSD}$ (RAID 10) cho vùng Hot Data; SAN Storage 20TB cho vùng Warm/Cold Data.
    • Hệ điều hành: Oracle Linux 7.9 Enterprise.
  • Máy chủ tích hợp dữ liệu (ODI & Kafka Cluster):
    • 3 Nodes Kafka Cluster (Mỗi node 16 vCPU, 64 GB RAM, 500 GB SSD).
    • 1 Node ODI Execution Agent (16 vCPU, 32 GB RAM).

Phân tích hiệu quả đầu tư (Cost-Benefit Analysis & ROI)

  • Tối ưu chi phí: Giảm $70%$ khối lượng tài nguyên CPU cần thiết trên máy chủ CoreBanking T24 nhờ chuyển dịch toàn bộ các truy vấn báo cáo và trích xuất dữ liệu sang tầng ODS.
  • Hiệu quả vận hành: Tiết kiệm hơn 1.200 giờ làm việc/năm của bộ phận kỹ thuật và vận hành cho việc xử lý các sự cố đồng bộ dữ liệu thủ công và trích xuất báo cáo tĩnh.
  • Thời gian hoàn vốn (ROI): Ước tính đạt điểm hòa vốn sau 14 tháng vận hành thông qua việc nâng cao năng suất bán hàng của kênh số và giảm chi phí bản quyền tính toán trên máy chủ Core chính.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Chi phí phần cứng lưu trữ ban đầu: Việc lưu trữ đa tầng và duy trì cả 4 phân vùng (Stage, Detail, Summary, Inquiry) đòi hỏi dung lượng đĩa lớn hơn khoảng $25%$ so với mô hình lưu trữ phẳng không chuẩn hóa.
  • Độ phức tạp trong quản trị metadata: Khi cấu trúc dữ liệu trên CoreBanking T24 có sự bổ sung các trường thông tin động mới, kỹ sư dữ liệu vẫn cần cập nhật lại định nghĩa XSD/XML Schema trong các thủ tục trích xuất PL/SQL.

Hướng phát triển trong tương lai

  • Ứng dụng công nghệ Apache Debezium kết hợp Kafka Connect để thay thế dần các module CDC truyền thống, hỗ trợ kết nối đa nguồn không đồng nhất một cách linh hoạt hơn.
  • Xây dựng kiến trúc dữ liệu dạng Lakehouse (kết hợp Apache Iceberg hoặc Delta Lake) trên tầng lưu trữ Cold Data nhằm cung cấp khả năng truy vấn phân tích dữ liệu phi cấu trúc và bán cấu trúc với chi phí tối ưu.
  • Áp dụng các mô hình học máy trực tuyến (Online Machine Learning) trực tiếp trên luồng Kafka Event Stream từ ODS để phát hiện sớm các giao dịch có dấu hiệu gian lận tài chính (Fraud Detection).

Đối tượng hưởng lợi

+---------------------------------------------------------------------------------------+
|                                    ĐỐI TƯỢNG HƯỞNG LỢI                                 |
+---------------------------+---------------------------+-------------------------------+
| Sinh viên & Người học     | Kỹ sư Dữ liệu (DE)        | Doanh nghiệp & Ngân hàng      |
| - Tài liệu thực chiến     | - Mẫu code XMLTable       | - Giảm 70% tải CoreBanking    |
| - Quy trình ETL ngân hàng | - Kiến trúc Event ELT     | - Tích hợp thời gian thực <=5s|
+---------------------------+---------------------------+-------------------------------+
  • Sinh viên và người học ngành Hệ thống thông tin / Khoa học dữ liệu: Tiếp cận tài liệu tham khảo hoàn chỉnh, giàu tính ứng dụng thực tiễn về mô hình ODS trong ngành tài chính; hiểu rõ phương pháp chuyển đổi dữ liệu bán cấu trúc trong môi trường sản xuất quy mô lớn.
  • Kỹ sư dữ liệu và lập trình viên (Data Engineers / Developers): Sở hữu mẫu thiết kế kiến trúc (Architectural Pattern) tích hợp giữa CDC, Kafka và Oracle Data Integrator; áp dụng trực tiếp các đoạn mã nguồn mẫu bóc tách XML đa luồng với hiệu năng tối ưu.
  • Ngân hàng và các tổ chức tài chính: Mô hình tham chiếu tin cậy giúp nâng cấp hạ tầng tích hợp dữ liệu từ CoreBanking truyền thống sang hệ thống phục vụ ngân hàng số thời gian thực với các chỉ số cam kết SLA đo lường rõ ràng.
  • Nhà nghiên cứu (Researchers): Dữ liệu thực nghiệm cụ thể về hiệu năng, độ trễ và khả năng mở rộng của các giải pháp ELT hiện đại trong việc xử lý khối lượng dữ liệu giao dịch quy mô hàng triệu bản ghi/ngày.

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

1. Yêu cầu kỹ thuật cốt lõi để triển khai hệ thống ODS này là gì?

Hệ thống đòi hỏi hạ tầng máy chủ cơ sở dữ liệu cài đặt Oracle Database 19c Enterprise hỗ trợ Partitioning, máy chủ trung gian chạy ODI 12c Agent, cụm Apache Kafka tối thiểu 3 nodes để đảm bảo khả năng chịu lỗi (Fault Tolerance), cùng đường truyền mạng nội bộ băng thông tối thiểu 10 Gbps giữa các trung tâm dữ liệu.

2. Giới hạn khả năng mở rộng (Scalability Limits) của hệ thống và giải pháp mở rộng là gì?

Ở tầng thu thập dữ liệu, Apache Kafka cho phép mở rộng quy mô theo chiều ngang bằng cách tăng số lượng Partitions và Brokers. Ở tầng lưu trữ ODS, công nghệ Oracle Real Application Clusters (RAC) kết hợp kỹ thuật phân vùng bảng (Table Partitioning theo ngày/mã khách hàng) cho phép hệ thống mở rộng dung lượng xử lý lên tới hàng trăm triệu bản ghi mà không làm suy giảm thời gian đáp ứng truy vấn.

3. Quy trình này tích hợp với các hệ thống hiện hữu (Legacy Systems) như thế nào?

Dữ liệu từ CoreBanking T24 được trích xuất thông qua hai cơ chế không xâm lấn: (1) Đọc trực tiếp Redo Logs của CSDL bằng Oracle GoldenGate và (2) Bắt sự kiện nghiệp vụ đẩy ra Kafka Queue qua Webhooks/JMS Bus. Cả hai phương thức đều không can thiệp hay làm ảnh hưởng đến mã nguồn gốc của hệ thống Core.

4. Nhu cầu bảo trì và vận hành hệ thống định kỳ gồm những gì?

Hệ thống yêu cầu giám sát dung lượng Tablespace hàng ngày, tự động dọn dẹp (Truncate/Purge) các bảng tạm trong vùng Stage sau khi đã chuyển đổi thành công sang vùng Detail, cập nhật số liệu thống kê (Gather Statistics) cho bộ tối ưu hóa truy vấn Oracle CBO (Cost-Based Optimizer) vào cuối mỗi tuần, và kiểm tra tính toàn vẹn của các gói Package ODI.

5. Cơ cấu chi phí và thời gian hoàn vốn đầu tư (ROI) ước tính?

Chi phí chính tập trung vào bản quyền phần mềm (Oracle Database, ODI, GoldenGate) và phần cứng lưu trữ SSD NVMe. Tuy nhiên, nhờ tận dụng nền tảng mã nguồn mở Apache Kafka cho tầng trung gian và tối ưu hóa năng lực máy chủ hiện có, ngân hàng tiết kiệm được chi phí nâng cấp bản quyền CoreBanking T24 (vốn tính theo dung lượng CPU). Thời gian hoàn vốn thực tế đạt mức 14 tháng sau khi chính thức nghiệm thu.

Kết luận

Đồ án tốt nghiệp "Xây dựng quy trình tích hợp dữ liệu ETL từ hệ thống CoreBanking T24 về hệ thống ODS tại Ngân hàng TMCP Quân Đội Việt Nam" đã giải quyết thành công bài toán tích hợp dữ liệu lớn, phân tán và bán cấu trúc trong môi trường vận hành ngân hàng hiện đại.

Bằng việc kết hợp sáng tạo giữa nền tảng tích hợp dữ liệu Oracle Data Integrator 12c, công nghệ thu thập dữ liệu thay đổi Oracle GoldenGate và hệ thống truyền thông điệp phân tán Apache Kafka, đề tài đã xây dựng một đường ống dữ liệu (Data Pipeline) mạnh mẽ với độ trễ thời gian thực $\le 5$ giây và khả năng chịu tải vượt mức 1.000 TPS.

Kết quả nghiên cứu không chỉ góp phần chuẩn hóa kiến trúc dữ liệu 4 phân vùng (Stage - Detail - Summary - Inquiry) và tối ưu hóa hiệu năng bóc tách XML từ bảng T24_CUSTOMER, mà còn mang lại giá trị kinh tế - kỹ thuật trực tiếp cho MBBank thông qua việc giải phóng $70%$ tải xử lý báo cáo trên hệ thống Core, bảo đảm tính sẵn sàng cao cho các dịch vụ ngân hàng số tiên tiến như MB App và hệ thống CRM. Đây là minh chứng rõ nét cho xu hướng ứng dụng công nghệ kỹ thuật dữ liệu chuyên sâu nhằm thúc đẩy chuyển đổi số toàn diện trong ngành tài chính - ngân hàng tại Việt Nam.