จาก Manual สู่การ Deploy อัตโนมัติ

Introduction to Databricks Lakehouse

Gang Wang

Senior Data Scientist

ปัญหาของการ Deploy แบบ Manual

$$

ตั้งค่า job ผ่าน UI ทีละรายการ
คัดลอก notebook ไปยัง production folder ด้วยตนเอง
การตั้งค่า เบี่ยงเบน ระหว่าง staging และ production
ไม่สามารถ ทำซ้ำ การ deploy ตั้งแต่ต้นได้

$$

recraft: half: บุคคลนั่งทำงานที่โต๊ะที่เต็มไปด้วยกระดาษโน้ตและเอกสารยุ่งเหยิง สื่อถึงความวุ่นวายของการ deploy แบบ manual

เหตุใดจึงสำคัญในระดับใหญ่

$$

โปรเจกต์ทั่วไปมี job, pipeline, cluster, permission และ schedule
แต่ละส่วนต้องตั้งค่าแยกกันใน UI
สมาชิกทีมลาออก — ความรู้เรื่องการตั้งค่า หายไปด้วย
เมื่อต้องตรวจสอบว่า "เดือนที่แล้วมีอะไรเปลี่ยนแปลง?" — ไม่มีคำตอบที่ชัดเจน

$$

recraft: half: ไวท์บอร์ดในออฟฟิศที่เต็มไปด้วยแผนภาพยุ่งเหยิง บันทึกที่ขีดฆ่า และเครื่องหมายคำถาม สื่อถึงความรู้ที่สูญหายและการตั้งค่าที่วุ่นวาย

Databricks Asset Bundles คืออะไร?

$$

radial: Databricks Asset Bundles

$$

ทุกอย่างอยู่ใน project folder เดียว จัดการเวอร์ชันด้วย Git และ deploy ด้วย คำสั่ง CLI คำสั่งเดียว

ข้อดีของ DAB

$$

ทำซ้ำได้ — deploy ด้วย config เดิมทุกครั้ง
ควบคุมเวอร์ชัน — ติดตามการเปลี่ยนแปลงใน Git
เลื่อน environment — dev → staging → prod
ผสาน CI/CD — ทำให้การ deploy ในไปป์ไลน์เป็นอัตโนมัติ

$$

recraft: half: สายการผลิตในโรงงานที่ผลิตกล่องเหมือนกันทุกใบบนสายพานลำเลียง สื่อถึงการ deploy อัตโนมัติที่ทำซ้ำได้

แบบดั้งเดิม vs. DAB

$$

	แบบดั้งเดิม	DAB
การตั้งค่า	คลิกใน UI	ไฟล์ YAML ใน Git
ทำซ้ำได้	Manual เกิดข้อผิดพลาดได้ง่าย	อัตโนมัติ สม่ำเสมอ
เลื่อน environment	คัดลอกและตั้งค่าใหม่	`bundle deploy --target prod`
ย้อนกลับ	สร้างใหม่จากความจำ	`git revert` + redeploy
การทำงานร่วมกัน	ทีละคน	Git workflow เต็มรูปแบบ

สรุป

$$

การ deploy ผ่าน UI แบบ manual นั้น เปราะบาง และไม่รองรับการขยายขนาด
Databricks Asset Bundles อธิบายโปรเจกต์ด้วย YAML
ข้อดี: ทำซ้ำได้, ควบคุมเวอร์ชัน, CI/CD, เลื่อน environment
ทุกอย่างอยู่ใน Git — แหล่งข้อมูลเดียวสำหรับการ deploy

มาฝึกกันเถอะ!

Introduction to Databricks Lakehouse

Preparing Video For Download...