BI 2 — Kiến trúc & luồng dữ liệu BI

Mở đầu: tại sao cần một kiến trúc rõ ràng?

Ở bài đầu tiên chúng ta đã hiểu BI (Business Intelligence) là gì và vì sao doanh nghiệp cần nó. Nhưng một câu hỏi quan trọng còn bỏ ngỏ: dữ liệu đi từ đâu đến đâu để biến thành một con số trên dashboard?

Hãy tưởng tượng bạn là lãnh đạo một ngân hàng. Sáng nay bạn mở báo cáo và thấy: "Tổng dư nợ cho vay cuối ngày hôm qua: 152.340 tỷ đồng". Con số này không tự nhiên xuất hiện. Nó đã đi qua một hành trình dài: từ hệ thống core banking ghi nhận từng khoản vay, qua các bước trích xuất ban đêm, làm sạch, đối chiếu, tổng hợp, rồi mới hiển thị lên màn hình.

Nếu không có một kiến trúc dữ liệu được thiết kế bài bản, hành trình này sẽ hỗn loạn: số liệu sai lệch, báo cáo chậm, mỗi phòng ban lại có một "phiên bản sự thật" khác nhau. Bài viết này sẽ đưa bạn từ con số không đến hiểu sâu toàn bộ luồng dữ liệu BI.

Các lớp kiến trúc BI

Một hệ thống BI hiện đại được tổ chức thành nhiều lớp (layer), mỗi lớp có một nhiệm vụ riêng. Cách phân lớp này không phải để làm phức tạp vấn đề, mà để cô lập trách nhiệm: khi có lỗi, ta biết tìm ở đâu; khi cần thay đổi, ta không phá vỡ toàn bộ hệ thống.

Sơ đồ tổng quan luồng dữ liệu

Hãy đi qua từng lớp một cách chi tiết.

Lớp 1 — Nguồn dữ liệu (Data Sources)

Đây là nơi dữ liệu "sinh ra" trong quá trình vận hành. Trong ngân hàng, các nguồn điển hình gồm:

• Core banking: hệ thống lõi ghi nhận tài khoản, giao dịch, khoản vay, tiền gửi. Đây là nguồn quan trọng nhất và thường là cơ sở dữ liệu quan hệ (Oracle, SQL Server).
• Ứng dụng (App): app mobile banking, internet banking sinh ra log hành vi người dùng, lượt đăng nhập, giao dịch online.
• File: dữ liệu từ đối tác gửi sang dưới dạng CSV, Excel, file phẳng (ví dụ danh sách nợ xấu từ CIC, dữ liệu thẻ từ tổ chức thanh toán).
• API: dữ liệu thời gian thực từ dịch vụ bên ngoài (tỷ giá, lãi suất thị trường, thông tin định danh eKYC).

Đặc điểm chung: dữ liệu nguồn được tối ưu cho ghi (write) và xử lý giao dịch (OLTP — Online Transaction Processing), không phải để phân tích. Ta không bao giờ chạy báo cáo nặng trực tiếp lên core banking, vì sẽ làm chậm hệ thống vận hành.

Lớp 2 — Ingestion (Thu nạp dữ liệu)

Ingestion là bước đưa dữ liệu từ nguồn vào hệ thống phân tích. Đây là cây cầu nối hai thế giới. Có hai cách chính:

• Pull: hệ thống BI chủ động kết nối vào nguồn và "kéo" dữ liệu ra (qua JDBC, query, file transfer).
• Push: nguồn chủ động "đẩy" dữ liệu sang (qua message queue như Kafka, hoặc webhook).

Một kỹ thuật quan trọng ở đây là CDC (Change Data Capture) — chỉ bắt những bản ghi thay đổi thay vì tải lại toàn bộ. Ví dụ thay vì copy 50 triệu dòng tài khoản mỗi đêm, CDC chỉ lấy vài nghìn dòng vừa được sửa.

Lớp 3 — Staging và ODS

Sau khi thu nạp, dữ liệu thô được đổ vào vùng Staging — một "phòng chờ" tạm thời. Ở đây dữ liệu gần như nguyên trạng so với nguồn, chưa biến đổi. Staging giúp ta:

