Databricks เผยรายละเอียดฟีเจอร์ Branching ของ Lakebase สำหรับการทดสอบ CI/CD
Databricks เผยรายละเอียดว่าฟีเจอร์ copy-on-write branching ของฐานข้อมูล Lakebase Postgres ช่วยลดเวลาในการจัดสรรฐานข้อมูลสำหรับ CI/CD ของลูกค้า Snorkel AI จากกว่า 30 นาที เหลือไม่ถึง 60 วินาที
คำตอบโดยย่อ
Databricks ประกาศอะไรเกี่ยวกับฟีเจอร์ branching ของฐานข้อมูล Lakebase สำหรับ CI/CD?
Databricks ระบุว่าฐานข้อมูล Lakebase ซึ่งเป็น Postgres แบบ serverless ใช้เทคนิค copy-on-write branching เพื่อให้แต่ละ pull request ใน CI/CD มีสำเนาข้อมูลจากฐานข้อมูลโปรดักชันที่แยกอิสระและเขียนได้ภายในเวลาไม่ถึง 60 วินาที จากเดิมที่ต้องใช้เวลากว่า 30 นาที ตามกรณีศึกษาของลูกค้า Snorkel AI ที่บริหารจัดการ branch พร้อมกันราว 100 รายการบนชุดข้อมูลขนาดประมาณ 2.5 เทราไบต์
ประเด็นสำคัญ
- Databricks ระบุว่าฟีเจอร์ copy-on-write branching ของ Lakebase ช่วยให้ลูกค้า Snorkel AI ลดเวลาในการจัดสรรฐานข้อมูลสำหรับ pull request ใน CI/CD จากกว่า 30 นาที เหลือไม่ถึง 60 วินาที
- ตามบล็อกโพสต์ระบุว่า Snorkel AI รัน branch สำหรับ pull request พร้อมกันราว 100 รายการบนชุดข้อมูลโปรดักชันขนาดประมาณ 2.5 เทราไบต์ โดยแต่ละ branch เพิ่มพื้นที่จัดเก็บข้อมูลสำหรับการเปลี่ยนแปลงของตัวเองเพียง 5 ถึง 10 กิกะไบต์เท่านั้น
- Databricks ระบุว่า branch รักษาความปลอดภัยของข้อมูลโปรดักชันผ่านเครือข่ายส่วนตัว ระบบ single sign-on ของ Okta สำหรับนักพัฒนา และโทเค็น OAuth แบบมีอายุสั้นสำหรับไปป์ไลน์ CI ที่ทำงานในฐานะ service principal
- การตั้งค่าวันหมดอายุของ branch จะลบ branch ของ pull request แต่ละรายการโดยอัตโนมัติเมื่อไม่จำเป็นต้องใช้งานแล้ว ซึ่ง Databricks ระบุว่าช่วยให้ต้นทุนการจัดเก็บข้อมูลใกล้เคียงกับขนาดของโปรดักชันรวมกับ branch ที่ใช้งานอยู่
- Databricks ระบุว่าแนวทาง branching แบบเดียวกันนี้สามารถให้งานของ AI agent แต่ละรายการมีสำเนาฐานข้อมูลที่แยกอิสระและใช้แล้วทิ้งเป็นของตัวเองได้
ปัญหาที่เกิดขึ้น
Snorkel AI บริษัทที่พัฒนาเครื่องมือสำหรับทีมพัฒนาข้อมูล AI ใช้ไปป์ไลน์ CI/CD บน Kubernetes โดยทุก pull request ที่เปิดไว้จะได้รับ namespace ชั่วคราวของตัวเองสำหรับการทดสอบ ตามข้อมูลจาก Databricks ระบุว่า Snorkel ต้องการทดสอบโค้ดกับข้อมูลจริงจากฐานข้อมูลโปรดักชันของตน ซึ่งเป็นคลัสเตอร์ Amazon Aurora PostgreSQL แต่การกู้คืนสำเนาฐานข้อมูลทั้งชุดใช้เวลาประมาณ 20 นาทีต่อหนึ่งสภาพแวดล้อม Databricks ระบุว่าความล่าช้านี้ไม่เหมาะกับรูปแบบการทำงานที่นักพัฒนาเปิด pull request อยู่ตลอดทั้งวัน ทำให้ Snorkel ไม่สามารถให้แต่ละ PR มีสำเนาฐานข้อมูลเป็นของตัวเองได้มาก่อน
แนวทางการทำ Branching ด้วย Lakebase
Databricks ระบุว่า Lakebase ซึ่งเป็นฐานข้อมูล Postgres แบบ serverless ช่วยให้ Snorkel สร้าง branch ใหม่ของฐานข้อมูลที่แยกอิสระและเขียนได้จากจุดเวลาใดก็ได้ คล้ายกับการสร้าง branch ใน Git โดย Databricks อธิบายว่า branch เหล่านี้ทำงานแบบ copy-on-write ซึ่งหมายความว่า branch ใหม่จะไม่คัดลอกข้อมูลใดๆ ในขณะสร้าง แต่จะใช้พื้นที่จัดเก็บข้อมูลร่วมกับ branch หลัก และจะเขียนข้อมูลใหม่เฉพาะในส่วนที่ branch นั้นมีการเปลี่ยนแปลงเท่านั้น ตามบล็อกโพสต์ระบุว่า Snorkel ใช้ AWS Database Migration Service เพื่อจำลองข้อมูลจากฐานข้อมูลโปรดักชัน Aurora ไปยัง Lakebase branch หลักที่เรียกว่า "main" โดยรักษาความต่างจากข้อมูลโปรดักชันให้อยู่ภายในราว 2 นาที ผ่านการจับการเปลี่ยนแปลงข้อมูลอย่างต่อเนื่อง (continuous change data capture) Databricks ระบุว่าไปป์ไลน์ CI ของ Snorkel จะเรียก Lakebase API เพื่อสร้าง branch ใหม่จาก main ทุกครั้งที่มีการเปิด pull request กำหนดเวลาหมดอายุให้กับ branch นั้น และลบ branch ทิ้งเมื่อ pull request ถูกปิด หากขั้นตอนการล้างข้อมูลนี้ไม่ทำงาน Databricks ระบุว่า branch จะหมดอายุโดยอัตโนมัติเมื่อครบกำหนดตามค่า time-to-live ที่ตั้งไว้
การควบคุมด้านความปลอดภัย
Databricks ระบุว่าข้อมูลโปรดักชันเคลื่อนย้ายระหว่าง Aurora, Lakebase และคลัสเตอร์ CI ของ Snorkel ผ่านเครือข่ายส่วนตัวแทนอินเทอร์เน็ตสาธารณะ บริษัทระบุว่านักพัฒนาของ Snorkel ยืนยันตัวตนผ่านระบบ single sign-on ของ Okta ที่เชื่อมต่อกับบัญชี Databricks ขณะที่ไปป์ไลน์ CI ทำงานในฐานะ service principal ของ Databricks ซึ่งขอรับโทเค็น OAuth แบบมีอายุสั้นผ่าน Databricks SDK Databricks ระบุว่าบันทึกการตรวจสอบ (audit log) ของ Postgres จะบันทึกตัวตนของ service principal ที่อยู่เบื้องหลังทุกคำสั่ง query ทำให้สามารถตรวจสอบย้อนกลับไปยังไปป์ไลน์ที่รันคำสั่งนั้นได้
ผลลัพธ์ที่ Databricks รายงาน
Databricks ระบุว่าเวลาในการจัดสรรฐานข้อมูลของ Snorkel ลดลงจากกว่า 30 นาที เหลือไม่ถึง 60 วินาที หลังจากนำฟีเจอร์ branching ของ Lakebase มาใช้ และระบบนี้ถูกออกแบบมาเพื่อรองรับ branch สำหรับ pull request พร้อมกันราว 100 รายการ บนชุดข้อมูลโปรดักชันขนาดประมาณ 2.5 เทราไบต์ ตามบล็อกโพสต์ระบุว่าแต่ละ branch ของ pull request จะเขียนข้อมูลที่เปลี่ยนแปลงเพิ่มเติมประมาณ 5 ถึง 10 กิกะไบต์บนฐานข้อมูลที่ใช้ร่วมกัน และ Snorkel ได้นำระบบนี้ไปใช้กับนักพัฒนา 60 ถึง 70 คนในหลายทีม Databricks อ้างคำพูดของนักพัฒนา Snorkel ที่ไม่เปิดเผยชื่อระบุว่า งานคัดลอกข้อมูลในอดีต "ใช้เวลาหลายชั่วโมงและมักเจอปัญหาคอขวดด้านเครือข่ายและปัญหาอื่นๆ กับแพลตฟอร์ม CI ต่างๆ" และทีมงานต้องการโซลูชันที่ตอบโจทย์ข้อกำหนดด้านความปลอดภัยและการปฏิบัติตามกฎระเบียบสำหรับข้อมูลที่ออกจาก virtual private cloud ของตน
การใช้งานนอกเหนือจาก CI/CD
Databricks ระบุว่ารูปแบบการทำ branching เดียวกันนี้สามารถนำไปใช้กับ AI agent ที่เขียนคำสั่ง SQL รันการโยกย้ายข้อมูล (migration) หรือเปลี่ยนแปลงข้อมูลได้ โดยแต่ละงานของ agent จะได้รับ branch ของตัวเองจากฐานข้อมูลหลัก เพื่อให้สามารถอ่านและเขียนข้อมูลได้โดยไม่ส่งผลกระทบต่อโปรดักชันหรือการทำงานของ agent อื่น บริษัทระบุว่า agent สามารถทำงานในฐานะ service principal ที่ใช้โทเค็น OAuth แบบมีอายุสั้น และ branch สามารถถูกตรวจสอบและลบทิ้งได้หากการเปลี่ยนแปลงของ agent ไม่เป็นที่ต้องการ หรือถูกล้างข้อมูลโดยอัตโนมัติผ่านการตั้งค่าวันหมดอายุ
ที่มา: บล็อก Databricks, "Lakebase branching for CI/CD: lessons from 100 PR databases," เผยแพร่เมื่อวันที่ 31 ตุลาคม 2026
คำถามที่พบบ่อย
- ฟีเจอร์ branching ของ Lakebase คืออะไร?
- Databricks ระบุว่าฟีเจอร์ branching ของ Lakebase ช่วยให้ผู้ใช้สร้างสำเนาฐานข้อมูล Postgres ที่แยกอิสระและเขียนได้จากจุดเวลาใดก็ได้ โดยใช้ระบบจัดเก็บข้อมูลแบบ copy-on-write ซึ่งคล้ายกับการสร้าง branch ใน Git
- Snorkel AI ใช้ฟีเจอร์ branching ของ Lakebase อย่างไร?
- ตามข้อมูลจาก Databricks ระบุว่า Snorkel AI ให้ทุก pull request ที่เปิดไว้มี Lakebase branch ของฐานข้อมูลโปรดักชัน Aurora PostgreSQL เป็นของตัวเองสำหรับการทดสอบ CI/CD ซึ่งมาแทนที่กระบวนการเดิมที่ต้องใช้เวลากว่า 30 นาทีต่อหนึ่งสภาพแวดล้อม
- Databricks ระบุว่าฟีเจอร์ branching ของ Lakebase ช่วยลดต้นทุนได้อย่างไร?
- Databricks ระบุว่าระบบจัดเก็บข้อมูลแบบ copy-on-write หมายความว่า branch จะใช้พื้นที่จัดเก็บเพิ่มเติมเฉพาะส่วนข้อมูลที่เปลี่ยนแปลงเท่านั้น และทรัพยากรประมวลผลของแต่ละ branch จะลดลงเป็นศูนย์เมื่อไม่มีการใช้งาน
- ฟีเจอร์ branching ของ Lakebase ใช้งานนอกเหนือจาก CI/CD ได้หรือไม่?
- Databricks ระบุว่ารูปแบบการทำ branching เดียวกันนี้ใช้ได้กับ AI agent ด้วย โดยให้งานของแต่ละ agent มี branch ฐานข้อมูลที่ใช้แล้วทิ้งเป็นของตัวเอง เพื่ออ่าน เขียน และทดสอบการเปลี่ยนแปลงโดยไม่ส่งผลกระทบต่อโปรดักชัน