BA tooling stack: từ SQL → dashboard → presentation

Mở đầu — vì sao bài này quan trọng

Suốt 58 bài trước, chúng ta đã rèn rất sâu một kỹ năng: viết SQL để moi ra con số đúng. Nhưng nếu bạn đi làm BA một thời gian, bạn sẽ nhận ra một sự thật hơi phũ: một câu query đúng không tự nó tạo ra giá trị. Giá trị chỉ xuất hiện khi con số đó đến được đúng người ra quyết định, vào đúng lúc, dưới một hình thức mà họ tin và hành động được.

Tôi đã chứng kiến nhiều bạn BA giỏi SQL nhưng "tắc" ở khúc sau. Họ chạy query trên DBeaver, copy kết quả dán vào Excel, vẽ biểu đồ, chụp màn hình dán vào slide, rồi gửi email. Tuần sau sếp hỏi lại, họ phải làm lại từ đầu. Một tháng sau số liệu lệch nhau giữa các báo cáo và không ai biết bản nào đúng. Đó không phải lỗi SQL — đó là lỗi không hiểu cả chuỗi công cụ (tooling stack) mà dữ liệu phải đi qua.

Bài này là bức tranh toàn cảnh: dữ liệu đi từ database thô, qua xử lý, lên dashboard, rồi thành câu chuyện trên slide như thế nào. Bạn sẽ hiểu mỗi tầng giải quyết vấn đề gì, SQL của bạn nằm ở đâu trong bức tranh đó, và khi nào nên dừng dùng SQL để chuyển sang công cụ khác. Đây là kiến thức giúp bạn nói chuyện ngang hàng với data engineer, chọn đúng công cụ cho đúng việc, và quan trọng nhất: biến kỹ năng SQL thành tác động thực sự lên doanh nghiệp.

Khái niệm cốt lõi

Hãy hình dung tooling stack hiện đại như một dây chuyền sản xuất. Nguyên liệu thô (dữ liệu giao dịch) đi vào một đầu, sản phẩm hoàn thiện (quyết định kinh doanh) đi ra đầu kia. Mỗi trạm trên dây chuyền có một nhiệm vụ riêng.

  [Nguồn dữ liệu: DB sản phẩm, SaaS, file]
        ↓  (1) Ingestion / ETL-ELT
  [Data Warehouse / Lakehouse]
        ↓  (2) Transformation (dbt, SQL)
  [Mô hình dữ liệu sạch: marts, metrics]
        ↓  (3) BI / Dashboard
  [Metabase, Looker, Power BI, Tableau]
        ↓  (4) Presentation
  [Slide, báo cáo, câu chuyện cho lãnh đạo]

Tầng 1 — Nguồn dữ liệu và Ingestion (ETL vs ELT)

Dữ liệu nằm rải rác: database giao dịch của sản phẩm (PostgreSQL, MySQL), các SaaS như Google Analytics, Facebook Ads, CRM (HubSpot), công cụ thanh toán... Việc đầu tiên là gom chúng về một chỗ.

Công cụ ingestion phổ biến: Airbyte (mã nguồn mở, nhiều bạn VN tự host để tiết kiệm chi phí), Fivetran và Stitch (dịch vụ trả phí, cắm-là-chạy). Chúng có sẵn hàng trăm "connector" để kéo dữ liệu từ nguồn về kho.

Bạn cần phân biệt hai triết lý:

ETL (Extract – Transform – Load): biến đổi dữ liệu trước khi nạp vào kho. Phổ biến thời kho dữ liệu còn đắt và yếu.
ELT (Extract – Load – Transform): nạp dữ liệu thô vào kho trước, rồi mới biến đổi bằng SQL bên trong kho. Đây là chuẩn hiện đại, vì kho dữ liệu đám mây giờ vừa rẻ vừa khoẻ. Và đây chính là lý do SQL của bạn cực kỳ giá trị — phần "T" trong ELT thường được viết bằng SQL.

Tầng 2 — Data Warehouse / Lakehouse

Đây là trái tim của stack: nơi tập trung dữ liệu để phân tích, tách biệt khỏi database vận hành (production) để query nặng của bạn không làm chậm app.

Các lựa chọn phổ biến: BigQuery (Google), Snowflake, Amazon Redshift, Databricks (mô hình lakehouse). Ở thị trường VN và Đông Nam Á, BigQuery rất được ưa chuộng vì trả tiền theo lượng query quét, khởi đầu gần như miễn phí cho team nhỏ.

