Đã đăng vào Thứ Ba, 11:22 CH 10 phút đọc

Google BigQuery - Bài học 33: Hiện đại hóa quy trình biến đổi dữ liệu – Sử dụng Dataform hoặc dbt (data build tool)

Chào anh em! Ở Bài học 32, chúng ta đã điểm mặt 10 thói quen xấu "đốt tiền" oan uổng trên BigQuery. Hôm nay, chúng ta tiến thêm một bước dài trong hành trình nâng tầm kỹ năng kỹ thuật lên chuẩn chuyên gia: Hiện đại hóa quy trình biến đổi dữ liệu (Data Transformation) với Dataform và dbt (data build tool).

Hãy thử nhìn lại cách mà phần lớn các đội ngũ dữ liệu (Data Teams) thường làm khi mới bắt đầu:

Bạn có hàng chục, hàng trăm câu lệnh SQL viết dở dang nằm rải rác ở các Saved Queries trên giao diện web của BigQuery, hoặc lưu trong các file .sql quản lý lộn xộn trong máy cá nhân.
Không có kiểm soát phiên bản (Git Version Control). Ai thích sửa gì thì sửa trực tiếp trên Production.
Không có cơ chế kiểm thử (Testing). Sáng ra sếp phát hiện bảng báo cáo bị lỗi giá trị NULL hoặc dữ liệu trùng lặp vì một bước JOIN sai sót từ đêm hôm trước.
Thứ tự chạy các bảng phụ thuộc lẫn nhau (orders phải chạy xong thì mới được tính daily_revenue) hoàn toàn phải dựa vào... trí nhớ của lập trình viên hoặc cronjob thủ công dễ sập nguồn.

Tình trạng hỗn loạn đó trong thế giới kỹ thuật hiện đại được gọi là "SQL Spaghetti". Để giải cứu các Data Engineer khỏi cơn ác mộng này, trường phái Analytics Engineering đã ra đời, mang toàn bộ tiêu chuẩn của Kỹ thuật phần mềm (Software Engineering) như Git, CI/CD, Testing, và Documentation áp dụng trực tiếp vào SQL thông qua Dataform và dbt.

Hãy cùng mổ xẻ cách áp dụng hai công cụ quyền lực này vào BigQuery nhé!

1. Analytics Engineering là gì? Tại sao SQL thuần không còn đủ?

Trong các hệ thống Data Warehouse hiện đại, quy trình xử lý dữ liệu được chia làm 3 bước chính: ELT (Extract $\rightarrow$ Load $\rightarrow$ Transform).

Giai đoạn Extract & Load đưa dữ liệu thô từ MySQL, PostgreSQL hay Kafka vào thẳng BigQuery (tầng Bronze/Raw).
Giai đoạn Transform (Biến đổi dữ liệu thô thành các bảng báo cáo sạch sẽ ở tầng Silver/Gold) mới chính là nơi tốn nhiều chất xám và dễ phát sinh lỗi nhất.

Nếu bạn viết các bước Transform này bằng các script đơn lẻ, bạn sẽ sớm gặp phải các bức tường:

Thiếu quản lý phụ thuộc (Lack of Dependency Management): Làm sao để hệ thống tự biết bảng mart_sales phải chờ bảng core_orders chạy xong mới được bắt đầu?
Thiếu kiểm thử chất lượng (No Data Testing): Làm sao để tự động chặn đứng pipeline nếu bảng doanh thu xuất hiện giá trị âm hoặc khóa chính order_id bị trùng lặp?
Thiếu tài liệu mô tả (Documentation): Người khác nhìn vào một bảng hàng chục cột trên BigQuery làm sao biết cột nào là gì, công thức tính ra sao?

Dataform và dbt sinh ra để giải quyết trọn vẹn 3 bài toán trên!

2. Giới thiệu cặp bài trùng: Dataform vs. dbt (data build tool)

Cả Dataform và dbt đều là các công cụ biến đổi dữ liệu theo phương thức Declarative (Khai báo) thay vì Imperative (Thủ tục). Bạn chỉ cần viết câu lệnh SQL định nghĩa Bảng (Table) hoặc Góc nhìn (View) muốn tạo ra, còn việc sắp xếp thứ tự chạy thế nào sẽ do công cụ tự lo.

2.1. Dataform (Tích hợp nguyên bản trong Google Cloud)

Bản chất: Dataform ban đầu là một startup độc lập, sau đó đã được Google mua lại và tích hợp trực tiếp làm một phần nguyên bản của Google Cloud (có sẵn ngay trong BigQuery Studio).
Ưu điểm lớn nhất: Không cần cài đặt phức tạp, giao diện web đồng bộ trực tiếp với Git (GitHub/GitLab), hoàn toàn miễn phí (bạn chỉ trả tiền khi BigQuery chạy câu lệnh SQL bên dưới). Hỗ trợ JavaScript để tạo ra các mô hình SQL động (Dynamic SQL generation).

2.2. dbt - data build tool (Tiêu chuẩn công nghiệp Open Source)

