# dbt: khi câu SQL ở site khách hàng cũng cần git, test và lịch sử

> Giá trị của công cụ này với một FDE không nằm ở câu SELECT, mà ở thứ bạn để lại khi đã rời khỏi warehouse của khách.

Bản gốc: https://fdetimes.net/vi/cong-cu/dbt/

Một bài test trong dbt được coi là đạt khi câu SQL của nó không trả về dòng nào. Nghe ngược đời, nhưng đó chính là triết lý của công cụ này: bạn viết truy vấn đi tìm dữ liệu sai, và im lặng là tin tốt.

Với một FDE, chi tiết nhỏ đó nói lên nhiều điều. Thử hình dung bạn đang ngồi ở site khách hàng, trước một warehouse đầy bảng thô mà sản phẩm của bạn phải đọc được số liệu sạch từ đó. Thứ khiến dự án sống sót sau khi bạn rời đi không phải câu SQL hay, mà là cách câu SQL đó được quản lý.

dbt Labs, đội ngũ phát triển dbt, gọi nó là công cụ biến dữ liệu thô trong warehouse thành các data product đáng tin cậy. Cơ chế rất đơn giản: bạn viết các câu SELECT thuần, dbt ghép chúng thành những model mô-đun, dễ bảo trì.

Thứ làm dbt khác một thư mục script là những gì bọc quanh câu SELECT: version control, CI/CD và tài liệu được áp lên code phân tích, để bất kỳ ai trong team biết SQL cũng đóng góp được vào pipeline production.

## Vì sao FDE cần nó hơn cả data engineer nội bộ?

Hãy hình dung tình huống quen thuộc. Khách hàng có bảng orders thô, một bảng customers hay thay đổi, và muốn sản phẩm của bạn đọc được số liệu sạch mỗi sáng. Cách nhanh nhất là viết vài script SQL, treo lên cron, rồi bay về. Ba tháng sau, ai đó sửa tay một cột, pipeline gãy và không ai biết vì sao.

dbt tồn tại để chặn kịch bản đó. Khi logic nằm trong model có version, mỗi thay đổi có lịch sử, có người review và có test chạy trước khi lên production. Đó là lý do nó hợp với FDE: bạn cần bàn giao thứ mà analyst của khách hàng tự sửa được, không phải thứ chỉ mình bạn hiểu.

## Một ví dụ tối thiểu, từ model đến snapshot

Thử hình dung model đầu tiên: một file stg_orders.sql chỉ chứa câu SELECT lấy id, customer_id, amount, status từ bảng thô và đổi tên cột cho nhất quán. Không có CREATE TABLE, không có DDL. Phần nặng nhọc đó dbt lo.

Kế tiếp là test. dbt có sẵn bốn generic test: unique, not_null, accepted_values và relationships. Bạn khai báo id phải unique và not_null, status chỉ được nhận vài giá trị định trước, customer_id phải tồn tại bên bảng customers. Mỗi test là một truy vấn tìm dòng vi phạm; không dòng nào trả về, pipeline đi tiếp.

Khi bảng orders của khách lên hàng trăm triệu dòng, bạn chuyển model sang incremental. Sau lần chạy đầu, dbt chỉ biến đổi những dòng mới hoặc đã thay đổi. Tài liệu dbt nói thẳng rằng cách này giới hạn lượng dữ liệu phải xử lý và giảm mạnh thời gian chạy, đúng thứ khách hàng hỏi đầu tiên khi hóa đơn compute tăng.

Còn bảng customers, nơi địa chỉ và gói dịch vụ đổi theo thời gian, snapshot là câu trả lời. Snapshot cài đặt type-2 slowly changing dimension trên bảng nguồn mutable: mỗi lần một dòng đổi, phiên bản cũ được giữ lại. Khi khách hỏi "tháng trước tài khoản này ở gói nào", bạn có dữ liệu thay vì cái nhún vai.

**Điểm mấu chốt:** Khách hàng không mua câu SQL của bạn; họ mua một pipeline mà analyst của họ dám sửa sau khi bạn đi.

## Thế hệ mới bắt lỗi trước khi chạm warehouse

