LTAP ของ Databricks ผสาน OLTP‑OLAP บน Lakehouse เพื่อตอบโจทย์ AI แบบเรียลไทม์

Lead: บริษัทเทคโนโลยีหลายแห่งกำลังทบทวนแนวคิด “lakehouse” ที่เคยเป็นมาตรฐานใหม่สำหรับการจัดเก็บข้อมูลขนาดใหญ่ หลังจากที่ Databricks เปิดตัวโซลูชัน LTAP (Lake Transactional/Analytical Processing) ซึ่งพยายามรวมการทำธุรกรรมและการวิเคราะห์บนสำเนาเดียวของข้อมูล ผู้เชี่ยวชาญด้านสถาปัตยกรรมข้อมูลบ่งชี้ว่าแนวทางนี้อาจยังไม่ตอบโจทย์ความต้องการของระบบเอเจนต์ AI ที่ต้องการทำงานแบบเรียลไทม์และอยู่ภายใต้ข้อจำกัดเรื่อง data sovereignty

Overview

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

Databricks ตอบสนองด้วย LTAP ซึ่งสร้างขึ้นบนแพลตฟอร์ม Lakebase และใช้ฐานข้อมูล Postgres® serverless เป็นหัวใจ การออกแบบนี้พยายามทำให้การทำธุรกรรม (OLTP) สามารถเกิดขึ้นพร้อมกับการวิเคราะห์เชิงลึก (OLAP) บน “lakehouse” เดียวกัน โดยอ้างว่าเป็นการแก้ไขข้อจำกัดของสถาปัตยกรรมเดิมที่ต้องแยกระบบสองประเภท

อย่างไรก็ตาม ผู้เขียนบทความชี้ให้เห็นว่าการทำงานบน Lakehouse ยังคงมีพื้นฐานจาก object storage ซึ่งออกแบบมาสำหรับการสแกนข้อมูลขนาดใหญ่และการบันทึกแบบต่อเนื่อง (append‑heavy) ไม่ได้เหมาะกับลักษณะของธุรกรรมที่ต้องการความคงตัว (ACID) สูง การพยายามเพิ่มเลเยอร์ ACID ลงบน object storage จึงอาจทำให้ระบบ “ว่ายน้ำ” อยู่ในสภาพแวดล้อมที่ไม่เหมาะสม

The LTAP Approach

LTAP ทำหน้าที่เป็นชั้นกลางระหว่างการทำธุรกรรมและการวิเคราะห์โดยใช้ Postgres serverless ที่ทำงานบนคลังข้อมูลแบบ lakehouse ผู้พัฒนากล่าวว่าโซลูชันนี้สามารถให้บริการ “single copy” ของข้อมูลที่พร้อมสำหรับทั้งสองภาระงาน

ข้อดีของแนวคิดนี้คือ

• ลดความซับซ้อนของการจัดตั้ง pipelines ระหว่างระบบ OLTP และ OLAP
• ทำให้ผู้ใช้สามารถเรียกดูผลการวิเคราะห์ได้ทันทีหลังจากทำธุรกรรมเสร็จสิ้น

แต่ในทางปฏิบัติ การบังคับใช้ ACID บน object storage ยังต้องอาศัยเทคนิคเชิงวิศวกรรมที่ซับซ้อน ซึ่งอาจทำให้ประสิทธิภาพในการอ่าน‑เขียนข้อมูลระดับมิลลิวินาทีลดลงเมื่อเปรียบเทียบกับฐานข้อมูล operational core ที่ออกแบบมาเพื่อการทำธุรกรรมโดยเฉพาะ

Operational Core vs. Lakehouse

จากมุมมองของสถาปัตยกรรมข้อมูล การตัดสินใจเริ่มต้นที่ “core” หรือ “lake” มีผลต่อความสามารถในการขยายและตอบสนองต่อข้อกำหนดด้านกฎหมายอย่างชัดเจน

• Operational core ใช้ฐานข้อมูลเชิงปฏิบัติการ (เช่น Postgres) ที่ให้การคงตัวระดับแถว, การล็อกแบบ row‑level และ audit trail ที่เป็นมาตรฐานของระบบธุรกิจมานานกว่า 40 ปี
• Lakehouse สะท้อนความต้องการในการวิเคราะห์ข้อมูลขนาดใหญ่ แต่ยังคงอาศัย object storage ซึ่งให้ประสิทธิภาพด้านต้นทุนและการสเกลสูงในงาน batch

เมื่อเอเจนต์ AI ต้องทำการตัดสินใจโดยตรงบนข้อมูลที่ได้รับการควบคุม (governed) การทำงานบน operational core จะหลีกเลี่ยงขั้นตอน “ย้ายข้อมูลไปยัง lake” ที่อาจเพิ่มความล่าช้าและเสี่ยงต่อการละเมิดนโยบายการกำกับดูแล

Governance & Sovereignty

