LTAP: Bước ngoặt xóa bỏ quy tắc 40 năm, hợp nhất OLTP và OLAP trong một hệ thống

Jonathan Katz đã dành cả sự nghiệp của mình ở cả hai phía của một ranh giới mà hầu hết ngành công nghiệp dữ liệu đã chấp nhận sống chung. Là một người đóng góp lâu năm cho Postgres và hiện là Giám đốc Sản phẩm Cấp cao tại Databricks, ông đã chứng kiến các hệ thống vận hành và phân tích hoạt động như hai thế giới tách biệt, chỉ được kết nối với nhau bằng các đường ống (pipelines), các bản sao và sự thỏa hiệp.

Trong cuộc trò chuyện này, Jonathan giải thích lý do tại sao sự tách biệt đó tồn tại ngay từ đầu, tại sao các tác nhân AI (AI agents) lại là yếu tố cuối cùng phá vỡ nó, và cách LTAP thu hẹp khoảng cách này bằng việc tư duy lại nơi hai thế giới gặp nhau: không phải trong một công cụ duy nhất, mà là trong một lớp lưu trữ thống nhất.

Giả định mà các tác nhân AI đã phá vỡ

Ngành công nghiệp đã sống chung với sự tách biệt nghiêm ngặt giữa các hệ thống cơ sở dữ liệu vận hành và phân tích trong nhiều thập kỷ. Tại sao sự trỗi dậy của các tác nhân AI tự hành lại đang phá vỡ điều đó?

Jonathan Katz: Có hai thế giới dữ liệu. Dữ liệu vận hành là thứ bạn chạm vào khi xử lý một giao dịch thẻ tín dụng hoặc tìm kiếm gian lận: các truy vấn rất ngắn, nhanh, xem xét dữ liệu theo từng dòng. Dữ liệu phân tích là thứ bạn đã tích lũy trong nhiều tuần, nhiều tháng hoặc nhiều năm, và khi truy vấn, bạn đang xem xét trên toàn bộ tập dữ liệu. Cả hai đều cố gắng trả về câu trả lời nhanh nhất có thể, nhưng chúng thực hiện theo những cách hoàn toàn khác nhau.

Sự khác biệt đó không phải là ngẫu nhiên. Nó xuất phát từ vật lý. Nếu bạn lưu trữ dữ liệu theo hàng (rows), đó là cách bạn trả về một câu trả lời đơn lẻ nhanh nhất có thể. Nếu bạn lưu trữ theo cột (columns), đó là cách bạn quét và tổng hợp trên mọi thứ nhanh nhất có thể. Ngoài ra, theo thiết kế, một truy vấn phân tích có thể tiêu tốn toàn bộ tài nguyên của một hệ thống song song quy mô lớn để có được câu trả lời trên một tập dữ liệu rất lớn, trong khi một truy vấn vận hành được thiết kế để tiêu tốn ít tài nguyên nhất có thể trong khi vẫn trả về câu trả lời nhanh chóng. Những điều này dẫn đến hai cách tư duy rất khác nhau về việc thiết kế và quản lý hệ thống dữ liệu của bạn, và đòi hỏi các loại tối ưu hóa khác nhau.

Postgres, một trong những cơ sở dữ liệu được triển khai rộng rãi nhất trên hành tinh, được xây dựng dựa trên các hàng vì nó được tối ưu hóa cho các khối lượng công việc vận hành. Các công cụ phân tích được xây dựng dựa trên các cột vì lý do ngược lại. Do sự khác biệt vật lý cơ bản đó, hai hệ thống này luôn phải tách biệt, và bất cứ khi nào bạn muốn phân tích dữ liệu vận hành, bạn phải chuyển nó đi nơi khác.

