ClickHouse ซีรีส์ย้ายระบบ

ย้ายเวิร์กโหลด
พิสูจน์ผลลัพธ์

ห้าสิบล้านแถว ไปป์ไลน์ dbt แบบ Medallion เต็มรูปแบบ คิวรีวิเคราะห์เจ็ดตัว ตัวผลิตข้อมูลสด และแดชบอร์ด Superset — เวิร์กโหลด Snowflake ที่มีรูปทรงเหมือนโปรดักชัน ซึ่งคุณย้ายมาที่ ClickHouse Cloud ตั้งแต่ต้นจนจบ แล้วเบนช์มาร์กและอธิบายให้ได้

6 ชั่วโมง · เจ็ดโมดูลย้าย 50M แถวเบนช์มาร์ก 7 คิวรี~$2-4 จากเครดิตทดลองใช้

ไม่ใช่การยกไปวาง แต่เป็นบันทึกการตัดสินใจ

ใครก็เขียนสคริปต์คัดลอกห้าสิบล้านแถวจาก warehouse หนึ่งไปอีกที่หนึ่งได้ ส่วนนั้นไม่ใช่ส่วนที่ยากของการย้ายระบบ และไม่ใช่สิ่งที่ลูกค้าจ่ายเงินให้ Solutions Architect มาทำให้ถูก

ส่วนที่ยากอยู่ก่อนหน้าการคัดลอก: ตระกูลเอนจิน MergeTree ไหนเหมาะกับตารางใด คีย์ ORDER BY ทำอะไรให้คุ้มค่าจริง ๆ และสำนวน Snowflake ไหน — QUALIFY, VARIANT, TASK ที่ตั้งเวลาไว้ — ที่ไม่มีของเทียบตรง ๆ ใน ClickHouse และต้องแปลกันจริงจัง

แล็บนี้บังคับให้คุณเขียนการตัดสินใจเหล่านั้นลงไปก่อนลงมือทำ โมดูล 02 ให้ผลลัพธ์เป็น migration-plan.md ที่มีเหตุผลกำกับทุกทางเลือก และสคริปต์ติดตั้งของโมดูล 03 จะตรวจหาไฟล์นั้นก่อนที่คุณจะแตะ ClickHouse

ถึงโมดูล 06 คุณจะต้องปกป้องแผนนั้นแบบเปิดตำรา ต่อการประเมินยี่สิบข้อและคำถามปลายเปิดสี่ข้อ — เป็นการทดสอบวิจารณญาณแบบเดียวกับที่บทสนทนากับลูกค้าจริงจะพาคุณไปเจอ

สิ่งที่คุณจะได้กลับไป

ทุกอย่างที่จะรันอยู่เมื่อคุณจบ

บนบัญชีทดลองใช้ Snowflake ของคุณเองและบัญชีทดลองใช้ ClickHouse Cloud ของคุณเอง — ไม่ต้องใช้บัตรเครดิตทั้งสองที่

01

เวิร์กโหลด Snowflake ที่ทำโปรไฟล์แล้ว

ทำบัญชีรายการตาราง ระบุรูปแบบคิวรี มองเห็นช่องว่างของ SQL dialect และประเมินขนาดงานย้ายระบบ ก่อนจะเริ่มวางแผนอะไรทั้งนั้น

02

การตัดสินใจเรื่องเอนจินและสคีมาที่ถูกต้อง

ตระกูลเอนจิน MergeTree ที่เหมาะกับแต่ละตาราง คีย์ ORDER BY ที่คุ้มค่ากับที่มันกินไป และชนิดข้อมูลกับสำนวน Snowflake ที่แปลเป็นของเทียบเท่าใน ClickHouse แล้ว

03

การย้ายระบบสไตล์โปรดักชัน ที่ลงมือทำจริง

ย้าย 50 ล้านแถว ด้วยสคริปต์ Python ที่รันต่อจากจุดเดิมได้ ตรวจความตรงกันของข้อมูล และสลับตัวผลิตข้อมูลด้วยสคริปต์

04

ไปป์ไลน์ dbt ที่สร้างขึ้นใหม่บน ClickHouse

