# Databricks Lakebase Branching: Snorkel AI ให้ทุก PR มีฐานข้อมูลผลิตจริงของตัวเอง

> Databricks เผยกรณีศึกษา Lakebase Branching ที่ Snorkel AI สร้างฐานข้อมูลแยกต่อ pull request เสร็จไม่ถึง 1 นาที แทนการกู้คืน Aurora กว่า 30 นาที

- ประเภท: ข่าว · หมวด: Data & Analytics
- เผยแพร่: 2026-11-01T11:14:00.000Z · อัปเดต: 2026-11-01T11:14:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/data/lakebase-branching-ci-cd-snorkel-100-pr-databases/

## สรุปประเด็นสำคัญ

- Databricks เผยแพร่บล็อกเมื่อ **31 ตุลาคม 2026** (เวลาไทย) ว่า Snorkel AI ใช้ **Lakebase Branching** ให้ทุก pull request มี Postgres branch ของตัวเองที่คัดลอกจากข้อมูลจริงบนฐานข้อมูลขนาดประมาณ **2.5 TB**
- เวลาสร้างสภาพแวดล้อมทดสอบลดจาก **กว่า 30 นาที** (กู้คืน Aurora ราว 20 นาทีต่อชุด) เหลือ **ไม่ถึง 60 วินาที** ตามที่ Databricks ระบุ และออกแบบรองรับ **100 PR พร้อมกัน**
- branch เป็นแบบ copy-on-write แต่ละ PR เขียนข้อมูลเพิ่มราว **5 ถึง 10 GB** บนฐานราว **1 TB** และเมื่อกำหนดเวลาหมดอายุ (TTL) จะคิดค่าพื้นที่เฉพาะข้อมูลที่เปลี่ยน
- เอกสาร Databricks ปรับปรุงล่าสุด **30 ตุลาคม 2026** ระบุว่า branch ที่ไม่มีวันหมดอายุคิดค่าพื้นที่เต็มขนาดข้อมูล เหมือนฐานข้อมูลอิสระ จึงควรตั้ง TTL ทุกครั้ง
- Snorkel ใช้ Okta SSO กับนักพัฒนา และให้ CI รันเป็น service principal ที่ขอ OAuth token อายุสั้น ไม่มีรหัสผ่านฐานข้อมูลถาวรใน CI

Databricks เผยแพร่กรณีศึกษาเมื่อ 31 ตุลาคม 2026 ว่า Snorkel AI ใช้ Lakebase Branching ให้ทุก pull request มีฐานข้อมูล Postgres ของตัวเองที่สร้างจากข้อมูลผลิตจริงขนาดประมาณ 2.5 TB เสร็จไม่ถึง 60 วินาที แทนการกู้คืนสำเนา Amazon Aurora ที่ใช้เวลากว่า 30 นาที ทำให้ Lakebase Branching ช่วยให้ทีมรันชุดทดสอบกับข้อมูลจริงได้ทุก PR และรองรับราว 100 PR พร้อมกัน

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

## Lakebase Branching ทำงานอย่างไร

Lakebase คือ Postgres แบบ serverless ของ Databricks ที่แยกที่เก็บข้อมูลออกจากการประมวลผล เอกสารระบุว่า Lakebase Branching ให้สร้างสำเนาฐานข้อมูลแบบเขียนได้และแยกขาดจากต้นทางจากข้อมูลปัจจุบันหรือจุดเวลาในอดีต เหมือนการแตก branch ใน Git โดยสำเนาใช้เทคนิค copy-on-write คือแบ่งหน้าข้อมูลร่วมกับต้นทาง และเขียนหน้าใหม่เฉพาะส่วนที่ branch นั้นแก้ไข

ผลที่เอกสารระบุมีสามข้อ ได้แก่ branch ปรากฏทันทีและขนาดฐานข้อมูลไม่มีผลต่อเวลาสร้าง การสร้าง branch ไม่กระทบประสิทธิภาพของงานผลิตจริง และการเปลี่ยนแปลงใน branch ลูกไม่ย้อนขึ้นไปหา branch แม่ แม้แต่ role, GRANT และฐานข้อมูลที่สร้างใน branch หนึ่งก็ไม่ไปปรากฏใน branch อื่น เมื่อต้องการข้อมูลใหม่จากแม่ สั่ง reset branch ลูกให้ตรงกับแม่ได้โดยไม่ต้องเขียนสคริปต์เติมข้อมูลหรือรื้อสภาพแวดล้อม