ข้อจำกัดเรื่อง data residency และ sovereignty เป็นประเด็นที่บริษัทขนาดใหญ่หลายแห่งให้ความสำคัญสูงสุด โดยเฉพาะธนาคาร โรงพยาบาล บริษัทโทรคมนาคมและหน่วยงานรัฐ ซึ่งต้องปฏิบัติตามกฎระเบียบที่กำหนดว่า “ข้อมูลต้องอยู่ในพื้นที่ที่กำหนด”

การใช้ Lakehouse ที่โฮสต์บนคลาวด์สาธารณะทำให้ผู้จัดการต้องยอมรับข้อจำกัดดังกล่าว เนื่องจากข้อมูลจะถูกเก็บไว้บน object storage ของผู้ให้บริการคลาวด์ การย้ายระบบบันทึกธุรกรรมหลักเข้าสู่คลาวด์จึงอาจไม่ใช่ทางเลือกที่เป็นไปได้สำหรับองค์กรเหล่านี้

ในทางตรงกันข้าม operational core ที่ทำงานบน Postgres สามารถติดตั้งได้หลายรูปแบบ ทั้ง on‑premises, hybrid หรือ multi‑cloud รวมถึงระบบแยกตัว (air‑gapped) ตามความต้องการของผู้กำกับดูแล ทำให้สามารถรักษาความสอดคล้องกับข้อบังคับด้านข้อมูลได้โดยไม่ต้องพึ่งพาโครงสร้างพื้นฐานของผู้จำหน่าย

Market Moves

แนวโน้มตลาดกำลังเปลี่ยนแปลงไปสู่การผสมผสานระหว่าง operational core และ lakehouse อย่างไรก็ตาม ผู้เล่นใหญ่ในวงการ lakehouse ได้เริ่มลงทุนเพื่อเติมเต็มช่องว่างนี้ ตัวอย่างเช่น บริษัทชั้นนำที่เคยเป็นผู้บุกเบิก lakehouse กำลังเร่งพัฒนาฐานข้อมูล Postgres ของตนเอง โดยใช้เงินประมาณ $1 พันล้าน ในการซื้อกิจการของ Neon** เพื่อเพิ่มความสามารถด้านฐานข้อมูลเชิงปฏิบัติการ

การเคลื่อนไหวนี้แสดงให้เห็นว่าตลาดรับรู้ถึงข้อจำกัดของโมเดล lakehouse‑first และกำลังมองหาวิธีผสานจุดแข็งของทั้งสองแบบเข้าด้วยกัน เพื่อรองรับความต้องการของเอเจนต์ AI ที่ทำงานตลอด 24/7 โดยไม่ละทิ้งข้อกำหนดด้านการควบคุมและประสิทธิภาพ

Analysis

จากมุมมองเชิงวิเคราะห์ การพัฒนาของ LTAP นั้นเป็นก้าวสำคัญที่ชี้ให้เห็นความพยายามของผู้ขายเทคโนโลยีที่จะทำให้ “transactional” และ “analytical” สามารถอยู่บนแพลตฟอร์มเดียวได้ อย่างไรก็ตาม แนวคิดนี้ยังต้องต่อสู้กับพื้นฐานทางเทคนิคของ object storage ที่ไม่รองรับการทำธุรกรรมระดับสูงอย่างเต็มที่

ดังนั้นองค์กรที่ต้องการความเร็วและความคงตัวแบบเรียลไทม์ ควรพิจารณา operational core เป็นจุดเริ่มต้น แล้วต่อยอดด้วยบริการ analytics หรือ vector search ที่เชื่อมต่อโดยตรงกับฐานข้อมูลเดียวกัน การทำเช่นนี้จะลดช่องโหว่ของการย้ายข้อมูลและเพิ่มความแม่นยำของการกำกับดูแล

ในขณะเดียวกัน ผู้ขาย lakehouse ควรพิจารณาปรับแนวทางจาก “lake‑first” ไปเป็น “core‑first” หรืออย่างน้อยให้มีตัวเลือกที่เปิดกว้างสำหรับการตั้งค่าแบบ on‑premises หรือ hybrid เพื่อดึงดูดกลุ่มลูกค้าที่ต้องปฏิบัติตามข้อกำหนดด้าน data sovereignty อย่างเคร่งครัด

Summary

แนวคิด LTAP ของ Databricks พยายามรวมธุรกรรมและการวิเคราะห์บนสำเนาเดียวของข้อมูล แต่ยังคงเผชิญกับความท้าทายทางเทคนิคของ object storage และข้อจำกัดด้านกฎหมายเกี่ยวกับ data sovereignty การพัฒนาตลาดกำลังเปลี่ยนไปสู่การผสมผสานระหว่าง operational core กับ lakehouse เพื่อให้เอเจนต์ AI ทำงานได้อย่างเรียลไทม์และปลอดภัยตามมาตรฐานที่กำหนด.