03 จัดเตรียมและย้ายข้อมูล

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

การจัดเวลา

รวมประมาณ 60 นาที และรูปทรงของเวลาสำคัญกว่าตัวเลขรวม: ราว 10-15 นาที เป็นงานที่ต้องลงมือทำ (ขั้นตอนที่ 1 จัดเตรียมบริการ ClickHouse Cloud ผ่าน Terraform ราว 2-3 นาที ขั้นตอนที่ 2 สร้าง trips_raw หยอดข้อมูลอ้างอิงโซน และรัน dbt run ครั้งแรกที่ยังว่างเปล่า อีกไม่กี่นาที) ตามด้วยการถ่ายโอนข้อมูลแบบไม่ต้องเฝ้า 40-50 นาที (สคริปต์ย้ายข้อมูลของขั้นตอนที่ 3 ซึ่งย้าย 50 ล้านแถวที่ราว 20K แถวต่อวินาที)

นี่คือข้อเท็จจริงด้านการจัดตารางที่สำคัญที่สุดเพียงข้อเดียวในเวิร์กช็อปทั้งหมด: เมื่อขั้นตอนที่ 3 เริ่มแล้ว จะไม่มีอะไรให้ห้องทำเป็นเวลาเกือบหนึ่งชั่วโมง เริ่มมัน แล้วพักที่จุดนี้ หรือใช้ช่วงรอกับเนื้อหาแนวการบรรยายของโมดูล 02 ที่ห้อง ยังไม่มีเวลาฟัง หรือช่วงถาม-ตอบสดเกี่ยวกับการตัดสินใจใน migration-plan.md ของพาร์ตเนอร์ อย่า จัดช่วงพักไว้ที่อื่นในโมดูลนี้ — จัดไว้ที่นี่ อย่างตั้งใจ

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

• เหตุผลของโมดูลนี้เองว่าเหตุใดแล็บนี้จึงย้ายข้อมูลด้วยสคริปต์ Python แทนที่จะใช้ ตัวเชื่อมต่อดั้งเดิม: Snowflake ไม่ใช่แหล่งข้อมูลต้นทางที่ ClickPipes รองรับ (Kafka, S3, Kinesis และ CDC ของ Postgres/MySQL รองรับ แต่ Snowflake ไม่) และทางเลือกทุกทาง (การส่งออกไปยัง S3, Snowflake -> Kafka -> ClickHouse) แลกการตั้งค่าระดับแล็บกับโครงสร้างพื้นฐาน ที่ไม่เกี่ยวกับตัวการย้ายข้อมูลเลย — บักเก็ต S3 หนึ่งอัน บทบาท IAM หนึ่งบทบาท คลัสเตอร์ Kafka หนึ่งคลัสเตอร์
• จุดขายจริงของสคริปต์ Python ที่คุ้มค่าจะระบุออกมาให้ชัด: ไม่ต้องมีบัญชี AWS เป็นระบบที่จบในตัวเอง (แพ็กเกจใหม่ทั้งสองอยู่ใน venv เดียวกับ dbt) ทำต่อจากที่ค้างได้ ผ่าน --resume โดยอ้างจุดอ้างอิง max(pickup_at) และโปร่งใสพอที่ พาร์ตเนอร์จะอ่านการแมปคอลัมน์ได้ แทนที่จะคลิกผ่านตัวช่วยแบบ UI
• ระบุทางเลือกสำหรับระบบจริงอย่างตรงไปตรงมา: เมื่อเกินราว 500M แถว หรือในกรณีที่ ต้นทุนของ warehouse จากการสแกนทั้งตารางมีความสำคัญ การส่งออกไปยัง S3 เป็นทางเลือกที่ดีกว่า — ส่งออก แบบขนาน โหลดแบบขนาน สคริปต์ Python เหมาะกับขนาดระดับแล็บ ไม่ใช่คำแนะนำ ที่ใช้ได้ทุกกรณี
• เกริ่นถึงช่องว่างของการย้ายข้อมูลตั้งแต่ตอนนี้ แม้ว่าโมดูล 05 จะเป็นตัวปิดมัน: producer บน Snowflake เขียนข้อมูลต่อเนื่องตลอดเวลาที่ขั้นตอนที่ 3 รัน ดังนั้น ClickHouse จึงตามหลัง Snowflake อยู่ ราวเท่ากับความยาวของการถ่ายโอน ช่องว่างนั้นเป็นเรื่องที่คาดไว้แล้วในจุดนี้ และเป็นสิ่งที่ cutover ของโมดูล 05 ถูกสร้างขึ้นมาเพื่อปิดและวัดโดยเฉพาะ — พูดเรื่องนี้ก่อนที่จะมีใครถาม ว่าการรอ 40-50 นาทีนั้น "ทำให้ข้อมูลสูญเปล่า" หรือไม่

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

