BI mã nguồn mở 1 — Superset vs Metabase & bối cảnh

Vì sao mở loạt bài về BI mã nguồn mở?

Ở loạt bài BI Zero to Hero (bi-01-intro) chúng ta đã đi qua nền tảng lý thuyết chung cho mọi công cụ. Hai loạt tiếp theo — Power BI (pbi-01-overview) và Looker (looker-01-overview) — triển khai lý thuyết đó trên hai sản phẩm thương mại phổ biến. Loạt bài này quay sang một nhánh khác nhưng ngày càng quan trọng với team dữ liệu ngân hàng Việt Nam: BI mã nguồn mở (open-source BI), cụ thể là hai công cụ chủ lực Metabase và Apache Superset.

Với một ngân hàng như NCB, câu hỏi không phải "công cụ nào đẹp nhất" mà là "công cụ nào cho phép cả trăm cán bộ nghiệp vụ tự xem số liệu mỗi ngày, dữ liệu nằm trong tường lửa, chi phí kiểm soát được, và đội kỹ thuật tuỳ biến được khi cần". Bốn động lực dưới đây giải thích vì sao open-source BI đáng để cân nhắc nghiêm túc, không chỉ như "phương án tiết kiệm".

1. Chi phí license — biến phí theo user thành chi phí hạ tầng

BI thương mại tính tiền theo số người dùng (per-seat) hoặc capacity. Power BI Pro khoảng 10 USD/user/tháng, Looker tính theo tier doanh nghiệp thường từ vài chục nghìn USD/năm trở lên. Với ngân hàng có 500–2.000 người cần xem dashboard (giao dịch viên, trưởng phòng, cán bộ rủi ro, kiểm toán nội bộ), chi phí per-seat nhân lên rất nhanh.

Metabase và Superset miễn phí ở lõi (Apache 2.0 / AGPL). Bạn không trả tiền theo đầu người; chi phí thực chuyển thành chi phí hạ tầng và vận hành: máy chủ, cơ sở dữ liệu metadata, thời gian của kỹ sư DevOps/DE. Với hàng trăm người đọc thụ động (viewer), mô hình này thường rẻ hơn nhiều lần. Cần lưu ý: cả hai đều có bản thương mại/cloud (Metabase Pro/Enterprise, Preset cho Superset) bổ sung SSO nâng cao, tính năng quản trị, hỗ trợ — không phải mọi thứ đều miễn phí.

2. Tự chủ và tránh vendor lock-in

Mã nguồn mở nghĩa là bạn sở hữu và kiểm soát phần mềm: đọc được source code, nâng cấp theo lịch của mình, không phụ thuộc vào lộ trình sản phẩm hay quyết định tăng giá của một hãng. Dashboard, dataset, metric đều lưu trong metadata database của chính bạn (thường là PostgreSQL/MySQL), có thể sao lưu, di chuyển, phiên bản hoá.

3. Self-host on-prem — dữ liệu không rời khỏi tường lửa

Đây là động lực quyết định trong ngành ngân hàng. Dữ liệu khách hàng (số dư, giao dịch, thông tin định danh) chịu ràng buộc pháp lý nghiêm ngặt (bảo vệ dữ liệu cá nhân, quy định của NHNN). Nhiều tổ chức không được phép đưa dữ liệu nhạy cảm lên cloud công cộng. Metabase và Superset cài đặt hoàn toàn trong data center nội bộ, kết nối thẳng tới PostgreSQL/warehouse on-prem; dữ liệu không bao giờ rời khỏi hạ tầng ngân hàng. Đây là lợi thế mà nhiều SaaS BI thương mại khó đáp ứng nếu không có triển khai on-prem riêng.

4. Tuỳ biến sâu

Cần nhúng dashboard vào cổng nội bộ (embedding)? Tuỳ biến giao diện theo brand ngân hàng? Viết plugin chart riêng? Tích hợp cơ chế xác thực nội bộ (LDAP/AD)? Mã nguồn mở cho phép can thiệp ở mọi tầng — điều gần như bất khả với sản phẩm đóng.

Hai công cụ chủ lực: Metabase và Apache Superset

Cả hai đều là BI web-based, self-host được, kết nối trực tiếp tới cơ sở dữ liệu SQL. Nhưng chúng phục vụ hai nhóm người dùng và hai triết lý khác nhau.

Metabase — dễ dùng, hướng người dùng nghiệp vụ

