BI 8 — Công cụ BI & vận hành: Power BI, Tableau, Metabase, Superset

Ở các bài trước chúng ta đã đi qua tư duy phân tích, mô hình dữ liệu, chỉ số (KPI/metric), và cách thiết kế dashboard. Bài này trả lời câu hỏi rất thực dụng: dùng công cụ nào để xây dựng và vận hành những thứ đó? Và quan trọng không kém: làm sao để khi có hàng trăm báo cáo, hàng chục đội, dữ liệu nhạy cảm (nhất là trong ngân hàng), mọi thứ vẫn an toàn, đáng tin và bảo trì được?

Đây là phần "hero" — nơi kiến thức phân tích gặp thực tế triển khai. Một biểu đồ đẹp mà sai số liệu, hoặc lộ dữ liệu khách hàng, thì còn tệ hơn không có biểu đồ.

1. Bức tranh tổng quan: BI không chỉ là cái biểu đồ

Một công cụ BI hiện đại thường gồm bốn lớp chức năng:

• Kết nối dữ liệu (connect): đọc từ data warehouse, database, file, API.
• Mô hình hóa (model): định nghĩa quan hệ giữa các bảng, tạo measure/metric, lớp ngữ nghĩa (semantic layer).
• Trực quan hóa (visualize): biểu đồ, bảng, dashboard.
• Chia sẻ & vận hành (deliver & govern): xuất bản, phân quyền, lập lịch làm mới, giám sát.

Khi chọn công cụ, đừng chỉ nhìn lớp "visualize" (cái dễ thấy nhất). Phần lớn chi phí dài hạn nằm ở model và govern.

2. So sánh các công cụ BI phổ biến

Không có công cụ "tốt nhất" — chỉ có công cụ phù hợp với ngữ cảnh: ngân sách, kỹ năng đội ngũ, hệ sinh thái sẵn có, và yêu cầu bảo mật.

2.1 Bảng so sánh nhanh

2.2 Mã nguồn mở vs thương mại

Công cụ thương mại (Power BI, Tableau, Looker): trả phí license/người dùng, đổi lại có hỗ trợ chính hãng, tính năng quản trị đầy đủ, lộ trình cập nhật rõ ràng. Chi phí có thể tăng nhanh theo số người dùng.

Mã nguồn mở (Metabase, Superset): không tốn phí license, nhưng "chi phí ẩn" nằm ở vận hành — bạn phải tự host, tự nâng cấp, tự đảm bảo bảo mật, tự xử lý sự cố. Cần đội có năng lực kỹ thuật. Nhiều dự án open source cũng có bản "cloud/enterprise" trả phí kèm hỗ trợ.

2.3 Khung quyết định ngắn gọn

• Hệ sinh thái: Đã dùng Microsoft? → Power BI là lựa chọn tự nhiên. Đã dùng Google Cloud/BigQuery? → cân nhắc Looker/Looker Studio.
• Kỹ năng đội: Đội phân tích quen Excel → Power BI dễ tiếp cận. Đội kỹ thuật mạnh, muốn tiết kiệm license → Superset/Metabase.
• Ngân sách: Hạn chế → open source hoặc Looker Studio. Sẵn sàng đầu tư cho hỗ trợ và quản trị → thương mại.
• Mức độ quản trị & bảo mật: Ngành ngân hàng cần RLS, kiểm toán, lineage chặt chẽ → ưu tiên công cụ có tính năng governance trưởng thành.

Lưu ý: đừng chọn công cụ trước rồi mới nghĩ tới nhu cầu. Hãy bắt đầu từ yêu cầu (ai dùng, dữ liệu gì, bảo mật ra sao) rồi mới ánh xạ sang công cụ.

3. Khái niệm cốt lõi: DAX và measure trong Power BI

Vì Power BI rất phổ biến trong doanh nghiệp, nắm được hai khái niệm sau sẽ giúp bạn hiểu cách BI hiện đại tính toán số liệu.

3.1 Measure vs Column

• Calculated column (cột tính toán): tính cho từng dòng, lưu trong bảng, tốn bộ nhớ. Ví dụ: Lợi nhuận = Doanh thu - Chi phí cho mỗi dòng giao dịch.
• Measure (thước đo): tính theo ngữ cảnh của báo cáo (filter, nhóm đang chọn), không lưu sẵn mà tính lúc hiển thị. Đây là khái niệm quan trọng nhất.

Ví dụ measure bằng DAX (Data Analysis Expressions — ngôn ngữ công thức của Power BI):

Total Revenue = SUM(Sales[Amount])

