05 ทำเบนช์มาร์กและ cutover

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

การจัดเวลา

ประมาณ 45 นาทีกระจายไปในห้าขั้นตอน: เพิ่มแดชบอร์ดของ ClickHouse (ขั้นตอนที่ 1 ราวสอง สามนาทีผ่านการนำเข้าด้วยสคริปต์) รันเบนช์มาร์ก (ขั้นตอนที่ 2 เจ็ดคำสั่งค้นหา คูณ สามรอบ คูณสองเอนจิน — ไม่กี่นาที ส่วนใหญ่ไม่ต้องเฝ้า แต่สั้นพอที่จะเพียง เฝ้าดูก็ได้) ตัว cutover เอง (ขั้นตอนที่ 3 แบบมีการโต้ตอบ — หยุด producer ตามเก็บส่วนต่าง รีเฟรช dbt เริ่ม producer ของ ClickHouse แต่ละอย่างเป็นขั้นตอนที่ตั้งใจให้ทำตามลำดับ) การตรวจสอบความเท่าเทียมของข้อมูล (ขั้นตอนที่ 4 รวดเร็ว) และการรื้อถอน (ขั้นตอนที่ 5)

TODO: ไม่มีการระบุเวลาแยกตามขั้นตอนในเอกสารของแล็บเองนอกจากยอดรวม 45 นาที ของโมดูล — ยืนยันการแบ่งเวลาระหว่างการซ้อม โดยเฉพาะว่ารอบตามเก็บด้วย --resume ของขั้นตอนที่ 3 เร็วพออย่างเชื่อถือได้หรือไม่ (ระดับวินาทีถึงนาที ตามคำอธิบาย ของแล็บเอง) จนไม่ต้องมีเวลาสำรอง

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

• นี่คือโมดูลที่เปลี่ยน "เตรียมพร้อมแล้ว" ให้เป็น "ย้ายแล้ว" โมดูล 03 และ 04 พิสูจน์ ข้อมูลและไปป์ไลน์ โมดูลนี้พิสูจน์ตัวเลข (เบนช์มาร์ก) และพิสูจน์ว่า เส้นทางการเขียนย้ายได้จริง (cutover)
• ลำดับของ cutover คือเนื้อหาสำคัญที่นี่ ไม่ใช่เพียงพิธีการ: หยุด producer บน Snowflake รัน --resume เพื่อปิดช่องว่าง รีเฟรช dbt แล้วจึงเริ่ม producer ของ ClickHouse แต่ละ ขั้นตอนขึ้นอยู่กับขั้นตอนก่อนหน้า — การรันสลับลำดับคือวิธีที่ทำให้ความไม่เท่าเทียมของข้อมูล เกิดขึ้นอย่างเงียบ ๆ พอดี (ดูปัญหาที่พบบ่อย)
• พูดให้ชัดว่าเหตุใด --resume จึงเร็วในจุดนี้ ขณะที่การย้ายข้อมูลครั้งแรกในโมดูล 03 ไม่เร็ว: มันทำจุดอ้างอิงจาก max(pickup_at) ที่มีอยู่แล้วใน ClickHouse และดึงเฉพาะส่วนต่าง ดังนั้นช่องว่างที่เปิดค้างมาตั้งแต่โมดูล 01 จึงปิดได้ในระดับวินาทีถึงนาที ไม่ใช่การถ่ายโอน ก้อนใหญ่อีก 40-50 นาที
• โยงตัว cutover กลับไปที่สภาพว่างเปล่าของ agg_hourly_zone_trips จากโมดูล 04: มันจะมีข้อมูล เป็นครั้งแรกในแล็บทั้งหมดเมื่อ producer ของ ClickHouse เริ่มทำงาน เพราะตัวกรองของมัน ตรงกับแถวจาก producer ที่ทำงานสดเท่านั้น นี่คือคำตอบที่คุ้มค่าของคำถามที่ พาร์ตเนอร์ถามมาตั้งแต่โมดูล 04
• นี่เป็นโมดูลสุดท้ายก่อนแบบประเมินแบบเขียน — เตือนห้องให้เก็บ migration-plan.md และไฟล์ CSV ของเบนช์มาร์กไว้ในที่ที่เข้าถึงได้ หลังจากที่การรื้อถอน ในขั้นตอนที่ 5 ลบสภาพแวดล้อมคลาวด์ทั้งสองไปแล้ว

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

