Kỹ sư dữ liệu chuyển từ các stack big data phức tạp sang DuckDB và DuckLake

Sau gần hai thập kỷ làm kỹ sư dữ liệu, Matt Martin đã rời bỏ các framework tính toán phân tán nặng nề để ưu tiên những công cụ đơn giản hơn dựa trên SQL. Trong một nghiên cứu tình huống gần đây do đội ngũ DuckDB công bố vào ngày 29 tháng 10 năm 2026, Martin giải thích cách ông thay thế cơ sở hạ tầng phức tạp bằng DuckDB và định dạng bảng mới của nó, DuckLake. Hành trình của ông làm nổi bật xu hướng ngày càng tăng trong giới kỹ sư, những người ưu tiên sự dễ sử dụng và chi phí bảo trì thấp hơn so với khả năng mở rộng quy mô lớn mà khối lượng công việc thực tế của họ không hề cần đến.

Chuyện gì đã xảy ra

Sự nghiệp của Martin bắt đầu với việc thao tác thủ công trên bảng tính và macro VBA trước khi phát triển thành các pipeline SQL tự động. Khi khối lượng dữ liệu tăng lên, ông áp dụng các công cụ big data tiêu chuẩn ngành như Teradata, Google BigQuery và Apache Spark. Mặc dù mạnh mẽ, những hệ thống này lại gây ra nhiều ma sát trong quá trình vận hành. Ông mô tả việc phải dành hàng giờ để đồng bộ hóa các phiên bản Java Virtual Machine và giải mã các stack trace dài dòng cho những tác vụ thường không cần đến xử lý song song quy mô lớn. Sự phức tạp trong việc duy trì các cụm Spark cho các báo cáo thông thường đã trở thành nút thắt cổ chai thay vì là yếu tố hỗ trợ.

Vào khoảng năm 2022, Martin khám phá ra DuckDB, một cơ sở dữ liệu phân tích nhúng chạy cục bộ mà không cần phụ thuộc bên ngoài. Ông nhận thấy có thể truy vấn trực tiếp các tệp CSV, Parquet và Iceberg bằng SQL tiêu chuẩn, loại bỏ hoàn toàn nhu cầu quản lý cụm. Sự đơn giản này dẫn dắt ông đến với DuckLake, một định dạng bảng mới lưu trữ metadata trong cơ sở dữ liệu SQL thay vì dưới dạng vô số tệp nhỏ. Martin báo cáo rằng các thao tác catalog vốn mất vài giây với Apache Iceberg nay được giải quyết trong chưa đầy một mili-giây với DuckLake, giúp tăng tốc đáng kể việc lập kế hoạch và thực thi truy vấn.

Chi tiết chính

• Martin chuyển từ Apache Spark và Google BigQuery sang DuckDB để giảm bớt chi phí hạ tầng cho các khối lượng công việc không ở mức petabyte.
• DuckLake lưu trữ metadata của bảng trong một cơ sở dữ liệu SQL, tránh được sự suy giảm hiệu suất do hàng nghìn tệp metadata nhỏ gây ra ở các định dạng như Iceberg.
• Phiên bản alpha sắp tới của DuckDB v2.0 giới thiệu I/O bất đồng bộ (asynchronous I/O), được Martin đo lường là nhanh hơn 67% đến 70% khi đọc số lượng lớn tệp từ lưu trữ đám mây.
• Các câu lệnh ATTACH động trong v2.0 cho phép lấy chuỗi kết nối và thông tin xác thực từ biến môi trường tại thời gian chạy, cải thiện tính bảo mật và linh hoạt.
• Giao thức từ xa Quack cho phép các instance DuckDB phục vụ dữ liệu qua HTTP, giúp truy cập an toàn vào các bảng DuckLake mà không cần phơi bày thông tin đăng nhập đám mây cho người dùng cuối.
• Martin nhấn mạnh rằng hầu hết các nhóm không cần xử lý thời gian thực cho các báo cáo hàng tháng, thách thức quan niệm phổ biến rằng các công cụ big data luôn là điều bắt buộc.

Bối cảnh

Các kiến trúc big data truyền thống thường dựa vào các hệ thống phân tán như Apache Spark để xử lý dữ liệu trên nhiều máy chủ. Những hệ thống này xuất sắc trong việc xử lý dữ liệu cỡ petabyte nhưng đòi hỏi cấu hình cẩn thận, quản lý phiên bản và tài nguyên tính toán đáng kể để khởi động và vận hành. Việc quản lý metadata trong các định dạng bảng mở như Apache Iceberg liên quan đến việc ghi nhiều tệp JSON và manifest cho mỗi giao dịch. Khi tập dữ liệu tăng trưởng, số lượng các tệp metadata này cũng tăng theo, làm chậm thời gian lập kế hoạch truy vấn vì hệ thống phải đọc và đối chiếu tất cả các tệp đó trước tiên.

