05 เบนช์มาร์กและตัดสวิตช์

จุดเริ่มต้น

โมดูล 04 เสร็จแล้ว: เลเยอร์ analytics มีข้อมูลและผ่านการทดสอบแล้ว analytics.fact_trips มีราว 50 ล้านแถว; analytics.dim_taxi_zones, analytics.dim_payment_type, analytics.dim_vendor และ analytics.dim_date โหลดครบแล้ว; dbt test ผ่านตั้งแต่ต้น จนจบ; และ analytics.taxi_zones_dict พร้อมใช้งานและคืนค่าเขตผ่าน dictGet() analytics.agg_hourly_zone_trips ยังว่างเปล่า — โดยการออกแบบ ไม่ใช่ข้อบกพร่อง — และจะ เป็นเช่นนั้นไปจนถึงการตัดสวิตช์ในโมดูลนี้ producer ของ Snowflake ยังทำงานอยู่ และช่องว่าง ระหว่าง Snowflake กับ ClickHouse ยังเปิดอยู่ กันเวลาไว้ประมาณ 45 นาที

ทำไม

ทุกโมดูลถึงจุดนี้เป็นการเตรียมการ โมดูล 03 พิสูจน์ว่า ClickHouse เก็บ 50 ล้านแถวได้; โมดูล 04 พิสูจน์ว่าไปป์ไลน์ dbt รันกับมันได้ ไม่มีโมดูลใดโดยตัวมันเองที่พาร์ตเนอร์จะเซ็นรับรอง ว่า "ย้ายแล้ว" — นั่นต้องมีอีกสองสิ่ง: ตัวเลข และการตัดสวิตช์

ตัวเลขคือเบนช์มาร์กในขั้นที่ 2: คิวรีเจ็ดตัวชุดเดียวกันจากแผนการย้ายระบบของคุณ รันติดต่อกัน กับ Snowflake และกับ ClickHouse หาค่ามัธยฐานจากสามรอบต่อฝั่ง นั่นคือสิ่งที่เปลี่ยน "ClickHouse ควรเร็วกว่า" ให้เป็นตัวเลขความเร็วที่เพิ่มขึ้นแบบเจาะจงและปกป้องได้ ซึ่งพาร์ตเนอร์ เอาไปเสนอผู้มีส่วนได้ส่วนเสียของตัวเองได้

การตัดสวิตช์ในขั้นที่ 3 คืออีกครึ่งหนึ่ง ทุกโมดูลจนถึงตอนนี้ทำให้สองระบบทำงานเคียงข้างกัน โดย Snowflake เป็นระบบต้นฉบับและ ClickHouse วิ่งตามอยู่ข้างหลัง การย้ายระบบที่ไม่เคย ย้ายเส้นทางการเขียนจริงคือการคัดลอก ไม่ใช่การย้ายระบบ ขั้นที่ 3 หยุด producer ของ Snowflake, ปิดช่องว่างที่การเขียนอย่างต่อเนื่องของมันเปิดไว้ตั้งแต่โมดูล 01 และเริ่มเขียน การเดินทางใหม่ลง ClickHouse แทน — ช่วงเวลาที่ ClickHouse กลายเป็นระบบต้นฉบับ

นี่ยังเป็นโมดูลสุดท้ายของแทร็ก Learner ก่อนการประเมินแบบเขียนในโมดูล 06 ซึ่งเป็นแบบ เปิดหนังสือโดยอ้างอิงสิ่งที่คุณผลิตขึ้นที่นี่ แดชบอร์ด, CSV ของเบนช์มาร์ก และการตรวจสอบ ความเท่าเทียม ทั้งหมดต้องเป็นของจริงก่อนที่คุณจะรื้ออะไรในขั้นที่ 5

แนวคิด — เบื้องหลังการทำงาน

