แผนการเรียนรู้
/

สัปดาห์ที่ 6: วิวัฒนาการสู่
คลังข้อมูลบนคลาวด์

การเปลี่ยนผ่านจาก On-Premise สู่ความยืดหยุ่นของ Cloud-Native Architecture

หัวใจสำคัญของสัปดาห์นี้

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

Phase 2: Cloud Infrastructure Setup

ผลลัพธ์การเรียนรู้

1
อธิบายข้อจำกัดของคลังข้อมูลแบบเดิมและประโยชน์ของระบบบนคลาวด์ได้
2
วิเคราะห์สถาปัตยกรรม **Multi-cluster Shared Data** ของ Snowflake ได้
3
เปรียบเทียบการทำงานระหว่าง **Snowflake** และ **BigQuery** เบื้องต้นได้
4
ตั้งค่าสภาพแวดล้อมบนคลาวด์ (Compute/Storage) สำหรับโครงการได้

วิกฤตของคลังข้อมูลแบบเดิม (On-Premise)

1. การแข่งขันแย่งชิงทรัพยากร

งานโหลดข้อมูล (Load) และงานวิเคราะห์ (Query) แย่ง RAM/CPU เดียวกัน ทำให้ระบบล่ม

2. ความยากในการขยาย (Scalability)

ต้องซื้อฮาร์ดแวร์เพิ่มล่วงหน้าหลายเดือน และมักใช้งานไม่คุ้มค่าในช่วงนอกเวลาทำงาน

"ในอดีต เราต้องทำ Preplanning อย่างหนัก แต่ปัจจุบันเราเน้น **Rapid Iteration** (การทำซ้ำอย่างรวดเร็ว)"
กิจกรรมกลุ่ม (15 นาที)

คลังข้อมูลล่มในวันลดราคา!

สถานการณ์: วันที่ 11.11 (Double Day)

บริษัทอีคอมเมิร์ซของคุณมีผู้ใช้เพิ่มขึ้น 20 เท่า และฝ่ายการตลาดต้องการดูรายงานยอดขายแบบ Real-time ทุก 5 นาที แต่ระบบคลังข้อมูลแบบเดิมกำลัง **"อืด"** มาก

คำถาม:

  1. ปัญหาเกิดจากการรวมศูนย์ (Centralized) ของอะไรบ้าง?
  2. หากคุณแก้ปัญหาด้วยการซื้อเซิร์ฟเวอร์เพิ่มหลังจบงาน 11.11 จะเกิดผลเสียอย่างไรในระยะยาว?

เฉลยขั้นตอนที่ 1: การวิเคราะห์ปัญหาโครงสร้างพื้นฐาน

1. สาเหตุของปัญหา

เกิดจาก **Resource Contention** (การแย่งชิงทรัพยากร) ระหว่างการโหลดข้อมูลสินค้าเข้า (Ingestion) และการสืบค้นรายงาน (Query) ที่ใช้ท่อประมวลผลเดียวกัน

2. ผลเสียระยะยาว

**Inflexibility:** หลังจากวัน 11.11 ระบบจะเหลือว่าง (Idle) แต่คุณยังต้องจ่ายค่าบำรุงรักษาฮาร์ดแวร์มหาศาล (Sunk Cost)

"นี่คือเหตุผลที่เราต้องการความยืดหยุ่น (Elasticity) ของ Cloud DW!"

การแยกส่วนพื้นที่จัดเก็บและการประมวลผล

สถาปัตยกรรมของ Snowflake :

Cloud Services

บริหารจัดการ, Metadata, ความปลอดภัย

Virtual Warehouse

ส่วนประมวลผล (Compute) ที่ยืดหยุ่นและขยายได้อิสระ

Database Storage

พื้นที่จัดเก็บข้อมูลแบบรวมศูนย์ที่รองรับได้ไม่จำกัด

"Workload Isolation: การตลาดและวิศวกรรมใช้ CPU แยกกัน แต่เห็นข้อมูลเดียวกัน!"

นิยามความสำเร็จบนคลาวด์

Scalability (ขยายขนาด)

"รองรับข้อมูลระดับ Petabytes"

  • • เพิ่มพลังประมวลผลตามความซับซ้อนของ Query
  • • ไม่มีการจำกัดพื้นที่จัดเก็บข้อมูลเบื้องหลัง
  • • สามารถให้บริการผู้ใช้พร้อมกัน (Concurrency) ได้หลักพันคน