DuckDB áp dụng một cách tiếp cận khác bằng cách chạy dưới dạng một tiến trình đơn lẻ, tương tự như SQLite nhưng được tối ưu hóa cho phân tích. Nó có thể đọc dữ liệu trực tiếp từ lưu trữ đối tượng như Amazon S3 mà không cần di chuyển dữ liệu vào một kho chứa độc quyền. DuckLake xây dựng dựa trên nền tảng này bằng cách sử dụng cơ sở dữ liệu quan hệ để theo dõi metadata của bảng. Vì cơ sở dữ liệu quan hệ được tối ưu hóa cao cho việc lập chỉ mục và truy vấn dữ liệu có cấu trúc, việc tra cứu thông tin bảng trở nên gần như tức thì, bất kể số lượng giao dịch đã diễn ra. Kiến trúc này giảm bớt gánh nặng vận hành cho các nhóm kỹ thuật trong khi vẫn duy trì hiệu suất cao cho các truy vấn phân tích điển hình.

Tại sao điều này quan trọng

Đối với các nhóm tự host phần mềm hoặc quản lý nền tảng dữ liệu nội bộ, độ phức tạp trong vận hành là một yếu tố chi phí chính. Duy trì các cụm Spark hoặc quản lý metadata Iceberg đòi hỏi kiến thức chuyên môn và sự chú ý liên tục. Nếu một công cụ có thể cung cấp hiệu suất yêu cầu với ít hạ tầng hơn, nó sẽ giải phóng thời gian kỹ thuật cho việc phát triển tính năng thay vì bảo trì nền tảng. Kinh nghiệm của Martin gợi ý rằng nhiều tổ chức đang thiết kế quá mức (over-engineer) các stack dữ liệu của họ, trả tiền cho khả năng mở rộng mà họ không bao giờ sử dụng. Áp dụng các công cụ nhẹ nhàng hơn như DuckDB có thể giảm hóa đơn đám mây và đơn giản hóa các pipeline triển khai.

Những cải tiến trong DuckDB v2.0 cũng giải quyết các điểm đau phổ biến trong môi trường cloud-native. I/O bất đồng bộ có nghĩa là việc đọc hàng nghìn tệp log từ S3 không còn chặn luồng chính nữa, khiến việc phân tích cục bộ trở nên khả thi cho các tác vụ trước đây đòi hỏi một cụm phân tán. Khả năng gắn catalog động bằng cách sử dụng biến môi trường nâng cao tính bảo mật bằng cách giữ bí mật khỏi các kho mã nguồn. Đối với các lãnh đạo IT, điều này có nghĩa là tuân thủ dễ dàng hơn và tự động hóa an toàn hơn. Giao thức Quack đơn giản hóa hơn nữa việc kiểm soát truy cập, cho phép các nhóm cung cấp dịch vụ dữ liệu mà không cần quản lý liên bang danh tính phức tạp hoặc cấp quyền hạn đám mây rộng rãi.

Bạn có thể làm gì

• Kiểm toán các khối lượng công việc dữ liệu hiện tại của bạn để xác định các báo cáo hoặc phân tích không yêu cầu xử lý thời gian thực hoặc thông lượng ở mức petabyte.
• Thử nghiệm DuckDB cục bộ bằng cách cài đặt gói và truy vấn một tệp CSV hoặc Parquet mẫu để đánh giá sự dễ sử dụng so với stack hiện tại của bạn.
• Thực nghiệm với DuckLake bằng cách gắn một bucket S3 sử dụng các câu lệnh SQL được cung cấp để so sánh hiệu suất metadata với định dạng bảng hiện có của bạn.
• Xem xét các script pipeline của bạn để tìm kiếm thông tin đăng nhập hard-coded và lên kế hoạch di chuyển sang các câu lệnh ATTACH động khi DuckDB v2.0 ổn định.
• Cân nhắc sử dụng giao thức Quack để phục vụ các dashboard nội bộ, giảm nhu cầu truy cập trực tiếp vào lưu trữ đám mây cho người dùng cuối.
• Theo dõi Substack của Martin để biết các benchmark chi tiết và ví dụ cấu hình nếu bạn quyết định thử nghiệm các công cụ này trong môi trường của mình.