เลเยอร์ BI ในเชิงกลไก bash superset/add_clickhouse_connection.sh เรียก REST API ของ Superset โดยตรงในขั้นที่ 1 — ไม่มีการคลิกด้วยมือใน UI ของ Superset มันลงทะเบียน การเชื่อมต่อ ClickHouse แล้วนำเข้าไฟล์ export แดชบอร์ดที่ commit ไว้ เพิ่มแดชบอร์ด ClickHouse สี่ตัวเคียงข้างแดชบอร์ด Snowflake สามตัวที่โมดูล 01 สร้าง (รวมเจ็ดตัว):

คิวรีเบนช์มาร์กเจ็ดตัวทดสอบอะไร ขั้นที่ 2 รันคิวรีเจ็ดตัวชุดเดียวกันจากแผนการย้ายระบบ ของคุณกับทั้งสองเอนจินและเทียบเวลาตามนาฬิกา แต่ละตัวเจาะช่องว่างของสำเนียงภาษาหรือ คุณสมบัติของเอนจินที่เจาะจงจากแผนในโมดูล 02:

ช่องว่างของการตัดสวิตช์ producer ของ Snowflake เขียนข้อมูลราว 60 การเดินทางต่อนาที มาตั้งแต่โมดูล 01 และไม่เคยหยุด สคริปต์ย้ายข้อมูลของโมดูล 03 จับภาพ TRIPS_RAW ตามที่มัน เป็นตอนสคริปต์นั้นรัน และโมดูล 04 สร้างไปป์ไลน์ dbt ทับบน snapshot นั้น การเดินทางทุก รายการที่ถูกเขียนลง Snowflake หลังจากแบตช์สุดท้ายของสคริปต์ย้ายข้อมูล มีอยู่แต่ใน Snowflake — ส่วนหางของ ClickHouse ขาดไป รอบไล่ตามด้วย --resume ในขั้นที่ 3 ปิดช่องว่าง นั้นพอดี: มันอ่าน max(pickup_at) ที่มีอยู่ใน ClickHouse แล้วดึงเฉพาะแถวที่เขียนหลังจากนั้น ดังนั้นรอบที่ปิดช่องว่างซึ่งเปิดมาตั้งแต่โมดูล 01 ใช้เวลาระดับวินาทีถึงนาที ไม่ใช่ 40-50 นาที อย่างที่การย้ายข้อมูลก้อนใหญ่ครั้งแรกใช้ ถ้าข้ามมันแล้วตัดสวิตช์ไปเลย ClickHouse จะทิ้ง การเดินทางที่ตกลงในช่องว่างนั้นไปอย่างถาวร — เป็นความล้มเหลวด้านความเท่าเทียมแบบเงียบ ๆ ที่ขั้นที่ 4 ถูกสร้างขึ้นมาเพื่อจับ แต่ต่อเมื่อขั้นที่ 3 ได้รันตามลำดับแล้ว

agg_hourly_zone_trips มีข้อมูลที่นี่ และที่นี่เท่านั้น มันว่างเปล่ามาตั้งแต่โมดูล 03 โดยการออกแบบ: ฟิลเตอร์ incremental ของมันคือ WHERE pickup_at >= now() - INTERVAL 2 HOUR ซึ่งตรงกับแถวที่ producer สดเขียนเท่านั้น และ จนถึงโมดูลนี้ producer เดียวที่เขียนอยู่คือของ Snowflake เมื่อขั้นที่ 3 เริ่ม producer ของ ClickHouse แถวใหม่จะตกลงในหน้าต่างสองชั่วโมงนั้นในที่สุด และตารางนั้น — พร้อมกับชาร์ต แดชบอร์ดทุกตัวที่หนุนด้วยมัน — ก็เลิกว่างเปล่าเป็นครั้งแรกในแล็บนี้

ขั้นที่ 1 — เพิ่มแดชบอร์ด ClickHouse

สำหรับการสร้างด้วยมือฉบับเต็ม — สร้าง dataset ทั้ง 7 ตัว, ชาร์ต 18 ตัว และแดชบอร์ด 4 ตัว ทีละขั้นใน UI ของ Superset — ให้ทำตาม Superset บน ClickHouse หากจะข้าม ขั้นตอนที่ทำด้วยมือและนำเข้าทุกอย่างในทีเดียวแทน:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse"
source .env && source .clickhouse_state
bash superset/add_clickhouse_connection.sh

