Materialization trong dbt: view, table, incremental, ephemeral

Materialization trả lời câu hỏi: “dbt nên hiện thực model này trong kho dữ liệu như thế nào?” — thành view, thành bảng vật lý, hay chỉ cập nhật phần mới? Điều hay: logic SQL giữ nguyên, bạn đổi chiến lược chỉ bằng một dòng cấu hình.

{{ config(materialized='table') }}

select ...

Bốn kiểu materialization

Kiểu	dbt làm gì	Hợp khi
view (mặc định)	Tạo một VIEW — truy vấn lại nguồn mỗi lần đọc	Model nhẹ, dữ liệu nhỏ, muốn luôn mới nhất
table	Tạo BẢNG vật lý, ghi toàn bộ kết quả	Model nặng, nhiều người đọc, cần nhanh
incremental	Lần đầu tạo bảng; lần sau chỉ thêm/cập nhật dữ liệu mới	Bảng rất lớn (log, sự kiện) — tiết kiệm lớn
ephemeral	Không tạo gì; nhúng thẳng vào model dùng nó (CTE)	Bước trung gian dùng lại, không cần lưu

Incremental — “chỉ xử lý dữ liệu mới”

Với bảng hàng trăm triệu dòng, build lại từ đầu mỗi lần rất tốn compute. Incremental cho dbt chỉ xử lý phần mới phát sinh:

{{ config(materialized='incremental', unique_key='don_hang_id') }}

select * from {{ ref('stg_don_hang') }}

{% if is_incremental() %}
  -- chỉ lấy dữ liệu mới hơn lần chạy trước
  where ngay_tao > (select max(ngay_tao) from {{ this }})
{% endif %}

is_incremental() đúng khi bảng đã tồn tại (lần chạy sau) → áp bộ lọc chỉ-lấy-mới.
unique_key giúp dbt cập nhật dòng đã có thay vì thêm trùng.
{{ this }} trỏ tới chính bảng đang build.

Ephemeral — bước trung gian không lưu

Model ephemeral không tạo đối tượng trong kho; dbt nhúng SQL của nó dưới dạng CTE vào các model dùng ref() tới nó. Hợp cho các bước làm sạch trung gian mà bạn không muốn để lại “rác” bảng trong kho.

Tinh chỉnh thêm

Tùy kho dữ liệu, bạn còn cấu hình được clustering, partition, tags, schema đích… ngay trong config(). Với Snowflake/BigQuery, đặt đúng các tham số này giúp truy vấn nhanh và tiết kiệm.

Đọc tiếp

Jinja & macros Template hóa SQL: vòng lặp, biến, hàm tái dùng.

Kiểm thử dữ liệu Đảm bảo model — dù materialization nào — luôn đúng.