02 Lập kế hoạch và thiết kế

Điểm khởi đầu

Module 01 đã hoàn tất: Snowflake được dựng đầy đủ, stream CDC và cả hai task theo lịch đang chạy, và — quan trọng nhất — producer chuyến đi vẫn đang ghi khoảng 60 chuyến/phút vào TRIPS_RAW. Hãy để nó chạy; module này chỉ đọc từ Snowflake. Hãy dự trù khoảng 90 phút và khoảng 0.5 Snowflake credit.

Vì sao

Lý do phổ biến nhất khiến các cuộc di chuyển sang ClickHouse cho kết quả kém không phải là vấn đề tinh chỉnh — đó là vấn đề kiến trúc. Các đội chuyển dữ liệu trước rồi mới nghĩ đến thiết kế sau. Đến khi họ nhận ra engine MergeTree sai đang âm thầm cho ra kết quả không đúng, hoặc một sort key sao chép từ schema nguồn bỏ qua các mẫu truy vấn thực tế, thì cuộc di chuyển đã "xong" rồi. Module này buộc thứ tự ngược lại: phân tích đặc tính những gì bạn thực sự có, rồi nêu rõ mọi quyết định về engine, sort key, ánh xạ kiểu dữ liệu và trình tự — bằng văn bản — trước khi module 03 thực thi bất kỳ điều nào trong số đó.

Đây cũng là module mà các đối tác dễ bị dụ bỏ qua nhất. Script setup.sh của module 03 kiểm tra migration-plan.md và cảnh báo nếu file thiếu hoặc chưa hoàn chỉnh, nhưng nó không bao giờ chặn — bạn có thể lao tới mà không cần nó. Nếu làm vậy, bạn sẽ chạy module 03 để thực thi những quyết định bạn chưa từng đưa ra: bạn sẽ thấy fact_trips được dựng lên như một ReplacingMergeTree mà không biết tại sao lại là engine đó chứ không phải MergeTree thuần, thấy một khóa ORDER BY mà không biết nó được suy ra từ workload truy vấn như thế nào, thấy delete_insert và FINAL trong các config dbt mà không biết cách suy ra chúng cho một workload khác, và thấy các con số tăng tốc benchmark ở module 04 mà bạn không thể giải thích hay tái lập cho một khách hàng. 90 phút ở đây là thứ biến phần còn lại của workshop từ việc copy lệnh thành việc hiểu một cuộc di chuyển.

Khái niệm — bên dưới lớp vỏ

Mọi quyết định mà module này tạo ra đều thuộc một trong năm nhóm, mỗi nhóm có một worksheet:

• Họ engine — biến thể MergeTree nào phù hợp với mẫu ghi của từng bảng: MergeTree thuần cho dữ liệu chỉ thêm mới, ReplacingMergeTree cho các bảng nhận cập nhật qua CDC, AggregatingMergeTree cho các bảng rollup đã tổng hợp trước. Xem Các engine MergeTree.
• Khóa ORDER BY — ClickHouse không có index để thêm vào sau; sort key được chọn một lần, dựa trên workload truy vấn thực tế, không dựa trên primary key của bảng nguồn.
• Ánh xạ kiểu dữ liệu và khoảng cách phương ngữ — VARIANT, LATERAL FLATTEN và MERGE INTO của Snowflake không có tương đương trực tiếp trong ClickHouse và cần một dạng đã được dịch. QUALIFY là ngoại lệ: ClickHouse đã có mệnh đề QUALIFY native từ v24.5, nhưng lab này vẫn dạy cách viết lại bằng subquery vì cách đó mang đi được sang các phiên bản ClickHouse và các engine SQL cũ hơn hoặc không có QUALIFY. Xem Snowflake so với ClickHouse.
• Thiết kế model dbt — materialization, config engine, chiến lược incremental và vị trí đặt FINAL cho từng model. Xem dbt trên ClickHouse.
• Thứ tự các đợt — đối tượng nào có thể chuyển trước vì chưa có gì ở phía sau phụ thuộc vào nó, và đối tượng nào phải chờ.

Bước 1 — Phân tích đặc tính môi trường Snowflake

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/02-plan-and-design"
source ../01-setup-snowflake/.env
./scripts/01_profile_snowflake.sh

