Databricks Tuyên Bố Giải Quyết Vấn Đề Dữ Liệu Kéo Dài Hàng Thập Kỷ, Mở Đường Cho AI Agent Tốc Độ Cao Hơn? 🤔🚀
Suốt nhiều thập kỷ, các chuyên gia dữ liệu đã vật lộn với thử thách quản lý đồng thời cơ sở dữ liệu vận hành (operational) và phân tích (analytical) mà không gây ra độ trễ hay suy giảm hiệu suất. Vấn đề này càng trở nên nghiêm trọng hơn khi các tác nhân AI (AI agents) — những hệ thống liên tục suy luận và hành động dựa trên dữ liệu trực tiếp — xuất hiện, đòi hỏi một đường ống dữ liệu không có bất kỳ rào cản nào. 💡
Tại sự kiện Data + AI Summit vừa qua, Databricks đã tự tin tuyên bố tìm ra lời giải cho "bài toán thế kỷ" này bằng việc ra mắt hai sản phẩm đột phá: Lakehouse//RT và LTAP. Mục tiêu của họ là hợp nhất cơ sở hạ tầng dữ liệu, mang lại sự đơn giản và tốc độ cần thiết cho kỷ nguyên AI. ✨
"Chén Thánh" Cho Các Tác Nhân AI 🎯
Reynold Xin, đồng sáng lập Databricks, mô tả một kiến trúc dữ liệu đơn giản hơn là "chén thánh cho các tác nhân AI". Ông lập luận rằng, khi người dùng phát triển nhiều ứng dụng với code, các tác nhân AI cần phân tích trên các ứng dụng đó đòi hỏi cơ sở hạ tầng bên dưới phải hoạt động cực kỳ nhanh chóng và không gây cản trở.
> "Các tác nhân AI thực sự thích một kiến trúc đơn giản hơn nhiều, vì chúng có thể hoạt động nhanh hơn rất nhiều," Xin nhấn mạnh.
LTAP: Cuộc Cách Mạng Hợp Nhất Ở Lớp Lưu Trữ 💾
Nhiều nhà cung cấp đã cố gắng hợp nhất dữ liệu giao dịch và phân tích trong nhiều năm. Năm 2014, Gartner đã đặt ra thuật ngữ HTAP (Hybrid Transactional/Analytical Processing) để mô tả những nỗ lực này, với các tên tuổi như MemSQL (nay là SingleStore), SAP HANA và MySQL Heatwave của Oracle. Tuy nhiên, Databricks có quan điểm khác.
> "Đối với chúng tôi, HTAP giống như một thất bại của ngành công nghiệp hơn là một thành công," Xin thẳng thắn chia sẻ.
LTAP là câu trả lời của Databricks cho HTAP, nhưng với một cách tiếp cận khác biệt: hợp nhất dữ liệu ở lớp lưu trữ thay vì lớp công cụ xử lý. Theo LTAP, dữ liệu giao dịch gốc từ Postgres sẽ được lưu trữ trực tiếp dưới định dạng Delta hoặc Iceberg ngay từ thời điểm ghi, loại bỏ nhu cầu về các đường ống ETL (Extract, Transform, Load) phức tạp đã kết nối các hệ thống vận hành và phân tích trong hàng thập kỷ. PostgreSQL vẫn là công cụ giao dịch, còn Spark và Lakehouse đảm nhiệm vai trò công cụ phân tích.
> "Mục đích chính là, bạn sử dụng công cụ tốt nhất cho từng tác vụ ở cấp công cụ truy vấn, chúng tôi chỉ đảm bảo rằng lớp lưu trữ cơ bản là một bản sao dữ liệu duy nhất," Xin giải thích.
Thách thức kỹ thuật lớn nhất là độ trễ. Lưu trữ đối tượng (object storage) thường có thời gian phản hồi lên tới vài giây, quá chậm cho các tác vụ OLTP (Online Transaction Processing) yêu cầu hiệu suất dưới mili giây. Lakebase (dịch vụ cơ sở dữ liệu PostgreSQL không máy chủ trên đám mây của Databricks) giải quyết vấn đề này thông qua một lớp bộ đệm (caching layer). Việc chuyển đổi từ định dạng hàng sang cột diễn ra ở lớp bộ đệm này khi CPU rảnh rỗi, giúp nén dữ liệu hiệu quả hơn 10 lần và giảm đáng kể chi phí mạng giữa lớp bộ đệm và bộ lưu trữ đối tượng.
Lakehouse//RT: Tốc Độ Phản Hồi Thời Gian Thực Đến Mức Độ Mili Giây ⚡
Lakehouse//RT là giải pháp của Databricks cho vấn đề lớp phục vụ thời gian thực chuyên dụng – một hệ thống riêng biệt mà các doanh nghiệp thường duy trì song song với Lakehouse của họ để xử lý các truy vấn có độ trễ thấp. Điều này thường đi kèm với việc sao chép dữ liệu, quản trị phân tán và độ phức tạp đường ống mà các tác nhân AI không thể chấp nhận được.
Các khả năng chính của Lakehouse//RT bao gồm:
* Công cụ tính toán Reyden: Được xây dựng đặc biệt cho việc phục vụ đồng thời cao, độ trễ thấp, Reyden truy vấn trực tiếp các bảng Delta và Iceberg mà không cần di chuyển dữ liệu ra khỏi Lakehouse. * Độ trễ và thông lượng: Lakehouse//RT cung cấp độ trễ dưới 100ms với 12.000 truy vấn mỗi giây, thậm chí chỉ 10ms trên các tập dữ liệu nhỏ hơn và hiệu suất tốt hơn tới 16 lần so với các lớp phục vụ chuyên dụng hiện có. * Quản trị và truy cập dữ liệu: Mọi truy vấn đều chạy trong khuôn khổ quản trị của Unity Catalog mà không cần lớp quyền riêng biệt, không sao chép dữ liệu và không cần đường ống nạp dữ liệu.
Góc Nhìn Chuyên Gia: Điểm Khác Biệt Nằm Ở Đâu? 🧐
Trong khi các vấn đề mà Databricks giải quyết đã được ghi nhận rõ ràng trong các nhóm dữ liệu doanh nghiệp, các nhà phân tích lại nhìn nhận điểm khác biệt ở một khía cạnh khác.
Stephanie Walter, Trưởng nhóm Thực hành AI Stack tại HyperFRAME Research, chia sẻ với VentureBeat:
> "Các doanh nghiệp đã có HTAP, streaming, kho dữ liệu đám mây và kho dữ liệu vận hành trong nhiều năm. Điểm khác biệt chính là cách đóng khung AI theo tác nhân (agentic AI framing)."
Walter lưu ý rằng các tác nhân AI cần dữ liệu vận hành trực tiếp, ngữ cảnh lịch sử, quản trị, truy xuất và ghi lại trong cùng một quy trình làm việc. Tuy nhiên, bà cũng cảnh báo: "Đó là một lập luận kiến trúc mạnh mẽ, nhưng Lakebase vẫn phải chứng minh được rằng nó có thể đáp ứng độ trễ, độ tin cậy và sự trưởng thành trong vận hành mà các CIO mong đợi."
Mike Leone, nhà phân tích tại Moor Insights and Strategy, cũng đồng ý rằng con đường dẫn đến sự khác biệt thực sự không chỉ nằm ở khái niệm hợp nhất. Ông nhấn mạnh việc phân tích mở trên data lake hiện đã trở thành tiêu chuẩn chung.
> "Động thái ít phổ biến hơn là cho phép các ghi giao dịch cũng nằm trong các định dạng mở, để cơ sở dữ liệu vận hành không bị bó hẹp trong một hộp độc quyền trong khi chỉ có nửa phân tích là mở," Leone nói.
Ông bổ sung thêm rằng, cách tiếp cận định dạng mở, kết hợp với Lakehouse//RT truy vấn dữ liệu trực tiếp từ lake, mới là điều mang lại cho kiến trúc này một lý do đáng tin cậy để loại bỏ toàn bộ các hệ thống chuyên biệt. Tuy nhiên, thách thức lớn nhất vẫn là chứng minh rằng cả hai công cụ thực sự chia sẻ một bản sao dữ liệu mà không cần bước chuyển đổi âm thầm nào ở giữa.
Ý Nghĩa Cho Doanh Nghiệp 📈
Đối với các kỹ sư dữ liệu đang đánh giá kiến trúc của mình cho các tác vụ AI theo tác nhân, câu hỏi không còn là nên sử dụng công cụ "tốt nhất" nào cho mỗi tác vụ, mà là liệu việc chạy các công cụ riêng biệt có còn khả thi hay không.
* Rủi ro vận hành: Các doanh nghiệp đã xây dựng cơ sở dữ liệu vận hành riêng biệt, các lớp phục vụ thời gian thực và Lakehouse phân tích có thể coi những khoảng trống giữa chúng là gánh nặng bảo trì. Nhưng với các tác nhân AI, những khoảng trống đó biến thành rủi ro vận hành: một hệ thống suy luận qua các ranh giới quản trị sẽ tìm thấy sự không nhất quán nhanh hơn bất kỳ đội ngũ con người nào. ⚠️ * Thị trường đang thay đổi: Thị trường đang dần loại bỏ các lớp phục vụ chuyên biệt nhanh hơn hầu hết các lộ trình sản phẩm của nhà cung cấp dự kiến. Theo VB Pulse Q1 2026, ý định sử dụng truy xuất kết hợp đã tăng gấp ba lần từ 10.3% lên 33.3% trong quý, trong khi việc áp dụng cơ sở dữ liệu vector độc lập giảm đối với mọi nhà cung cấp được theo dõi. Logic hợp nhất tương tự hiện đang ảnh hưởng đến lớp phục vụ thời gian thực. * Kiến trúc truyền thống đã lỗi thời: Cách tiếp cận truyền thống – các công cụ "tốt nhất" cho mỗi loại công việc, với các đường ống nối giữa chúng – được xây dựng cho tốc độ tiêu thụ phân tích của con người. Các tác vụ AI theo tác nhân không chấp nhận kiến trúc đó.
> "Nỗi đau mà họ đang chỉ ra, tất cả việc sao chép và đồng bộ hóa giữa các hệ thống vận hành và phân tích, là có thật và rất tốn kém, và bất kỳ ai đang vận hành ở quy mô lớn đều cảm nhận được điều đó," Leone kết luận. ✅
Databricks đang đặt cược lớn vào việc hợp nhất dữ liệu để mở khóa tiềm năng thực sự của AI. Dù vậy, như các nhà phân tích đã chỉ ra, "lời hứa vàng" này vẫn cần thời gian để chứng minh hiệu quả và độ tin cậy trong môi trường doanh nghiệp thực tế. Chúng ta hãy cùng chờ xem!