04 Xây dựng lại pipeline dbt

Tài liệu đồng hành của người hướng dẫn cho bài học của học viên 04 Xây dựng lại pipeline dbt.

Thời lượng

Khoảng 30 phút. Đoạn duy nhất có khoảng trống thực sự là lần dbt run thứ hai ở Bước 1 (khoảng 8-12 phút để xử lý 50 triệu dòng qua các model incremental) — ngắn đủ để thường không cần một giờ nghỉ riêng, nhưng dài đủ để bạn nên thuyết minh thay vì ngồi xem trong im lặng. Bước 2 (dictionary về zone) và các câu truy vấn kiểm chứng đều nhanh và có tính tương tác.

Nội dung trình bày

• Hãy định vị module này là chứng minh pipeline, không phải chứng minh dữ liệu: module 03 đã chứng minh ClickHouse có thể chứa 50 triệu dòng; module này chứng minh chính pipeline Medallion từ module 01 — các view staging, bảng fact incremental, việc nạp lại dimension, các test — chạy được trên ClickHouse với hình dạng không đổi.
• Cơ chế dbt duy nhất đáng dừng lại để nói: delete_insert thay thế cho MERGE INTO (ClickHouse không có câu lệnh MERGE), và ReplacingMergeTree là lưới an toàn bên dưới nó, không phải thứ thay thế cho nó — nếu delete_insert hoàn tất bình thường thì RMT chẳng có gì phải dọn; nó chỉ quan trọng khi một lần chạy bị ngắt giữa đường.
• mv_live_trip_feed đáng được gọi tên rõ ràng: nó không có đối tượng tương ứng nào ở phía Snowflake. Một materialized view tiêu chuẩn chỉ luôn thấy các dòng trong lô dữ liệu đã kích hoạt nó; một materialized view REFRESHABLE chạy lại toàn bộ truy vấn của nó theo lịch, nên nó có thể duy trì một giá trị tổng hợp trên toàn bộ lịch sử. Đây là năng lực mới mà việc migration mang lại, không phải một bản port thẳng.
• Hãy nói điều này trước khi có ai hỏi: agg_hourly_zone_trips sẽ rỗng sau lần dbt run ở Bước 1, và như vậy là đúng, không phải lỗi. Bộ lọc incremental của nó là WHERE pickup_at >= now() - INTERVAL 2 HOUR, chỉ khớp với các dòng do một producer đang chạy ghi vào; mọi dòng vừa được migrate đều là dữ liệu lịch sử. Nó sẽ còn rỗng cho tới khi module 05 khởi động producer ClickHouse tại thời điểm cutover. Các đối tác chắc chắn sẽ cho rằng pipeline bị lỗi — hãy đi trước câu hỏi đó.

Các lỗi thường gặp

• agg_hourly_zone_trips trả về 0 dòng sau Bước 1, và một đối tác báo đó là lỗi. Không phải lỗi — xem phần nội dung trình bày ở trên. Hãy xác nhận dim_taxi_zones (265 dòng) và fact_trips (khoảng 50 triệu dòng) đã có dữ liệu như mong đợi trước khi dành thời gian cho agg_hourly_zone_trips; nếu hai bảng đó đúng thì bảng tổng hợp rỗng đang hoạt động đúng như thiết kế. Đây là lỗi tiêu biểu của module này — hãy chờ đón câu hỏi đó ở mọi lần chạy.
• dbt run ở Bước 1 thất bại hoặc không kết nối được. Module này phụ thuộc vào profile dbt cho ClickHouse mà module 03 đáng lẽ đã tạo (~/.dbt/profiles.yml, nyc_taxi_ch). Nếu profile đó bị thiếu — xem "Configure the dbt profile" ở Bước 2 trong 03 Cấp phát và di chuyển dữ liệu — thì Bước 1 sẽ thất bại ở đây, trễ một module so với nguyên nhân gốc.
• TODO: mục ## dbt on ClickHouse trong trang Troubleshooting của site không có entry riêng cho một lỗi chỉ xuất hiện ở bước này. Hãy ghi lại ở đây bất cứ điều gì đặc thù phát hiện trong buổi tổng duyệt.

Các bước reset

• Cứ chạy lại dbt run thoải mái — nó là incremental và an toàn để lặp lại; không có gì ở đây cần teardown.
• Sau khi thay đổi một model hoặc schema dbt, buộc dựng lại toàn bộ các model incremental: dbt run --full-refresh (từ workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/dbt/nyc_taxi_dbt_ch).
• Nếu dictionary về zone trông sai hoặc cũ, chỉ cần chạy lại scripts/04_create_dictionary.sql — đó là CREATE OR REPLACE DICTIONARY, an toàn để chạy lại mà không cần drop gì trước.
• Không có bước reset ở cấp môi trường nào áp dụng ở đây — teardown của module này chính là workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/teardown.sh đã nói ở module 03; đừng chạy nó khi đang giữa module.