02 วางแผนและออกแบบ

จุดเริ่มต้น

โมดูล 01 เสร็จแล้ว: Snowflake สร้างครบแล้ว, สตรีม CDC และ task ตามกำหนดเวลาทั้งสอง กำลังทำงาน และที่สำคัญที่สุด — producer การเดินทางยังเขียนข้อมูลราว 60 การเดินทาง/นาที เข้าไปใน TRIPS_RAW ปล่อยให้มันทำงานต่อไป โมดูลนี้อ่านจาก Snowflake เท่านั้น กันเวลาไว้ ประมาณ 90 นาที และเครดิต Snowflake ราว 0.5 เครดิต

ทำไม

เหตุผลที่พบบ่อยที่สุดที่การย้ายระบบมา ClickHouse ให้ผลไม่ถึงเป้าไม่ใช่ปัญหาการจูน — มันเป็น ปัญหาสถาปัตยกรรม ทีมย้ายข้อมูลก่อนแล้วค่อยคิดเรื่องการออกแบบทีหลัง พอถึงเวลาที่พวกเขา ตระหนักว่าเอนจิน MergeTree ที่ผิดกำลังให้ผลลัพธ์ที่ไม่ถูกต้องอย่างเงียบ ๆ หรือว่า sort key ที่ คัดลอกมาจากสคีมาต้นทางเพิกเฉยต่อรูปแบบการคิวรีที่เกิดขึ้นจริง การย้ายระบบก็ "เสร็จ" ไปแล้ว โมดูลนี้บังคับลำดับตรงกันข้าม: โปรไฟล์สิ่งที่คุณมีอยู่จริง แล้วจึงระบุทุกการตัดสินใจเรื่องเอนจิน, sort key, การแมปชนิดข้อมูล และการจัดลำดับให้ชัดเจน — เป็นลายลักษณ์อักษร — ก่อนที่โมดูล 03 จะดำเนินการสิ่งใด

นี่ยังเป็นโมดูลที่พาร์ตเนอร์อยากข้ามที่สุดด้วย setup.sh ของโมดูล 03 ตรวจหา migration-plan.md และเตือนถ้ามันหายไปหรือไม่สมบูรณ์ แต่มันไม่เคยขัดขวาง — คุณลุยต่อ ได้โดยไม่มีมัน ถ้าคุณทำอย่างนั้น คุณจะรันโมดูล 03 โดยดำเนินการตามการตัดสินใจที่คุณไม่เคย ทำ: คุณจะเห็น fact_trips โผล่มาเป็น ReplacingMergeTree โดยไม่รู้ว่าทำไมต้องเป็นเอนจิน นั้นและไม่ใช่ MergeTree ธรรมดา, เห็นคีย์ ORDER BY โดยไม่รู้ว่ามันถูกอนุมานมาจาก เวิร์กโหลดคิวรีอย่างไร, เห็น delete_insert และ FINAL ในคอนฟิก dbt โดยไม่รู้ว่าจะอนุมาน มันสำหรับเวิร์กโหลดอื่นได้อย่างไร และเห็นตัวเลขความเร็วที่เพิ่มขึ้นจากเบนช์มาร์กในโมดูล 04 ที่คุณอธิบายหรือทำซ้ำให้ลูกค้าดูไม่ได้ 90 นาทีที่นี่คือสิ่งที่เปลี่ยนส่วนที่เหลือของเวิร์กช็อป จากการคัดลอกคำสั่งให้เป็นการเข้าใจการย้ายระบบ

แนวคิด — เบื้องหลังการทำงาน

ทุกการตัดสินใจที่โมดูลนี้ผลิตออกมาจัดอยู่ในหนึ่งในห้าหมวด แต่ละหมวดมีใบงานของตัวเอง:

• ตระกูลเอนจิน — MergeTree แบบใดเหมาะกับรูปแบบการเขียนของแต่ละตาราง: MergeTree ธรรมดาสำหรับการเขียนต่อท้ายเท่านั้น, ReplacingMergeTree สำหรับตารางที่ ได้รับการอัปเดตผ่าน CDC, AggregatingMergeTree สำหรับ rollup ที่รวมค่าไว้ล่วงหน้า ดู เอนจิน MergeTree
• คีย์ ORDER BY — ClickHouse ไม่มีอินเด็กซ์ที่จะเพิ่มภายหลังได้ sort key ถูกเลือก ครั้งเดียว จากเวิร์กโหลดคิวรีที่เกิดขึ้นจริง ไม่ใช่จาก primary key ของตารางต้นทาง
• การแมปชนิดข้อมูลและช่องว่างของสำเนียงภาษา — VARIANT, LATERAL FLATTEN และ MERGE INTO ของ Snowflake ไม่มีสิ่งเทียบเท่าโดยตรงใน ClickHouse และต้องมีรูปแบบที่แปลแล้ว QUALIFY เป็นข้อยกเว้น: ClickHouse มี clause QUALIFY ในตัวมาตั้งแต่ v24.5 แต่แล็บนี้ ยังสอนการเขียนใหม่เป็น subquery เพราะมันพอร์ตไปใช้กับ ClickHouse เวอร์ชันและเอนจิน SQL ที่เก่ากว่าหรือไม่มี QUALIFY ได้ ดู Snowflake เทียบกับ ClickHouse
• การออกแบบโมเดล dbt — materialization, คอนฟิกเอนจิน, กลยุทธ์ incremental และการวาง FINAL ในแต่ละโมเดล ดู dbt บน ClickHouse
• การจัดลำดับระลอก — อ็อบเจกต์ใดย้ายได้ก่อนเพราะยังไม่มีอะไรปลายน้ำพึ่งพามัน และ อ็อบเจกต์ใดต้องรอ

ขั้นที่ 1 — โปรไฟล์สภาพแวดล้อม 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

สิ่งนี้รันกับอินสแตนซ์ Snowflake ของโมดูล 01 ที่ทำงานอยู่ และเขียน profile_report.md ที่มีสี่ส่วน: บัญชีรายการอ็อบเจกต์ (ทุกตาราง, view, สตรีม และ task พร้อมจำนวนแถวและ เกรดความซับซ้อน), 10 คิวรีอันดับต้นตามเวลาที่ใช้ไปทั้งหมดในช่วง 7 วันที่ผ่านมา, สถิติของ ตาราง (จำนวนแถว, ช่วงวันที่, อัตราค่าว่าง, การใช้ VARIANT) และช่องว่างความเข้ากันได้ของ สคีมาที่ตรวจพบอัตโนมัติ

profile_report.md ถูก gitignore ไว้ — มันถูกสร้างขึ้นใหม่จากบัญชี Snowflake ของคุณเองใน การรันแต่ละครั้ง จึงเจาะจงกับเครื่องและไม่เคยถูก commit อย่าคาดหวังว่าจะเจอมันในโคลนใหม่ และอย่าพยายาม commit มันเอง

หาก ACCOUNT_USAGE ยังใช้ไม่ได้ (ต้องรอการแพร่กระจาย 1-3 ชั่วโมง หรือต้องใช้ role ACCOUNTADMIN) สคริปต์จะย้อนไปใช้ INFORMATION_SCHEMA และบันทึกไว้ว่าอะไรที่มันวัด ไม่ได้ คุณยังรัน scripts/02_query_history.sql ด้วยมือใน UI ของ Snowflake ได้ด้วย

ขั้นที่ 2 — ทำใบงานทั้งห้า

ทำใบงานทั้งห้าตามลำดับ แต่ละใบสอนแนวคิดหนึ่ง แล้วมีแบบฝึกหัดปรนัยสำหรับเวิร์กโหลด NYC Taxi จริง ทุกคำตอบจะถูกตรวจทันทีที่คุณเลือก และแต่ละใบงานมีปุ่ม "Copy as markdown" ที่ให้ตารางที่กรอกแล้วเพื่อวางลงในแผนการย้ายระบบของคุณ

