DuckLake v1.0: The Lakehouse Format Built on SQL Reaches Production-Readiness

DuckDB Labs · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Thông báo phát hành của nhà cung cấp; giữ lại vì cho thấy một format tiến hoá trong một năm từ bản phác thảo tới bản production, và phần phụ lục phân loại công việc. Mọi nhận định là theo DuckDB Labs. Đọc cùng DuckDB Labs 2026 (cây file metadata của Iceberg) và DuckDB Labs 2026.

Bối cảnh

• Manifesto 5/2025: theo DuckDB Labs, metadata của lakehouse nên nằm trong một database (catalog) chứ không rải thành file trên object storage như Iceberg và Delta. Catalog là bất kỳ hệ nào nói SQL, có primary key và lưu được bảng: SQLite, PostgreSQL, hoặc chính DuckDB. Dữ liệu vẫn là Parquet trên object storage.
• Trong năm đầu: thêm Parquet có sẵn mà không chép, tương thích Iceberg, kiểu geometry và variant, script migrate từ DuckDB sang DuckLake.

Thay đổi chính (v1.0, 4/2026)

• Spec ổn định, cam kết tương thích ngược; bản tham chiếu là extension ducklake trong DuckDB 1.5.2. Nâng cấp extension không còn tự migrate catalog, migration phải bật rõ ràng.
• Data inlining bật mặc định (ngưỡng 10 dòng), nay gồm cả delete và update: thay đổi nhỏ ghi vào catalog, CHECKPOINT mới đổ ra Parquet.
• Sorted tables (sắp khi compaction, flush, và tuỳ chọn lúc insert) để thu hẹp cận min/max và bỏ được nhiều file; bucket partitioning bằng murmur3 như Iceberg cho cột cardinality cao.
• Variant (nhị phân, nhiều kiểu hơn JSON, tách được thành cột nguyên thuỷ có thống kê); thống kê bounding box cho geometry; deletion vector kiểu Iceberg v3 (thử nghiệm).
• Phụ lục: 108 PR từ cuối 2025, trong đó 68 PR về độ tin cậy và tính đúng, 12 về hiệu năng, 12 refactor. Ví dụ lỗi đã sửa: retry khi commit đồng thời âm thầm làm mất delete đã inline; insert + delete đồng thời trên cùng bảng sinh dòng trùng; delete_orphaned_files có thể xoá chính catalog nếu nó nằm trong thư mục dữ liệu; deadlock khi inline delete. Hiệu năng: COUNT(*) lấy từ thống kê số dòng trong metadata thay vì quét Parquet (nhanh hơn 8–258 lần trên S3); cache một truy vấn metadata để bớt round-trip, "quan trọng với catalog Postgres ở xa".
• Áp dụng: extension nằm trong top 10 extension của DuckDB theo lượt tải; có client cho DataFusion, Spark, Trino, Pandas; MotherDuck có dịch vụ host; "hàng chục công ty" dùng ở production.
• Hướng tới: v1.1 inline cả variant cho catalog không hỗ trợ kiểu đó, nhiều deletion vector trong một file Puffin; v2.0 có thể có branching kiểu Git, phân quyền, materialized view tăng dần.

Vì sao

• Catalog là database thì commit là một giao dịch SQL, thay đổi nhỏ có chỗ lưu rẻ, và metadata không phình thành cây file; đổi lại mọi client phụ thuộc một database trung tâm (và round-trip tới nó) (Tách compute khỏi storage, Pipeline dữ liệu và analytics).
• Hai phần ba công việc để lên 1.0 là sửa tính đúng dưới ghi đồng thời và các đường dọn dẹp: phần khó của một format không nằm ở tính năng.

Bài học cho SWE

• "Production-ready" của một format lưu trữ chủ yếu là: tương thích ngược có cam kết, migration không tự động, và lỗi đồng thời được tìm ra bằng người dùng thật.
• Công cụ dọn dẹp (xoá file mồ côi) là chỗ nguy hiểm: phạm vi xoá phải giới hạn chặt (chỉ Parquet), không suy theo thư mục.
• Thống kê trong metadata trả lời được nhiều query mà không chạm dữ liệu.

Liên quan

• DuckDB Labs 2026 · DuckDB Labs 2026 · Grab 2026 · Snowflake 2026
• Pipeline dữ liệu và analytics · Tách compute khỏi storage