Viết kiểm thử dữ liệu dbt cho bảng báo cáo hằng ngày bằng AI
Biến các quy tắc quen thuộc như không thiếu mã, không trùng đơn và trạng thái hợp lệ thành dbt data tests. Bài viết hướng dẫn dùng AI để soạn nháp YAML/SQL, rồi kiểm tra lại logic trước khi đưa vào quy trình chạy hằng ngày.
Một dashboard doanh thu có thể lệch không phải vì biểu đồ sai, mà vì bảng orders có đơn không gắn được khách hàng hoặc xuất hiện một giá trị status ngoài quy ước.
Thay vì chờ dashboard bất thường rồi mới lọc dữ liệu thủ công, bạn có thể đưa các quy tắc này vào dbt. Khi chạy dbt test, dbt sẽ cho biết từng kiểm thử đạt hay không đạt.
AI không quyết định business rule thay bạn. Nhưng nó có thể hỗ trợ soạn nháp YAML và SQL từ các quy tắc mà team đã xác nhận.
Data test trong dbt là gì?
Data test là một assertion — một khẳng định về dữ liệu của model, source, seed hoặc snapshot trong dự án dbt.
Về bản chất, data test là truy vấn select tìm các bản ghi vi phạm assertion:
Không trả về dòng vi phạm nào: test pass.
Có trả về dòng vi phạm: test fail.
dbt test sẽ báo trạng thái của từng test.
Đây là cách biến các bước kiểm tra quen thuộc — tìm giá trị NULL, mã trùng hoặc khóa không khớp — thành quy tắc có thể chạy lặp lại.
dbt có sẵn bốn generic data tests:
| Quy tắc cho báo cáo | Data test phù hợp |
|---|---|
| Mã đơn không được trống | notnull |
| Mỗi đơn chỉ xuất hiện một lần | unique |
| Mã khách của đơn phải tồn tại trong bảng khách | relationships |
| Trạng thái đơn chỉ thuộc danh sách cho phép | acceptedvalues |
Các cột dùng làm khóa join, bộ lọc dashboard hoặc điều kiện tính KPI thường là nơi nên bắt đầu.
Bước 1: Viết business rule trước khi nhờ AI
Đừng chỉ yêu cầu AI “viết dbt tests cho bảng này”. Nếu thiếu ngữ cảnh, đầu ra có thể dùng sai tên cột, sai grain hoặc tự giả định giá trị nghiệp vụ.
Hãy cung cấp các thông tin cần thiết:
Tên model và danh sách cột.
Grain của bảng.
Khóa chính hoặc khóa nghiệp vụ.
Model và cột dùng để đối chiếu quan hệ.
Danh sách giá trị hợp lệ.
Các quy tắc tính toán riêng.
Phiên bản dbt, nếu team biết rõ.
Tài liệu dbt ghi nhận cú pháp arguments cho generic data test khả dụng từ dbt v1.10.5 trở lên. Với phiên bản cũ hơn, đối số có thể được khai báo ở cấp trên cùng của test.
Ví dụ về model báo cáo đơn hàng:
| Cột | Vai trò | Rule |
|---|---|---|
| orderid | Định danh đơn | Không rỗng, không trùng |
| customerid | Khóa join khách hàng | Phải khớp với customers.id |
| status | Trạng thái lọc dashboard | Chỉ nhận giá trị đã thống nhất |
AI có thể chuyển các rule này thành cấu trúc YAML. Nhưng danh sách trạng thái hợp lệ, ý nghĩa khóa và grain vẫn cần người hiểu nghiệp vụ xác nhận.
Bước 2: Dùng AI để soạn nháp generic data tests
Bạn có thể dùng prompt sau để yêu cầu AI tạo YAML:
text
Bạn là data engineer dùng dbt.
Hãy chuyển các business rule bên dưới thành dbt generic data tests
trong một file YAML.
Model: <modelname>
Schema:
<columnname>: <datatype>
<columnname>: <datatype>
Business rules:
<rule1>
<rule2>
<rule3>
Yêu cầu:
Chỉ dùng các generic data tests: notnull, unique,
relationships, acceptedvalues khi phù hợp.
Với relationships, nêu rõ model tham chiếu và field.
Với acceptedvalues, chỉ dùng đúng danh sách giá trị tôi cung cấp.
Không tự thêm cột, model hoặc giá trị nghiệp vụ.
Giải thích ngắn mục đích của từng test.
Ví dụ đầu vào:
text
Model: orders
Schema:
orderid: string
customerid: string
status: string
Business rules:
orderid không được rỗng và không được trùng.
customerid phải khớp với id ở model customers.
status chỉ được là placed, shipped, completed hoặc returned.
Đầu ra cần có cấu trúc gần như sau:
yaml
models:
name: orders
columns:
name: orderid
datatests:
unique
notnull
name: status
datatests:
acceptedvalues:
arguments:
values: ['placed', 'shipped', 'completed', 'returned']
name: customerid
datatests:
relationships:
arguments:
to: ref('customers')
field: id
Generic data test là test có tham số, có thể khai báo trên nhiều model, cột, source, seed hoặc snapshot. dbt khuyến nghị chúng nên chiếm phần lớn bộ data test khi cùng một kiểu assertion được dùng lặp lại.
Sau khi AI trả lời, hãy đối chiếu từng tên model và tên cột với dự án thực tế. Một tên như customerkey thay cho customerid, hoặc một ref() sai model, có thể khiến test không chạy như mong muốn.
Bước 3: Dùng singular data test cho rule tổng hợp
Bốn generic test tích hợp sẵn không bao phủ mọi logic báo cáo. Ví dụ: hoàn tiền có thể có giá trị âm, nhưng tổng giá trị thanh toán theo đơn không được âm.
Đây là assertion trên kết quả tổng hợp, phù hợp với singular data test.
Singular test là một file .sql, thường đặt trong thư mục tests theo cấu hình test-paths. Mỗi file chứa một câu lệnh select trả về các dòng vi phạm. Tên file cũng là tên test.
Ví dụ:
sql
-- Refunds have a negative amount, so the total amount should always be >= 0.
-- Therefore return records where totalamount < 0 to make the test fail.
select
orderid,
sum(amount) as totalamount
from {{ ref('fctpayments') }}
group by orderid
having totalamount < 0
Lưu file với tên:
text
tests/asserttotalpaymentamountispositive.sql
Không thêm dấu chấm phẩy (;) ở cuối câu lệnh trong singular test, vì điều đó có thể làm data test fail.
Với dữ liệu mẫu sau:
| orderid | amount |
|---|---:|
| 1 | 5 |
| 2 | 3 |
| 3 | -1 |
Truy vấn test sẽ trả về đơn 3 với totalamount âm. Đây là kết quả mong đợi: test đã tìm thấy bản ghi vi phạm rule.
Prompt gợi ý:
text
Viết một dbt singular data test cho rule sau.
Model cần dùng: <modelname>
Business rule: <businessrule>
Các cột có sẵn: <columnlist>
Yêu cầu:
Trả về các bản ghi vi phạm, không trả về bản ghi hợp lệ.
Dùng ref() để tham chiếu model.
Mỗi file chỉ có một câu select.
Không thêm dấu chấm phẩy ở cuối câu lệnh.
Nêu rõ các giả định về mức độ tổng hợp của dữ liệu.
Bước 4: Kiểm tra đầu ra AI như kiểm tra SQL mới
YAML hợp lệ chưa chắc đã phản ánh đúng nghiệp vụ. Trước khi đưa test vào quy trình chạy hằng ngày, hãy kiểm tra:
Chạy dbt test và đọc kết quả của từng test.
Đối chiếu các dòng fail với dữ liệu nguồn và quy tắc nghiệp vụ.
Kiểm tra grain của bảng. unique(orderid) chỉ phù hợp khi một dòng thực sự đại diện cho một đơn. Nếu bảng ở grain đơn hàng–sản phẩm, orderid lặp lại có thể hợp lệ.
Rà lại quan hệ tham chiếu. Xác nhận ref('customers'), trường id và ý nghĩa của customerid đều đúng với mô hình dữ liệu.
Kiểm tra phạm vi dữ liệu. Rule áp cho báo cáo hằng ngày có thể cần được xem xét khi chạy trên dữ liệu lịch sử hoặc backfill.
Rà lại acceptedvalues. Khi nghiệp vụ thêm một trạng thái mới, test fail có thể là tín hiệu cần cập nhật quy tắc thay vì lỗi kỹ thuật.
dbt cho phép mở rộng data test theo logic riêng của tổ chức: bất kỳ assertion nào có thể biểu diễn bằng truy vấn select đều có thể trở thành data test. Nếu một cấu trúc singular test được lặp lại nhiều lần và chỉ khác model hoặc cột, đó là dấu hiệu nên cân nhắc generic test có tham số.
Checklist trước khi bảo vệ dashboard bằng dbt
[ ] Business rule được mô tả rõ và đã được xác nhận.
[ ] Grain của bảng đã được xác định trước khi dùng unique.
[ ] Khóa chính có unique và notnull khi phù hợp.
[ ] Khóa join quan trọng có relationships khi phù hợp.
[ ] Cột có tập giá trị hữu hạn có acceptedvalues.
[ ] Rule tổng hợp hoặc đối soát có singular test SQL.
[ ] AI không tự thêm tên cột, model hoặc giá trị nghiệp vụ.
[ ] Đã chạy dbt test và xem lại các dòng fail.
AI có thể giúp soạn nhanh phần khung. Phần quan trọng nhất vẫn là biến kinh nghiệm nghiệp vụ thành các assertion rõ ràng, để dữ liệu được kiểm tra trước khi đi vào dashboard.