# Databricks Transactions GA รันหลายคำสั่งข้ามหลายตารางแบบ atomic บน Delta Lake และ Iceberg

> Databricks Transactions แบบ multi-statement เปิดใช้ทั่วไปเมื่อ 16 ต.ค. 2026 ให้คำสั่งหลายชุดข้ามหลายตาราง Delta Lake และ Iceberg สำเร็จหรือยกเลิกพร้อมกัน

- ประเภท: ข่าว · หมวด: Data & Analytics
- เผยแพร่: 2026-10-19T12:13:00.000Z · อัปเดต: 2026-10-19T12:13:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/data/databricks-transactions-ga-delta-lake-iceberg/

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

- Databricks ประกาศ **Databricks Transactions** แบบ multi-statement และ multi-table เป็น **Generally Available** เมื่อ **16 ตุลาคม 2026** ใช้ได้กับตาราง Delta Lake และ Apache Iceberg ที่ Unity Catalog จัดการ (managed tables)
- มี 2 โหมด: **non-interactive** ใช้ `BEGIN ATOMIC` แล้ว commit หรือ rollback ให้อัตโนมัติ และ **interactive** ใช้ `BEGIN TRANSACTION` กับ `COMMIT` ที่สั่งเองผ่าน JDBC, ODBC หรือ PyODBC
- โหมด non-interactive ใช้ได้บน SQL warehouse, serverless และคลัสเตอร์ **Databricks Runtime 18.0** ขึ้นไป ส่วนโหมด interactive ใช้ได้บน SQL warehouse เท่านั้น
- transaction ถูก rollback อัตโนมัติเมื่อนานรวมเกิน **48 ชั่วโมง** และโหมด interactive จะ rollback เมื่อไม่มีความเคลื่อนไหว **10 นาที**
- Databricks อ้างผลทดสอบของตัวเองว่างาน ETL ที่มี transaction พร้อมกัน **20 รายการ** มี median latency ต่ำกว่าคลังข้อมูลแบบดั้งเดิม **4.7 เท่า**

Databricks ประกาศให้ Databricks Transactions แบบ multi-statement เปิดใช้ทั่วไป (Generally Available) เมื่อวันที่ 16 ตุลาคม 2026 ทำให้คำสั่ง SQL หลายคำสั่งที่แก้หลายตาราง Delta Lake และ Apache Iceberg สำเร็จหรือยกเลิกพร้อมกันเป็นหน่วยเดียว งานคลังข้อมูลที่เคยต้องอาศัยระบบ data warehouse แยกจึงย้ายมาอยู่บน lakehouse ได้มากขึ้น

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

![แผนภาพของ Databricks แสดง BEGIN TRANSACTION แล้ว MERGE และ UPDATE ก่อน COMMIT พร้อมกันไปยังตาราง fact_sales และ dim_customer](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/databricks-transactions-ga-delta-lake-iceberg/databricks-transactions-begin-commit-diagram.webp?v=e8509881) _(ภาพ: Databricks)_

## Databricks Transactions ทำงานอย่างไร

Databricks Transactions มีสองโหมดให้เลือกตามลักษณะงาน ตามเอกสารของ Databricks

| โหมด | วิธีเขียน | Commit / Rollback | เหมาะกับ |
| --- | --- | --- | --- |
| Non-interactive | `BEGIN ATOMIC ... END` | อัตโนมัติเมื่อสำเร็จ / อัตโนมัติเมื่อเกิด error | ลำดับงานตายตัว งานตามตารางเวลา |
| Interactive | `BEGIN TRANSACTION; ... COMMIT;` | สั่งเอง | งานที่มีเงื่อนไข การตรวจสอบและดีบัก การเชื่อมผ่าน JDBC, ODBC, PyODBC |