ไฟล์ superset/dashboards/dashboard_export_*.zip ที่ commit ไว้มีโฮสต์ของ ClickHouse ถูกลบข้อมูลออกเป็น your-instance.clickhouse.cloud ทางลัดด้านบนแก้ URI จาก .env ก่อนนำเข้า ดังนั้นเรื่องนี้จะเกิดขึ้นแบบมองไม่เห็น — คุณจะไม่สังเกตเห็นการลบข้อมูลนั้น แต่ถ้าคุณนำเข้า ZIP ด้วยมือผ่าน UI ของ Superset แทน การเชื่อมต่อฐานข้อมูลที่มันสร้าง จะเชื่อมต่อไม่ได้ — คุณต้องแก้การเชื่อมต่อนั้นภายหลังให้ชี้ไปที่ CLICKHOUSE_HOST และ credential จริงของคุณ ดู Superset บน ClickHouse ว่าทำ อย่างไรแน่ ๆ

ตรวจสอบ:

เปิด http://localhost:8088 (admin / admin) ภายใต้ Dashboards คุณควรเห็นทั้งหมด 7 ตัว — แดชบอร์ด Snowflake 3 ตัว และอีก 4 ตัวที่ขึ้นต้นด้วย CH —

ขั้นที่ 2 — รันเบนช์มาร์ก

รันคิวรีทั้งเจ็ดตัวติดต่อกันกับทั้ง Snowflake และ ClickHouse และเทียบเวลาตามนาฬิกา:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse"
source .env && source .clickhouse_state
./scripts/run_benchmark.sh

ผลลัพธ์ที่คาดไว้:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  NYC Taxi Lab — Query Benchmark: Snowflake vs ClickHouse
  (median of 3 runs each)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Query                                   Snowflake     ClickHouse    Speedup
────────────────────────────────────────────────────────────────────────
Q1  Hourly revenue by borough           5.0s          0.7s          6x
Q2  Rolling 7-day avg distance          5.5s          0.8s          6x
Q3  Top 10 trips (QUALIFY→subquery)     5.0s          0.7s          6x
Q4  Driver ratings (JSON flatten)       5.4s          0.8s          6x
Q5  Surge pricing (VARIANT)             5.1s          0.7s          6x
Q6  Hourly aggregation (MERGE→RMT)      5.9s          0.8s          7x
Q7  CDC/live data freshness             7.9s          0.8s          9x
────────────────────────────────────────────────────────────────────────
Total                                   40.1s         5.6s          7x avg
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ตัวเลขเหล่านี้เป็นการรันตัวแทนหนึ่งครั้ง ไม่ใช่การรับประกัน — ตัวเลขของคุณเองจะต่างไปตาม ขนาด warehouse, ระดับของ ClickHouse Cloud และอะไรก็ตามที่รันอยู่กับเซอร์วิสใดในเวลานั้น

สคริปต์เขียนทุกการรันไปที่ workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/scripts/benchmark_results_<timestamp>.csv เก็บมันไว้บนดิสก์ — มันเป็นหนึ่งในสองไฟล์ที่การประเมินในโมดูล 06 ต้องใช้ ดังนั้นอย่าลบมัน ระหว่างการรื้อระบบในขั้นที่ 5

ขั้นที่ 3 — ตัดสวิตช์ไปที่ ClickHouse

ช่องว่างของการย้ายระบบ producer ของ Snowflake ทำงานตลอดแล็บนี้ เขียนข้อมูลราว 60 การเดินทางต่อนาที สคริปต์ย้ายข้อมูลของโมดูล 03 จับภาพ TRIPS_RAW ตามที่มันเป็นตอน สคริปต์นั้นรัน — แถวที่เขียนหลังจากนั้นมีอยู่แต่ใน Snowflake ปิดช่องว่างนั้นก่อนตัดสวิตช์ เส้นทางการเขียน

รันทั้งสี่ขั้นด้านล่างตามลำดับ — ลำดับคือสิ่งที่ทำให้สองระบบสอดคล้องกัน:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse"
source .env && source .clickhouse_state
source .venv/bin/activate

