ใบงานที่ 1: การเลือกเอนจิน MergeTree

เวลาที่ใช้โดยประมาณ: 15–20 นาที เอกสารอ้างอิง: เอนจิน MergeTree

แนวคิด

ใน Snowflake คุณสร้างตารางแล้ว Snowflake ตัดสินใจว่าจะจัดเก็บมันอย่างไร ใน ClickHouse คุณเป็นผู้เลือกเอนจินจัดเก็บข้อมูล — และการเลือกนี้กำหนดความถูกต้อง ไม่ใช่แค่ ประสิทธิภาพ

เอนจินสามตัวที่คุณต้องใช้ในแล็บนี้:

MergeTree — เอนจินพื้นฐาน ข้อมูลถูกจัดเก็บเป็นไฟล์คอลัมนาร์ที่เรียงลำดับแล้ว ไม่มีการ ขจัดข้อมูลซ้ำ ใช้ตัวนี้เมื่อตารางเป็นแบบเขียนเพิ่มเท่านั้น หรือเมื่อไปป์ไลน์ของคุณจัดการ การอัปเดตจากภายนอก (เช่น โหลดใหม่ทั้งหมดในทุกการรัน dbt)

ReplacingMergeTree(version_col) — ขยาย MergeTree ด้วยการขจัดข้อมูลซ้ำแบบเบื้องหลัง เมื่อแถวที่มีคีย์ ORDER BY เดียวกันอยู่ในหลาย part จะเก็บไว้เพียงแถวที่มีค่า version_col สูงสุดหลังการ merge ใช้ตัวนี้เมื่อแถวสามารถถูกอัปเดตได้ และคุณมีคอลัมน์ที่ เพิ่มขึ้นแบบทางเดียวในทุกการอัปเดต (เช่น timestamp updated_at)

จุดพลาดที่สำคัญ: การขจัดข้อมูลซ้ำเป็นแบบอะซิงโครนัส จนกว่า ClickHouse จะรัน merge เบื้องหลัง ทั้งเวอร์ชันเก่าและใหม่ของแถวจะอยู่ร่วมกัน ใช้ SELECT ... FINAL กับตาราง ReplacingMergeTree เสมอ เพื่อบังคับการขจัดข้อมูลซ้ำตอนคิวรี

AggregatingMergeTree — ขยาย MergeTree ด้วยการ merge สถานะการรวมค่าบางส่วน ใช้ตัวนี้ เมื่อตารางจัดเก็บสถานะการรวมค่าที่นำมารวมกันได้ (เช่น HyperLogLog sketch, quantile digest) และคุณต้องการการรวมค่าแบบเบื้องหลัง ไม่จำเป็นสำหรับแล็บ NYC Taxi — ตารางการรวมค่าถูกสร้างใหม่โดย dbt ไม่ใช่สะสมค่าไปเรื่อย ๆ

แผนผังการตัดสินใจ

Does the table receive UPDATE or DELETE operations?
│
├── No (insert-only)
│   └─► MergeTree()
│
└── Yes
    ├── Is there a timestamp/version column that increases on every update?
    │   ├── Yes → ReplacingMergeTree(version_col)
    │   └── No (e.g., full-reload dimension tables)
    │       └─► MergeTree()  — dbt handles upsert via atomic table swap (full rebuild)
    │
    └── Does the table store partial aggregate states (AggregateFunction types)?
        └── Yes → AggregatingMergeTree()

โมเดล staging เป็น view เสมอ

ใน dbt + ClickHouse โมเดล staging ควรถูก materialize เป็น view ไม่ใช่ตาราง view ไม่มีต้นทุนพื้นที่จัดเก็บและสดใหม่เสมอ — มันเป็นเพียง SQL ที่บันทึกไว้ ไม่ใช่ อ็อบเจกต์ทางกายภาพ

แบบฝึกหัดการเลือกเอนจินด้านล่างครอบคลุม โมเดล dbt ชั้นวิเคราะห์ (ตาราง fact, การรวมค่า, ตาราง dimension) และ Materialized View ของ ClickHouse ไม่รวม trips_raw หรือโมเดล staging:

• trips_raw เป็นตาราง ClickHouse พื้นฐานที่สร้างโดยตรงจากสคริปต์ย้ายข้อมูล (scripts/02_migrate_trips.py) — ไม่ใช่โมเดล dbt มันใช้ ReplacingMergeTree(_synced_at) เพราะสคริปต์ย้ายข้อมูลอาจลองแบตช์ใหม่และเขียน trip_id เดิมซ้ำ หลังการตัดสวิตช์ producer ที่ทำงานอยู่ก็อาจลองใหม่เมื่อเกิดความล้มเหลวชั่วคราวได้ด้วย _synced_at DateTime DEFAULT now() รับประกันว่าการเขียนล่าสุดชนะ
• stg_trips เป็น view ของ dbt ที่อยู่บน trips_raw มันใช้ SELECT ... FROM trips_raw FINAL เพื่อคลี่คลายข้อมูลซ้ำที่ยังไม่ merge ก่อนที่ข้อมูลจะไปถึงโมเดลวิเคราะห์ ปลายน้ำ ความรับผิดชอบเรื่องการขจัดข้อมูลซ้ำอยู่ที่นี่ — ไม่ใช่ในตาราง staging แบบ ReplacingMergeTree

แบบฝึกหัด: การเลือกเอนจินให้ตารางของ NYC Taxi

สำหรับแต่ละตารางด้านล่าง ให้ระบุรูปแบบการอัปเดต ระบุคอลัมน์เวอร์ชัน (ถ้ามี) และเลือกเอนจินที่ทำให้ตารางยังถูกต้อง แล้วจึงทำคำถามเชิงเหตุผลเมื่อกรอกครบทุกแถว

Loading worksheet...

ถ่ายลงใน migration-plan.md

เมื่อกรอกใบงานนี้เสร็จแล้ว ให้คัดลอกการตัดสินใจเรื่องเอนจินของคุณไปยังส่วนที่ 3 ของ migration-plan.md และติ๊กช่อง:

- [ ] Engine selection: completed