DuckDB sử dụng RDBMS để giải quyết vấn đề "thay đổi nhỏ" trong kiến trúc Lakehouse

DuckDB sử dụng RDBMS để giải quyết vấn đề "thay đổi nhỏ" trong kiến trúc Lakehouse

Đội ngũ phát triển DuckDB đã tung ra DuckLake v1.0, một định dạng lakehouse sẵn sàng cho môi trường sản xuất nhằm giải quyết vấn đề hiệu suất do các thay đổi nhỏ gây ra. Giải pháp mới này sử dụng RDBMS để quản lý siêu dữ liệu, giúp tăng tốc độ truy vấn và nhập liệu vượt trội so với các định dạng hiện hành.

Vấn đề "thay đổi nhỏ" trong Lakehouse

DuckDB Labs, công ty đứng sau hệ quản trị cơ sở dữ liệu mã nguồn mở DuckDB, vừa phát hành phiên bản đầu tiên sẵn sàng cho sản xuất của định dạng lakehouse DuckLake. Động thái này diễn ra sau khi nhóm công bố "tuyên ngôn" DuckLake vào năm ngoái, hứa hẹn tái thiết kế khái niệm kết hợp kho dữ liệu (data warehouse) và hồ dữ liệu (data lake) trên một hệ thống duy nhất.

Về cơ bản, DuckLake đề xuất sử dụng hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) để quản lý siêu dữ liệu (metadata) trong các triển khai lakehouse dựa trên các định dạng bảng mở phổ biến như Apache Iceberg và Delta Lake. Điều này cho phép các kỹ sư sử dụng PostgreSQL, SQLite hoặc chính DuckDB làm cơ sở dữ liệu danh mục (catalog database) cho nhiệm vụ này.

Tại sao các thay đổi nhỏ lại gây hại cho hiệu suất?

Hannes Mühleisen, đồng sáng lập và CEO của DuckDB Labs, giải thích rằng vấn đề cốt lõi nằm ở cách các lakehouse hiện tại xử lý các thay đổi nhỏ. Khi bạn thêm một hàng dữ liệu vào bảng, hệ thống lakehouse truyền thống sẽ buộc phải ghi một tệp mới chỉ chứa hàng đó, đồng thời cập nhật một lượng lớn siêu dữ liệu và danh mục.

"Điều này rất kém hiệu quả, vì các định dạng như Parquet thực sự không muốn lưu trữ một hàng duy nhất, chúng muốn lưu trữ hàng triệu hàng," ông Mühleisen nói. "Việc truy xuất tất cả các tệp nhỏ này từ kho lưu trữ đối tượng (object store) cực kỳ kém hiệu quả vì bạn phải thực hiện tất cả các lần chuyển tải này."

Giải pháp "lách luật" bằng thiết kế tốt hơn

Cách tiếp cận của DuckLake sử dụng RDBMS siêu dữ liệu để gom nhóm (batch) các thay đổi nhỏ này, sau đó chuyển chúng sang định dạng Parquet trong các khối dữ liệu lớn hơn.

"Sự khác biệt về thiết kế chính giữa các định dạng hồ dữ liệu khác và DuckLake là chúng tôi có một cơ sở dữ liệu và chúng tôi không ngại sử dụng nó," Mühleisen nhấn mạnh. "Bây giờ, khi bạn thêm một hàng duy nhất, thay vì ghi một tệp mới vào kho lưu trữ đối tượng, chúng tôi sẽ thêm nó vào một bảng trong cơ sở dữ liệu. Cơ sở dữ liệu như PostgreSQL hay DuckDB xử lý các thay đổi nhỏ tốt hơn nhiều so với kho lưu trữ đối tượng."

Cơ sở dữ liệu siêu dữ liệu sẽ lưu trữ các thay đổi nhỏ (như thêm hoặc xóa hàng) cho đến khi chúng cuối cùng được "đẩy" (flush) trở lại Parquet dưới dạng một tệp tương đối lớn hơn, trong khi vẫn "hoàn toàn minh bạch với người dùng".

Hiệu suất ấn tượng

Trong một bài đăng trên blog đi kèm với bản phát hành 1.0, Pedro Holanda, kỹ sư chính của DuckDB Labs, cho biết các điểm chuẩn của công ty cho thấy truy vấn nhanh hơn 926 lần và tốc độ nhập liệu nhanh hơn 105 lần khi so sánh với Iceberg.

"Khi tôi viết bài đăng trên blog nói rằng chúng tôi có sự khác biệt 1.000 lần, tôi cảm thấy như 'Ồ, một số người sẽ tức giận', nhưng không ai tức giận cả. Họ nói rằng 'Đây là một vấn đề thực sự'," Holanda chia sẻ. "Thậm chí có người nói rằng chúng tôi đang gian lận về kiến trúc. Đó chính là điểm mấu chốt: gian lận bằng một thiết kế tốt hơn."

Tuy nhiên, các kỹ sư trong ngành vẫn tiếp tục xây dựng dựa trên kiến trúc lakehouse hiện có và cố gắng giải quyết các vấn đề tương tự. Một số chuyên gia cho rằng cộng đồng Iceberg đã đi khá xa trong việc giải quyết các vấn đề về danh mục siêu dữ liệu, trong khi DuckDB vẫn là một cơ sở dữ liệu non trẻ so với các "ông lớn" đã chiếm lĩnh thị trường.