Metabase (viết bằng Clojure/JavaScript) đặt cược vào sự đơn giản. Điểm nổi bật là chế độ query builder trực quan ("Notebook editor"): người dùng nghiệp vụ chọn bảng, thêm bộ lọc, nhóm, tính tổng — không cần viết một dòng SQL nào. Tính năng "Ask a question" cho phép đặt câu hỏi và nhận về bảng/biểu đồ. Cài đặt nhanh (một file JAR hoặc một container Docker là chạy được), giao diện thân thiện. Metabase rất hợp khi mục tiêu là trao quyền self-service cho cán bộ nghiệp vụ ít kỹ thuật: trưởng phòng chi nhánh tự lọc số liệu huy động theo tháng mà không cần nhờ đội DA.

Đánh đổi: query builder mạnh nhưng không phủ hết mọi truy vấn phức tạp; hệ thống chart ít loại hơn Superset; khả năng tuỳ biến hình ảnh hạn chế hơn.

Apache Superset — mạnh, hướng kỹ thuật/analyst

Superset (dự án Apache, viết bằng Python/Flask ở backend và React ở frontend) hướng tới analyst và kỹ sư dữ liệu. Điểm mạnh:

• SQL Lab — một IDE SQL trong trình duyệt: viết truy vấn tuỳ ý, xem kết quả, lưu thành dataset, chia sẻ. Đây là công cụ đắc lực cho analyst quen SQL.
• Kho biểu đồ phong phú — hàng chục loại chart (từ bar/line/pie tới heatmap, sankey, geospatial, big number với sparkline), nhiều tuỳ chọn cấu hình.
• Semantic layer nhẹ — định nghĩa metric, calculated column ở tầng dataset, dùng lại nhiều nơi.
• Kiến trúc mở rộng tốt — thiết kế để phục vụ nhiều người dùng, hỗ trợ async query qua Celery, caching.

Đánh đổi: đường học dốc hơn Metabase; người dùng nghiệp vụ thuần tuý (không SQL) khó tự phục vụ như với Metabase; vận hành phức tạp hơn (cần metadata DB, cache, message broker cho async).

Chọn cái nào? Ma trận quyết định

Thực tế nhiều tổ chức dùng song song: Metabase cho self-service diện rộng của nghiệp vụ, Superset cho analyst xây dashboard phân tích sâu — cả hai cùng trỏ vào một warehouse.

So sánh với BI thương mại đã có

Bạn đã đọc về Power BI (pbi-01-overview) và Looker (looker-01-overview). Bảng dưới đối chiếu bốn công cụ ở những chiều quan trọng với ngân hàng.

Điểm mạnh open-source: chi phí, tự chủ, on-prem, tuỳ biến. Điểm yếu: semantic layer và trải nghiệm modeling chưa sánh được DAX (Power BI) hay LookML (Looker); ít tính năng "enterprise" đóng gói sẵn (governance, lineage) trừ khi mua bản thương mại; phải tự lo vận hành và hỗ trợ.

Khi nào chọn open-source? Khi (a) dữ liệu buộc phải giữ on-prem; (b) số viewer lớn khiến per-seat quá đắt; (c) đội kỹ thuật đủ năng lực tự vận hành; (d) cần tuỳ biến/nhúng sâu. Khi nào nên cân nhắc thương mại? Khi cần semantic layer/governance mạnh sẵn có, cần hỗ trợ chính thức có SLA, hoặc đội không muốn gánh vận hành.

Kiến trúc chung của BI hiện đại

Dù là công cụ nào, luồng dữ liệu trong một hệ BI hiện đại đều đi qua các tầng giống nhau. Hiểu tấm bản đồ này giúp bạn định vị mọi khái niệm ở các bài sau.

Các tầng:

1. Connection — cấu hình kết nối tới database/warehouse: host, cổng, credentials, driver (ví dụ driver PostgreSQL). Đây là ranh giới bảo mật: tài khoản kết nối nên là read-only với quyền tối thiểu.
2. Dataset / semantic layer — lớp trừu tượng giữa bảng vật lý và chart. Định nghĩa bảng/truy vấn nguồn, đặt tên thân thiện cho cột, khai báo metric (ví dụ "tổng số dư", "số giao dịch") và calculated column dùng lại được.
3. Chart — một truy vấn nền + một cách trực quan hoá. Mỗi chart bản chất sinh ra một câu SQL gửi xuống database.
4. Dashboard — tập hợp nhiều chart trên một trang, thêm filter dùng chung tác động đồng thời lên các chart.
5. Chia sẻ — phân quyền, RLS (row-level security), lịch làm mới, thông báo, nhúng.