• Tách rời quá trình lấy dữ liệu khỏi quá trình xử lý.
• Có thể chạy lại (re-run) nếu bước sau lỗi, mà không cần kết nối lại nguồn.

ODS (Operational Data Store) là một biến thể nâng cao của staging. ODS là nơi gom dữ liệu từ nhiều nguồn vận hành, đã được làm sạch ở mức cơ bản, và thường được giữ ở mức chi tiết (detail), cập nhật gần như liên tục. Người ta dùng ODS cho các truy vấn vận hành cần dữ liệu tươi (ví dụ: "khách hàng này hiện có bao nhiêu tài khoản đang mở?") mà không muốn động vào core banking.

Phân biệt nhanh: Staging là tạm và thô; ODS là tích hợp và tương đối tươi nhưng vẫn chi tiết; DWH là nơi lưu trữ lịch sử, đã chuẩn hoá theo mô hình phân tích.

Lớp 4 — Data Warehouse (Kho dữ liệu)

Data Warehouse (DWH) là trái tim của hệ thống BI. Đây là kho lưu trữ tập trung, được thiết kế để phân tích (OLAP — Online Analytical Processing), lưu giữ dữ liệu lịch sử nhiều năm và đã được tích hợp từ mọi nguồn.

Bốn đặc tính kinh điển của DWH (theo Bill Inmon — cha đẻ của khái niệm này):

1. Subject-oriented (hướng chủ đề): tổ chức theo chủ đề nghiệp vụ như Khách hàng, Khoản vay, Giao dịch — chứ không theo ứng dụng.
2. Integrated (tích hợp): dữ liệu từ nhiều nguồn được chuẩn hoá về một định dạng thống nhất (ví dụ giới tính: nguồn A ghi "M/F", nguồn B ghi "1/0" — DWH thống nhất thành "Nam/Nữ").
3. Time-variant (biến thiên theo thời gian): lưu lịch sử, cho phép so sánh "hôm nay vs cùng kỳ năm trước".
4. Non-volatile (bất biến): dữ liệu đã vào DWH thì không sửa/xoá theo kiểu giao dịch — chỉ thêm mới.

Lớp 5 — Data Mart

Nếu DWH là kho trung tâm phục vụ toàn ngân hàng, thì Data Mart là kho con phục vụ một phòng ban hoặc một chủ đề cụ thể. Ví dụ:

• Data Mart Tín dụng: phục vụ phòng quản lý rủi ro tín dụng.
• Data Mart Huy động: phục vụ khối nguồn vốn.
• Data Mart Marketing: phục vụ chiến dịch khách hàng.

Data Mart thường nhỏ hơn, đã tổng hợp sẵn theo nhu cầu của bộ phận đó, nên truy vấn nhanh và dễ hiểu cho người dùng nghiệp vụ. Có hai cách tiếp cận:

• Top-down (Inmon): xây DWH lớn trước, rồi cắt ra các Data Mart.
• Bottom-up (Kimball): xây từng Data Mart trước, rồi liên kết chúng qua các chiều dùng chung (conformed dimensions) — sẽ học sâu ở bài sau.

Lớp 6 — Semantic Layer (Lớp ngữ nghĩa)

Đây là lớp thường bị bỏ quên nhưng cực kỳ quan trọng. Semantic layer là lớp "phiên dịch" giữa cấu trúc dữ liệu kỹ thuật và ngôn ngữ nghiệp vụ. Nó định nghĩa:

• Metrics (chỉ số): "Dư nợ" = tổng cột outstanding_balance của các khoản vay có trạng thái = 'ACTIVE'.
• Mối quan hệ giữa các bảng.
• Quy tắc bảo mật ở mức hàng/cột.

Lợi ích lớn nhất: một định nghĩa duy nhất, dùng chung. Khi mọi dashboard đều lấy "Dư nợ" từ semantic layer, sẽ không còn cảnh hai báo cáo cho ra hai con số khác nhau. Các công cụ như Power BI (mô hình tabular), LookML (Looker), hay dbt metrics layer đều đóng vai trò này.