Revenue LY = CALCULATE(
    [Total Revenue],
    SAMEPERIODLASTYEAR(Calendar[Date])
)

YoY Growth % = DIVIDE(
    [Total Revenue] - [Revenue LY],
    [Revenue LY]
)

Điểm mấu chốt: cùng một measure Total Revenue, nếu báo cáo đang lọc theo chi nhánh A tháng 1, nó tự tính tổng cho đúng phạm vi đó. Đây gọi là filter context (ngữ cảnh lọc). Việc dùng measure thay vì cột giúp số liệu nhất quán và mô hình nhẹ hơn.

Khái niệm "measure tính theo ngữ cảnh" tồn tại ở mọi công cụ dù tên gọi khác nhau: Tableau gọi là calculated field/LOD, Looker dùng measure trong LookML. Hiểu một nơi, suy ra chỗ khác.

4. Import vs DirectQuery (Live): dữ liệu nằm ở đâu khi xem báo cáo?

Đây là quyết định kiến trúc ảnh hưởng lớn đến hiệu năng và độ tươi của dữ liệu.

Trong thực tế nhiều tổ chức dùng mô hình lai (composite): import bảng tổng hợp/lịch sử để truy vấn nhanh, dùng DirectQuery cho dữ liệu cần realtime. Tableau có khái niệm tương tự: Extract (giống Import) vs Live connection (giống DirectQuery).

Nguyên tắc chọn: nếu dữ liệu không cần tươi từng phút và dung lượng vừa phải → Import (nhanh, ổn định). Nếu cần realtime hoặc dữ liệu quá lớn → DirectQuery, và phải tối ưu warehouse phía sau.

5. Row-Level Security (RLS): vì sao chi nhánh A chỉ thấy dữ liệu chi nhánh A

Đây là tính năng bắt buộc phải hiểu trong ngân hàng. RLS đảm bảo cùng một báo cáo, nhưng mỗi người dùng chỉ thấy phần dữ liệu họ được phép.

5.1 Vấn đề

Giả sử bạn có một dashboard "Doanh số chi nhánh". Bạn không muốn xây 50 bản sao cho 50 chi nhánh. Bạn muốn một báo cáo, và mỗi giám đốc chi nhánh đăng nhập chỉ thấy số của chi nhánh mình; còn lãnh đạo vùng thấy nhiều chi nhánh.

5.2 Cách hoạt động (khái niệm chung)

RLS gồm hai phần:

1. Quy tắc lọc (security rule/filter): ví dụ "chỉ hiển thị dòng có Branch = chi nhánh của người dùng".
2. Ánh xạ người dùng → vai trò/phạm vi: thường dùng email/username đăng nhập để tra ra phạm vi.

Trong Power BI, người ta thường dùng hàm trả về danh tính người đang xem, ví dụ một filter dạng:

[BranchID] = LOOKUPVALUE(
    UserBranch[BranchID],
    UserBranch[Email], USERPRINCIPALNAME()
)

Khi giám đốc chi nhánh A đăng nhập, USERPRINCIPALNAME() trả về email của họ, hệ thống tra bảng ánh xạ và chỉ cho phép các dòng thuộc chi nhánh A.

5.3 Static vs Dynamic RLS

• Static RLS: tạo vai trò cố định (ví dụ "Vai trò Chi nhánh A" lọc cứng Branch = "A"). Dễ làm nhưng không mở rộng tốt khi có nhiều chi nhánh.
• Dynamic RLS: dùng bảng ánh xạ người dùng → phạm vi, một quy tắc áp cho tất cả. Mở rộng tốt, nên dùng cho tổ chức lớn.

Cảnh báo: RLS lọc dòng (row) chứ không ẩn cột (column). Nếu cột chứa dữ liệu nhạy cảm (số CMND, số dư) mà người dùng không được xem, bạn cần thêm cơ chế khác (object-level security hoặc che/mask ở tầng dữ liệu). RLS sai cấu hình là một trong những lỗi rò rỉ dữ liệu phổ biến nhất — luôn kiểm thử với tài khoản giả lập của từng vai trò.

6. Lịch Refresh & lập lịch

Với mô hình Import/Extract, dữ liệu trong báo cáo chỉ "đông cứng" tới lần làm mới gần nhất. Vận hành tốt cần lịch refresh rõ ràng.