Thế hệ hiện tại của dbt, gọi là v2, được viết bằng Rust và hiểu SQL theo nhiều dialect engine khác nhau. Hệ quả thực dụng: nó bắt được lỗi SQL trước khi câu lệnh đến warehouse. Ở site khách hàng, nơi mỗi lần chạy sai tốn cả tiền compute lẫn niềm tin, đó là tính năng đáng giá nhất.

v2 là trải nghiệm mặc định khi bạn cài dbt, xây trên runtime CLI mã nguồn mở theo giấy phép Apache 2.0. dbt miễn phí; một số tính năng mở khóa khi đăng nhập tài khoản dbt platform.

## Giới hạn bạn phải nói thật với khách hàng

dbt bắt đầu từ dữ liệu thô đã nằm sẵn trong warehouse; đó là điểm xuất phát mà chính dbt Labs mô tả. Vì thế, trước khi viết model đầu tiên, bạn nên hỏi khách hàng dữ liệu nguồn đã vào warehouse chưa và bằng cách nào, bởi câu hỏi đó nằm ngoài những câu SELECT mà dbt quản lý.

Test chỉ bắt những gì bạn khai báo. Bốn test có sẵn kiểm tra cấu trúc, không kiểm tra nghĩa: doanh thu âm vẫn đi qua not_null bình thường. Bạn phải viết thêm test nghiệp vụ, và tốt nhất là viết cùng người hiểu dữ liệu nhất phía khách hàng.

Incremental model chỉ xử lý dòng mới hoặc đã thay đổi, nên lời khuyên ở đây là thống nhất với khách ngay từ đầu tiêu chí nào đánh dấu một dòng là "mới" trong hệ thống của họ. Hãy coi đó là một quyết định thiết kế cần trao đổi với khách, không phải một dòng cấu hình.

## Học gì trước

SQL vững là điều kiện, không phải lợi thế. Thứ cần luyện là kỷ luật kỹ sư quanh SQL: git, review, test chạy tự động. Trong CV, một dòng "xây dbt project với test và snapshot cho bảng khách hàng" nói nhiều hơn "thành thạo SQL".

Khi đọc JD, bạn có thể coi các cụm "analytics engineering", "data model", "warehouse" đứng cạnh chữ FDE là dấu hiệu nên chuẩn bị sẵn câu chuyện về một dbt project bạn từng dựng cho buổi phỏng vấn.

Thử hình dung người phỏng vấn đưa bạn một bảng orders thô và hỏi tuần đầu ở site bạn làm gì. Câu trả lời đáng tin không phải "viết SQL", mà là đi qua đúng vòng: model SELECT, bốn test, snapshot cho bảng hay đổi, rồi giải thích vì sao analyst của khách phải tự sửa được.

Hãy tập kể câu chuyện đó trong năm phút, với một project thật trên máy bạn.

Khách hàng sẽ không nhớ câu SQL bạn viết. Họ nhớ pipeline vẫn chạy, và test vẫn im lặng, rất lâu sau khi bạn rời đi.

**Thử ngay tuần này:**

- Cài dbt, nối vào một warehouse thử nghiệm, viết một model stg_orders chỉ gồm SELECT và chạy nó
- Khai báo đủ bốn generic test (unique, not_null, accepted_values, relationships) cho model đó và cố tình làm một test fail
- Tạo một snapshot cho bảng customers giả lập, sửa một dòng, chạy lại và xem lịch sử được giữ thế nào

## Nguồn

- [What is dbt? | dbt Developer Hub](https://docs.getdbt.com/docs/introduction)

- [Add data tests to your DAG | dbt Developer Hub](https://docs.getdbt.com/docs/build/data-tests)

- [Configure incremental models | dbt Developer Hub](https://docs.getdbt.com/docs/build/incremental-models)

- [Add snapshots to your DAG | dbt Developer Hub](https://docs.getdbt.com/docs/build/snapshots)

- [dbt Labs and Fivetran merge announcement (dbt Labs blog)](https://www.getdbt.com/blog/dbt-labs-and-fivetran-merge-announcement)

- [What is dbt? | dbt Developer Hub (page at the about-fusion URL, last updated Sep 10, 2026)](https://docs.getdbt.com/docs/fusion/about-fusion)