Sự trỗi dậy của các tác nhân AI đã thay đổi những gì chúng ta cần từ cơ sở dữ liệu. Đó là một phần lý do tại sao kiến trúc của Lakebase tồn tại ngay từ đầu: các cơ sở dữ liệu được xây dựng để theo kịp cách các tác nhân thực sự làm việc. Ví dụ, các tác nhân được giao nhiệm vụ tìm kiếm gian lận hoặc các điểm bất thường, và những sự kiện đó xảy ra trong hàng trăm mili giây. Nhưng hệ thống đó cũng đang xử lý một khối lượng lớn các lệnh ghi và đọc ngắn cùng một lúc. Một tác nhân đơn lẻ có thể đủ thông minh để biết nó cần chạy truy vấn nào. Một nhóm các tác nhân có thể dễ dàng làm quá tải một hệ thống vận hành nếu không có các rào chắn bảo vệ tại chỗ.

LTAP thực sự là gì

LTAP là gì, và nó thực sự hoạt động như thế nào bên dưới bề mặt?

Jonathan Katz: LTAP, viết tắt của Lake Transactional/Analytical Processing (Xử lý Giao dịch/Phân tích trên Hồ dữ liệu), cho phép bạn chạy các truy vấn phân tích trực tiếp trên dữ liệu vận hành trực tiếp mà không cần di chuyển dữ liệu đó đi bất cứ đâu và không gây tải lên hệ thống đang phục vụ các giao dịch của bạn. Nó thực hiện điều này bằng cách hợp nhất dữ liệu giao dịch và phân tích vào một lớp lưu trữ logic duy nhất thay vì buộc chúng phải đi qua các hệ thống riêng biệt được kết nối bằng một đường ống.

Bên dưới bề mặt, LTAP chỉ có thể thực hiện được nhờ cách kiến trúc của chính Lakebase: tính toán không trạng thái (stateless), tạm thời, hoàn toàn tách biệt với lưu trữ trong hồ dữ liệu. Sự tách biệt đó, được kế thừa từ Neon, có nghĩa là lớp lưu trữ bền vững có thể xử lý các lệnh ghi lưu lượng cao và định kỳ đẩy chúng xuống bộ lưu trữ đối tượng (object storage) để lưu trữ vĩnh viễn, độc lập với bất kỳ tác vụ tính toán nào đang chạy trên đó tại bất kỳ thời điểm nào. Vì dữ liệu đó đã được tối ưu hóa cho lưu trữ đám mây, tại sao không biểu diễn nó ở cùng định dạng cột mà Lakehouse đã sử dụng, để các công cụ như Apache Spark và SQL có thể đọc trực tiếp và có được các truy vấn phân tích hiệu suất cao mà không cần bản sao thứ hai?

Phần khó nhất là đảm bảo không có gì bị mất trong quá trình chuyển đổi. Postgres có các kiểu dữ liệu và mã hóa riêng, và các định dạng mở như Iceberg và Delta cũng có các định dạng riêng. Chúng tôi phải ghi dữ liệu ra theo cách bảo toàn chính xác biểu diễn vật lý của dữ liệu Postgres gốc, không thay đổi một bit nào, và đưa nó vào một tệp Parquet. Đó là mảnh ghép cho phép chúng tôi hợp nhất các biểu diễn vận hành và phân tích của cùng một dữ liệu thành một. Trên thực tế, lớp lưu trữ chạy theo hai tầng: một tầng "nóng" hơn giữ dữ liệu ở định dạng hàng để truy cập vận hành nhanh, và một tầng "lạnh" hơn giữ dữ liệu ở định dạng cột để đọc phân tích, vì vậy cả hai phía đều có thể nhận được những gì chúng cần một cách hiệu quả.

Tại sao LTAP thành công trong khi HTAP bị đình trệ

HTAP đã cố gắng giải quyết vấn đề phân tích thời gian thực nhiều năm trước và đã bị đình trệ. Tại sao việc thực hiện điều này ở lớp lưu trữ lakehouse lại thành công trong khi HTAP truyền thống thất bại?

Jonathan Katz: Bạn có thể làm cho các hệ thống HTAP hoạt động, nhưng chúng rất đắt đỏ. Chúng cồng kềnh, khó vận hành và nhìn chung không mở. Điều khác biệt về mô hình LTAP là bạn có được tính toán vận hành serverless và tính toán phân tích serverless như hai thứ riêng biệt. Bạn có thể tùy chỉnh chính xác lượng tài nguyên tính toán bạn đang sử dụng cho mỗi khối lượng công việc một cách độc lập, thay vì phải trả tiền cho một hệ thống cố gắng thực hiện cả hai công việc cùng một lúc. Lưu trữ là phần rẻ tiền của bất kỳ hệ thống dữ liệu nào. Tính toán mới là phần đắt đỏ.

