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

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

โดย กองบรรณาธิการ THAI DATA19 ต.ค. 2026 19:13 น. อ่าน 4 นาที

แชร์Facebook X LINE LinkedIn

ภาพ: Databricks

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

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 Transactions แสดง BEGIN TRANSACTION ตามด้วย MERGE และ UPDATE แล้ว COMMIT ไปยังตาราง fact_sales และ dim_customer พร้อมกัน — แผนภาพของ Databricks แสดง BEGIN TRANSACTION แล้ว MERGE และ UPDATE ก่อน COMMIT พร้อมกันไปยังตาราง fact_sales และ dim_customer ภาพ: 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 และ Transaction modes — หน้าเอกสาร Transactions ของ Databricks แสดง Requirements ตาราง Unity Catalog managed แบบ Delta Lake หรือ Iceberg compute ที่รองรับ และตาราง Transaction modes แบบ Non-interactive กับ Interactive ภาพ: 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 เท่า กราฟไม่ได้ระบุว่าเทียบกับผลิตภัณฑ์ใด และเป็นผลที่ผู้ขายทดสอบเอง

กราฟ Performance of Concurrent Transactions at Scale ของ Databricks เทียบ median latency ของงาน ETL ที่มี 20 transaction พร้อมกัน ระหว่างคลังข้อมูลแบบดั้งเดิมกับ Lakehouse ที่เร็วกว่า 4.7 เท่า — กราฟของ Databricks เรื่อง Performance of Concurrent Transactions at Scale งาน ETL ที่มี 20 transaction พร้อมกัน Lakehouse มี median latency ต่ำกว่าคลังข้อมูลแบบดั้งเดิม 4.7 เท่า ภาพ: 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

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

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 — Databricks
Transactions | Databricks on AWS — Databricks

บุคคล องค์กร และสถานที่ในข่าวนี้

เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว

องค์กรและบริษัท: Databricks11
ผลิตภัณฑ์และเทคโนโลยี: Apache Iceberg6 Unity Catalog6
กฎหมายและมาตรฐาน: PDPA90

แท็กDatabricks Transactions Data Warehouse Delta Lake

แชร์Facebook X LINE LinkedIn

พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