## Snorkel AI ใช้ Lakebase Branching ใน pipeline อย่างไร

Snorkel รัน CI บน Kubernetes โดยทุก pull request ได้ namespace ชั่วคราวของตัวเอง ฐานข้อมูลผลิตจริงเป็น Aurora PostgreSQL การกู้คืนสำเนาให้แต่ละ namespace ใช้เวลาราว 20 นาที ซึ่งช้าเกินไปเมื่อนักพัฒนาเปิด PR ทั้งวัน ทางเลือกอื่นอย่างฐานข้อมูล staging ร่วมกัน ข้อมูลตัวอย่างย่อส่วน หรือข้อมูลสังเคราะห์ ก็พาปัญหาเดิมกลับมา คือชุดทดสอบรบกวนกัน สคีมาล้าสมัย และบั๊กที่เกิดเฉพาะกับรูปแบบข้อมูลจริง

ขั้นตอนที่บล็อกอธิบายมีสี่ขั้น

1. ใช้ AWS DMS ทำสำเนาข้อมูลจาก Aurora เข้า main branch ของโครงการ Lakebase ด้วยการโหลดเต็มครั้งแรกและตามด้วย change data capture ให้ main ตามหลังของจริงราว 2 นาที โดยเปิดโหมด Full LOB เพื่อรองรับค่า JSONB ขนาด 10 ถึง 20 MB
2. เมื่อมี PR ใหม่ CI เรียก Lakebase API ของ Lakebase Branching สร้าง branch จาก main พร้อมตั้งเวลาหมดอายุ แล้วส่งรายละเอียดการเชื่อมต่อให้ namespace ของ PR
3. แอปใน namespace เชื่อมต่อ branch ผ่าน Postgres มาตรฐาน รัน migration เขียนข้อมูล และเปลี่ยนสคีมาได้โดยไม่กระทบ main หรือ PR อื่น
4. เมื่อ PR ปิดหรือผ่านการทดสอบ pipeline ลบ branch และใช้ TTL เป็นตาข่ายสำรองถ้าขั้นตอนลบไม่ทำงาน

![แผนภาพจากบล็อก Databricks แสดงการไหลของข้อมูลจาก Aurora ผ่าน DMS เข้า main branch ของ Lakebase และแตก branch ให้แต่ละ PR](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/lakebase-branching-ci-cd-snorkel-100-pr-databases/lakebase-branching-architecture-aurora-dms.webp?v=99db0f26) _(ภาพ: Databricks)_

## ตัวเลข ความปลอดภัย และค่าใช้จ่ายของ Lakebase Branching

| หัวข้อ | ตัวเลขหรือเงื่อนไขตามบล็อกและเอกสาร Databricks |
| --- | --- |
| เวลาสร้างสภาพแวดล้อมต่อ PR | กว่า 30 นาที เหลือไม่ถึง 60 วินาที |
| ขนาดข้อมูลผลิตจริง | ประมาณ 2.5 TB (ส่วนที่ branch ใช้ร่วมกันบนที่เก็บข้อมูลหลัก บล็อกระบุว่าราว 1 TB) |
| จำนวน PR พร้อมกัน | ออกแบบรองรับราว 100 branch |
| พื้นที่เขียนเพิ่มต่อ PR | ราว 5 ถึง 10 GB |
| ความสดของข้อมูล | main ตามหลัง Aurora ราว 2 นาที |
| การใช้งานจริงพร้อมกัน | คาดว่ามี 20 ถึง 30 branch ที่รับทราฟฟิกพร้อมกัน ประมาณ 5 query ต่อวินาทีต่อ branch |
| ผู้ใช้ | นักพัฒนา 60 ถึง 70 คน |

