Metabase: dashboard tự phục vụ trên database của khách, dựng xong trong một buổi chiều

“Set up in five minutes”: README của Metabase trên GitHub hứa như vậy, và phần cài đặt đúng là nhanh thật. Cái giá thật sự nằm ở những gì diễn ra sau năm phút đó.

Metabase giải đúng bài này. Repo chính thức tự giới thiệu nó là công cụ Business Intelligence và Embedded Analytics mã nguồn mở, dễ dùng, để ai cũng làm việc được với dữ liệu.

Vậy nên câu hỏi thực sự không phải là bạn có dựng nổi dashboard trong một buổi chiều hay không. Câu hỏi là dashboard ấy có còn an toàn khi khách mời thêm hai mươi người vào dùng.

Một buổi chiều mẫu trông thế nào?

Thử hình dung một công ty phân phối. Dữ liệu đơn hàng nằm trong database vận hành, và các trưởng vùng muốn xem doanh số của vùng mình. Bước đầu tiên khá đơn giản: Metabase có Docker image chính thức cho Open-source Edition, bạn pull về và chạy là xong.

Bước thứ hai là kết nối database của khách. Tài liệu Metabase yêu cầu cấp cho Metabase một tài khoản database có đúng quyền, và trỏ sang một trang riêng về roles và privileges. Hãy đọc trang đó trước buổi hẹn để xin khách tạo sẵn một user riêng cho Metabase.

Trước khi hẹn lịch, nên kiểm tra database của khách có nằm trong danh sách driver chính thức do đội Metabase bảo trì hay không. Các database ngoài danh sách đó dùng driver cộng đồng. Nếu rơi vào trường hợp này, bạn cần chạy thử trước, đừng đợi đến lúc ngồi trước mặt khách mới phát hiện vấn đề.

Bước thứ ba mới là phần làm khách hài lòng. Metabase gọi mỗi truy vấn đã lưu là một question; bạn tạo vài question về doanh số theo vùng và theo tháng, gom chúng thành một dashboard rồi đưa trưởng vùng tự bấm thử. Đến đây là hết buổi chiều. Nhưng bản dựng này vẫn chưa phải production.

Vì sao bản demo chưa phải production?

Cấu hình Docker mặc định lưu dữ liệu ứng dụng của chính Metabase, tức các question, dashboard và tài khoản người dùng bạn vừa tạo, trong H2 nhúng sẵn. Tài liệu nói rõ: muốn chạy production thì phải lưu dữ liệu ứng dụng trong một database đủ chuẩn production.

Vì thế, ngay trong email tổng kết sau buổi demo, hãy ghi bước chuyển application database thành việc phải làm, đừng để nó thành ghi chú nhỏ cuối thư.

Giấy phép là chuyện thứ hai cần nói rõ. Bản mã nguồn mở phát hành theo AGPL, còn các bản thương mại dùng giấy phép thương mại riêng. Khi bạn triển khai cho khách, nhất là khi họ định nhúng dashboard vào sản phẩm bán cho người khác, đội pháp lý của họ cần biết điều này từ sớm.

Quyền gán cho nhóm, không gán cho từng người

Tài liệu Metabase viết thẳng: quyền được cấp cho nhóm, không cấp cho từng người. Như vậy khi khách tuyển thêm người, họ chỉ việc thêm người đó vào đúng nhóm, không ai phải ngồi cấu hình lại từng tài khoản.

Bài toán “mỗi trưởng vùng chỉ thấy vùng của mình” được giải bằng row and column security: hàng và cột hiển thị được giới hạn tùy theo người đang đăng nhập. Với công ty phân phối kia, một ma trận quyền giả định có thể trông như sau.

Nhóm	Bảng được xem	Cột phải ẩn	Giới hạn hàng
Trưởng vùng	Đơn hàng, Khách hàng	Giá vốn, số điện thoại khách	Chỉ vùng của người đăng nhập
Tài chính	Đơn hàng, Hóa đơn	Số điện thoại khách	Toàn bộ
Vận hành kho	Đơn hàng, Tồn kho	Giá bán, giá vốn	Chỉ kho được phân công

Mỗi ô trong bảng là một câu bạn cần khách xác nhận, chẳng hạn trưởng vùng có được thấy giá vốn hay không. Hãy vẽ ma trận này cùng khách trước khi dựng bất kỳ biểu đồ nào. Làm ngược thứ tự thì gần như chắc chắn phải làm lại.

Embedding: chỗ dễ hứa sai nhất

Đến một lúc nào đó, khách sẽ hỏi có nhúng được dashboard vào portal của họ không. Trước khi trả lời, bạn cần biết rằng static embedding nay đã bị deprecated và được thay bằng guest embed.

Guest embed được bảo vệ bằng JWT: Metabase chỉ tải embed khi request mang JWT ký bằng shared secret. Nhưng Metabase không biết ai đang xem, nên row and column security theo người dùng không áp dụng được. Kiểu này hợp với số liệu chung, ai xem cũng như nhau.

Nếu portal phục vụ nhiều tenant và mỗi tenant chỉ được thấy dữ liệu của mình, tài liệu Metabase khuyến nghị embedding dùng SSO cho analytics tự phục vụ multi-tenant. Hãy dẫn khách sang hướng này ngay từ đầu, thay vì hứa guest embed rồi phát hiện ma trận quyền ở trên không còn tác dụng.

Hai lỗi dễ mắc nhất là gì?

Lỗi đầu tiên là nối Metabase bằng tài khoản admin của database cho nhanh. Demo vẫn chạy trơn tru, nhưng mọi question người dùng tự tạo sau đó đều đi qua tài khoản có quyền cao nhất trên dữ liệu của khách.

Tài liệu chỉ đòi một tài khoản có đúng quyền; với dashboard chỉ để xem, user chỉ đọc trên đúng schema cần dùng là lựa chọn an toàn hơn nhiều.

Lỗi thứ hai là để shared secret của guest embed lọt vào code frontend. Vì Metabase tải embed với bất kỳ request nào mang JWT ký đúng secret, ai đọc được secret cũng tự ký được request của riêng mình. Secret phải nằm ở backend của khách, và nên đưa điểm này vào checklist review trước khi bàn giao.

Nên học gì trước?

Phần nào hỏng gây hậu quả lớn nhất thì học trước: tài khoản database và privileges, rồi mô hình quyền theo nhóm cùng row and column security, rồi đến các kiểu embedding. Kéo thả biểu đồ là phần bạn tự học được trong một giờ.

Trong CV, đừng chỉ ghi “dựng dashboard Metabase”. Hãy viết rằng bạn đã thiết kế phân quyền theo nhóm cho bao nhiêu nhóm người dùng, và vì sao bạn chọn kiểu embedding đó. Nhà tuyển dụng FDE đọc dòng ấy sẽ thấy bạn hiểu được rủi ro dữ liệu của khách, không chỉ biết dùng công cụ.

Năm phút đủ để cài Metabase, một buổi chiều đủ để khách thích nó. Còn việc khách có tin bạn hay không phụ thuộc vào những gì bạn làm với quyền truy cập ngay trong chiều hôm đó.