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

คู่มือประกอบสำหรับผู้สอนของบทเรียนผู้เรียน 02 วางแผนและออกแบบ

การจัดเวลา

ประมาณ 90 นาที และแทบไม่มีส่วนใดที่รันเองได้ นี่เป็นโมดูลเดียวที่สร้างขึ้นรอบงานใบงาน แบบเดี่ยวหรือจับคู่ ไม่ใช่สคริปต์ที่รันอยู่เบื้องหลัง ขั้นตอนที่ 1 (สคริปต์ทำโปรไฟล์) เป็นส่วนเดียวที่เป็นระบบอัตโนมัติและเสร็จในไม่กี่นาที ทุกอย่างที่เหลือ — ใบงานห้าใบของขั้นตอนที่ 2 และ migration-plan.md ของขั้นตอนที่ 3 — คือที่ที่ เวลา 90 นาทีหมดไปจริง ๆ อย่าวางช่วงพักไว้ภายในโมดูลนี้ หากห้องต้องการพัก ให้พักที่รอยต่อกับโมดูล 03 ไม่ใช่ระหว่างกลางใบงาน

แนวการบรรยาย

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

ปัญหาที่พบบ่อย

• ACCOUNT_USAGE ใช้ไม่ได้เมื่อสคริปต์ทำโปรไฟล์ของขั้นตอนที่ 1 รัน มันต้องรอ ช่วงหน่วงการแพร่กระจายข้อมูล 1-3 ชั่วโมงหลังจากสร้างบัญชี Snowflake หรือต้องมีบทบาท ACCOUNTADMIN สคริปต์จะถอยไปใช้ INFORMATION_SCHEMA โดยอัตโนมัติและ ระบุว่าอะไรที่วัดไม่ได้ — นี่คือการลดทอนอย่างนุ่มนวล ไม่ใช่การพัง แต่ พาร์ตเนอร์อาจไม่สังเกตว่าเกิดการถอยไปใช้ทางเลือกสำรอง ชี้ให้พวกเขาไปที่ scripts/02_query_history.sql ซึ่งรันด้วยมือได้ใน Snowflake UI หากโปรไฟล์อัตโนมัติดูข้อมูลบางเกินไป
• พาร์ตเนอร์มองว่ารายการตรวจสอบความสมบูรณ์ใน migration-plan.md เป็นสิ่งที่ทำหรือไม่ก็ได้ มัน ไม่ใช่ — setup.sh ของโมดูล 03 อ่านมัน และช่องที่ไม่ได้ติ๊กคือสัญญาณว่าโมดูล นี้ถูกข้ามในเนื้อหาแม้ว่าไฟล์จะมีอยู่ก็ตาม
• TODO: ไม่มีหัวข้อการแก้ปัญหาใน README ของโมดูลนี้เอง ต่างจากโมดูล 01 และ 03 เติมส่วนนี้จากการซ้อมเมื่อได้ลองรันส่วนใบงานกับ ห้องเรียนจริงแล้ว

ขั้นตอนการรีเซ็ต

• profile_report.md (ผลลัพธ์ของขั้นตอนที่ 1) ถูก gitignore ไว้และสร้างขึ้นใหม่สด ๆ จาก บัญชี Snowflake ที่ใช้งานจริงของพาร์ตเนอร์ในทุกครั้งที่รัน — หากดูเก่าหรือผิด ก็เพียง รัน ./scripts/01_profile_snowflake.sh ใหม่ ไม่มีอะไรต้องรื้อถอน
• ใบงานทั้งห้าใบกรอกบนไซต์ โดยคำตอบถูกตรวจให้คะแนนทันทีและ บันทึกไว้ในเบราว์เซอร์ของผู้เข้าร่วม (localStorage) ไม่ใช่ในรีโป ส่วน migration-plan.md ยังแก้ไขในที่ตั้งเดิมในรีโป — โมดูลนี้ไม่ได้จัดเตรียมสิ่งใดในคลาวด์ทั้งสอง ดังนั้นจึงไม่มี teardown.sh และไม่มีแฟล็กของ setup ให้ใช้
• หากผู้เข้าร่วมทำให้ใบงานอยู่ในสภาพที่ผิดพลาด ให้ชี้พวกเขาไปที่ตัวควบคุม "Clear answers" ของใบงานนั้นเอง แทนที่จะใช้ git checkout — คำตอบของพวกเขาไม่เคยแตะ git ดังนั้น checkout จึงไม่ช่วยอะไร