ด้านความปลอดภัย Snorkel ให้ข้อมูลเดินทางผ่านเครือข่ายส่วนตัว ไม่ผ่านอินเทอร์เน็ตสาธารณะ นักพัฒนาเข้าสู่ระบบด้วย Okta ที่เชื่อมกับบัญชี Databricks และจัดสรรผ่าน SCIM ส่วน CI รันเป็น service principal ที่ขอ OAuth token อายุสั้นผ่าน Databricks SDK จึงไม่มีรหัสผ่านฐานข้อมูลถาวรใน pipeline และ audit log ของ Postgres บันทึกตัวตนของ service principal ในทุก query

![แผนภาพ copy-on-write จากบล็อก Databricks: branch ของแต่ละ PR ใช้หน้าข้อมูลร่วมกับ main และเขียนเพิ่มราว 5 ถึง 10 GB ก่อนถูกลบเมื่อ PR ปิดหรือ TTL หมด](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/lakebase-branching-ci-cd-snorkel-100-pr-databases/lakebase-branching-copy-on-write-storage.webp?v=620d4836) _(ภาพ: Databricks)_

เรื่องค่าใช้จ่าย เอกสารที่ปรับปรุงเมื่อ 30 ตุลาคม 2026 ระบุว่าคิดค่าประมวลผลกับค่าพื้นที่แยกกัน ค่าประมวลผลคิดเฉพาะชั่วโมงที่ทำงานจริงและย่อเหลือศูนย์เมื่อว่าง ส่วนค่าพื้นที่ของ branch ที่มี TTL คิดเฉพาะข้อมูลที่เปลี่ยน เช่น แก้ 1 GB บนฐาน 100 GB จ่ายราว 1 GB แต่ branch ถาวรที่ไม่มีวันหมดอายุคิดเต็มขนาดข้อมูลเหมือนฐานข้อมูลอิสระ

## ทำไมเรื่องนี้สำคัญ

การทดสอบกับข้อมูลที่ใกล้ของจริงเป็นสิ่งที่ทีมพัฒนาอยากทำแต่ทำไม่ได้ เพราะสำเนาเต็มช้าและแพง Lakebase Branching เปลี่ยนต้นทุนของสำเนาให้ขึ้นกับสิ่งที่แก้ไข ไม่ใช่ขนาดฐานข้อมูล บล็อกยังเสนอว่ารูปแบบเดียวกันใช้กับ AI agent ได้ โดยให้แต่ละงานของ agent มี branch ของตัวเอง อ่านและเขียนข้อมูลจริงได้ ตรวจสิ่งที่ agent เปลี่ยนก่อนนำไปใช้ หรือลบทิ้งโดยไม่มีอะไรต้องย้อนกลับ ซึ่งสอดคล้องกับทิศทางที่ Databricks วางหน่วยความจำของ agent ไว้บน Lakebase ตามที่เราเขียนไว้ใน[Databricks Agent Memory](/data/databricks-agent-memory-beta-lakebase/)

ข้อควรระวังของ Lakebase Branching คือบล็อกเป็นกรณีศึกษาของลูกค้ารายเดียวที่ Databricks เป็นผู้เล่า ตัวเลขเวลาและขนาดยังไม่ผ่านการทดสอบอิสระ และข้อมูลผลิตจริงที่ไหลเข้า branch ย่อมมีข้อมูลส่วนบุคคลติดไปด้วย

## สิ่งที่องค์กรควรทำ

- **วัดเวลาสร้างสภาพแวดล้อมทดสอบปัจจุบัน** ถ้าทีมยังกู้คืนสำเนาเต็มหรือใช้ staging ร่วมกัน ให้จดเวลาและจำนวนครั้งที่ชุดทดสอบรบกวนกัน เพื่อเทียบก่อนตัดสินใจย้ายไปแนวคิด branch
- **ตั้ง TTL เป็นค่าบังคับ** ตามเอกสาร Databricks Lakebase Branching แบบ branch ถาวรคิดค่าพื้นที่เต็ม จึงควรให้ pipeline ใส่วันหมดอายุทุกครั้ง และลบ branch เมื่อ PR ปิด
- **อย่าลอกข้อมูลส่วนบุคคลเข้าสภาพแวดล้อมทดสอบโดยไม่ป้องกัน** ข้อมูลลูกค้าที่ไหลเข้า main branch อยู่ในขอบเขต PDPA การมี branch 100 ชุดหมายถึงจุดเข้าถึงที่ต้องกำกับสิทธิ์เพิ่ม ควรพิจารณาการปกปิดข้อมูลก่อนทำสำเนา
- **แยกตัวตนคนกับ pipeline** ใช้ SSO กับนักพัฒนาและใช้ service principal กับ CI พร้อม token อายุสั้น เพื่อไม่ต้องเก็บรหัสผ่านฐานข้อมูลใน pipeline
- **ทดลอง Lakebase Branching กับ agent ก่อนเปิดสิทธิ์เขียนผลิตจริง** ให้ agent ทำงานบน branch แล้วให้คนตรวจความเปลี่ยนแปลงก่อนนำไปใช้ เป็นแนวทางที่บล็อกเสนอ