• ใบงานที่ 1: การเลือกเอนจิน MergeTree — ตระกูลเอนจินและการเลือกเอนจินต่อตาราง
• ใบงานที่ 2: การออกแบบ sort key — ORDER BY ที่อนุมานจากเวิร์กโหลดคิวรี
• ใบงานที่ 3: การแปลงสคีมา — การแมปชนิดข้อมูลและการแปลงฟังก์ชัน
• ใบงานที่ 4: แผนระลอกการย้ายระบบ — การจัดลำดับตาม dependency และการกำหนดระลอก
• ใบงานที่ 5: การออกแบบโมเดล dbt — materialization, เอนจิน, กลยุทธ์ incremental และการวาง FINAL

คำตอบของคุณถูกบันทึกใน local storage ของเบราว์เซอร์ ไม่ใช่ในรีโป — มันไม่ตามคุณไปยัง เครื่องอื่นและไม่รอดจากการล้างข้อมูลเว็บไซต์ หากคุณเปลี่ยนแล็ปท็อปกลางเวิร์กช็อป คุณจะต้อง ทำใบงานใหม่ที่เครื่องนั้น

ขั้นที่ 3 — กรอกแผนการย้ายระบบ

เปิด workshop_public/snowflake_migration_lab/02-plan-and-design/migration-plan.md และกรอก แต่ละส่วนโดยใช้คำตอบจากใบงานของคุณ เอกสารนี้มีสิบส่วนและมี Completion Checklist ที่มี ช่องติ๊กห้าช่องอยู่ด้านบน:

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

setup.sh ของโมดูล 03 ตรวจ checklist นี้และเตือนถ้ามันไม่สมบูรณ์ แต่มันไม่ขัดขวางคุณจาก การไปต่อ การทำให้เสร็จอยู่ดีคือสิ่งที่ทำให้การตัดสินใจในโมดูล 03 มีเหตุผล ไม่ใช่รู้สึกเหมือน สุ่มมา

วิธีตรวจสอบว่าคุณทำเสร็จแล้ว

คุณเสร็จแล้วเมื่อทุกข้อต่อไปนี้เป็นจริง:

• ใบงานทั้งห้าใบแสดงคะแนนเต็ม — บรรทัดคะแนนที่ด้านล่างของแต่ละใบอ่านว่า N/N correct
• workshop_public/snowflake_migration_lab/02-plan-and-design/migration-plan.md มีช่องติ๊กทุกช่องใน Completion Checklist ติ๊กแล้ว
• profile_report.md มีอยู่บนดิสก์จากขั้นที่ 1 (ถูก gitignore ไว้ จึงไม่ปรากฏใน git status)

เมื่อเขียนแผนของคุณเองเสร็จแล้ว ให้เทียบกับ ตัวอย่างที่ทำไว้: แผนที่กรอกเสร็จ — แผนที่กรอกครบสำหรับเวิร์กโหลดเดียวกันนี้ ใช้มันเพื่อตรวจสอบเหตุผลของคุณและเพื่อทำความ เข้าใจจุดใดก็ตามที่คุณเลือกต่างออกไป ไม่ใช่ใช้เป็นเทมเพลตให้กรอกก่อนที่คุณจะได้คิดด้วย ตัวเอง

สถานะปลายทาง

migration-plan.md ที่กรอกแล้วอยู่บนดิสก์ ทุกช่องติ๊กติ๊กครบ หนุนด้วยใบงานที่ทำเสร็จห้าใบ producer ของ Snowflake ยังทำงานอยู่ — โมดูล 03 ย้ายข้อมูลออกจากต้นทางที่ยังมีชีวิตและ เคลื่อนไหว และการตัดสวิตช์ในโมดูล 05 วัดช่วงห่างที่แม่นยำซึ่ง producer สร้างขึ้นระหว่าง Snowflake กับ ClickHouse ตอนย้ายระบบ อย่าหยุดมันตอนนี้