Lớp 7 — Dashboard và Report

Lớp cuối cùng — nơi người dùng tiếp xúc. Gồm dashboard tương tác (Power BI, Tableau, Superset), báo cáo định kỳ (PDF/Excel gửi email), và các bảng số liệu cho lãnh đạo. Nguyên tắc: lớp này chỉ đọc và trình bày, không xử lý logic nghiệp vụ phức tạp (logic đó phải nằm ở semantic layer hoặc DWH).

ETL vs ELT: hai triết lý biến đổi dữ liệu

Giữa các lớp trên, dữ liệu phải được biến đổi (transform): làm sạch, chuẩn hoá, tổng hợp. Câu hỏi là: biến đổi trước hay sau khi nạp vào kho? Đây chính là sự khác biệt giữa ETL và ELT.

• ETL (Extract — Transform — Load): trích xuất → biến đổi (trên một máy chủ xử lý riêng) → rồi mới nạp dữ liệu sạch vào kho. Đây là cách truyền thống, phổ biến khi kho lưu trữ đắt đỏ và năng lực tính toán giới hạn.
• ELT (Extract — Load — Transform): trích xuất → nạp dữ liệu thô vào kho ngay → rồi biến đổi bên trong kho bằng chính sức mạnh tính toán của kho. Phổ biến trong thời đại cloud data warehouse (Snowflake, BigQuery) khi lưu trữ rẻ và tính toán co giãn được.

Bảng so sánh ETL vs ELT

Tiêu chí	ETL	ELT
Thứ tự	Transform trước khi Load	Load trước, Transform sau
Nơi biến đổi	Máy chủ ETL riêng	Bên trong kho dữ liệu
Dữ liệu thô lưu trong kho	Không (chỉ lưu dữ liệu sạch)	Có (lưu cả thô lẫn sạch)
Phù hợp hạ tầng	On-premise, kho đắt	Cloud, kho co giãn
Tốc độ nạp ban đầu	Chậm hơn (biến đổi trước)	Nhanh (nạp thô ngay)
Linh hoạt phân tích lại	Thấp (mất dữ liệu thô)	Cao (còn dữ liệu thô)
Yêu cầu bảo mật/PII	Dễ che dữ liệu nhạy cảm trước khi nạp	Cần kiểm soát trong kho
Ví dụ công cụ	Informatica, SSIS, Talend	dbt, Snowflake, BigQuery

Khi nào dùng cái nào? Nếu bạn ở ngân hàng dùng hạ tầng on-premise truyền thống, dữ liệu nhạy cảm cần che trước khi lưu, và khối lượng ổn định — ETL hợp lý. Nếu bạn dùng cloud, cần linh hoạt phân tích lại dữ liệu thô và muốn tận dụng sức tính toán của kho — ELT là lựa chọn hiện đại.

Batch vs Streaming: nhịp điệu của dữ liệu

Dữ liệu di chuyển theo hai nhịp:

• Batch (xử lý theo lô): gom dữ liệu trong một khoảng thời gian rồi xử lý cả lô. Ví dụ kinh điển: cuối ngày (EOD — End of Day) trích toàn bộ giao dịch trong ngày. Ưu điểm: đơn giản, ổn định, dễ đối chiếu. Nhược điểm: dữ liệu có độ trễ (sáng mai mới có số của hôm nay).
• Streaming (xử lý dòng): xử lý từng sự kiện ngay khi nó xảy ra, gần như tức thời. Ví dụ: phát hiện gian lận thẻ trong vài giây sau khi quẹt. Ưu điểm: độ trễ thấp. Nhược điểm: phức tạp hơn, khó đối chiếu, tốn hạ tầng (cần Kafka, Flink, Spark Streaming).

Trong thực tế, ngân hàng thường dùng kết hợp: báo cáo tài chính, dư nợ, lợi nhuận chạy theo batch EOD (cần chính xác tuyệt đối, đối chiếu kỹ); còn cảnh báo gian lận, giám sát giao dịch dùng streaming (cần tức thời). Đây là tư duy "đúng nhịp cho đúng việc".

