04 สร้างไปป์ไลน์ dbt ขึ้นใหม่

คู่มือประกอบสำหรับผู้สอนของบทเรียนผู้เรียน 04 สร้างไปป์ไลน์ dbt ขึ้นใหม่

การจัดเวลา

ประมาณ 30 นาที ช่วงเดียวที่มีเวลาว่างจริงคือ dbt run ครั้งที่สองในขั้นตอนที่ 1 (ราว 8-12 นาทีในการประมวลผล 50 ล้านแถวผ่านโมเดล incremental) — สั้น พอที่มักไม่จำเป็นต้องมีช่วงพักของตัวเอง แต่ยาวพอที่ควรบรรยายไปด้วยมากกว่า จะเฝ้าดูอย่างเงียบ ๆ ขั้นตอนที่ 2 (dictionary ของโซน) และคำสั่งค้นหาเพื่อตรวจสอบนั้น รวดเร็วและมีการโต้ตอบ

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

• วางกรอบโมดูลนี้ว่าเป็นการพิสูจน์ไปป์ไลน์ ไม่ใช่ข้อมูล: โมดูล 03 พิสูจน์แล้วว่า ClickHouse รองรับ 50 ล้านแถวได้ โมดูลนี้พิสูจน์ว่าไปป์ไลน์ Medallion แบบเดียวกันจากโมดูล 01 — staging view, ตาราง fact แบบ incremental, การโหลดมิติซ้ำ, การทดสอบ — ทำงานบน ClickHouse ได้โดยรูปทรงไม่เปลี่ยน
• กลไก dbt หนึ่งอย่างที่คุ้มค่าจะหยุดพูดถึง: delete_insert มาแทน MERGE INTO (ClickHouse ไม่มีคำสั่ง MERGE) และ ReplacingMergeTree เป็นตัวรองรับความปลอดภัย อยู่ข้างใต้ ไม่ใช่ตัวแทนของมัน — หาก delete_insert ทำงานเสร็จตามปกติจะไม่มี อะไรให้ RMT มาเก็บกวาด มันมีความสำคัญเฉพาะเมื่อการรันถูกขัดจังหวะกลางทาง
• mv_live_trip_feed คุ้มค่าที่จะเรียกชื่อออกมาให้ชัด: มันไม่มีสิ่งที่เทียบเท่าบน Snowflake เลย materialized view แบบมาตรฐานเห็นแต่แถวในชุดข้อมูลที่กระตุ้นให้มันทำงาน ส่วน materialized view แบบ REFRESHABLE รันคำสั่งค้นหาทั้งหมดใหม่ตามกำหนดเวลา จึงสามารถ ดูแลค่าสรุปตลอดอายุการใช้งานได้ นี่เป็นความสามารถใหม่ที่การย้ายข้อมูลเพิ่มเข้ามา ไม่ใช่การ ย้ายแบบตรง ๆ
• พูดเรื่องนี้ก่อนที่จะมีใครถาม: agg_hourly_zone_trips จะว่างเปล่าหลัง dbt run ของขั้นตอนที่ 1 และนั่นถูกต้องแล้ว ไม่ใช่บั๊ก ตัวกรอง incremental ของมันคือ WHERE pickup_at >= now() - INTERVAL 2 HOUR ซึ่งตรงกับแถวที่เขียนโดย producer ที่ทำงานสด เท่านั้น ทุกแถวที่เพิ่งย้ายมาล้วนเป็นข้อมูลย้อนหลัง มันจะว่างเปล่าไปจนกว่าโมดูล 05 จะเริ่ม producer ของ ClickHouse ตอน cutover พาร์ตเนอร์มักคิดว่านี่คือไปป์ไลน์ที่พังอยู่เสมอ — ตัดหน้าคำถามนี้ไว้ก่อน

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

• agg_hourly_zone_trips คืนค่า 0 แถวหลังขั้นตอนที่ 1 และพาร์ตเนอร์รายงานว่าเป็น บั๊ก มันไม่ใช่ — ดูแนวการบรรยายด้านบน ยืนยันว่า dim_taxi_zones (265 แถว) และ fact_trips (ราว 50 ล้านแถว) มีข้อมูลตามที่คาดไว้ ก่อนที่จะเสียเวลา กับ agg_hourly_zone_trips หากสองตารางนั้นถูกต้อง ตารางสรุปที่ว่างเปล่าก็ ทำงานตรงตามที่ออกแบบไว้ นี่คือปัญหาหลักของโมดูลนี้ — คาดว่าจะมี คำถามนี้ทุกครั้ง
• dbt run ในขั้นตอนที่ 1 ล้มเหลวหรือเชื่อมต่อไม่ได้ โมดูลนี้ขึ้นอยู่กับโปรไฟล์ dbt ของ ClickHouse ที่โมดูล 03 ควรจะสร้างไว้แล้ว (~/.dbt/profiles.yml, nyc_taxi_ch) หากโปรไฟล์นั้นหายไป — ดูหัวข้อ "Configure the dbt profile" ของขั้นตอนที่ 2 ใน 03 จัดเตรียมและย้ายข้อมูล — ขั้นตอนที่ 1 จะล้มเหลวที่นี่แทน ซึ่งช้ากว่าต้นตอของปัญหาไปหนึ่งโมดูล
• TODO: หัวข้อ ## dbt on ClickHouse ของหน้า การแก้ปัญหา บนไซต์ ยังไม่มีรายการเฉพาะสำหรับความผิดพลาดที่ปรากฏขึ้น เฉพาะในขั้นตอนนี้ บันทึกสิ่งที่พบจากการซ้อมไว้ที่นี่

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

• รัน dbt run ซ้ำได้ตามสะดวก — มันเป็นแบบ incremental และปลอดภัยที่จะทำซ้ำ ไม่มีอะไรที่นี่ต้อง รื้อถอน
• หลังเปลี่ยนโมเดลหรือสคีมาของ dbt ให้บังคับสร้างโมเดล incremental ขึ้นใหม่ทั้งหมด: dbt run --full-refresh (จาก workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/dbt/nyc_taxi_dbt_ch)
• หาก dictionary ของโซนดูผิดหรือเก่า ก็เพียงรัน scripts/04_create_dictionary.sql ใหม่ — มันเป็น CREATE OR REPLACE DICTIONARY ซึ่งปลอดภัยที่จะรันซ้ำโดยไม่ต้องลบอะไร ก่อน
• ไม่มีการรีเซ็ตระดับสภาพแวดล้อมที่ใช้ที่นี่ — การรื้อถอนของโมดูลนี้คือ workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/teardown.sh ตัวเดียวกับที่กล่าวถึง ในโมดูล 03 อย่ารันมันระหว่างที่โมดูลนี้ยังดำเนินอยู่