Worksheet 5: Thiết kế model dbt

Thời lượng dự kiến: 15–20 phút Tài liệu tham chiếu: dbt trên ClickHouse

Khái niệm

Worksheet 1–4 đã tạo ra phần cái gì: engine nào, ORDER BY nào, kiểu ClickHouse nào. Worksheet này tạo ra phần như thế nào: những quyết định đó được diễn đạt thành cấu hình dbt ra sao, trước khi viết bất kỳ dòng SQL nào.

Một model dbt-clickhouse có ba lớp cấu hình mà các nhà phát triển Snowflake không cần nghĩ tới:

1. Materialization — dbt tạo ra đối tượng vật lý nào (view, table, incremental, ephemeral)?
2. Config engine — với các model table và incremental, engine ClickHouse nào và cột version nào?
3. Chiến lược incremental — với các model incremental, dbt xử lý các dòng mới/đã cập nhật như thế nào?

Còn có một mối quan tâm về tính đúng đắn chỉ riêng ReplacingMergeTree mới có:

4. Vị trí đặt FINAL — trong DAG dbt, FINAL đặt ở đâu để bảo đảm các lượt đọc đã được khử trùng lặp?

Hãy dùng cây quyết định này cho materialization:

• Chỉ đọc insert-only từ một source, không ghi gì vào chính model đó? → view
• Chỉ có logic join thuần, không được truy vấn trực tiếp? → ephemeral
• Dựng lại toàn bộ ở mỗi lượt chạy dbt, không cập nhật một phần? → table
• Chỉ xử lý các dòng mới/đã thay đổi ở mỗi lượt chạy? → incremental

Các staging model luôn là view — cùng nguyên tắc từ Worksheet 1. stg_trips và stg_taxi_zones là các lượt đọc chuyển tiếp, không tự ghi gì, nên chúng vẫn là view bất kể dữ liệu nguồn của chúng hoạt động thế nào.

Bài tập 1: Chọn Materialization

Với từng model, hãy chọn materialization dbt đúng, rồi trả lời vì sao ở câu hỏi bên dưới bảng.

Bài tập 2: Cấu hình engine

Chỉ các model có materialization table hoặc incremental mới cần một engine ClickHouse — view và model ephemeral thì không có. Hãy tham chiếu các câu trả lời ở Worksheet 1: config engine của dbt là việc hiện thực hóa các quyết định về engine mà bạn đã đưa ra ở đó.

Bài tập 3: Thiết kế chiến lược incremental

Với từng model incremental, hãy thiết kế cấu hình incremental đầy đủ: unique_key, incremental_strategy, và bộ lọc SQL nằm bên trong khối bảo vệ is_incremental():

{% if is_incremental() %}
  WHERE <your filter here>
{% endif %}

Bài tập 4: Vị trí đặt FINAL

Khử trùng lặp của ReplacingMergeTree diễn ra bất đồng bộ. FINAL buộc nó xảy ra tại thời điểm đọc — nhưng đặt FINAL ở model sai sẽ có hậu quả về tính đúng đắn hoặc hiệu năng. Với từng model bên dưới, hãy trả lời liệu FINAL có thuộc mệnh đề FROM của chính model đó hay không.

Loading worksheet...

Chuyển sang migration-plan.md

Khi bạn đã hoàn thành worksheet này, hãy điền Phần 10 của migration-plan.md bằng các câu trả lời của bạn và tick ô:

- [ ] dbt model design: completed