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

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 02 Lập kế hoạch và thiết kế.

Thời lượng

Khoảng 90 phút, và gần như không có phần nào tự chạy. Đây là module duy nhất được xây quanh việc làm phiếu bài tập cá nhân hoặc theo cặp, chứ không phải các script chạy ở nền. Bước 1 (script profiling) là phần tự động duy nhất và xong trong vài phút; mọi thứ còn lại — năm phiếu bài tập ở Bước 2 và migration-plan.md ở Bước 3 — là nơi 90 phút thực sự tiêu tốn. Đừng xếp giờ nghỉ vào giữa module này; nếu lớp cần nghỉ, hãy nghỉ ở ranh giới với module 03, không phải giữa lúc đang làm phiếu bài tập.

Nội dung trình bày

• Mở đầu bằng việc nói rõ module này không phải cái gì: nó không phải một khoảng chờ trước khi migration "thật" diễn ra ở module 03. Lý do phổ biến nhất khiến các cuộc migration sang ClickHouse không đạt hiệu năng mong đợi là vấn đề kiến trúc, không phải vấn đề tuning — các đội chuyển dữ liệu trước rồi mới thiết kế sau.
• Hãy nói điều này thẳng thắn, vì đó là lập luận mạnh nhất bạn có để biện minh cho 90 phút: đây là module mà các đối tác dễ bị dụ bỏ qua nhất, bởi vì setup.sh của module 03 chỉ cảnh báo khi thiếu hoặc chưa hoàn chỉnh migration-plan.md — nó không bao giờ chặn.
• Đi qua chuyện gì xảy ra nếu một đối tác vẫn bỏ qua nó: về mặt máy móc họ vẫn sẽ thành công ở module 03 — fact_trips vẫn được tạo ra dưới dạng ReplacingMergeTree, dữ liệu vẫn di chuyển — nhưng họ sẽ không biết vì sao là engine đó mà không phải MergeTree thuần, sẽ không biết khóa ORDER BY được suy ra từ workload truy vấn như thế nào, sẽ không nhận ra delete_insert và FINAL trong các cấu hình dbt, và sẽ không thể giải thích hay tái lập các mức tăng tốc trong benchmark của module 05 cho một khách hàng.
• Chỉ chỉ vào trang tham chiếu Worked Example sau khi các đối tác đã tự thử làm kế hoạch của mình — đó là công cụ kiểm tra đối chiếu, không phải một template để sao chép trước khi tự suy nghĩ cho hết.

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

• ACCOUNT_USAGE không khả dụng khi script profiling ở Bước 1 chạy. Nó cần hoặc một khoảng chờ lan truyền 1-3 giờ sau khi tài khoản Snowflake được tạo, hoặc quyền ACCOUNTADMIN. Script tự động chuyển sang dùng INFORMATION_SCHEMA và ghi lại những gì nó không đo được — đây là cơ chế giảm cấp có kiểm soát, không phải crash, nhưng một đối tác có thể không nhận ra là cơ chế dự phòng đã kích hoạt. Hãy chỉ họ tới scripts/02_query_history.sql, có thể chạy thủ công trong Snowflake UI, nếu bản profile tự động trông sơ sài.
• Một đối tác coi Completion Checklist trong migration-plan.md là không bắt buộc. Nó bắt buộc — setup.sh của module 03 đọc nó, và một ô chưa tick là dấu hiệu cho thấy module này đã bị bỏ qua về mặt nội dung dù bản thân tệp có tồn tại.
• TODO: không có mục Troubleshooting nào trong README của chính module này, khác với module 01 và 03. Hãy điền vào đây từ buổi tổng duyệt, sau khi phần phiếu bài tập đã được chạy với một lớp học thật.

Các bước reset

• profile_report.md (đầu ra của Bước 1) được gitignore và được tạo lại mới từ tài khoản Snowflake trực tiếp của chính đối tác ở mỗi lần chạy — nếu nó trông cũ hoặc sai, chỉ cần chạy lại ./scripts/01_profile_snowflake.sh. Không có gì phải teardown.
• Năm phiếu bài tập được điền trực tiếp trên site, với đáp án được chấm ngay lập tức và lưu trong trình duyệt của người tham gia (localStorage), không lưu trong repo. migration-plan.md vẫn được sửa trực tiếp trong repo — module này không cấp phát gì ở cả hai cloud, nên không có teardown.sh và không có cờ setup nào để dùng.
• Nếu một người tham gia làm phiếu bài tập rơi vào trạng thái xấu, hãy chỉ họ tới nút "Clear answers" của chính phiếu đó thay vì một lệnh git checkout — câu trả lời của họ chưa bao giờ đi vào git, nên checkout cũng chẳng giúp được gì.