dbt-clickhouse ที่ตั้งค่าด้วย delete_insert โมเดล ReplacingMergeTree และ materialized view แบบรีเฟรชได้

05

เหตุผลทางธุรกิจ ที่วัดเป็นตัวเลขได้

เบนช์มาร์กเจ็ดคิวรีที่คุณเปลี่ยนเป็นตัวเลขประสิทธิภาพ 6-9x ซึ่งอธิบายต่อหน้าลูกค้าได้

06

การตัดสินใจที่คุณอธิบายได้

ผ่านการประเมินของโมดูล 06 — เป็นหลักฐานว่าคุณเอาแพตเทิร์นเดียวกันไปใช้กับเวิร์กโหลดของลูกค้ารายใหม่ได้

ช่องว่างของ dialect ที่คุณต้องแปลจริง ๆ

QUALIFYsubquery ที่ใช้ ROW_NUMBER
LATERAL FLATTENJSONExtract / arrayJoin
VARIANTJSON / String พร้อมฟังก์ชัน extract
MERGEReplacingMergeTree กับ delete_insert
TASK ที่ตั้งเวลาไว้materialized view แบบรีเฟรชได้
STREAMฟีดจากตัวผลิตข้อมูลสด

เส้นทาง · ลงมือทำ 6 ชั่วโมง

เจ็ดโมดูล เรียงตามลำดับ

หนึ่งสายงาน ตั้งแต่ต้นจนจบ: ทำโปรไฟล์ต้นทาง วางแผนปลายทาง ย้ายข้อมูล สร้างไปป์ไลน์ขึ้นใหม่ แล้วพิสูจน์ผลลัพธ์

  1. 00

    ติดตั้งชุดเครื่องมือ สร้างบัญชีทดลองใช้ทั้งสองคลาวด์ โคลน repo และสร้าง virtualenv ของ dbt ทั้งสองชุด — ทุกอย่างที่การย้ายระบบต้องมีก่อนคุณแตะข้อมูล

  2. 01

    จัดสภาพแวดล้อม Snowflake ที่สะท้อนการติดตั้งใช้งานของลูกค้าจริง: 50M แถว ไปป์ไลน์ dbt แบบ Medallion ตัวผลิตข้อมูลทริปแบบสด และแดชบอร์ด Superset สามชุด

  3. 02

    ทำโปรไฟล์เวิร์กโหลด Snowflake แล้วตัดสินใจเรื่องสถาปัตยกรรมที่การย้ายระบบจะลงมือทำตาม: การเลือกเอนจิน sort key การแปลงสคีมา ระลอกการ deploy และการออกแบบโมเดล dbt

  4. 03

    จัดสรร ClickHouse Cloud ด้วย Terraform สร้างตารางปลายทางจากแผนของคุณ และย้าย 50 ล้านแถวด้วยสคริปต์ที่รันต่อจากจุดเดิมได้ กันเวลาไว้ 60 นาทีโดยรวม — ราว 40-50 นาทีของนั้นเป็นการโอนข้อมูลที่ปล่อยรันเบื้องหลังได้โดยไม่ต้องเฝ้า

  5. 04

    สร้างไปป์ไลน์ Medallion ขึ้นใหม่บน ClickHouse ด้วย dbt-clickhouse — โมเดล incremental แบบ delete_insert, ReplacingMergeTree, materialized view แบบรีเฟรชได้ — แล้วสร้าง dictionary ของโซน

  6. 05

    สร้างแดชบอร์ดขึ้นใหม่บน ClickHouse เบนช์มาร์กทั้งเจ็ดคิวรีบนทั้งสองเอนจิน สลับตัวผลิตข้อมูลมา ตรวจความตรงกัน แล้วรื้อระบบทิ้ง

  7. 06

    ทำแบบประเมินปรนัย 20 ข้อและคำถามปลายเปิด 4 ข้อ แบบเปิดตำรา เพื่อรับ ClickHouse Migration Proficiency Badge

ค่าเริ่มต้นคือทำเองตามจังหวะของคุณ ทุกโมดูลระบุจุดตรวจเริ่มต้น จึงไม่มีใครถูกทิ้งไว้เพราะจังหวะของห้อง ตัวผลิตข้อมูล Snowflake ที่เริ่มในโมดูล 01 ต้องรันต่อเนื่องไปจนถึงโมดูล 05 — วางแผนช่วงพักรอบมัน ไม่ใช่ปิดมันแล้วพัก

