01 สภาพแวดล้อมต้นทาง

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

การจัดเวลา

รวมประมาณ 45 นาที ขั้นตอนที่ 2 (./setup.sh) เป็นช่วงเดียวที่รันเองโดยไม่ต้องเฝ้า — ราว 5-10 นาที ซึ่งส่วนใหญ่คือการหยอดข้อมูลสังเคราะห์ด้วย TABLE(GENERATOR) — และคุ้มค่าที่จะ พูดคุยไปด้วยมากกว่าจะเฝ้าดูอย่างเงียบ ๆ มันเป็นจังหวะที่ดีสำหรับแนวการบรรยายด้านล่างนี้ เวลาที่เหลือ (ขั้นตอนที่ 1 และ 3-5) ต้องมีพาร์ตเนอร์อยู่ที่คีย์บอร์ด: ตั้งค่าข้อมูลรับรอง ตรวจสอบว่า producer และ Superset ขึ้นมาแล้ว เริ่มลูปรีเฟรช dbt และอ่านผ่านคำสั่งค้นหาทั้งเจ็ด

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

• โมดูลนี้มีอยู่เพื่อสร้างต้นทางที่คุ้มค่าต่อการย้าย: คอลัมน์ VARIANT สตรีม CDC หนึ่งสตรีม งานตามกำหนดเวลาสองงาน และชั้น BI ที่อ่านอยู่บนทั้งหมดนั้น — ไม่ใช่ตาราง ของเล่น ทุกสิ่งเหล่านั้นจะกลายเป็นการตัดสินใจเรื่องการย้ายข้อมูลที่เฉพาะเจาะจงในโมดูล 02
• เดินผ่านรูปทรง Medallion หนึ่งครั้งบนไดอะแกรม: RAW -> STAGING -> ANALYTICS ภายใน NYC_TAXI_DB และสองอ็อบเจ็กต์ที่ทำให้มันเคลื่อนไหวได้โดยไม่ขึ้นกับ dbt — TRIPS_CDC_STREAM และงานตามกำหนดเวลาสองงาน
• ชี้ให้เห็นคลังคำสั่งค้นหา (ขั้นตอนที่ 5) แม้ว่าพาร์ตเนอร์จะยังไม่แปลงคำสั่งเหล่านั้น จนถึงโมดูล 02 — ทั้งเจ็ดคำสั่งมีคอมเมนต์ที่ร่างฝั่ง ClickHouse ไว้แล้ว ดังนั้น พาร์ตเนอร์จึงเริ่มจับรูปแบบได้ตั้งแต่ตอนนี้
• ระบุให้ชัด และย้ำอีกครั้งเมื่อจบโมดูล: ปล่อยให้ producer และลูปรีเฟรช dbt ทำงานต่อไป Cutover ของโมดูล 05 วัดช่องว่างที่แม่นยำซึ่ง producer สร้างขึ้นระหว่าง Snowflake กับ ClickHouse ในระหว่างการย้ายข้อมูล และพาร์ตเนอร์ที่เก็บกวาดด้วยการหยุดมันที่นี่จะ ทำลายการสาธิตนั้นอย่างเงียบ ๆ ในอีกสามโมดูลถัดไป

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

• terraform init ล้มเหลวด้วยข้อผิดพลาดของ provider ยืนยันว่า Terraform >= 1.6 และ เครื่องเข้าถึงอินเทอร์เน็ตไปยัง Terraform registry ได้
• snowsql ถูกปฏิเสธการเชื่อมต่อ ตรวจสอบ SNOWFLAKE_ORG และ SNOWFLAKE_ACCOUNT ทดสอบ โดยตรงด้วย snowsql -a ${SNOWFLAKE_ORG}-${SNOWFLAKE_ACCOUNT} -u ${SNOWFLAKE_USER}
• dbt run ล้มเหลวด้วย relation not found รัน ./setup.sh --skip-seed ก่อน — มัน สร้างโครงสร้างฐานข้อมูล — และยืนยันว่า profiles.yml ชี้ไปที่ NYC_TAXI_DB
• Superset แสดง connection refused Superset ต้องใช้เวลาราว 60 วินาทีหลัง docker-compose up เพื่อเริ่มต้นระบบ ตรวจ docker logs nyc_taxi_superset หากยังไม่ขึ้น หลังจากนั้น
• การหยอดข้อมูลใช้เวลานานกว่าที่พาร์ตเนอร์คาด คำสั่ง insert ด้วย TABLE(GENERATOR) สร้าง 50M แถวในราว 10-12 นาที ส่วนคำสั่ง UPDATE ที่ตามมาซึ่งเติมคอลัมน์ JSON TRIP_METADATA บนทั้ง 50M แถวอาจเพิ่มอีก 15-20 นาทีบน warehouse ขนาด SMALL นี่เป็น พฤติกรรมปกติของ Snowflake สำหรับการอัปเดตคอลัมน์ VARIANT ขนาดใหญ่ ไม่ใช่การ ค้าง — พูดให้ชัดก่อนที่พาร์ตเนอร์จะเริ่มไล่แก้สคริปต์ที่ทำงานถูกต้องอยู่แล้ว
• พาร์ตเนอร์หยุด producer ของข้อมูลการเดินทางเมื่อโมดูลนี้ดูเหมือน "เสร็จ" แล้ว มันยังไม่เสร็จ — โมดูล 02 ถึง 05 ทั้งหมดขึ้นอยู่กับการที่มันยังทำงานอยู่ และ cutover ของโมดูล 05 วัดช่องว่างที่มันสร้างขึ้นโดยเฉพาะ นี่คือความผิดพลาดจากความอยากเก็บกวาดที่สร้าง ความเสียหายมากที่สุดในเวิร์กช็อปทั้งหมด พูดออกมาให้ชัด มากกว่าหนึ่งครั้ง

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

• จัดเตรียมใหม่โดยไม่ต้องจ่ายเวลาโหลดข้อมูล ~10 นาทีอีกครั้ง: ./setup.sh --skip-seed (โครงสร้างพื้นฐานมีอยู่แล้วและ TRIPS_RAW มีข้อมูลอยู่แล้ว)
• ปรับแก้เฉพาะการเปลี่ยนแปลงของ Terraform หรือ SQL: ใช้ ./setup.sh --skip-seed เพียงอย่างเดียว
• ปรับแก้เฉพาะโมเดล dbt โดยข้าม Superset ไปทั้งหมด: ./setup.sh --skip-seed --skip-superset
• ทดสอบการเปลี่ยนแปลงของ Terraform โดยไม่รัน dbt ซ้ำ: เพิ่ม --skip-dbt
• หลังเปลี่ยนสคีมาของโมเดล dbt ให้บังคับสร้าง incremental ขึ้นใหม่ทั้งหมด: --full-refresh (ใช้ร่วมกับ --skip-seed เพื่อเลี่ยงการจ่ายเวลาโหลดข้อมูลอีกครั้ง)
• รีเซ็ตทั้งหมดเฉพาะเมื่อสภาพแวดล้อมกู้คืนไม่ได้แล้ว: source .env && ./teardown.sh จาก workshop_public/snowflake_migration_lab/01-setup-snowflake/ แล้วรัน ./setup.sh แบบธรรมดาอีกครั้ง วิธีนี้ทำลายข้อมูลและต้องจ่ายเวลาหยอดข้อมูลเต็ม ~10-12 นาทีใหม่ — อย่าใช้เป็นทางเลือกแรกสำหรับพาร์ตเนอร์ที่ติดขัด