Data Lake vs Data Warehouse vs Lakehouse

Khi khối lượng và sự đa dạng của dữ liệu bùng nổ (ảnh, log, dữ liệu phi cấu trúc), DWH truyền thống bộc lộ giới hạn. Các kiến trúc lưu trữ mới ra đời.

Tiêu chí	Data Warehouse	Data Lake	Lakehouse
Loại dữ liệu	Có cấu trúc	Mọi loại (thô, ảnh, log, JSON)	Mọi loại
Schema	Schema-on-write (định nghĩa trước)	Schema-on-read (định nghĩa khi đọc)	Cả hai
Chi phí lưu trữ	Cao	Thấp	Thấp–trung bình
Hiệu năng truy vấn BI	Cao	Thấp (cần xử lý thêm)	Cao
Quản trị/chất lượng	Chặt chẽ	Lỏng (dễ thành "đầm lầy dữ liệu")	Chặt (có giao dịch ACID)
Đối tượng dùng	Phân tích viên, BI	Kỹ sư dữ liệu, data scientist	Cả hai nhóm
Ví dụ	Snowflake, Teradata	S3 + Hadoop	Databricks, Delta Lake, Iceberg

Cách hiểu trực quan: Data Warehouse như một thư viện có người sắp xếp sách theo chủ đề, dễ tìm nhưng chỉ nhận sách đúng chuẩn. Data Lake như một nhà kho lớn chứa mọi thứ, rẻ nhưng dễ lộn xộn. Lakehouse cố gắng kết hợp ưu điểm cả hai: lưu trữ rẻ và đa dạng như lake, nhưng có quản trị và hiệu năng truy vấn như warehouse — nhờ các định dạng bảng mở có hỗ trợ giao dịch (Delta, Iceberg, Hudi).

Orchestration: nhạc trưởng của luồng dữ liệu

Một luồng dữ liệu gồm hàng chục, hàng trăm bước phụ thuộc lẫn nhau: bước B chỉ chạy khi bước A xong, bước C cần cả A lẫn B. Ai điều phối thứ tự này? Đó là vai trò của orchestration.

Công cụ phổ biến nhất là Apache Airflow, hoạt động dựa trên khái niệm DAG (Directed Acyclic Graph — đồ thị có hướng không chu trình). Mỗi node là một task, mỗi mũi tên là một phụ thuộc. "Không chu trình" nghĩa là không có vòng lặp — dữ liệu luôn chảy về phía trước.

Orchestration không chỉ chạy đúng thứ tự, mà còn: lên lịch (mỗi đêm 2h sáng), thử lại khi lỗi (retry), gửi cảnh báo khi thất bại, và ghi log để truy vết. Không có nhạc trưởng, dàn nhạc dữ liệu sẽ hỗn loạn.

Data Quality và Reconciliation

Trong ngân hàng, một con số sai có thể dẫn đến quyết định sai trị giá hàng tỷ đồng. Vì vậy chất lượng dữ liệu (data quality) và đối chiếu (reconciliation) là bắt buộc.

Kiểm tra chất lượng dữ liệu thường gồm:

• Completeness (đầy đủ): có thiếu bản ghi không? Số dòng nạp có khớp số dòng nguồn?
• Accuracy (chính xác): giá trị có đúng không? (số dư âm bất thường, ngày sinh năm 1850?)
• Consistency (nhất quán): cùng một khách hàng có mã thống nhất giữa các bảng?
• Uniqueness (duy nhất): có bản ghi trùng lặp không?
• Timeliness (kịp thời): dữ liệu có về đúng hạn không?

Reconciliation (đối chiếu) là bước so khớp tổng kiểm soát (control total) giữa nguồn và đích. Ví dụ: tổng dư nợ trong DWH phải bằng đúng tổng dư nợ trong core banking. Nếu lệch dù chỉ một đồng, quy trình phải dừng và báo động — vì trong tài chính, sai một đồng cũng là sai.

Lịch refresh: EOD và near real-time

