Bài 5, dbt: biến sự kiện thô thành bảng dùng được

Ở bài 4, Nhà Gọn đã có dữ liệu thô trong BigQuery. Nhưng họ nhanh chóng thấy một vấn đề: mỗi lần cần một con số, ai đó lại viết lại cùng những phép mở lồng và biến đổi, và hai người viết ra hai con số khác nhau cho cùng một khái niệm "khách hoạt động". Dữ liệu thô mạnh, nhưng nó lộn xộn.

Bài này về lớp giải quyết chuyện đó: biến sự kiện thô thành các bảng sạch, có kỷ luật, dùng được cho mọi báo cáo. Công cụ phổ biến nhất cho việc này là dbt. Đây là phần kỹ thuật, phù hợp khi bạn đã có kho dữ liệu và bắt đầu có nhiều người cùng đọc số, không phải việc làm ngay từ đầu.

---

#Từ thô tới sạch: nghề analytics engineer

Có một nghề nằm giữa kỹ sư dữ liệu (lo hạ tầng, đường ống) và nhà phân tích (lo phân tích): analytics engineer. Việc của họ là nhận dữ liệu thô đã đổ vào kho, và biến nó thành dữ liệu sạch, đáng tin, dễ dùng cho người phân tích.

Cách làm hiện đại gọi là tải trước, biến đổi sau: đổ dữ liệu thô vào kho, rồi biến đổi ngay trong kho, tận dụng sức mạnh tính toán của kho. dbt là công cụ cho bước biến đổi đó. Mỗi mô hình trong dbt là một câu truy vấn SQL, và dbt lo phần còn lại: vật chất hóa thành bảng, quản lý thứ tự phụ thuộc giữa các mô hình, chạy kiểm thử, và tự sinh tài liệu kèm sơ đồ nguồn gốc dữ liệu.

---

#Mô hình theo lớp

Nguyên tắc là không nhảy thẳng từ thô sang bảng cuối, mà đi qua các lớp:

Nguồn (sự kiện GA4 thô, bán hàng, CRM)
  → Làm sạch: một mô hình cho mỗi nguồn, chỉ đổi tên, ép kiểu, mở lồng
  → Trung gian: logic ghép, dựng phiên
  → Sẵn dùng: bảng chia theo lĩnh vực (sản phẩm, marketing, doanh thu)

Lớp làm sạch chỉ làm sạch, không nhét logic kinh doanh vào. Lớp sẵn dùng mới là nơi có logic và là nguồn cho mọi dashboard. Cách chia lớp này giữ cho hệ thống dễ tái dùng: một mô hình làm sạch được dùng bởi nhiều bảng cuối, thay vì mỗi báo cáo tự làm sạch lại từ đầu.

Ở lớp sẵn dùng, có hai loại bảng:

• Bảng sự kiện: chứa các phép đo, nhiều dòng. Với Nhà Gọn: bảng đơn hàng, bảng phiên truy cập. Chứa số và các khóa liên kết.
• Bảng chiều: mô tả, ít thay đổi. Với Nhà Gọn: bảng khách hàng (kèm kênh, trạng thái kích hoạt), bảng sản phẩm. Dùng để cắt các số trong bảng sự kiện.

---

#Định nghĩa một lần, hết cãi nhau

Đây là giá trị lớn nhất của cách làm này. Trước khi có một lớp mô hình tập trung, định nghĩa "khách hoạt động" nằm rải rác trong từng dashboard, mỗi nơi một kiểu, và mỗi cuộc họp lại có người hỏi "số của ai đúng".

Với dbt, bạn định nghĩa "khách đã kích hoạt" đúng một lần, trong một cột của một mô hình. Mọi dashboard, mọi công cụ đọc cùng cột đó. Hết cảnh bốn con số cho một khái niệm.

-- Định nghĩa kích hoạt một lần, mọi nơi đọc cột này
select
  user_id,
  count(*) as so_don,
  min(order_ts) as ngay_don_dau,
  logical_or(has_review_14d) as da_kich_hoat
from {{ ref('int_don_hang') }}
group by user_id

---

#Ba lỗi thường gặp với mô hình hóa dữ liệu

Lỗi	Vì sao hại	Cách sửa
Không xác định hạt	Mô hình nhập nhằng, đếm sai	Viết ra hạt trước khi viết SQL
Nhét logic kinh doanh vào lớp làm sạch	Khó tái dùng, rối	Lớp làm sạch chỉ làm sạch
Định nghĩa một chỉ số ở nhiều nơi	Số không khớp, mất niềm tin	Một định nghĩa, một chỗ, mọi nơi đọc chung

---

#Trước khi sang bài 6

1. Nếu bạn đã có kho dữ liệu, dựng một dự án dbt tối thiểu nối vào nó.
2. Viết lớp làm sạch cho ít nhất hai nguồn, ví dụ sự kiện GA4 và dữ liệu bán hàng.
3. Viết vài bảng sẵn dùng: bảng sự kiện, bảng khách hàng, bảng doanh thu, mỗi bảng xác định hạt rõ ràng.
4. Định nghĩa một chỉ số quan trọng, ví dụ kích hoạt, đúng một lần và dùng lại nó cho retention.
5. Thêm vài kiểm thử, chạy dựng toàn bộ cho tới khi qua, và sinh tài liệu.

Có các bảng sạch rồi, câu hỏi tiếp theo là công cụ nào đọc chúng để trả lời câu hỏi về hành vi sản phẩm nhanh và tự phục vụ. GA4 mạnh cho marketing nhưng yếu cho phân tích hành vi sâu. Bài 6 nói về các công cụ product analytics như Mixpanel, Amplitude và PostHog, khi nào cần thêm chúng, và cách giữ chúng dùng chung một bộ đặt tên với GA4 để số không lệch nhau.