• Tần suất: theo nhu cầu nghiệp vụ — báo cáo cuối ngày có thể refresh 1 lần/đêm; dashboard vận hành có thể vài giờ/lần. Đừng refresh dày hơn mức cần thiết (tốn tài nguyên).
• Thời điểm: nên chạy sau khi pipeline ETL/ELT nạp xong dữ liệu, tránh giờ cao điểm của nguồn.
• Incremental refresh (làm mới tăng dần): chỉ nạp lại dữ liệu mới/thay đổi thay vì toàn bộ — quan trọng với bảng lớn (giao dịch ngân hàng nhiều năm).
• Cảnh báo lỗi: refresh thất bại phải báo cho đội phụ trách, không để báo cáo hiển thị số cũ mà không ai biết.
• Phụ thuộc (dependency): lý tưởng là refresh được kích hoạt bởi pipeline dữ liệu ("data đã sẵn sàng → refresh"), không chỉ chạy theo giờ cố định.

7. Quản trị BI (Data Governance)

Khi tổ chức có nhiều báo cáo và nhiều người tự tạo dashboard, hỗn loạn dễ xảy ra: ba dashboard cùng tên "Doanh thu" nhưng ra ba con số khác nhau. Governance giải quyết điều đó.

7.1 Các trụ cột chính

• Data catalog (danh mục dữ liệu): "thư viện" liệt kê có những dataset/bảng/báo cáo nào, ý nghĩa, ai sở hữu. Giúp người mới tìm đúng nguồn thay vì tự dựng lại.
• Data lineage (truy vết nguồn gốc): sơ đồ "dữ liệu này từ đâu ra" — từ bảng nguồn → biến đổi nào → measure nào → dashboard nào. Khi một con số sai, lineage giúp truy ngược nhanh; khi đổi bảng nguồn, biết báo cáo nào bị ảnh hưởng.
• Certified dataset (dataset được chứng nhận): đánh dấu nguồn dữ liệu/báo cáo đã được kiểm chứng là "nguồn sự thật" (single source of truth). Người dùng nên xây trên dataset chứng nhận thay vì tự kết nối lung tung.
• Quản lý phiên bản báo cáo (version control): lưu lịch sử thay đổi báo cáo, có môi trường phát triển/kiểm thử/sản xuất, để thay đổi không phá vỡ báo cáo đang dùng. Một số tổ chức đưa định nghĩa BI (LookML, file dự án) vào Git.
• Ownership & vòng đời: mỗi dataset/dashboard phải có người chịu trách nhiệm; báo cáo không còn dùng phải được lưu trữ/xóa (tránh "nghĩa địa dashboard").

7.2 Quản trị truy cập & dữ liệu nhạy cảm (PII trong ngân hàng)

Ngân hàng xử lý PII (thông tin nhận dạng cá nhân: tên, CMND/CCCD, số tài khoản, số dư). Yêu cầu khắt khe hơn:

• Phân quyền tối thiểu (least privilege): mặc định không có quyền; chỉ cấp đúng phạm vi cần thiết.
• Che/giả lập dữ liệu (masking): ví dụ hiển thị *****1234 thay vì số tài khoản đầy đủ với người không cần xem đủ.
• RLS + Column/Object-level security: kết hợp lọc dòng và ẩn cột nhạy cảm.
• Nhật ký kiểm toán (audit log): ghi lại ai xem/xuất dữ liệu gì, khi nào — phục vụ tuân thủ và điều tra sự cố.
• Kiểm soát xuất dữ liệu (export): hạn chế khả năng tải dữ liệu thô ra ngoài; cân nhắc cấm xuất với dataset chứa PII.
• Tuân thủ: căn theo quy định nội bộ và pháp luật (bảo vệ dữ liệu cá nhân) — đây không chỉ là vấn đề kỹ thuật.

8. Vận hành & tối ưu hiệu năng

Một dashboard chạy nhanh hôm nay có thể chậm dần khi dữ liệu lớn lên hoặc nhiều người dùng cùng truy cập.

• Giám sát hiệu năng: theo dõi thời gian tải dashboard, truy vấn chậm, tỉ lệ refresh thất bại. Power BI có công cụ phân tích hiệu năng; Superset/Metabase có log truy vấn.
• Tối ưu mô hình:
  • Mô hình sao (star schema) thường nhanh hơn mô hình phẳng/bông tuyết phức tạp (xem lại bài mô hình dữ liệu).
  • Chỉ giữ cột thực sự cần; bỏ cột không dùng để giảm dung lượng.
  • Dùng bảng tổng hợp (aggregate/pre-aggregation) cho truy vấn nặng thay vì tính lại từ dữ liệu chi tiết.
  • Đẩy phép tính nặng về tầng warehouse/ETL thay vì để công cụ BI tính lúc hiển thị.