คำสั่งที่ใช้ใน transaction ได้ ได้แก่ `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `MERGE INTO`, `COPY INTO`, `EXECUTE IMMEDIATE` และคำสั่งตรวจสอบอย่าง `DESCRIBE TABLE`, `SHOW COLUMNS` และ `GET DIAGNOSTICS` ใช้คู่กับ stored procedure, temporary table และ SQL scripting ได้ และเขียนลง streaming table ได้ด้วย ระบบปลายทางจึงไม่ได้รับข้อมูลที่ยังประมวลผลไม่ครบ

ด้านธรรมาภิบาล transaction ยังทำตามนโยบาย attribute-based access control ของ Unity Catalog ทั้งตอนอ่านและเขียน รวมถึง row-level security และ column masking

## เงื่อนไขการใช้งานและข้อจำกัด

- **ตาราง** ทุกตารางที่เขียนต้องเป็น managed table ของ Unity Catalog แบบ Delta Lake หรือ Iceberg และเปิด Catalog commits
- **Compute** โหมด non-interactive ใช้ SQL warehouse, serverless หรือคลัสเตอร์ Databricks Runtime 18.0 ขึ้นไป โหมด interactive ใช้ SQL warehouse และ transaction บนข้อมูลที่แชร์ผ่าน OpenSharing ต้องใช้ Runtime 18.1 ขึ้นไป
- **เวลา** rollback อัตโนมัติเมื่อนานรวมเกิน 48 ชั่วโมง โหมด interactive จะ rollback เมื่อไม่มีความเคลื่อนไหว 10 นาที
- **การจัดการ error** โหมด non-interactive rollback ทันทีเมื่อมีคำสั่งผิดพลาด หรือใช้ `SIGNAL` เพื่อยกเลิกเมื่อกฎธุรกิจไม่ผ่าน ส่วนโหมด interactive ต้องสั่ง `ROLLBACK` เอง
- **แหล่งที่ไม่รองรับ transaction** อ่านได้ผ่าน hint `allow_nontransactional_read` แต่เอกสารเตือนว่าการอ่านแบบนี้ไม่ได้ผลเดิมซ้ำทุกครั้ง

![หน้าเอกสาร Transactions ของ Databricks แสดง Requirements ตาราง Unity Catalog managed แบบ Delta Lake หรือ Iceberg compute ที่รองรับ และตาราง Transaction modes แบบ Non-interactive กับ Interactive](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/databricks-transactions-ga-delta-lake-iceberg/databricks-transactions-docs-requirements.webp?v=2de46a06) _(ภาพ: Databricks (ภาพหน้าจอ))_

## ลูกค้าที่ใช้แล้วและตัวเลขที่ Databricks อ้าง

Databricks ยกตัวอย่าง Fivetran ที่ใช้ Databricks Transactions กับ History Mode ซึ่งเก็บทุกเวอร์ชันของข้อมูลแบบ SCD Type 2 ทุกการเปลี่ยนแปลงต้องเขียนสองครั้ง คือปิดเวอร์ชันเดิมและเพิ่มเวอร์ชันใหม่ Egidio Terra จาก Fivetran บอกว่าการ commit สองขั้นตอนเป็นหน่วยเดียว "let Fivetran remove an entire class of consistency-repair code" หรือทำให้ตัดโค้ดซ่อมความสอดคล้องของข้อมูลออกได้ทั้งกลุ่ม ส่วน Accolade ใช้ประมวลผลข้อมูลการเคลมและหนี้สินราว 1,700 transaction ต่อวัน

ด้านความเร็ว Databricks ระบุว่า row-level concurrency ให้ transaction หลายรายการเขียนตารางเดียวกันได้พร้อมกันถ้าไม่ได้แก้แถวเดียวกัน และแสดงกราฟว่างาน ETL ตัวแทนที่มี transaction พร้อมกัน 20 รายการมี median latency ต่ำกว่าคลังข้อมูลบนคลาวด์และแบบดั้งเดิม 4.7 เท่า กราฟไม่ได้ระบุว่าเทียบกับผลิตภัณฑ์ใด และเป็นผลที่ผู้ขายทดสอบเอง

![กราฟของ Databricks เรื่อง Performance of Concurrent Transactions at Scale งาน ETL ที่มี 20 transaction พร้อมกัน Lakehouse มี median latency ต่ำกว่าคลังข้อมูลแบบดั้งเดิม 4.7 เท่า](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/databricks-transactions-ga-delta-lake-iceberg/databricks-transactions-concurrency-latency-chart.webp?v=e68a9fc6) _(ภาพ: Databricks)_

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

Databricks อ้างว่าเป็นสถาปัตยกรรม lakehouse รายแรกที่รองรับ transaction หลายคำสั่งแบบ native ทั้งบน Delta Lake และ Iceberg และชี้ปัญหาสามข้อของการแยกคลังข้อมูลไว้อีกระบบ

- **สำเนาและการย้ายข้อมูลเพิ่ม** ทำให้ข้อมูลช้าลง ต้นทุนสูงขึ้น และเสี่ยงที่สองฝั่งไม่ตรงกัน
- **ธรรมาภิบาลกระจัดกระจาย** ต้องดูแลสิทธิ์การเข้าถึงและการตรวจสอบซ้ำในหลายระบบ
- **โค้ดแก้ความไม่สอดคล้อง** นักพัฒนาต้องเขียน orchestration การกระทบยอด และการลองใหม่เอง

transaction หลายตารางเป็นหนึ่งในเหตุผลหลักที่องค์กรยังต้องคงคลังข้อมูลแยกไว้คู่กับ data lake การที่ Databricks Transactions รองรับทั้ง Delta Lake และ Iceberg ลดเหตุผลที่ต้องคัดลอกข้อมูลไปไว้สองที่ และทำให้รูปแบบอย่าง Write-Audit-Publish ทำได้ในขั้นตอนเดียว คือเขียนข้อมูลใหม่ ตรวจคุณภาพ แล้วเผยแพร่พร้อมกัน หรือยกเลิกทั้งหมดถ้าไม่ผ่าน การแข่งขันระหว่าง lakehouse กับ data warehouse จึงย้ายจากเรื่องรูปแบบตารางไปเป็นเรื่องความสามารถด้านงานคลังข้อมูลแบบเดิม

## ผลต่อองค์กรไทย

- **ทบทวนงาน ETL ที่แก้หลายตาราง** งานอย่างตัดสต็อกพร้อมปรับสถานะคำสั่งซื้อ หรือบันทึกบัญชีคู่ เป็นกลุ่มแรกที่ควรย้ายมาใช้ transaction แล้วตัดโค้ดซ่อมข้อมูลที่เขียนไว้เดิม
- **ตรวจความพร้อมของตาราง** ตารางต้องเป็น managed table ของ Unity Catalog และเปิด Catalog commits ทีมที่ยังใช้ external table หรือ Hive metastore ต้องวางแผนย้ายก่อน
- **เลือกโหมดให้ตรงงาน** งานตามตารางเวลาใช้ `BEGIN ATOMIC` เพื่อให้ rollback อัตโนมัติ ส่วนเครื่องมือ BI หรือแอปที่ต่อผ่าน JDBC/ODBC ใช้โหมด interactive บน SQL warehouse และต้องจัดการ `ROLLBACK` เมื่อเกิด error
- **วัดผลด้วยงานจริงก่อนตัดสินใจย้ายคลังข้อมูล** ตัวเลข 4.7 เท่าเป็นผลทดสอบของ Databricks เอง ควรทดสอบกับข้อมูลและปริมาณงานขององค์กรก่อนเลิกใช้คลังข้อมูลเดิม
- **ใช้ร่วมกับ column masking ตาม PDPA** นโยบายปิดบังข้อมูลส่วนบุคคลใน Unity Catalog ยังมีผลภายใน transaction ช่วยให้ขั้นตอน stage–validate–publish ของข้อมูลลูกค้าไม่เปิดเผยข้อมูลเกินสิทธิ์

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

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

### Databricks Transactions คืออะไร?

Databricks Transactions คือความสามารถให้รันคำสั่ง SQL หลายคำสั่งข้ามหลายตารางเป็นหน่วยเดียว ถ้าทุกคำสั่งสำเร็จจะ commit พร้อมกัน ถ้าคำสั่งใดล้มเหลวจะ rollback ทั้งหมด เปิดใช้ทั่วไปเมื่อ 16 ตุลาคม 2026 สำหรับตาราง Delta Lake และ Apache Iceberg ที่ Unity Catalog จัดการ

### ใช้ Databricks Transactions ต้องมีอะไรบ้าง?

ตารางที่เขียนต้องเป็น managed table ของ Unity Catalog แบบ Delta Lake หรือ Iceberg และเปิด Catalog commits ไว้ โหมด non-interactive ใช้บน SQL warehouse, serverless หรือคลัสเตอร์ Databricks Runtime 18.0 ขึ้นไป ส่วนโหมด interactive ใช้บน SQL warehouse

### Databricks Transactions ต่างจาก transaction ใน data warehouse ทั่วไปอย่างไร?

Databricks บอกว่า Databricks Transactions ทำงานบนรูปแบบตารางเปิดอย่าง Delta Lake และ Iceberg ไม่ต้องย้ายข้อมูลไปเก็บในคลังข้อมูลแยก และใช้ row-level concurrency ให้หลาย transaction เขียนตารางเดียวกันได้พร้อมกัน ถ้าไม่ได้แก้แถวเดียวกัน ต่างจากคลังข้อมูลที่ใช้ lock เรียงการเขียน

### transaction ที่ค้างไว้นานจะเกิดอะไรขึ้น?

เอกสารของ Databricks ระบุว่า transaction ทุกแบบจะถูก rollback อัตโนมัติเมื่อนานรวมเกิน 48 ชั่วโมง โหมด interactive จะ rollback เมื่อไม่มีความเคลื่อนไหว 10 นาที และถ้าคำสั่งในโหมด interactive ล้มเหลว ต้องสั่ง ROLLBACK เองเพื่อล้างสถานะ


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

- [Transactions are Generally Available, advancing warehousing on the Lakehouse](https://www.databricks.com/blog/transactions-are-generally-available-advancing-warehousing-lakehouse) — Databricks
- [Transactions | Databricks on AWS](https://docs.databricks.com/aws/en/transactions/) — Databricks