Đó là toàn bộ lập luận cho việc hợp nhất lớp lưu trữ thay vì công cụ: bạn giữ được công cụ chuyên biệt, hiệu quả cho từng công việc, và bạn chỉ trả tiền cho tài nguyên tính toán ở nơi bạn thực sự cần, thay vì chạy một hệ thống đắt đỏ cố gắng trở nên giỏi mọi thứ cùng một lúc.

Điều gì xảy ra khi các tác nhân hành động dựa trên dữ liệu cũ

Hãy cho tôi biết một quy trình tác nhân cụ thể bị hỏng hoặc suy giảm hiệu suất ngày nay vì nó đang đọc và hành động dựa trên dữ liệu cũ. Điều gì thực sự xảy ra?

Jonathan Katz: Phát hiện gian lận là ví dụ rõ ràng nhất. Các giao dịch thẻ tín dụng được thanh toán trong hàng trăm mili giây hoặc ít hơn. Nếu tác nhân chịu trách nhiệm bắt gian lận đang làm việc dựa trên một bản sao dữ liệu cũ vài phút hoặc vài giờ, thì nó quá chậm để bắt được bất cứ điều gì trước khi giao dịch đã hoàn tất. Vì vậy, bạn muốn tác nhân đó làm việc trực tiếp với hệ thống vận hành.

Nhưng hệ thống vận hành đang xử lý một luồng ghi và đọc ngắn liên tục, và nó không được xây dựng để hấp thụ các truy vấn phân tích nặng. Nếu tác nhân chạy một truy vấn quét toàn bộ lịch sử mua hàng của khách hàng để kiểm tra các điểm bất thường, đó là một truy vấn đắt đỏ khi chạy trên một hệ thống được tối ưu hóa cho loại khối lượng công việc ngược lại. Nó có thể làm giảm hiệu suất của mọi giao dịch khác đang cố gắng thanh toán cùng lúc. Và một kiến trúc hiện đại thường cần dữ liệu từ cả hai phía vận hành và phân tích để đưa ra quyết định tốt, vì vậy tác nhân phải lấy dữ liệu từ cả hai. Một tác nhân có thể xử lý điều đó một cách có trách nhiệm. Một đội ngũ các tác nhân chạy các truy vấn tương tự cùng lúc có thể làm quá tải hệ thống vận hành nhanh chóng nếu không có gì kiểm soát lượng tải mà chúng được phép gây ra.

Quản trị, tính mở và trường hợp doanh nghiệp

Databricks triển khai LTAP cụ thể như thế nào ngày nay, và bạn sẽ mô tả điều đó như thế nào với một người đã hiểu tại sao HTAP lại thiếu sót?

Jonathan Katz: Ngoài các cơ chế lưu trữ, mảnh ghép quan trọng khác là danh mục (catalog). Một trong những đổi mới thực sự của Lakehouse là cung cấp cho các tổ chức một cái nhìn tập trung, thống nhất về tất cả dữ liệu của họ: ai có quyền truy cập vào cái gì, các chính sách nhất quán trên mọi thứ, để mọi người không thể đọc những thứ như số an sinh xã hội trừ khi họ thuộc nhóm đặc quyền. Điều đó chưa bao giờ thực sự áp dụng cho các hệ thống vận hành, vì các hệ thống vận hành được xây dựng như các kho dữ liệu biệt lập ngay từ đầu. Mối quan hệ giữa dữ liệu vận hành và phân tích từng là: bạn xây dựng một đường ống, bạn chuyển dữ liệu qua, và sau đó, chúc may mắn. Không ai sở hữu những gì xảy ra với nó ở hạ nguồn. LTAP đảo ngược điều đó. Đó là tất cả dữ liệu của bạn, trong một mô hình lưu trữ thống nhất, dưới một danh mục duy nhất. Bạn không bao giờ phải lo lắng về việc dữ liệu vận hành rời khỏi ranh giới quản trị chỉ vì ai đó cần phân tích nó.