Điểm BA cần nhớ: warehouse dùng SQL gần giống bạn đã học, nhưng mỗi nền tảng có "phương ngữ" riêng (hàm ngày tháng, cú pháp window). Bài 5 và các bài về MySQL/PostgreSQL đã cho bạn nền tảng; khi sang BigQuery bạn chỉ cần làm quen vài khác biệt cú pháp.

Tầng 3 — Transformation layer (dbt)

Đây là tầng làm thay đổi nghề BA mạnh nhất trong 5 năm qua. dbt (data build tool) cho phép bạn viết các phép biến đổi bằng chính SQL SELECT mà bạn đã thành thạo, rồi dbt lo việc tạo bảng/view, quản lý thứ tự phụ thuộc, kiểm thử chất lượng và sinh tài liệu.

Ý tưởng cốt lõi: thay vì mỗi người tự viết một query tính "doanh thu", ta định nghĩa một lần trong dbt thành một bảng sạch (gọi là mart), ai cũng dùng chung. Đây là cách diệt tận gốc căn bệnh "mỗi báo cáo một con số".

Tầng 4 — BI / Dashboard và Tầng 5 — Presentation

Tầng BI (Metabase, Looker, Power BI, Tableau) biến bảng dữ liệu sạch thành biểu đồ, dashboard tự phục vụ — chúng ta đã chạm tới ở bài 38 và 39. Tầng presentation là khâu cuối: chắt lọc từ dashboard ra 3–5 thông điệp, dựng thành câu chuyện trên slide cho lãnh đạo. Dashboard là để khám phá; slide là để thuyết phục. Lẫn lộn hai mục đích này là lỗi kinh điển.

Tình huống thực tế

Ví dụ 1 — Startup giao đồ ăn dán SQL vào Excel rồi vỡ trận

Một startup giao đồ ăn ở TP.HCM (tạm gọi FoodFast), giai đoạn đầu chỉ có một bạn BA. Quy trình của bạn ấy: mỗi sáng chạy 12 câu query trên DBeaver, copy kết quả sang một file Excel "Master Report", refresh các PivotTable, rồi export PDF gửi cho ban giám đốc qua Zalo.

Mọi thứ ổn cho tới khi công ty tăng từ 5.000 lên 80.000 đơn/ngày. File Excel nặng 200MB, mỗi sáng mất 90 phút để cập nhật, và hai lần file hỏng làm mất báo cáo. Tệ hơn: phòng Marketing tự chạy query riêng để tính "doanh thu", ra con số lệch 8% so với báo cáo của BA, vì hai bên định nghĩa "đơn hợp lệ" khác nhau (một bên trừ đơn huỷ, bên kia không).

Diễn giải: vấn đề không phải SQL sai. Vấn đề là không có tầng transformation tập trung và không có warehouse. SQL chạy thẳng vào database production (làm app chậm giờ cao điểm), logic nghiệp vụ bị nhân bản ở nhiều nơi, và Excel bị dùng sai vai trò — nó trở thành "kho dữ liệu" thủ công thay vì công cụ trình bày.

Họ giải quyết bằng cách: đưa dữ liệu lên BigQuery (qua Airbyte), định nghĩa bảng fct_orders chuẩn trong dbt với đúng một định nghĩa "đơn hợp lệ", rồi cắm Metabase vào đó. Báo cáo sáng tự cập nhật, BA chỉ còn việc diễn giải con số. Thời gian làm báo cáo từ 90 phút xuống còn 0.

Bài học: khi dữ liệu lớn lên, Excel phải lùi về đúng vai trò trình bày. Logic nghiệp vụ phải sống ở một nơi duy nhất, có thể tái sử dụng.

Ví dụ 2 — Ngân hàng số chuẩn hoá metric bằng dbt

Một ví dụ giả định hợp lý từ một fintech VN (tạm gọi PayViet, kiểu MoMo/ZaloPay). Họ có 4 team phân tích: Growth, Risk, Finance, Product. Trong một buổi họp, CEO hỏi "tháng này có bao nhiêu người dùng hoạt động?" — và nhận về 4 con số khác nhau: 6,2 triệu, 5,9 triệu, 7,1 triệu, 6,8 triệu. Lý do: mỗi team định nghĩa "active" khác nhau (có đăng nhập? có giao dịch? trừ tài khoản test?).