ก่อนเข้าร่วม

เหมาะกับใคร และต้องเตรียมอะไร

เหมาะกับใคร ผู้เข้าร่วม

  • Solutions Architect ของ ClickHouse และพาร์ตเนอร์ที่ทำงานย้ายระบบจาก Snowflake
  • ใครก็ตามที่เคยถูกถามว่า “ทำไมต้องเอนจินนี้ ทำไมต้อง sort key นี้” และอยากมีคำตอบที่อธิบายได้
  • ทีมที่กำลังจะย้ายเวิร์กโหลดวิเคราะห์ข้อมูลที่มีรูปทรงเหมือนโปรดักชันออกจาก Snowflake
  • ใช้ SQL และเทอร์มินัลได้คล่อง — ไม่ต้องมีพื้นด้าน data engineering

ต้องเตรียมอะไร สิ่งที่ต้องมี

  • ชุดเครื่องมือของโมดูล 00: Terraform, Docker, Python 3.11-3.13, dbt Core และ SnowSQL CLI
  • บัญชีทดลองใช้ Snowflake — ไม่ต้องใช้บัตรเครดิต
  • บัญชีทดลองใช้ ClickHouse Cloud — ไม่ต้องใช้บัตรเครดิต
  • เครดิตทดลองใช้ ClickHouse Cloud ถูกใช้ไปราว $2-4 ตลอดเซสชัน

รูปแบบการเรียน รูปแบบ

  • ลงมือทำ 100% ตลอดเจ็ดโมดูล — ทุกคำสั่งและทุกคิวรีคัดลอกไปวางได้
  • ทำเองหรือมีผู้ดำเนินการก็ได้ พร้อมแทร็กผู้สอนที่มีทุกโมดูลคู่ขนาน
  • ตัวผลิตข้อมูล Snowflake รันสดตลอดทาง จังหวะเวลาจึงเป็นของจริง ไม่ใช่การจำลอง
  • แบบประเมินของโมดูล 06 เป็นแบบเปิดตำราและตรวจเอง

สิ่งที่แล็บนี้ไม่ครอบคลุม ขอบเขต

  • การนำข้อมูลเข้าแบบสตรีมมิงเรียลไทม์ — ตัวผลิตข้อมูลทริปบน Docker ทำหน้าที่แทน Kafka, Kinesis หรือ ClickPipes
  • คลัสเตอร์ ClickHouse หลายโหนด — งานทั้งหมดอยู่บนการติดตั้ง ClickHouse Cloud เซอร์วิสเดียว
  • การกำกับดูแลข้อมูลและการควบคุมการเข้าถึง — การเข้าถึงตามบทบาท ความปลอดภัยระดับแถว และการปิดบังข้อมูล ไม่ได้ทำในแล็บนี้
  • การวิวัฒน์สคีมาแบบเพิ่มทีละส่วน, ต้นทางที่ไม่ใช่ Snowflake และ SLA กับการมอนิเตอร์ระดับโปรดักชัน — แต่ละอย่างเป็นหัวข้อของตัวเอง

พร้อมย้ายเวิร์กโหลดหรือยัง

เตรียมบัญชีทดลองใช้ Snowflake และ ClickHouse Cloud มา แล้วกลับไปพร้อม 50 ล้านแถวที่ย้ายแล้ว ไปป์ไลน์ dbt ที่สร้างขึ้นใหม่ และคิวรีเบนช์มาร์กเจ็ดตัวที่คุณอธิบายให้ลูกค้าฟังได้

50Mแถวที่ย้ายด้วยสคริปต์ Python ที่รันต่อจากจุดเดิมได้
6-9xความเร็วที่วัดได้ครบทั้งเจ็ดคิวรีเบนช์มาร์ก — เป็นเพียงตัวอย่างจนกว่าคุณจะรันของตัวเองในโมดูล 05
แบดจ์ได้รับในโมดูล 06 จากการปกป้องแผนการย้ายระบบของคุณ
TH