Mở đầu — vì sao bài này quan trọng
Bạn đã viết được những câu SQL rất "ngon": JOIN nhiều bảng, window function, CTE lồng nhau. Nhưng hãy thành thật trả lời một câu hỏi: ai sẽ chạy lại những câu query đó vào tuần sau, tháng sau? Nếu câu trả lời là "tôi tự chạy lại bằng tay mỗi lần sếp hỏi", thì bạn đang biến mình thành một cái máy chạy report — và đó là cái bẫy lớn nhất của nghề BA.
Giá trị thật sự của một BA không nằm ở chỗ viết được câu SQL khó, mà ở chỗ biến câu SQL đó thành một tài sản dùng được nhiều lần cho nhiều người. Đây chính là tinh thần của self-serve analytics — tự phục vụ. Thay vì để Product Manager, Marketing hay CEO phải đợi bạn viết query rồi gửi file Excel qua email, bạn dựng sẵn một dashboard để họ tự vào xem, tự lọc theo ngày, tự tải số liệu. Bạn giải phóng chính mình khỏi những câu hỏi lặp đi lặp lại "tháng này doanh thu bao nhiêu vậy em?".
Hai công cụ phổ biến nhất giúp BA làm điều này là Metabase (mã nguồn mở, miễn phí, cực kỳ thân thiện) và Looker (của Google, mạnh về quản trị và mô hình hóa dữ liệu ở quy mô doanh nghiệp). Bài này không dạy bạn viết SQL mới — bạn đã biết rồi. Bài này dạy bạn cách đưa SQL của mình lên hai công cụ này một cách đúng đắn, để query trở thành dashboard, và dashboard trở thành thứ mà cả công ty dùng mà không cần làm phiền bạn nữa.
Khái niệm cốt lõi
Self-serve analytics là gì và vai trò của BA
Self-serve analytics nghĩa là người dùng nghiệp vụ (không biết SQL) có thể tự tìm câu trả lời cho mình thông qua một giao diện đã được BA/Data team dựng sẵn. BA đóng vai trò người kiến tạo lớp giữa: bạn viết SQL chuẩn xác một lần, đóng gói thành "câu hỏi" (question) và "dashboard", rồi trao cho người dùng quyền tự lọc và khám phá.
Vai trò của BA trong mô hình này có ba lớp việc rõ ràng:
- Tạo questions — mỗi question là một câu trả lời cho một câu hỏi nghiệp vụ, viết bằng SQL thuần (native query) hoặc bằng giao diện kéo-thả (query builder).
- Lưu vào collections — sắp xếp các question vào thư mục có tổ chức để người sau tìm được, không bị lạc.
- Build dashboards — gom nhiều question lên một màn hình, thêm bộ lọc chung, để người dùng có cái nhìn tổng thể và tự tương tác.
Metabase: chiều sâu cho BA
Metabase là công cụ open-source, có thể tự cài trên server công ty (thậm chí chạy thử bằng Docker trong 5 phút) hoặc dùng bản Cloud. Điểm mạnh khiến nó cực kỳ phổ biến ở các startup Việt Nam là độ thân thiện: người mới có thể tạo biểu đồ mà không viết một dòng SQL nào.
Có hai cách tạo question trong Metabase, và một BA giỏi cần phân biệt khi nào dùng cái nào:
- Query Builder (GUI): kéo-thả, chọn bảng, chọn cột để group, chọn filter. Phù hợp cho câu hỏi đơn giản và cho người dùng nghiệp vụ tự làm. Hạn chế: không làm được những thứ phức tạp như CTE, window function, self join nhiều điều kiện.
- Native query (SQL thuần): bạn viết SQL trực tiếp. Đây là nơi BA tỏa sáng — mọi kỹ thuật bạn học ở các bài trước đều dùng được.
SELECT
DATE(o.created_at) AS ngay,
COUNT(*) AS so_don,
SUM(o.total) AS doanh_thu
FROM orders o
WHERE o.status = 'completed'
[[ AND o.city = {{thanh_pho}} ]]
AND o.created_at BETWEEN {{tu_ngay}} AND {{den_ngay}}
GROUP BY DATE(o.created_at)
ORDER BY ngay
Cú pháp {{tu_ngay}} tạo ra một ô filter để người dùng tự chọn. Cú pháp [[ ... {{thanh_pho}} ]] là optional filter — nếu người dùng không nhập thành phố thì cả mệnh đề đó tự biến mất, query vẫn chạy đúng. Đây là chìa khóa để một câu SQL phục vụ được hàng chục cách lọc khác nhau.
Looker: mô hình hóa thay vì viết lại SQL
Looker (nay là Looker / Looker Studio trong hệ sinh thái Google Cloud) đi theo triết lý khác hẳn. Thay vì để mỗi người viết SQL riêng, Looker dùng một ngôn ngữ mô hình hóa tên là LookML. BA hoặc Data Engineer định nghĩa trước:
- Dimensions: các cột để nhóm/lọc (ví dụ: thành phố, danh mục sản phẩm, ngày).
- Measures: các phép tính tổng hợp (ví dụ:
SUM(total),COUNT(DISTINCT user_id)). - Explores: các "khu vực khám phá" gom dimension và measure lại để người dùng kéo-thả.
Một ví dụ LookML để bạn hình dung:
measure: doanh_thu_thuan {
type: sum
sql: ${TABLE}.total ;;
filters: [status: "completed"]
value_format_name: vnd
}
Sau khi định nghĩa xong, mọi người trong công ty chỉ cần chọn "Doanh thu thuần" từ menu — họ không cần biết rằng phía sau nó là SUM(total) WHERE status = 'completed'.
Khi nào Metabase, khi nào Looker
Quy tắc thực dụng: Metabase thắng ở tốc độ triển khai, chi phí (miễn phí), và sự linh hoạt cho từng query rời rạc — lý tưởng cho startup và team nhỏ. Looker thắng ở quản trị, tính nhất quán định nghĩa và quy mô doanh nghiệp — nhưng tốn phí và cần đầu tư công sức xây LookML ban đầu.
Tình huống thực tế
Tình huống 1 — Tiki: dashboard tự phục vụ cho team Category
Hãy tưởng tượng bạn là BA tại một sàn TMĐT kiểu Tiki. Mỗi sáng, 12 bạn Category Manager (mỗi người phụ trách một ngành hàng như Điện tử, Mẹ & Bé, Sách) đều nhắn bạn cùng một câu: "Doanh thu ngành mình hôm qua bao nhiêu, top sản phẩm bán chạy là gì?". Bạn mất 2 tiếng mỗi sáng chỉ để chạy lại 12 lần cùng một câu SQL với tham số khác nhau.
Giải pháp Metabase: bạn viết một native query có biến {{nganh_hang}} và {{ngay}}, dựng một dashboard "Bảng điều khiển Category" gồm 3 card — doanh thu theo ngày, top 10 sản phẩm, tỷ lệ hủy đơn. Bạn gắn một dashboard filter chung tên "Ngành hàng" liên kết tới biến {{nganh_hang}} của cả 3 card. Mỗi Category Manager mở dashboard, chọn ngành của mình từ dropdown, là có ngay số liệu.
Kết quả: 2 tiếng/ngày của bạn được giải phóng hoàn toàn. Quan trọng hơn, 12 người giờ nhìn cùng một định nghĩa "doanh thu" (cùng lọc status = 'completed'), không còn tranh cãi số liệu. Bài học: một câu SQL được tham số hóa đúng cách có thể thay thế hàng chục lần chạy tay — đây là đòn bẩy lớn nhất của self-serve.
Tình huống 2 — Be (ride-hailing): khi định nghĩa "tài xế hoạt động" loạn xạ
Một hãng gọi xe kiểu Be gặp vấn đề kinh điển: phòng Vận hành báo cáo "8.500 tài xế hoạt động tháng này", phòng Tài chính lại nói "11.200". Khi truy ra, hóa ra phòng Vận hành định nghĩa tài xế hoạt động là "có ít nhất 1 cuốc hoàn thành", còn phòng Tài chính tính cả "tài xế có đăng nhập app". Cùng một cụm từ, hai câu SQL khác nhau, hai con số lệch nhau 30%.
Đây chính xác là bài toán Looker sinh ra để giải. BA cùng Data team ngồi lại, thống nhất định nghĩa, rồi mã hóa nó một lần vào LookML:
measure: tai_xe_hoat_dong {
type: count_distinct
sql: ${driver_id} ;;
filters: [trip_status: "completed"]
}
Từ đó, bất kỳ ai trong công ty — dù là Vận hành hay Tài chính — khi kéo measure "Tài xế hoạt động" đều nhận cùng một con số, vì cùng một logic SQL được Looker sinh ra. Bài học: khi tổ chức lớn lên, vấn đề không còn là "viết được SQL không" mà là "cả công ty có đồng ý một định nghĩa không". Looker giải bài toán quản trị này bằng tầng mô hình hóa, thứ mà mỗi người tự viết SQL không bao giờ làm được.
Tình huống 3 — MoMo: filter động và quyền truy cập theo vùng
Một ví fintech kiểu MoMo cần dashboard giao dịch cho 3 vùng (Bắc, Trung, Nam), nhưng Regional Manager miền Nam không được phép xem số liệu miền Bắc vì lý do nội bộ. Đồng thời, mỗi manager muốn tự lọc theo loại giao dịch (nạp tiền, chuyển tiền, thanh toán hóa đơn).
Trong Metabase, BA xử lý bằng hai cơ chế kết hợp. Phần lọc động giải quyết bằng SQL variable optional như đã học:
SELECT loai_gd, COUNT(*) AS so_gd, SUM(amount) AS gia_tri
FROM transactions
WHERE created_at BETWEEN {{tu_ngay}} AND {{den_ngay}}
[[ AND loai_gd = {{loai_giao_dich}} ]]
GROUP BY loai_gd
Phần phân quyền theo vùng giải quyết bằng data sandboxing / row-level permission của Metabase (bản Pro) hoặc access_filter trong LookML của Looker — tự động chèn điều kiện WHERE region = <vùng của user> dựa trên thông tin đăng nhập. Manager miền Nam đăng nhập thì query tự thêm region = 'South', không cách nào nhìn thấy dữ liệu miền Bắc.
Bài học: self-serve không có nghĩa là "ai cũng thấy mọi thứ". Một BA trưởng thành luôn nghĩ tới phân quyền và bảo mật dữ liệu ngay khi thiết kế dashboard, đặc biệt với dữ liệu tài chính nhạy cảm.
Hướng dẫn từng bước
Dưới đây là quy trình dựng một dashboard self-serve hoàn chỉnh trong Metabase — luồng phổ biến nhất bạn sẽ làm hàng tuần.
Bước 1 — Kết nối nguồn dữ liệu. Vào Admin → Databases → Add database, chọn MySQL/PostgreSQL, nhập host, port, tên DB và tài khoản read-only (quan trọng: dùng tài khoản chỉ đọc để không ai lỡ tay DELETE). Metabase sẽ tự quét schema.
Bước 2 — Viết question bằng native query. Bấm New → SQL query, chọn database, viết câu SQL của bạn. Bắt đầu đơn giản, chạy thử bằng nút Run (hoặc Cmd/Ctrl + Enter) cho tới khi ra đúng số.
Bước 3 — Thêm SQL variables. Thay các giá trị cứng bằng {{ten_bien}}. Với mỗi biến, Metabase hiện một panel cho bạn chọn kiểu (Text, Number, Date, hoặc Field Filter — kiểu mạnh nhất, gắn thẳng vào một cột để có dropdown gợi ý sẵn giá trị). Bọc các điều kiện không bắt buộc trong [[ ... ]].
Bước 4 — Trực quan hóa. Chuyển từ tab Data sang chọn loại biểu đồ (line cho xu hướng theo thời gian, bar cho so sánh, number cho một con số lớn duy nhất). Đặt format tiền tệ VND, đặt tên cột tiếng Việt dễ hiểu.
Bước 5 — Lưu vào collection. Đặt tên question rõ ràng theo chuẩn, ví dụ "[Sales] Doanh thu theo ngày - theo ngành hàng", lưu vào collection của team tương ứng. Đặt tên tốt là 50% của self-serve — người sau phải tìm thấy được.
Bước 6 — Tạo dashboard và gắn filter chung. New → Dashboard, kéo các question vào. Bấm Add a filter ở cấp dashboard, tạo filter "Ngày", "Ngành hàng", rồi wire (nối) từng filter tới biến tương ứng trong mỗi card. Giờ một thao tác chọn filter sẽ cập nhật toàn bộ dashboard.
Bước 7 — Phân quyền và chia sẻ. Đặt quyền xem cho đúng group, bật subscription gửi email/Slack định kỳ nếu cần (ví dụ 7h sáng mỗi ngày tự gửi ảnh dashboard cho ban giám đốc).
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng tài khoản full quyền để kết nối. Rất nguy hiểm. Luôn tạo user database read-only cho công cụ BI. Một câu lệnh sai trong SQL editor không bao giờ được phép xóa dữ liệu thật.
Lỗi 2 — Quên optional filter, bắt người dùng luôn phải nhập. Nếu bạn viết AND city = {{thanh_pho}} mà không bọc [[ ]], người dùng buộc phải chọn thành phố mới chạy được. Hãy luôn cân nhắc dùng [[ ... ]] cho các filter không bắt buộc.
Lỗi 3 — Nhầm Field Filter với biến Text thường. Field Filter (gắn vào cột) cho bạn dropdown gợi ý giá trị thật và xử lý được nhiều giá trị (IN), trong khi biến Text chỉ nhận một chuỗi gõ tay. Với cột phân loại như thành phố, ngành hàng, hãy luôn dùng Field Filter.
Lỗi 4 — Mỗi BA tự định nghĩa lại "doanh thu". Đây là gốc rễ của mọi cuộc tranh cãi số liệu. Dù dùng Metabase hay Looker, hãy thống nhất và tài liệu hóa định nghĩa các chỉ tiêu cốt lõi. Với Looker, mã hóa vào measure. Với Metabase, dùng tính năng Models (lớp dữ liệu chuẩn hóa) hoặc ít nhất một collection "Định nghĩa chuẩn" để mọi người tham chiếu.
Mẹo 1 — Đặt tên question và collection có tiền tố team. Ví dụ [Marketing], [Finance]. Khi công ty có hàng trăm question, cấu trúc đặt tên cứu bạn khỏi mớ hỗn độn.
Mẹo 2 — Để Looker sinh SQL rồi đọc lại. Trong Looker, mỗi explore có nút xem SQL được sinh ra. Đây là cách tuyệt vời để kiểm tra logic và để bạn — người giỏi SQL — phát hiện join sai hay measure tính nhầm.
Mẹo 3 — Cache hợp lý. Cả Metabase lẫn Looker đều cache kết quả. Với dashboard nặng chạy trên bảng lớn, đặt lịch refresh (ví dụ mỗi giờ) thay vì để query chạy live mỗi lần mở — vừa nhanh cho người dùng, vừa nhẹ cho database.
Bài tập thực hành
- Tham số hóa một query. Lấy một câu SQL báo cáo doanh thu theo ngày mà bạn từng viết, thêm hai biến
{{tu_ngay}}và{{den_ngay}}, cùng một optional filter[[ AND category = {{nganh_hang}} ]]. Viết ra phiên bản hoàn chỉnh.
- Thiết kế dashboard trên giấy. Cho một startup giao đồ ăn, phác thảo một dashboard self-serve cho team Vận hành gồm tối thiểu 4 card (ví dụ: số đơn theo giờ, thời gian giao trung bình, tỷ lệ hủy, top quận theo doanh thu) và liệt kê các dashboard filter chung cần có.
- So sánh công cụ. Viết một đoạn ngắn lập luận: với một công ty 15 người mới có dữ liệu, bạn chọn Metabase hay Looker? Nêu ít nhất ba lý do dựa trên chi phí, tốc độ triển khai và nhu cầu nhất quán định nghĩa.
- Định nghĩa measure. Viết một measure LookML (hoặc mô tả tương đương trong Metabase Model) cho chỉ tiêu "Khách hàng mua lặp lại trong 30 ngày", và giải thích tại sao việc tập trung định nghĩa này lại quan trọng.
Tóm tắt
Bài này không thêm cú pháp SQL mới — nó dạy bạn cách biến SQL thành tài sản dùng chung thông qua self-serve analytics. Bạn đã nắm ba lớp việc của BA: tạo questions (bằng GUI hoặc native query có SQL variables), lưu vào collections có tổ chức, và build dashboards với filter chung để người dùng tự khám phá. Bạn hiểu Metabase mạnh ở tốc độ, chi phí thấp và sự linh hoạt cho startup — với vũ khí chủ lực là SQL variables và optional filter [[ ]]. Bạn hiểu Looker đi theo triết lý mô hình hóa qua LookML, định nghĩa dimension/measure một lần để cả công ty dùng chung một con số nhất quán. Ba tình huống Tiki, Be và MoMo cho thấy: tham số hóa giải phóng thời gian, mô hình hóa giải quyết tranh cãi định nghĩa, và phân quyền bảo vệ dữ liệu nhạy cảm. Hãy nhớ nguyên tắc cốt lõi: BA giỏi không phải người chạy report giỏi, mà là người dựng được hệ thống để người khác không cần làm phiền mình nữa.