# Step 1: Stop the Snowflake producer (freeze the dataset)
docker stop nyc_taxi_producer

# Step 2: Catch up the delta — only migrates rows with pickup_at newer than
# what's already in ClickHouse. Runs in seconds to minutes, not the original
# 40-50 minutes, because only the gap rows move.
python scripts/02_migrate_trips.py --resume

# Step 3: Refresh the analytics tables with the newly migrated rows
cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/dbt/nyc_taxi_dbt_ch"
dbt run
cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse"

# Step 4: Start the ClickHouse producer
source .env && source .clickhouse_state
./scripts/03_cutover.sh

อย่าข้ามขั้นที่ 2 --resume อ่าน max(pickup_at) ที่มีอยู่ใน ClickHouse แล้วเพิ่ม ฟิลเตอร์ WHERE PICKUP_DATETIME > <watermark> ให้กับคิวรีของ Snowflake ดังนั้นมันถ่ายโอน เฉพาะแถวที่เขียนในช่วงและหลังการรันย้ายข้อมูลครั้งแรกของโมดูล 03 — แถวที่ ClickHouse ไม่เคยเห็น ถ้าตัดสวิตช์โดยไม่ทำ ClickHouse จะทิ้งการเดินทางที่ตกลงในหน้าต่างนั้นไปอย่าง ถาวร การตรวจสอบความเท่าเทียมในขั้นที่ 4 ถูกสร้างขึ้นเพื่อจับสิ่งนั้นพอดี แต่ต่อเมื่อขั้นตอนนี้ ได้รันก่อนแล้ว

./scripts/03_cutover.sh ถามให้ Type "cutover" to confirm แล้วทำขั้นที่ 1-3 ซ้ำเป็น ตะแกรงกันตกของตัวเอง: มันหยุด producer ของ Snowflake อีกครั้ง (ไม่มีผลถ้าคุณทำไปแล้ว), รัน dbt run อีกรอบ แล้วสร้างและเริ่ม producer ของ ClickHouse (nyc_taxi_ch_producer) สามสิบวินาทีหลัง producer เริ่มทำงาน มันยืนยันว่าแถวใหม่กำลังตกลงใน default.trips_raw และรัน dbt อีกครั้ง — การรันที่ในที่สุดก็ให้ agg_hourly_zone_trips มีแถวแรก ปิดช่องว่างที่ โมดูล 04 เปิดไว้โดยการออกแบบ

ตรวจสอบ:

-- Most recent trip should be within the last 60 seconds
SELECT max(pickup_at) AS most_recent_trip FROM default.trips_raw;

-- Row count should be increasing — wait 60 seconds and run again
SELECT count() FROM default.trips_raw;

-- agg_hourly_zone_trips should now have rows for the first time in the lab
SELECT count() FROM analytics.agg_hourly_zone_trips;

docker ps | grep nyc_taxi_ch_producer   # should show running

การรักษาความสดของเลเยอร์ analytics fact_trips และ agg_hourly_zone_trips เป็นโมเดล incremental ของ dbt — มันไม่รีเฟรชเอง 03_cutover.sh รัน dbt run หนึ่งครั้งหลังยืนยันว่า producer ทำงานอยู่ แต่แดชบอร์ดจะค่อย ๆ เก่าลงเมื่อการเดินทางใหม่สะสมขึ้น; รัน dbt run จาก dbt/nyc_taxi_dbt_ch ใหม่เมื่อไรก็ตามที่คุณอยากได้ตัวเลขปัจจุบัน (ในโปรดักชันคุณจะ ตั้งกำหนดเวลาสิ่งนี้ — cron, Airflow, dbt Cloud — แต่การรันตามต้องการก็เพียงพอสำหรับแล็บ) ในทางกลับกัน analytics.mv_live_trip_feed เป็น materialized view แบบ refreshable — dbt run ของโมดูล 04 สร้างมันไว้แล้วด้วย engine = 'ReplacingMergeTree(refreshed_at)' — แต่แล็บไม่เคยเปิดช่วงเวลารีเฟรชของมัน: คำสั่ง MODIFY REFRESH EVERY 30 SECOND ที่จะทำให้มันรันซ้ำด้วยตัวเองมีอยู่แค่ในรูปคอมเมนต์ ในไฟล์โมเดล การเปิดใช้มันเป็น ALTER TABLE คำสั่งเดียวที่คุณจะรันเอง; ถ้าไม่มีมัน mv_live_trip_feed จะอัปเดตเพียงครั้งเดียวตอนที่ dbt สร้างมัน