• Tối ưu truy vấn DirectQuery: đảm bảo warehouse có index/partition phù hợp, tránh truy vấn quét toàn bảng.
• Kiểm soát số lượng visual trên một trang: mỗi biểu đồ là một (hoặc nhiều) truy vấn — quá nhiều visual làm trang tải chậm.

9. Sơ đồ: Kiến trúc triển khai BI & luồng governance

Sơ đồ cho thấy: dữ liệu chảy từ nguồn qua pipeline vào warehouse, được mô hình hóa thành measure ở lớp ngữ nghĩa, rồi công cụ BI dựng dashboard cho người dùng. Song song đó, các thành phần governance (catalog, RLS, lịch refresh, audit/lineage) bao quanh để đảm bảo an toàn và tin cậy.

10. Áp dụng cho ngân hàng: ví dụ thực tế

Hình dung một dashboard "Tổng quan tín dụng chi nhánh":

• Nguồn: dữ liệu khoản vay từ core banking, nạp hằng đêm qua ELT vào warehouse.
• Mô hình: star schema (fact = khoản vay/giao dịch, dimension = chi nhánh, sản phẩm, thời gian, khách hàng).
• Measure: Dư nợ, Tỉ lệ nợ xấu (NPL), Tăng trưởng tín dụng — định nghĩa một lần, dùng nhiều nơi.
• RLS: giám đốc chi nhánh chỉ thấy chi nhánh mình; PII của khách hàng được che bớt; chỉ vai trò rủi ro mới thấy chi tiết khoản nợ xấu.
• Refresh: chạy sau khi ELT đêm hoàn tất; incremental refresh cho bảng giao dịch lớn.
• Governance: dataset được chứng nhận, có lineage để khi NPL "nhảy số" bất thường thì truy ngược được tới bảng nguồn, có audit log để biết ai đã xuất dữ liệu.

Đây chính là lúc mọi kiến thức từ bài 1 đến bài 8 hội tụ.

Tóm tắt

• Công cụ BI có bốn lớp: kết nối, mô hình hóa, trực quan hóa, chia sẻ & vận hành; chi phí dài hạn nằm nhiều ở mô hình hóa và quản trị.
• Không có công cụ tốt nhất: chọn theo hệ sinh thái, kỹ năng đội, ngân sách, và yêu cầu bảo mật. Power BI mạnh trong hệ Microsoft, Tableau mạnh trực quan hóa, Looker mạnh lớp ngữ nghĩa, Metabase/Superset là open source self-host, Excel vẫn phổ biến cho ad-hoc.
• Measure tính theo ngữ cảnh lọc (DAX trong Power BI) là khái niệm trung tâm để số liệu nhất quán.
• Import vs DirectQuery: đánh đổi giữa tốc độ và độ tươi dữ liệu; thường dùng mô hình lai.
• RLS đảm bảo mỗi người chỉ thấy phần dữ liệu được phép — bắt buộc với ngân hàng; nhớ RLS lọc dòng chứ không ẩn cột.
• Vận hành tốt cần lịch refresh hợp lý và governance: catalog, lineage, dataset chứng nhận, version control, kiểm soát PII, audit log, và tối ưu hiệu năng.

Tự kiểm tra

1. Khi nào bạn chọn một công cụ BI mã nguồn mở (Metabase/Superset) thay vì công cụ thương mại? Nêu ít nhất hai yếu tố cân nhắc.
2. Giải thích sự khác nhau giữa measure và calculated column. Tại sao measure tính theo "ngữ cảnh lọc"?
3. So sánh Import và DirectQuery: mỗi chế độ phù hợp tình huống nào?
4. Mô tả cách Dynamic RLS giúp một dashboard duy nhất phục vụ 50 chi nhánh mà mỗi giám đốc chỉ thấy chi nhánh mình. Vì sao RLS không đủ để bảo vệ một cột chứa số CMND?
5. Data lineage giúp ích gì khi một con số trên dashboard bị nghi sai?
6. Kể ra ba kỹ thuật bảo vệ PII trong môi trường BI ngân hàng.

Đọc tiếp

• Quay lại bắt đầu chuỗi: BI 1 — Giới thiệu để xem lại tư duy phân tích nền tảng và nối mạch toàn bộ loạt bài.
• Để hiểu sâu lớp dữ liệu phía sau mọi dashboard, hãy xem mục SQL (truy vấn, JOIN, aggregate, window function) — nền tảng cho measure và mô hình BI.
• Để áp dụng vào nghiệp vụ thực tế, xem mục Banking (sản phẩm tín dụng, NPL, dữ liệu khách hàng và yêu cầu bảo mật PII) — bối cảnh cho phần governance ở bài này.