Script này chạy trên instance Snowflake của module 01 đang hoạt động và ghi ra profile_report.md với bốn phần: một bản kiểm kê đối tượng (mọi bảng, view, stream và task kèm số dòng và một mức độ phức tạp), 10 truy vấn tốn nhiều thời gian chạy tổng cộng nhất trong 7 ngày qua, thống kê bảng (số dòng, khoảng thời gian, tỷ lệ null, mức dùng VARIANT), và các khoảng cách tương thích schema được phát hiện tự động.

profile_report.md đã được gitignore — nó được sinh mới từ chính account Snowflake của bạn ở mỗi lượt chạy, nên nó đặc thù theo máy và không bao giờ được commit. Đừng mong tìm thấy nó trong một bản clone mới, và đừng tự commit nó.

Nếu ACCOUNT_USAGE chưa khả dụng (nó cần độ trễ lan truyền 1-3 giờ hoặc role ACCOUNTADMIN), script sẽ lùi về dùng INFORMATION_SCHEMA và ghi chú những gì nó không đo được. Bạn cũng có thể chạy scripts/02_query_history.sql bằng tay trong UI của Snowflake.

Bước 2 — Làm năm worksheet

Hãy làm năm worksheet theo thứ tự. Mỗi worksheet dạy một khái niệm, rồi có các bài tập trắc nghiệm cho chính workload NYC Taxi này. Mỗi câu trả lời được kiểm ngay khi bạn chọn, và mỗi worksheet có một nút "Copy as markdown" cho bạn bảng đã điền để dán vào kế hoạch di chuyển của mình.

• Worksheet 1: Chọn engine MergeTree — họ engine và engine cụ thể cho từng bảng
• Worksheet 2: Thiết kế sort key — ORDER BY được suy ra từ workload truy vấn
• Worksheet 3: Dịch schema — ánh xạ kiểu dữ liệu và dịch hàm
• Worksheet 4: Kế hoạch các đợt di chuyển — thứ tự phụ thuộc và phân đợt
• Worksheet 5: Thiết kế model dbt — materialization, engine, chiến lược incremental và vị trí đặt FINAL

Câu trả lời của bạn được lưu trong local storage của trình duyệt, không phải trong repo — chúng không theo bạn sang máy khác và không tồn tại sau khi bạn xóa dữ liệu site. Nếu bạn đổi laptop giữa workshop, bạn sẽ phải làm lại các worksheet ở máy đó.

Bước 3 — Điền kế hoạch di chuyển

Mở workshop_public/snowflake_migration_lab/02-plan-and-design/migration-plan.md và điền từng phần bằng các câu trả lời worksheet của bạn. Tài liệu có mười phần và một Completion Checklist với năm ô tick ở đầu:

- [ ] Engine selection: completed
- [ ] Sort key design: completed
- [ ] Schema translation: completed
- [ ] Migration wave plan: completed
- [ ] dbt model design: completed

Script setup.sh của module 03 kiểm tra checklist này và cảnh báo nếu nó chưa hoàn chỉnh, nhưng nó không chặn bạn đi tiếp. Dù vậy, hoàn thành nó là điều làm cho các quyết định của module 03 trở nên có ý nghĩa thay vì cảm giác tùy tiện.

Cách kiểm tra bạn đã xong

Bạn xong khi tất cả những điều sau đều đúng:

• Cả năm worksheet đều đạt điểm tối đa — dòng điểm ở cuối mỗi worksheet hiện N/N correct.
• workshop_public/snowflake_migration_lab/02-plan-and-design/migration-plan.md đã tick mọi ô trong Completion Checklist.
• profile_report.md tồn tại trên đĩa từ Bước 1 (đã gitignore, nên nó sẽ không xuất hiện trong git status).

Khi kế hoạch của riêng bạn đã được viết ra, hãy so nó với Ví dụ mẫu: một kế hoạch đã hoàn chỉnh — một kế hoạch được điền đầy đủ cho cùng workload này. Dùng nó để kiểm tra lại lập luận của bạn và để hiểu bất kỳ chỗ nào bạn chọn khác đi, chứ không phải như một khuôn mẫu để điền trước khi bạn tự suy nghĩ thấu đáo.

Trạng thái kết thúc

Một file migration-plan.md đã điền trên đĩa, mọi ô đã tick, được hậu thuẫn bởi năm worksheet đã hoàn thành. Producer Snowflake vẫn đang chạy — module 03 di chuyển dữ liệu ra khỏi một nguồn đang sống và đang chuyển động, và bước cutover của module 05 đo chính xác khoảng trống mà producer tạo ra giữa Snowflake và ClickHouse trong lúc di chuyển. Đừng dừng nó lúc này.