Elasticity (ความยืดหยุ่น)

"จ่ายเท่าที่ใช้ (On-demand)"

  • • เปิด-ปิด ส่วนประมวลผลได้ทันทีเมื่อไม่มีการใช้งาน
  • • ปรับขนาดจากเซิร์ฟเวอร์จิ๋วเป็นซูเปอร์คอมพิวเตอร์ในไม่กี่วินาที
  • • เหมาะสำหรับงานที่มีความผันผวนสูง (Spiky workloads)
เวิร์กชอป: การคำนวณต้นทุน (20 นาที)

เปรียบเทียบ TCO (Total Cost of Ownership)

โจทย์: บริษัท E-Commerce ต้องประมวลผลรายงานใหญ่ 2 ฉบับต่อวัน

Option A: On-Premise

ซื้อเซิร์ฟเวอร์ $50,000 (ใช้ได้ 3 ปี) ค่าดูแล \$2,000/เดือน ไม่ว่ารายงานจะรันกี่ชั่วโมงก็ตาม

Option B: Cloud DW

ไม่มีค่าเริ่มต้น ค่าประมวลผล \$10 ต่อชั่วโมง (รันรายงานละ 1 ชม.) ค่าจัดเก็บคงที่ \$50/เดือน

จงคำนวณต้นทุนต่อเดือนของทั้งสองตัวเลือก!

เฉลยขั้นตอนที่ 2: การคำนวณเปรียบเทียบต้นทุน

ต้นทุน Option A:

  • • ค่าตัดจำหน่ายเซิร์ฟเวอร์ (\$50,000 / 36 เดือน) \$1,388
  • • ค่าดูแลรักษาพนักงานและไฟฟ้า \$2,000
  • • รวมต่อเดือน: **\$3,388**

ต้นทุน Option B:

  • • ค่ารันรายงาน (\$10 x 2 ฉบับ x 30 วัน) \$600
  • • ค่าจัดเก็บข้อมูล \$50
  • • รวมต่อเดือน: **\$650**
💡 บทสรุป: คลาวด์ช่วยลดค่าใช้จ่ายแฝง และเปลี่ยนจาก "ค่าใช้จ่ายลงทุน (CapEx)" เป็น "ค่าใช้จ่ายดำเนินการ (OpEx)"

อนาคต: คลังข้อมูลที่เพิ่มประสิทธิภาพด้วย AI

ในสถาปัตยกรรมคลาวด์สมัยใหม่ ML จะเข้ามาช่วยจัดการอัตโนมัติ:

  • Adaptive Indexing
    สร้างและลบดัชนี (Index) อัตโนมัติตามพฤติกรรมการใช้งานจริง
  • Workload Forecasting
    พยากรณ์ปริมาณงานล่วงหน้าและขยายขนาด Compute รอไว้
  • Cost Guardrail
    ใช้ ML ตรวจสอบ Query ที่ "แพงเกินจำเป็น" และแจ้งเตือนก่อนรัน

Project Phase 2 Kick-off

ภารกิจสัปดาห์นี้: การสร้าง "บ้าน" บนคลาวด์

  1. 1. สมัครบัญชี **Snowflake Free Trial** หรือใช้ **BigQuery Sandbox**
  2. 2. สร้าง **Database Storage** เพื่อรองรับข้อมูลโครงการอีคอมเมิร์ซ
  3. 3. ทดลองสร้าง **Virtual Warehouse (Compute)** ขนาดเล็ก (X-Small)
  4. 4. อัปโหลดไฟล์ตัวอย่าง (Kaggle Dataset) เข้าสู่ระบบ [Kaggle]

"เรากำลังเตรียมรากฐานสำหรับ Medallion Architecture ในสัปดาห์หน้า"

บทสรุปสัปดาห์ที่ 6

1. คลังข้อมูลบนคลาวด์แก้ปัญหา **Resource Contention** ด้วยการแยกส่วน Compute/Storage
2. **Elasticity** ช่วยให้ธุรกิจเปลี่ยนความไวได้ตามความต้องการ (Spiky Workloads)
3. **Zero-Management:** คุณไม่ต้องเป็นช่างซ่อมเซิร์ฟเวอร์ แต่เป็น "สถาปนิกข้อมูล" อย่างเต็มตัว
Next Week: Data Lakehouse & Medallion Architecture!