Bản chất: Là một công cụ mã nguồn mở (Open Source) cực kỳ nổi tiếng và là tiêu chuẩn vàng của cộng đồng Data Engineering toàn cầu hiện nay (gồm bản dbt Core chạy local và dbt Cloud).
Ưu điểm lớn nhất: Hệ sinh thái khổng lồ, hỗ trợ hàng trăm plugin kiểm thử dữ liệu có sẵn (dbt-expectations), khả năng quản lý môi trường linh hoạt và cộng đồng hỗ trợ cực mạnh trên toàn thế giới.

3. Các khái niệm cốt lõi của Dataform và dbt

Dù bạn dùng Dataform hay dbt, mô hình làm việc đều dựa trên 3 trụ cột chính sau đây:

3.1. Mô hình hóa dạng file SQL (Models)

Thay vì viết một stored procedure khổng lồ, mỗi bảng hoặc view trong kho dữ liệu của bạn sẽ được tách thành một file .sql riêng biệt. Ví dụ, file dim_users.sql chỉ chuyên trách tạo bảng danh mục người dùng, file fact_orders.sql chuyên trách tạo bảng sự kiện đơn hàng.

3.2. Hàm `ref()` – Xây dựng Đồ thị phụ thuộc (DAG - Directed Acyclic Graph)

Đây là "linh hồn" của dbt và Dataform. Thay vì gọi cứng tên bảng bằng chuỗi văn bản thông thường (ví dụ: FROM \my-project.core_dwh.orders``), bạn sử dụng hàm **ref():

SQL

-- Đoạn code SQL viết trong dbt / Dataform
SELECT 
    user_id,
    COUNT(order_id) AS total_orders,
    SUM(total_amount) AS lifetime_value
FROM {{ ref('fact_orders') }} -- Hàm ref tự động hiểu bảng này phụ thuộc vào fact_orders!
GROUP BY user_id;

Phép thuật của ref(): Công cụ sẽ tự động đọc toàn bộ các file SQL trong project của bạn, phân tích mối quan hệ giữa các hàm ref(), và tự động vẽ ra một Đồ thị phụ thuộc (DAG) để biết chính xác thứ tự chạy: Bảng nào chạy trước, bảng nào chạy sau, hoàn toàn không cần con người can thiệp thủ công!

3.3. Kiểm thử dữ liệu tự động (Data Assertions / Tests)

Ngay trong mã nguồn của project, bạn có thể khai báo các quy tắc kiểm tra chất lượng dữ liệu (Data Quality Tests) đi kèm với mỗi bảng:

not_null: Cột order_id tuyệt đối không được có giá trị NULL.
unique: Cột order_id phải là duy nhất (không được phép trùng lặp).
accepted_values: Cột status chỉ được phép nhận các giá trị: ['PENDING', 'COMPLETED', 'CANCELLED'].

Khi bạn chạy lệnh biên dịch, công cụ sẽ tự động thực hiện các câu lệnh kiểm tra này. Nếu có bất kỳ dòng dữ liệu nào vi phạm, pipeline sẽ ngay lập tức dừng lại và báo động đỏ!

4. Đưa quy trình CI/CD vào Data Warehouse với Git

Khi sử dụng Dataform hoặc dbt kết hợp với Git (GitHub / GitLab), quy trình phát triển báo cáo và biến đổi dữ liệu của đội ngũ sẽ thay đổi hoàn toàn theo chuẩn kỹ thuật phần mềm chuyên nghiệp:

Develop (Nhánh cá nhân): Lập trình viên tạo một nhánh Git riêng (feature/add-new-revenue-metric), viết thêm file SQL mới và kiểm tra kết quả trực tiếp trên môi trường Dataset dev_sandbox cá nhân.
Pull Request (Code Review): Mở yêu cầu sát nhập code (PR). Các thành viên khác trong team cùng review câu lệnh SQL, kiểm tra chi phí dự kiến (Dry Run).
CI/CD Automation: Khi PR được duyệt và merge vào nhánh chính (main), hệ thống tự động kích hoạt tiến trình triển khai (Deployment) lên môi trường Production trên BigQuery một cách an toàn tuyệt đối.

Tổng kết Bài học 33

Hiện đại hóa quy trình biến đổi dữ liệu với Dataform hoặc dbt là bước ngoặt quyết định sự chuyên nghiệp của một tổ chức dữ liệu:

Dẹp bỏ "SQL Spaghetti": Chuyển từ các đoạn script rời rạc sang quản lý mã nguồn SQL có cấu trúc Modular.
Đồ thị phụ thuộc (DAG) qua hàm ref(): Tự động điều phối thứ tự thực thi các bảng một cách thông minh.
Kiểm thử tự động & Git CI/CD: Đảm bảo chất lượng dữ liệu tuyệt đối và chuẩn hóa quy trình phát triển như một kỹ sư phần mềm thực thụ.

Và bây giờ, chúng ta đã đi đến chặng đường cuối cùng của toàn bộ lộ trình – nơi mọi kiến thức về kiến trúc (Colossus, Dremel), GoogleSQL, Procedural Scripting, Partitioning, Clustering và Data Transformation hội tụ lại trong một bức tranh hoàn chỉnh.

Hẹn gặp lại anh em ở bài học khép lại chuỗi series – Bài học 34: Capstone Project (Đồ án cuối khóa) – Thiết kế kiến trúc Data Platform hoàn chỉnh cho hệ thống E-commerce & Logistics!

bigquery