Kết nối trực tiếp (SQL-on-read) vs import

Có hai mô hình lấy dữ liệu, tương tự DirectQuery vs Import bên Power BI (pbi-06-storage-directquery):

• Kết nối trực tiếp / SQL-on-read (live query): mỗi lần mở chart, công cụ gửi câu SQL xuống database gốc và lấy kết quả tươi. Metabase và Superset mặc định hoạt động theo mô hình này — chúng không tự lưu trữ dữ liệu nghiệp vụ, chỉ lưu metadata (định nghĩa chart/dashboard). Ưu điểm: dữ liệu luôn cập nhật, không nhân bản dữ liệu nhạy cảm. Nhược điểm: tải trực tiếp lên database gốc, phụ thuộc tốc độ warehouse; cần cache để giảm tải.
• Import / extract: nạp trước dữ liệu vào một engine lưu trữ của công cụ BI (ví dụ VertiPaq của Power BI). Nhanh khi truy vấn nhưng phải làm mới định kỳ và nhân bản dữ liệu — điều thường không mong muốn với dữ liệu ngân hàng nhạy cảm. Metabase/Superset không có engine lưu trữ riêng theo kiểu này; thay vào đó chúng dựa vào cache kết quả truy vấn để tăng tốc.

Vì cả hai công cụ đều thiên về SQL-on-read, chúng rất hợp với kiến trúc "warehouse là nguồn sự thật duy nhất" trên PostgreSQL/warehouse nội bộ ngân hàng.

Các khái niệm chung cần nắm

Trước khi vào chi tiết từng công cụ, thống nhất từ vựng — chúng xuất hiện xuyên suốt loạt bài:

• Dataset (Superset) / Model (Metabase) — nguồn dữ liệu đã được chuẩn hoá ở tầng semantic: một bảng vật lý hoặc một truy vấn SQL đã lưu, kèm metric và cột tính toán. Chart được xây trên dataset, không trực tiếp trên bảng thô.
• Chart / Question — một truy vấn nền cộng cách hiển thị. "Question" là thuật ngữ của Metabase; "Chart"/"Slice" là của Superset. Bản chất: một SELECT gửi xuống DB.
• Dashboard — nhiều chart bố trí trên một trang, kể một câu chuyện dữ liệu (xem bi-04-metrics-kpi về chọn KPI).
• Filter — điều khiển tương tác trên dashboard (chọn khoảng thời gian, chi nhánh, loại tiền tệ...) tác động đồng thời lên nhiều chart. Về mặt SQL, filter thường trở thành mệnh đề WHERE được chèn vào truy vấn nền.
• Cache — lưu tạm kết quả truy vấn để lần sau trả nhanh, giảm tải database gốc. Có TTL (thời gian sống); cần cân bằng giữa độ tươi dữ liệu và hiệu năng.
• RLS (Row-Level Security) — giới hạn dòng dữ liệu mỗi người được xem. Ví dụ giám đốc chi nhánh Hà Nội chỉ thấy khách hàng thuộc chi nhánh mình. Đây là yêu cầu bắt buộc trong ngân hàng; chi tiết ở gov-06-access-control và bài governance của loạt này.

Một chart bản chất là một câu SQL

Để cảm nhận "truy vấn nền một chart", hãy xem một chart điển hình trên dashboard nội bộ: tổng số dư theo loại tiền tệ. Trên PostgreSQL warehouse của ngân hàng, chart này sinh ra chính xác một câu SELECT như sau — bạn có thể chạy trực tiếp trên sandbox:

-- ▶ Chạy được
SELECT currency,
       COUNT(*)      AS so_tai_khoan,
       SUM(balance)  AS tong_so_du
FROM accounts
GROUP BY currency
ORDER BY tong_so_du DESC;

Khi người dùng thêm filter "loại tiền = VND" trên dashboard, công cụ BI đơn giản chèn thêm WHERE currency = 'VND' vào truy vấn nền. Hiểu điều này giúp bạn debug hiệu năng: một dashboard chậm thường là do câu SQL nền chậm, không phải do công cụ BI. Tối ưu nằm ở tầng database (index, materialized view, replication — xem db-opt-06-replication), không phải ở giao diện.

Lộ trình loạt bài

Loạt bài đi từ dễ tới sâu, xen kẽ hai công cụ rồi tổng hợp:

1. Bài này — bối cảnh, so sánh, khái niệm nền.
2. osbi-02-metabase-basics — Metabase căn bản: cài đặt, kết nối DB, query builder, question, dashboard đầu tiên.
3. osbi-03-metabase-advanced — Metabase nâng cao: models, native query, variable/filter, alert, embedding.
4. osbi-04-superset-basics — Superset căn bản: kiến trúc, dataset, chart, dashboard.
5. osbi-05-superset-sql-viz — SQL Lab và kho biểu đồ Superset.
6. osbi-06-semantic-metrics — semantic layer & metric ở cả hai công cụ, so với DAX/LookML.
7. osbi-07-governance-security — phân quyền, RLS, kết nối read-only, kiểm toán.
8. osbi-08-deployment-banking — triển khai on-prem cho ngân hàng: Docker/K8s, HA, cache, backup.

Use case thực tế

Bối cảnh: Khối Vận hành NCB cần một "Dashboard huy động vốn" cho ~350 người dùng: 300 giao dịch viên/trưởng phòng chi nhánh (chỉ xem, ít kỹ thuật) và 50 analyst/cán bộ ALM cần khoan sâu số liệu. Dữ liệu (số dư, giao dịch) nằm trên warehouse PostgreSQL on-prem, không được đưa lên cloud.

Bài toán chi phí: nếu dùng Power BI Pro cho toàn bộ 350 người, chi phí ~350 × 10 USD × 12 = 42.000 USD/năm chỉ riêng license, chưa kể ràng buộc on-prem khó thoả mãn.

Phương án open-source đã chọn:

1. Hạ tầng: cài Metabase (Docker) cho 300 viewer nghiệp vụ và Superset cho 50 analyst, cả hai trên 2 VM trong data center, cùng trỏ tới một tài khoản PostgreSQL read-only trên warehouse. Metadata lưu ở một PostgreSQL riêng, có backup hằng đêm.
2. Semantic: định nghĩa dataset "accounts" với metric tong_so_du = SUM(balance), so_tai_khoan = COUNT(*); dùng lại cho nhiều chart.
3. Chart nền: ví dụ chart "cơ cấu số dư theo loại tiền" chạy đúng câu SELECT ở mục trên; chart "số giao dịch theo loại nghiệp vụ" chạy một SELECT tương tự trên bảng transactions gộp theo kind.
4. RLS: cấu hình để trưởng phòng chi nhánh chỉ thấy khách hàng thuộc city của mình.
5. Cache: đặt TTL 15 phút cho các chart tổng hợp nặng, giảm tải warehouse giờ cao điểm.

Kết quả (minh hoạ): chi phí license 0 đồng; chi phí thực là ~2 VM + thời gian 1 kỹ sư DE vận hành bán thời gian — thấp hơn hàng chục nghìn USD/năm so với per-seat. Dữ liệu không rời khỏi tường lửa. Nghiệp vụ tự lọc số liệu qua query builder Metabase mà không cần biết SQL; analyst dùng SQL Lab của Superset cho phân tích sâu.

Ghi nhớ

• Bốn động lực chọn BI mã nguồn mở trong ngân hàng: chi phí license (không per-seat), tự chủ/tránh lock-in, self-host on-prem giữ dữ liệu trong tường lửa (quan trọng nhất với dữ liệu nhạy cảm), và tuỳ biến sâu.
• Metabase — dễ dùng, hướng nghiệp vụ, query builder không cần SQL, "Ask a question". Superset — mạnh, hướng analyst/DE, có SQL Lab và kho chart phong phú. Nhiều nơi dùng song song.
• So với Power BI/Looker: open-source thắng ở chi phí, on-prem, tuỳ biến; thua ở semantic layer/governance đóng gói sẵn (DAX, LookML) và hỗ trợ chính thức.
• Kiến trúc BI hiện đại: warehouse → connection → dataset/semantic → chart → dashboard → chia sẻ. Mỗi chart bản chất là một câu SQL gửi xuống DB.
• Metabase/Superset mặc định SQL-on-read (live query, chỉ lưu metadata + cache), không import/nhân bản dữ liệu — rất hợp kiến trúc "warehouse là nguồn sự thật" on-prem.
• Từ vựng chung cần thuộc: dataset, chart/question, dashboard, filter (→ WHERE), cache (TTL), RLS (row-level security).
• Dashboard chậm thường do SQL nền chậm, không phải do công cụ BI — tối ưu ở tầng database (index, materialized view, replica read-only).