การตัดสวิตช์ย้อนกลับ หากคุณต้องยกเลิกขั้นตอนนี้และกลับไปใช้ producer ของ Snowflake:

docker stop nyc_taxi_ch_producer
cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/01-setup-snowflake/superset"
docker-compose --env-file ../.env up -d producer

ขั้นที่ 4 — ตรวจสอบความเท่าเทียม

ตอนนี้ที่รอบไล่ตามด้วย --resume ได้รันแล้วและ producer ของ ClickHouse ทำงานอยู่ ทั้งสอง ระบบควรอยู่ในภาวะเท่าเทียม ยืนยันมัน:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse"
source .env && source .clickhouse_state
bash scripts/01_verify_migration.sh

ผลลัพธ์ที่คาดไว้:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Migration Parity Check
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✓ ClickHouse default.trips_raw: 50,008,250 rows

  ✓ Snowflake NYC_TAXI_DB.RAW.TRIPS_RAW: 50,008,250 rows
  ✓ Row count parity: PASS  (difference: 0 rows = 0.0000%)

  ✓ trip_metadata populated: 50,008,250 non-empty rows
  pickup_at range: 2022-03-30   2026-03-31

  ✓ ClickHouse has 50,008,250 rows — migration looks complete
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

จำนวนแถวของคุณเองจะต่างออกไป สิ่งที่สำคัญคือบรรทัดความเท่าเทียม producer ของ Snowflake ถูกหยุดไปแล้วถึงจุดนี้ ดังนั้นไม่มีแถวใหม่ตกลงที่นั่น — จำนวนควรตรงกันเป๊ะ หรือคลาดกันไม่กี่ แถวถ้ามีแบตช์ที่ยังเดินทางอยู่ระหว่างรอบ --resume ซึ่งอยู่ในเกณฑ์ 0.01% ที่สคริปต์ตรวจสอบ อย่างสบาย

หากการตรวจสอบความเท่าเทียมล้มเหลว (ต่างกันมากกว่า 0.01%) ช่องว่างยังไม่ปิดสนิท — รันรอบไล่ตามอีกครั้งแล้วตรวจใหม่:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse"
source .env && source .clickhouse_state
python scripts/02_migrate_trips.py --resume
bash scripts/01_verify_migration.sh

ขั้นที่ 5 — รื้อระบบ

ก่อนรื้ออะไรก็ตาม ให้ยืนยันว่าการย้ายระบบอยู่ในสถานะสุดท้ายที่ถูกต้อง:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse"
source .env && source .clickhouse_state
bash scripts/01_verify_migration.sh

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/dbt/nyc_taxi_dbt_ch"
dbt test

เมื่อทั้งสี่ข้อผ่าน สองไฟล์คือทุกอย่างที่โมดูล 06 ต้องใช้ และทั้งสองรอดจากการรื้อระบบ: workshop_public/snowflake_migration_lab/02-plan-and-design/migration-plan.md และ workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/scripts/benchmark_results_<timestamp>.csv โมดูล 06 เป็นการประเมินแบบเขียนบนกระดาษ เปิดหนังสือได้ ใช้เวลาราว 60 นาที และไม่ต้องใช้ อะไรอย่างอื่น — ไม่มีเหตุผลที่จะเปิดเซอร์วิส ClickHouse Cloud ที่มีค่าใช้จ่ายไว้ตลอดช่วง การสอบแบบเขียน คัดลอกหรือจดเนื้อหาของทั้งสองไฟล์ไว้ที่ที่คุณเข้าถึงได้ แล้วรื้อทุกอย่าง:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse"
source .env && ./teardown.sh