## บริการของ THAI DATA CLOUD ที่เกี่ยวข้อง

ข่าว Lakebase Branching นี้ชี้ว่าทีมพัฒนาไทยที่อยากให้ทุก pull request ทดสอบกับสภาพแวดล้อมใกล้ของจริงต้องมีเซิร์ฟเวอร์สำหรับรัน CI และชุดทดสอบที่สร้างและทิ้งได้เร็ว [Cloud Linux Server](https://thaidata.cloud/cloud-linux-server/) ของ THAI DATA CLOUD ให้เลือก Ubuntu, AlmaLinux หรือ Debian มี Root Access เต็มรูปแบบ และตั้งอยู่ใน Data Center ไทยและสิงคโปร์ (THAI DATA CLOUD เป็นผู้ดำเนินงานเว็บไซต์นี้)

ติดตามข่าวฐานข้อมูลและ Data Platform เพิ่มเติมได้ที่[หมวด Data](/data/)

## คำถามที่พบบ่อย

### Lakebase Branching คืออะไร?

Lakebase Branching คือความสามารถของ Lakebase ซึ่งเป็น Postgres แบบ serverless ของ Databricks ที่สร้างสำเนาฐานข้อมูลแบบเขียนได้ แยกจากต้นทาง ตามจุดเวลาใดก็ได้ เหมือนการแตก branch ใน Git โดยไม่คัดลอกข้อมูลตอนสร้าง

### Lakebase Branching ช่วยให้ทดสอบ CI/CD เร็วขึ้นแค่ไหน?

Databricks ระบุว่า Snorkel AI สร้างสภาพแวดล้อมต่อ pull request ได้ไม่ถึง 60 วินาที จากเดิมกู้คืนสำเนา Aurora ประมาณ 20 นาทีหรือกว่า 30 นาทีรวมขั้นตอนอื่น เป็นตัวเลขของลูกค้ารายเดียวที่ Databricks เล่าเอง ควรวัดกับงานของตัวเองก่อน

### ทำไมต้องตั้ง TTL ให้ branch ของ Lakebase?

เอกสารของ Databricks ระบุว่า branch ที่มีวันหมดอายุถูกคิดค่าพื้นที่เฉพาะข้อมูลที่เปลี่ยน แต่ branch แบบถาวรถูกคิดเต็มขนาดข้อมูลเหมือนฐานข้อมูลอิสระ การตั้ง TTL จึงกันค่าใช้จ่ายบานปลายจาก branch ที่ลืมลบ

### ใช้ Lakebase Branching กับ AI agent ได้หรือไม่?

ได้ บล็อกของ Databricks เสนอให้แต่ละงานของ agent ใช้ branch ของตัวเอง เพื่อให้ agent อ่านและเขียนข้อมูลจริงได้โดยไม่แตะฐานข้อมูลผลิตจริง ตรวจสิ่งที่ agent เปลี่ยนก่อนนำไปใช้ หรือลบ branch ทิ้งได้ทันที


## แหล่งอ้างอิง

- [Lakebase branching for CI/CD: lessons from 100 PR databases](https://www.databricks.com/blog/lakebase-branching-cicd-lessons-100-pr-databases) — Databricks
- [Branches | Databricks on AWS](https://docs.databricks.com/aws/en/oltp/projects/branches) — Databricks Documentation