Tần suất làm mới dữ liệu phải khớp với nhu cầu nghiệp vụ:

• EOD (End of Day): phổ biến nhất cho báo cáo tài chính. Sau khi core banking "đóng ngày", dữ liệu được trích và xử lý qua đêm, sẵn sàng vào sáng hôm sau.
• Intraday / near real-time: làm mới nhiều lần trong ngày, hoặc gần như liên tục, cho các nhu cầu giám sát (theo dõi dòng tiền, cảnh báo rủi ro).

Nguyên tắc thiết kế: không làm mới nhanh hơn mức nghiệp vụ thực sự cần, vì mỗi lần refresh đều tốn tài nguyên và làm tăng độ phức tạp.

Ví dụ luồng dữ liệu trong ngân hàng

Hãy ráp tất cả lại bằng một ví dụ thực tế — báo cáo dư nợ EOD:

1. 22:00 — Core banking đóng ngày, chốt sổ.
2. 00:30 — Airflow kích hoạt DAG. Bước Extract kéo dữ liệu khoản vay, tài khoản, giao dịch trong ngày vào vùng staging.
3. 01:00 — Bước Clean & validate: chuẩn hoá định dạng, loại bản ghi lỗi, đánh dấu dữ liệu bất thường.
4. 01:30 — Reconcile: so tổng dư nợ staging với core. Khớp → đi tiếp; lệch → dừng và báo động đội vận hành.
5. 02:00 — Load vào DWH (thêm dữ liệu của ngày mới, giữ nguyên lịch sử).
6. 02:30 — Build các Data Mart Tín dụng, Huy động.
7. 03:00 — Semantic layer tính lại các metrics; dashboard được refresh.
8. 07:00 — Lãnh đạo mở báo cáo, thấy con số "Dư nợ cuối ngày: 152.340 tỷ" — chính xác, đã đối chiếu, sẵn sàng cho quyết định.

Toàn bộ hành trình này diễn ra trong đêm, tự động, lặng lẽ — và đó chính là vẻ đẹp của một kiến trúc BI được thiết kế tốt.

Tóm tắt

Kiến trúc BI tổ chức dữ liệu thành nhiều lớp: từ nguồn (core banking, app, file, API), qua ingestion, vào staging/ODS, lên Data Warehouse, cắt thành Data Mart, qua semantic layer để thống nhất định nghĩa nghiệp vụ, rồi hiển thị ở dashboard/report. Việc biến đổi dữ liệu theo hai triết lý ETL (biến đổi trước khi nạp, hợp on-premise) hoặc ELT (nạp thô rồi biến đổi trong kho, hợp cloud). Dữ liệu chảy theo nhịp batch (EOD, chính xác) hoặc streaming (tức thời, cho cảnh báo). Về lưu trữ, Data Warehouse chặt chẽ, Data Lake linh hoạt và rẻ, còn Lakehouse kết hợp cả hai. Orchestration (Airflow/DAG) điều phối thứ tự, còn data quality và reconciliation đảm bảo mỗi con số đều đáng tin — đặc biệt quan trọng trong ngân hàng nơi sai một đồng cũng là sai.

Tự kiểm tra

1. Hãy kể tên 7 lớp trong kiến trúc BI theo đúng thứ tự dữ liệu đi qua, và nêu nhiệm vụ chính của mỗi lớp.
2. Phân biệt ETL và ELT: thứ tự khác nhau ở đâu, và mỗi cách phù hợp với loại hạ tầng nào?
3. Khi nào nên dùng batch và khi nào nên dùng streaming? Cho một ví dụ nghiệp vụ ngân hàng cho mỗi loại.
4. So sánh Data Warehouse, Data Lake và Lakehouse về loại dữ liệu, schema và quản trị. Lakehouse giải quyết vấn đề gì của hai cái còn lại?
5. Vì sao bước reconciliation (đối chiếu) lại quan trọng đến mức có thể làm dừng cả quy trình? Giải thích trong bối cảnh báo cáo dư nợ EOD.

Đọc tiếp

BI 3 — Mô hình hoá chiều