Cũng có một lập luận về lý do tại sao điều này cần được xây dựng trên một nền tảng mở. Postgres đang tiến gần đến việc trở thành cơ sở dữ liệu được ưa chuộng thứ ba trên bảng xếp hạng của DB-Engines. Đó không nhất thiết là thước đo về mức độ áp dụng, nhưng đó là một tín hiệu mạnh mẽ về hướng đi của mọi thứ, và nó cho thấy giá trị của sự linh hoạt và lựa chọn. Nguồn mở đã thúc đẩy một số hệ thống quan trọng nhất trên thế giới trong nhiều thập kỷ. LTAP mở rộng cùng nguyên tắc đó. Ngay cả trong Postgres, dữ liệu của bạn có thể di chuyển giữa các hệ thống Postgres, nhưng bạn vẫn bị ràng buộc với Postgres. Với lớp lưu trữ thống nhất của LTAP, bạn không còn phải di chuyển dữ liệu xung quanh để có được công cụ phù hợp với nó nữa. Bạn đang mang công cụ đến với dữ liệu.

Sự thay đổi cốt lõi: lưu trữ thống nhất

Nếu bạn phải mô tả sự thay đổi cốt lõi mà LTAP đại diện trong một câu, dù bạn diễn đạt thế nào, bạn sẽ nói gì?

Jonathan Katz: Phiên bản đơn giản hóa là lưu trữ thống nhất. Nói điều đó với một người từ phía phân tích và họ hiểu ngay lập tức. Nói với một người từ phía vận hành và họ có thể hỏi bạn có ý gì. Nhưng một khi bạn có thể mang các biểu diễn vận hành và phân tích của cùng một dữ liệu lại với nhau mà không cần di chuyển bất cứ thứ gì, không cần thay đổi bất kỳ bit nào, nó sẽ giải quyết rất nhiều vấn đề mà trước đây cảm thấy không thể tránh khỏi. Tôi không cần chạy các đường ống nữa chỉ để đưa dữ liệu vào lớp đồng hoặc bạc. Tôi có thể bắt đầu phân tích nó ngay khi nó được ghi. Tôi cũng muốn đảo ngược lại: điều này ít nói về việc phát minh ra thứ gì đó mới mà nhiều hơn về việc mang hai thế giới lẽ ra không bao giờ nên tách biệt trở lại với nhau. Dữ liệu chỉ là dữ liệu. Chúng ta càng có thể đối xử với nó như vậy, thì mọi người, và bây giờ là các tác nhân, càng dễ dàng làm việc với nó mà không cần mọi người phải thương lượng qua một đường ống trước.

Mang cả hai thế giới trở lại với nhau

Trong bốn mươi năm, ranh giới giữa dữ liệu vận hành và phân tích vẫn tồn tại vì vật lý của lưu trữ đòi hỏi điều đó. Các tác nhân là khối lượng công việc đầu tiên không thể chịu đựng được sự chậm trễ mà ranh giới đó tạo ra. LTAP không cố gắng xóa bỏ sự khác biệt giữa một giao dịch và một truy vấn phân tích. Nó loại bỏ cái giá phải trả khi chạy cả hai trên cùng một dữ liệu. Đối với một Kiến trúc sư Dữ liệu đang đánh giá liệu một khối lượng công việc tác nhân có thực sự cần mô hình này hay không, bài kiểm tra mà Jonathan mô tả là một bài kiểm tra hữu ích: nếu quyết định tiếp theo của một tác nhân phụ thuộc vào dữ liệu vẫn đang ổn định, trên một hệ thống được xây dựng để giữ dữ liệu đó gần và được bảo vệ, thì mô hình đường ống và sao chép cũ sẽ không đủ nhanh. Đó là vấn đề cụ thể mà LTAP được xây dựng để giải quyết.

Để tìm hiểu thêm về LTAP, hãy đọc "Từ nguyên khối đến Lakebase đến LTAP: tư duy lại cơ sở dữ liệu từ lưu trữ trở lên".