Diễn giải: đây là vấn đề về governance (quản trị định nghĩa), không phải kỹ thuật. Họ đưa toàn bộ định nghĩa metric vào dbt: monthly_active_user được định nghĩa một lần là "tài khoản không-test có ít nhất một giao dịch thành công trong 30 ngày". Mọi dashboard, mọi team từ đó kéo từ cùng một bảng metrics_mau.

Bài học: ở quy mô lớn, giá trị của BA không chỉ là viết query, mà là chuẩn hoá và bảo vệ định nghĩa. dbt biến SQL của bạn thành tài sản dùng chung của cả công ty, có version control như code.

Ví dụ 3 — BA bê nguyên dashboard vào phòng họp ban lãnh đạo

Một BA tại công ty thương mại điện tử (kiểu Tiki/Shopee) chuẩn bị họp quý với ban lãnh đạo. Bạn ấy mở thẳng dashboard Power BI với 18 biểu đồ, 30 chỉ số, nhiều bộ lọc. Trong 20 phút, lãnh đạo loay hoay không biết nhìn vào đâu, hỏi toàn câu lạc đề, và cuộc họp kết thúc không có quyết định nào.

Diễn giải: dashboard được thiết kế cho người tự khám phá — nhiều chiều, tương tác cao. Phòng họp lãnh đạo cần điều ngược lại: một câu chuyện tuyến tính. BA này nên rút từ 18 biểu đồ ra đúng 3 thông điệp: (1) doanh thu quý tăng 14% nhưng (2) chủ yếu nhờ tăng giá, đơn hàng thực giảm 3%, vì vậy (3) cần đầu tư lại vào giữ chân khách. Mỗi thông điệp một slide, một biểu đồ sạch, một câu kết luận.

Bài học: dashboard và slide là hai công cụ cho hai mục đích khác nhau. Tầng presentation đòi hỏi biên tập — bỏ đi 90% để 10% còn lại đủ sức thuyết phục.

Hướng dẫn từng bước

Đây là quy trình tham khảo để một BA đi từ câu hỏi nghiệp vụ tới slide cuối cùng, áp đúng từng tầng của stack.

Bắt đầu từ câu hỏi nghiệp vụ, không phải từ dữ liệu. Viết ra một câu rõ ràng: "Tỷ lệ khách quay lại trong 30 ngày của nhóm mua lần đầu tháng 5 là bao nhiêu, và đang tăng hay giảm?". Câu hỏi tốt định hướng toàn bộ phần còn lại.

Xác định dữ liệu sống ở tầng nào. Nếu công ty đã có warehouse + dbt: tìm trong tầng mart đã có bảng fct_orders, dim_customers chưa. Nếu chưa có gì, bạn sẽ query thẳng database — chấp nhận, nhưng đừng để nó thành thói quen ở quy mô lớn.

Viết transformation bằng SQL ở đúng chỗ. Nếu là logic dùng nhiều lần (định nghĩa "đơn hợp lệ", "active user"), đừng nhét vào query dashboard — đưa nó lên dbt thành một model để tái sử dụng. Nếu chỉ là phân tích một lần, query trực tiếp trong BI là đủ.

Dựng dashboard ở tầng BI cho việc khám phá. Cắm Metabase/Looker vào bảng sạch. Thêm bộ lọc theo thời gian, theo vùng. Đây là nơi bạn và đồng nghiệp tự tìm hiểu dữ liệu, kiểm chứng giả thuyết.

Chắt lọc thành câu chuyện ở tầng presentation. Từ dashboard, chọn ra 3–5 thông điệp. Với mỗi thông điệp: một biểu đồ tối giản, một tiêu đề là kết luận (không phải "Doanh thu theo tháng" mà "Doanh thu chững lại do đơn hàng giảm"), một hành động đề xuất.

Đóng vòng lặp. Sau khi trình bày, ghi lại câu hỏi mới phát sinh để vòng phân tích sau làm tốt hơn. Stack tốt là stack giúp bạn lặp lại nhanh.

Lỗi thường gặp & mẹo

Lỗi 1 — Dùng database production làm kho phân tích. Chạy query nặng thẳng vào DB của app sẽ làm chậm trải nghiệm người dùng, thậm chí gây sự cố. Mẹo: luôn yêu cầu một bản sao read-only hoặc một warehouse riêng. Đây cũng là lý do bài 57 về quyền read-only quan trọng.

Lỗi 2 — Biến Excel thành kho dữ liệu. Excel tuyệt vời để trình bày và phân tích nhanh, nhưng tệ hại khi làm nơi lưu trữ chính — dễ hỏng, không version, logic giấu trong công thức không ai đọc được. Mẹo: dữ liệu sống trong warehouse, Excel chỉ là điểm cuối.