• พาร์ตเนอร์นำเข้าไฟล์ ZIP ของแดชบอร์ดด้วยมือผ่าน Superset UI แทนที่จะ รัน add_clickhouse_connection.sh ไฟล์ที่ส่งออกซึ่งคอมมิตไว้มีโฮสต์ของ ClickHouse ถูกปิดบังเป็น your-instance.clickhouse.cloud สคริปต์จะแก้ URI จาก .env ก่อนนำเข้า แต่การนำเข้าด้วยมือผ่าน UI จะใช้โฮสต์ตัวยึดตำแหน่งตามที่เป็นอยู่ และ การเชื่อมต่อจะเชื่อมต่อไม่ได้ ให้พวกเขาแก้การเชื่อมต่อภายหลังเพื่อชี้ไปที่ CLICKHOUSE_HOST และข้อมูลรับรองจริง
• พาร์ตเนอร์ข้ามรอบตามเก็บด้วย --resume ในขั้นตอนที่ 3 แล้วทำ cutover ไปเลย ClickHouse จะทิ้งแถวที่เข้ามาในช่องว่างระหว่างการย้ายข้อมูลครั้งแรกของโมดูล 03 กับ ช่วงที่ producer หยุดไปอย่างถาวร — เป็นความไม่เท่าเทียมของข้อมูลแบบเงียบ ๆ ขั้นตอน ที่ 4 มีการตรวจสอบความเท่าเทียมที่สร้างขึ้นมาเพื่อจับเรื่องนี้ แต่ก็เฉพาะถ้ามีการรันมัน พาร์ตเนอร์ที่ข้าม ไปเขียนสรุปเบนช์มาร์กเลยโดยไม่รันขั้นตอนที่ 4 จะไม่สังเกตเห็นแถวที่หายไป
• producer บน Snowflake ถูกหยุดไปแล้วตั้งแต่โมดูล 01 หรือ 02 โดย พาร์ตเนอร์ที่อยากเก็บกวาด Cutover จะไม่มีอะไรให้ใช้วัดช่องว่างเทียบกัน หาก producer ไม่เคยทำงานต่อเนื่อง — เรื่องนี้ทำให้การสาธิต cutover ทั้งหมดพัง ไม่ใช่แค่ขั้นตอน นี้ หากเกิดขึ้นแล้ว วิธีแก้ที่ตรงไปตรงมาคือเริ่ม producer ใหม่ ปล่อยให้เขียนสัก ไม่กี่นาทีเพื่อสร้างช่องว่างจริง แล้วจึงดำเนินต่อ ไม่มีทางย้อนกลับไป สาธิตช่องว่างที่ไม่เคยเปิดอยู่ได้
• การตรวจสอบความเท่าเทียมล้มเหลว (ผลต่างมากกว่า 0.01%) รันรอบตามเก็บอีกครั้ง แล้วตรวจใหม่: python scripts/02_migrate_trips.py --resume แล้ว bash scripts/01_verify_migration.sh
• Superset แสดง 403 Forbidden คุกกี้เซสชันหมดอายุ — ออกจากระบบ เข้าสู่ระบบใหม่ ที่ http://localhost:8088 แล้วรัน superset/add_clickhouse_connection.sh อีกครั้ง
• เบนช์มาร์กแสดง N/A สำหรับคำสั่งค้นหาหนึ่ง ซึ่งบ่อยที่สุดคือ Q7 สคริปต์เบนช์มาร์ก เชื่อมต่อกับ ClickHouse ไม่ได้ — ยืนยันว่า CLICKHOUSE_HOST ถูกตั้งค่าแล้ว (source .clickhouse_state) และบริการกำลังทำงานอยู่

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

• การตรวจสอบความเท่าเทียมล้มเหลว: รัน python scripts/02_migrate_trips.py --resume ใหม่ แล้ว bash scripts/01_verify_migration.sh
• ต้องย้อน cutover กลับ (cutover ย้อนกลับ): docker stop nyc_taxi_ch_producer แล้ว นำ producer บน Snowflake กลับขึ้นมาจาก workshop_public/snowflake_migration_lab/01-setup-snowflake/superset ด้วย docker-compose --env-file ../.env up -d producer
• รีเซ็ตสภาพแวดล้อมทั้งหมด: source .env && ./teardown.sh จาก workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/ ทำลายบริการ ClickHouse Cloud และคอนเทนเนอร์ producer ของ ClickHouse (หาก cutover เกิดขึ้นแล้ว) ส่วน Snowflake ไม่ถูกแตะโดยสคริปต์นี้ — รื้อถอนแยกกันด้วย source .env && ./teardown.sh จาก workshop_public/snowflake_migration_lab/01-setup-snowflake/
• ก่อนรันการรื้อถอนใดก็ตาม ยืนยันว่า migration-plan.md และไฟล์ CSV ของเบนช์มาร์ก (scripts/benchmark_results_<timestamp>.csv) ถูกบันทึกไว้ในที่ที่เข้าถึงได้ — สภาพแวดล้อม คลาวด์ทั้งสองจะหายไปหลังจากนี้ และโมดูล 06 ต้องใช้สองไฟล์นั้นพอดี ไม่ต้องใช้อะไรอื่น