Worksheet 1: Chọn engine MergeTree

Thời lượng dự kiến: 15–20 phút Tài liệu tham chiếu: Các engine MergeTree

Khái niệm

Trong Snowflake, bạn tạo một bảng và Snowflake quyết định cách lưu trữ nó. Trong ClickHouse, bạn chọn storage engine — và lựa chọn này quyết định tính đúng đắn, chứ không chỉ hiệu năng.

Ba engine bạn cần cho lab này:

MergeTree — Engine nền. Dữ liệu được lưu trong các file dạng cột đã sắp xếp. Không có khử trùng lặp. Dùng engine này khi bảng chỉ nhận thêm mới (insert-only) hoặc khi pipeline của bạn quản lý việc cập nhật từ bên ngoài (ví dụ: nạp lại toàn bộ ở mỗi lượt chạy dbt).

ReplacingMergeTree(version_col) — Mở rộng MergeTree với khử trùng lặp ở chế độ nền. Khi các dòng có cùng khóa ORDER BY tồn tại trong nhiều part, chỉ dòng có giá trị version_col lớn nhất được giữ lại sau một lần merge. Dùng khi các dòng có thể bị cập nhật và bạn có một cột tăng đơn điệu ở mỗi lần cập nhật (ví dụ: timestamp updated_at).

Cạm bẫy quan trọng: Khử trùng lặp diễn ra bất đồng bộ. Cho đến khi ClickHouse chạy một lần merge nền, cả phiên bản cũ và phiên bản mới của một dòng cùng tồn tại. Luôn dùng SELECT ... FINAL trên các bảng ReplacingMergeTree để buộc khử trùng lặp tại thời điểm truy vấn.

AggregatingMergeTree — Mở rộng MergeTree với việc merge các trạng thái tổng hợp cục bộ. Dùng engine này khi bảng lưu các trạng thái tổng hợp có thể kết hợp được (ví dụ: sketch HyperLogLog, quantile digest) và bạn cần tổng hợp ở chế độ nền. Không cần cho lab NYC Taxi — các bảng tổng hợp được dbt dựng lại, không phải tích lũy dần.

Cây quyết định

Does the table receive UPDATE or DELETE operations?
│
├── No (insert-only)
│   └─► MergeTree()
│
└── Yes
    ├── Is there a timestamp/version column that increases on every update?
    │   ├── Yes → ReplacingMergeTree(version_col)
    │   └── No (e.g., full-reload dimension tables)
    │       └─► MergeTree()  — dbt handles upsert via atomic table swap (full rebuild)
    │
    └── Does the table store partial aggregate states (AggregateFunction types)?
        └── Yes → AggregatingMergeTree()

Staging model luôn là view

Trong dbt + ClickHouse, các staging model nên được materialize thành view, không phải bảng. View không tốn chi phí lưu trữ và luôn tươi mới — chúng chỉ là SQL đã lưu, không phải đối tượng vật lý.

Bài tập chọn engine bên dưới bao trùm các dbt model ở lớp analytics (bảng fact, bảng tổng hợp, bảng dimension) và ClickHouse Materialized View. Nó không bao gồm trips_raw hay các staging model:

• trips_raw là một bảng ClickHouse nền được script di chuyển tạo trực tiếp (scripts/02_migrate_trips.py) — không phải một dbt model. Nó dùng ReplacingMergeTree(_synced_at) vì script di chuyển có thể thử lại một batch và chèn lại cùng một trip_id. Sau khi cutover, producer đang chạy cũng có thể thử lại khi gặp lỗi tạm thời; _synced_at DateTime DEFAULT now() bảo đảm lần ghi gần nhất thắng.
• stg_trips là một view dbt nằm trên trips_raw. Nó áp dụng SELECT ... FROM trips_raw FINAL để giải quyết mọi bản trùng chưa được merge trước khi dữ liệu đến các analytics model phía sau. Trách nhiệm khử trùng lặp thuộc về đây — không phải ở một bảng staging dùng ReplacingMergeTree.

Bài tập: chọn engine cho các bảng NYC Taxi

Với từng bảng bên dưới, hãy xác định mẫu cập nhật, chỉ ra cột version (nếu có), và chọn engine giữ cho bảng đúng đắn. Sau đó làm các câu hỏi lập luận khi mọi dòng đã được điền.

Loading worksheet...

Chuyển sang migration-plan.md

Khi bạn đã điền xong worksheet này, hãy sao các quyết định về engine của bạn vào Phần 3 của migration-plan.md và tick ô:

- [ ] Engine selection: completed