สิ่งนี้ทำลายเซอร์วิส ClickHouse Cloud (ผ่าน terraform destroy) และคอนเทนเนอร์ producer การเดินทางของ ClickHouse หากมีการตัดสวิตช์ไปแล้ว

ทรัพยากร Snowflake ของส่วนที่ 1 ไม่ถูกรื้อโดยสคริปต์นี้ ให้รื้อฝั่ง Snowflake แยกต่างหาก:

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/01-setup-snowflake"
source .env && ./teardown.sh

วิธีตรวจสอบว่าคุณทำเสร็จแล้ว

ถึงจุดนี้ในโมดูล คุณควรได้ยืนยันตามลำดับแล้วว่า:

• การตรวจสอบความเท่าเทียมผ่าน — 01_verify_migration.sh ในขั้นที่ 4 รายงาน PASS โดยส่วนต่างของจำนวนแถวต่ำกว่า 0.01%
• CSV ของเบนช์มาร์กอยู่บนดิสก์ — ขั้นที่ 2 เขียน benchmark_results_<timestamp>.csv โดยคิวรีทั้ง 7 ตัวมีค่าความเร็วที่เพิ่มขึ้น และคุณเก็บมันไว้ก่อนการรื้อระบบในขั้นที่ 5
• มีแดชบอร์ด 7 ตัว — การตรวจ Superset ในขั้นที่ 1 แสดงแดชบอร์ด Snowflake 3 ตัวและ แดชบอร์ด CH — 4 ตัวเคียงข้างกัน
• producer ของ ClickHouse กำลังเขียน — บล็อกตรวจสอบในขั้นที่ 3 แสดงว่า default.trips_raw มีแถวเพิ่มขึ้นและ nyc_taxi_ch_producer ทำงานอยู่ ก่อนที่ขั้นที่ 5 จะหยุดมันเพื่อรื้อระบบ

หากข้อใดไม่เป็นจริงในเวลานั้น ให้ย้อนกลับไปที่ขั้นตอนที่เกี่ยวข้อง แทนที่จะรันการตรวจ เหล่านี้ใหม่ตอนนี้ — ขั้นที่ 5 ได้ทำลายเซอร์วิส ClickHouse Cloud ไปแล้ว และถ้ามีการ ตัดสวิตช์ ก็ทำลายคอนเทนเนอร์ producer ไปพร้อมกัน

สถานะปลายทาง

การย้ายระบบเสร็จสมบูรณ์และวัดผลแล้ว: ย้าย 50 ล้านแถวจาก Snowflake ไป ClickHouse และ ตรวจสอบว่าเท่าเทียมกันแล้ว, เบนช์มาร์กคิวรีเจ็ดตัวแบบชนกันตัวต่อตัวโดย ClickHouse เร็วกว่า ในทุกตัว, สร้างเลเยอร์ BI ขึ้นใหม่ด้วยแดชบอร์ด ClickHouse 4 ตัวเคียงข้างแดชบอร์ด Snowflake เดิม 3 ตัว และตัดสวิตช์เส้นทางการเขียนจาก Snowflake ไป ClickHouse อย่างถาวร สภาพแวดล้อม คลาวด์ทั้งสองถูกรื้อแล้ว — ไม่มีเซอร์วิส ClickHouse Cloud, ไม่มีคอนเทนเนอร์ producer ของ ClickHouse และเมื่อการรื้อระบบของส่วนที่ 1 ได้รันแล้วด้วย ก็ไม่มี warehouse ของ Snowflake เช่นกัน

สองไฟล์รอดจากการรื้อระบบและเป็นทุกอย่างที่โมดูล 06 ต้องใช้: workshop_public/snowflake_migration_lab/02-plan-and-design/migration-plan.md และ workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/scripts/benchmark_results_<timestamp>.csv โมดูล 06 เป็นการประเมินแบบเขียนเปิดหนังสือ — เอาสองไฟล์นั้นไป ไม่ต้องเอาอย่างอื่น