• dbt run ครั้งแรกในขั้นตอนที่ 2 ล้มเหลวด้วย Could not find profile named 'nyc_taxi_ch' ไม่มีอะไรในแล็บที่สร้างโปรไฟล์ dbt nyc_taxi_ch ของ ClickHouse ให้โดยอัตโนมัติ แม้ว่า dbt_project.yml จะต้องใช้มัน บทเรียนของผู้เรียน 03 จัดเตรียมและย้ายข้อมูล ครอบคลุมเรื่องนี้: หัวข้อ "Configure the dbt profile" ของขั้นตอนที่ 2 พาพาร์ตเนอร์ผ่านการผสาน บล็อก nyc_taxi_ch: เข้าไปใน ~/.dbt/profiles.yml ที่มีอยู่ก่อนที่ dbt run นี้ จะรัน หากพาร์ตเนอร์ข้ามหรือคัดลอกขั้นตอนนั้นผิด ให้ชี้พวกเขากลับไปที่ตรงนั้น แทนที่จะ อธิบายวิธีแก้ซ้ำที่นี่
• การยืนยันตัวตนของ Terraform ล้มเหลวด้วย 401 Unauthorized ตรวจสอบ CLICKHOUSE_TOKEN_KEY และ CLICKHOUSE_TOKEN_SECRET — ทั้งคู่อยู่ใน ClickHouse Cloud UI ใต้ Settings -> API keys และต้องมีขอบเขตสิทธิ์ Admin
• สคริปต์ย้ายข้อมูลล้มเหลวกลางทาง รันใหม่ด้วย --resume มันทำจุดอ้างอิงจาก max(pickup_at) ที่มีอยู่แล้วใน ClickHouse และข้ามแถวที่โหลดไปแล้ว ดังนั้นการเริ่มใหม่ จะไม่เคยทำให้เกิดการโหลดที่ไม่สมบูรณ์และกู้คืนไม่ได้
• สคริปต์ย้ายข้อมูลเชื่อมต่อไม่ได้เลย ยืนยันว่าตัวแปรสภาพแวดล้อมของ Snowflake และ ClickHouse ทุกตัวถูกตั้งค่าไว้ (echo $SNOWFLAKE_ORG $SNOWFLAKE_ACCOUNT $SNOWFLAKE_USER $SNOWFLAKE_PASSWORD และ echo $CLICKHOUSE_HOST $CLICKHOUSE_PASSWORD) แล้ว source .env && source .clickhouse_state และลองใหม่
• dbt run ล้มเหลวด้วย Connection refused หรือ Unknown host CLICKHOUSE_HOST ยัง ไม่ได้ถูกตั้งค่าในเชลล์ปัจจุบัน — source .clickhouse_state จาก workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/ แล้วลองใหม่

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

• สคริปต์ย้ายข้อมูลถูกขัดจังหวะ: python scripts/02_migrate_trips.py --resume จะทำต่อ จากจุดอ้างอิง แทนที่จะเริ่มการถ่ายโอน 50M แถวใหม่ทั้งหมด
• บริการ ClickHouse Cloud ต้องการการสร้างใหม่ให้สะอาด: source .env && ./teardown.sh จาก workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/ (ทำลายบริการ และคอนเทนเนอร์ producer ของ ClickHouse หาก cutover เกิดขึ้นแล้ว) แล้ว ./setup.sh อีกครั้ง วิธีนี้ไม่แตะฝั่ง Snowflake ของโมดูล 01 — ฝั่งนั้นมี teardown.sh ของตัวเองอยู่ใน workshop_public/snowflake_migration_lab/01-setup-snowflake/
• การรีเซ็ตทั้งหมดมีต้นทุนสูงในจุดนี้: การย้ายข้อมูลใหม่ต้องจ่ายเวลาถ่ายโอน 40-50 นาที ทั้งหมดอีกครั้ง เลือกใช้ --resume หรือการแก้ไขแบบเจาะจงแทนการรื้อถอนทั้งหมด เมื่อ ตัวบริการ ClickHouse เองยังทำงานได้ดีอยู่