แล็บย้ายระบบ NYC Taxi จาก Snowflake
ย้ายเวิร์กโหลด Snowflake ที่มีรูปทรงแบบโปรดักชันไปยัง ClickHouse Cloud — 50 ล้านแถว, ไปป์ไลน์ dbt แบบ Medallion, คิวรีวิเคราะห์เจ็ดตัว, producer ที่ทำงานสด และแดชบอร์ด BI — แล้วปกป้องการตัดสินใจของคุณ
ยินดีต้อนรับสู่ playbook ของแล็บย้ายระบบ NYC Taxi จาก Snowflake แล็บนี้ทำขึ้นสำหรับ ClickHouse Solutions Architect และพาร์ตเนอร์ที่กำลังเรียนรู้การย้ายเวิร์กโหลด Snowflake ระดับโปรดักชันไปยัง ClickHouse Cloud: สตรีมข้อมูลการเดินทางของแท็กซี่ใน NYC แบบสังเคราะห์ จำนวน 50 ล้านแถว, ไปป์ไลน์ dbt แบบ Medallion ที่สมบูรณ์, คิวรีวิเคราะห์ซับซ้อนเจ็ดตัว, producer ข้อมูลที่ทำงานสด และแดชบอร์ด Superset ซึ่งสร้างขึ้นเพื่อจำลองเวิร์กโหลดแบบที่คุณ จะพบในงานร่วมกับลูกค้าจริง
ทำไมต้องเวิร์กช็อปนี้
จุดประสงค์ของแล็บนี้ไม่ใช่การย้ายแถวข้อมูลจากคลังหนึ่งไปอีกคลังหนึ่ง — สคริปต์คัดลอกก็ทำได้
จุดประสงค์คือการตัดสินใจ และปกป้องการตัดสินใจ ที่การย้ายระบบจริงบังคับให้คุณต้องทำ: เอนจิน
ตระกูล MergeTree ตัวใดเหมาะกับแต่ละตาราง, ออกแบบคีย์ ORDER BY ให้คุ้มค่าได้อย่างไร และ
สำนวน SQL ของ Snowflake ตัวใดที่ไม่มีสิ่งเทียบเท่าโดยตรงใน ClickHouse เมื่อจบแล้วคุณจะ
สามารถโปรไฟล์เวิร์กโหลด Snowflake, ตัดสินใจเรื่องเอนจินและสคีมาได้ถูกต้อง, ดำเนินการย้าย
ระบบแบบโปรดักชันด้วยสคริปต์ที่ทำงานต่อจากจุดเดิมได้, สร้างไปป์ไลน์ dbt ขึ้นใหม่บน
ClickHouse, วัดผลเชิงธุรกิจด้วยการเบนช์มาร์กเจ็ดคิวรี และอธิบายพร้อมปกป้องทุกการตัดสินใจ
เหล่านั้น
playbook นี้มีสามแทร็ก แทร็ก Learner คือบทเรียนที่คุณทำจริง แทร็ก Instructor คือคู่มือของ ผู้ดำเนินการสำหรับโมดูลชุดเดียวกัน: การจับเวลา, แนวการพูด, ความล้มเหลวที่พบบ่อย และขั้นตอน รีเซ็ต ส่วน Reference เป็นเนื้อหาประจำ — คู่มือเอนจิน, dbt และแดชบอร์ด — มีไว้ให้อ่านควบคู่ ไปกับโมดูลใดก็ได้ ไม่จำเป็นต้องอ่านตามลำดับ
โมดูล
| # | Learner | Instructor | ผลลัพธ์ |
|---|---|---|---|
| 00 | ตั้งค่า | บันทึก | ติดตั้งชุดเครื่องมือแล้ว, สร้างบัญชีทดลองใช้ทั้งสองคลาวด์แล้ว, โคลนรีโปแล้ว, สร้าง virtualenv ของ dbt ทั้งสองตัวแล้ว — ทุกอย่างที่การย้ายระบบต้องมีก่อนคุณจะแตะข้อมูล |
| 01 | สภาพแวดล้อมต้นทาง | บันทึก | สภาพแวดล้อม Snowflake ที่สะท้อนการติดตั้งใช้งานของลูกค้าจริง: 50 ล้านแถว, ไปป์ไลน์ dbt แบบ Medallion, producer การเดินทางที่ทำงานสด และแดชบอร์ด Superset สามตัว |
| 02 | วางแผนและออกแบบ | บันทึก | โปรไฟล์เวิร์กโหลด Snowflake แล้ว และระบุการตัดสินใจด้านสถาปัตยกรรมที่การย้ายระบบจะดำเนินการอย่างชัดเจน: การเลือกเอนจิน, sort key, การแปลงสคีมา, ระลอกการติดตั้งใช้งาน และการออกแบบโมเดล dbt |
| 03 | จัดเตรียมและย้ายข้อมูล | บันทึก | จัดเตรียม ClickHouse Cloud ด้วย Terraform แล้ว, สร้างตารางเป้าหมายจากแผนของคุณแล้ว และย้าย 50 ล้านแถวด้วยสคริปต์ย้ายข้อมูล Python ที่ทำงานต่อจากจุดเดิมได้ |
| 04 | สร้างไปป์ไลน์ dbt ขึ้นใหม่ | บันทึก | สร้างไปป์ไลน์ Medallion ขึ้นใหม่บน ClickHouse ด้วย dbt-clickhouse — โมเดล incremental แบบ delete_insert, ReplacingMergeTree, refreshable materialized view — และสร้าง dictionary ของโซนแล้ว |
| 05 | เบนช์มาร์กและตัดสวิตช์ | บันทึก | สร้างแดชบอร์ดขึ้นใหม่บน ClickHouse แล้ว, เบนช์มาร์กคิวรีทั้งเจ็ดตัวกับทั้งสองเอนจินแล้ว, ตัดสวิตช์ producer แล้ว, ตรวจสอบความเท่าเทียมแล้ว และรื้อทั้งสองคลาวด์แล้ว |
| 06 | การประเมิน | บันทึก | ทำการประเมินแบบปรนัย 20 ข้อและคำถามปลายเปิด 4 ข้อเสร็จแล้วแบบเปิดหนังสือ เพื่อรับ ClickHouse Migration Proficiency Badge |
สิ่งที่แล็บนี้ไม่ครอบคลุม
แล็บนี้กำหนดขอบเขตไว้ที่รูปแบบการย้ายระบบหลัก หัวข้อต่อไปนี้อยู่นอกขอบเขตโดยเจตนา:
- การนำเข้าข้อมูลแบบสตรีมมิงเรียลไทม์ — แล็บใช้ producer การเดินทางที่ทำงานบน Docker สำหรับการเขียนสดหลังตัดสวิตช์ ไม่ใช่แหล่งสตรีมมิงแบบ Kafka, Kinesis หรือ ClickPipes
- คลัสเตอร์ ClickHouse แบบหลายโหนด — งานทั้งหมดอยู่บนการติดตั้งใช้งาน ClickHouse Cloud แบบเซอร์วิสเดียว ไม่ครอบคลุมการติดตั้งใช้งานแบบกระจายที่โฮสต์เอง (sharding, โทโพโลยี การทำ replication)
- การกำกับดูแลข้อมูลและการควบคุมการเข้าถึง — ไม่มีการทำ role-based access, row-level security และนโยบายการปิดบังข้อมูล
- การเปลี่ยนแปลงสคีมาแบบค่อยเป็นค่อยไป — แล็บใช้สคีมาคงที่ตลอด ไม่ครอบคลุมการจัดการ การเปลี่ยนสคีมาแบบสดระหว่างการย้ายระบบ
- แหล่งข้อมูลที่ไม่ใช่ Snowflake — รูปแบบการย้ายระบบนี้เจาะจงกับ Snowflake PostgreSQL, MySQL, BigQuery และแหล่งอื่นมีสำเนียง SQL และแนวทาง CDC ที่ต่างกัน
- SLA และการมอนิเตอร์ในโปรดักชัน — ไม่ครอบคลุม observability, การแจ้งเตือน และการ จัดการ SLA ใน ClickHouse Cloud ระดับโปรดักชัน
เวลาและค่าใช้จ่าย
| โมดูล | เวลาตามนาฬิกา | เครดิต Snowflake | ClickHouse Cloud |
|---|---|---|---|
| 00 — ตั้งค่า | ~30 นาที | — | — |
| 01 — สภาพแวดล้อมต้นทาง | ~45 นาที | ~2–4 เครดิต | — |
| 02 — วางแผนและออกแบบ | ~90 นาที | ~0.5 เครดิต | — |
| 03 — จัดเตรียมและย้ายข้อมูล | ~60 นาที | ~1–2 เครดิต | ~$1–2 (ทดลองใช้) |
| 04 — สร้างไปป์ไลน์ dbt ขึ้นใหม่ | ~30 นาที | ~0.5–1 เครดิต | ~$0.5–1 (ทดลองใช้) |
| 05 — เบนช์มาร์กและตัดสวิตช์ | ~45 นาที | ~1–2 เครดิต | ~$0.5–1 (ทดลองใช้) |
| 06 — การประเมิน | ~60 นาที | — | — |
| รวม | ~6 ชั่วโมง | ~6–10 เครดิต | ~$2–4 |
ประมาณการเครดิต Snowflake สมมติว่าใช้ warehouse ขนาด X-Small มาตรฐาน ค่าใช้จ่ายของ ClickHouse Cloud สมมติว่าเป็นเซอร์วิสระดับ Development ที่ถูกรื้อทิ้งภายในไม่กี่ชั่วโมง