Lỗi 3 — Logic nghiệp vụ nhân bản khắp nơi. Mỗi dashboard tự định nghĩa lại "doanh thu" dẫn tới số liệu đá nhau. Mẹo: nguyên tắc DRY (Don't Repeat Yourself) — định nghĩa metric một lần ở tầng transformation, mọi nơi kéo về dùng.

Lỗi 4 — Lẫn lộn dashboard với slide. Bê 18 biểu đồ vào phòng họp lãnh đạo. Mẹo: tự hỏi "người xem cần khám phá hay cần được thuyết phục?". Khám phá thì dashboard, thuyết phục thì slide tuyến tính.

Lỗi 5 — Chọn công cụ theo trào lưu thay vì theo nhu cầu. Team 5 người không cần Snowflake + Fivetran đắt đỏ; BigQuery + Airbyte tự host là đủ. Mẹo: chọn theo quy mô dữ liệu, ngân sách và năng lực vận hành của team.

Mẹo cộng thêm — Hiểu "data lineage". Khi một con số sai, bạn cần truy ngược: nó đến từ dashboard nào → query nào → bảng dbt nào → nguồn nào. Stack hiện đại (dbt) tự sinh sơ đồ lineage này. Biết đọc nó giúp bạn debug nhanh và trả lời tự tin câu hỏi "số này ở đâu ra?".

Bài tập thực hành

Vẽ stack của chính bạn. Nếu đang đi làm, vẽ sơ đồ dữ liệu đi từ nguồn nào → qua công cụ gì → tới báo cáo cuối ở công ty bạn. Đánh dấu chỗ nào đang dùng SQL, chỗ nào đang dùng Excel sai vai trò. Nếu chưa đi làm, vẽ stack lý tưởng cho FoodFast ở Ví dụ 1.

Phân biệt ETL vs ELT. Viết 3–4 câu giải thích vì sao một fintech VN xử lý 50 triệu giao dịch/ngày nên chọn ELT (load thô lên warehouse rồi transform) thay vì ETL truyền thống. Gợi ý: nghĩ về chi phí lưu trữ, khả năng query lại dữ liệu thô, và việc tận dụng SQL.

Thiết kế một metric chuẩn. Cho bài toán "Monthly Active User" của PayViet (Ví dụ 2), viết định nghĩa metric thật chặt bằng lời (loại trừ gì, tính trong khoảng nào) rồi phác câu SQL SELECT mà bạn sẽ đưa vào dbt làm bảng dùng chung.

Biên tập từ dashboard sang slide. Tưởng tượng một dashboard e-commerce có 15 biểu đồ. Chọn ra đúng 3 thông điệp cho cuộc họp lãnh đạo quý, đặt cho mỗi slide một tiêu đề-kết luận và một hành động đề xuất.

So sánh công cụ. Lập bảng nhỏ so sánh Metabase vs Power BI vs Looker theo 3 tiêu chí: chi phí, độ khó học, khả năng self-serve. Kết luận: với một startup VN 20 người, bạn chọn cái nào và vì sao?

Tóm tắt

Tooling stack hiện đại là một dây chuyền: Nguồn → Ingestion (ETL/ELT) → Warehouse → Transformation (dbt) → BI/Dashboard → Presentation. Mỗi tầng giải một vấn đề riêng.
SQL của bạn không bị thay thế — nó là ngôn ngữ chung xuyên suốt tầng transformation (phần "T" của ELT, các model dbt) và tầng BI. Càng lên cao trong stack, SQL càng có đòn bẩy.
ELT là chuẩn hiện đại: nạp dữ liệu thô vào warehouse rồi transform bằng SQL ngay trong kho, tận dụng sức mạnh và chi phí rẻ của warehouse đám mây.
Giá trị lớn nhất của BA ở quy mô lớn là chuẩn hoá định nghĩa metric một lần, dùng chung mọi nơi — diệt căn bệnh "mỗi báo cáo một con số".
Dashboard để khám phá, slide để thuyết phục — đừng lẫn lộn. Tầng presentation đòi hỏi biên tập tàn nhẫn: bỏ 90% để 10% còn lại đủ sức tạo ra quyết định.
Chọn công cụ theo quy mô và ngân sách, không theo trào lưu. Một team nhỏ với BigQuery + Airbyte + dbt + Metabase đã có một stack hiện đại đầy đủ mà gần như miễn phí khởi đầu.