Vì sao DuckDB là lựa chọn đầu tiên của tôi khi xử lý dữ liệu

 (robinlinacre.com)
30 điểm bởi GN⁺ 2026-01-18 | 2 bình luận | Chia sẻ qua WhatsApp
  • DuckDB là một công cụ SQL mã nguồn mở có thể xử lý dữ liệu bảng quy mô lớn trên một máy đơn một cách nhanh chóng và đơn giản, gần đây được sử dụng rộng rãi trong kỹ thuật dữ liệu
  • Cài đặt đơn giản, không có phụ thuộc, và có thể chạy ngay trong môi trường Python nên rất phù hợp cho CI và tự động hóa kiểm thử
  • Nhờ tối ưu hóa truy vấn phân tích, hiệu năng có thể nhanh hơn SQLite hoặc Postgres tới 1.000 lần, đồng thời có thể truy vấn trực tiếp nhiều định dạng tệp khác nhau như csv, parquet, json
  • Với cú pháp SQL thân thiện (EXCLUDE, COLUMNS, QUALIFY, chuỗi hàm, v.v.) và Python API, có thể phát triển các pipeline phức tạp một cách hiệu quả
  • Với tuân thủ ACID, UDF hiệu năng cao, tiện ích mở rộng tích hợp PostgreSQL, DuckDB đang nổi lên như một giải pháp thay thế lakehouse cho dữ liệu quy mô trung bình

Tổng quan về DuckDB

  • DuckDB là một công cụ SQL in-process tập trung vào tối ưu hóa truy vấn phân tích
    • Nó chạy bên trong ứng dụng mà không cần máy chủ riêng, không cần dịch vụ bên ngoài như Postgres
    • Được tối ưu cho các phép nối và tổng hợp quy mô lớn, và có thể cho hiệu năng nhanh hơn 100~1.000 lần so với các công cụ tập trung vào giao dịch (OLTP)
  • Trường hợp sử dụng chính là đọc trực tiếp các tệp lớn như csv, parquet, json từ đĩa để xử lý hàng loạt (batch processing)
  • Cũng có thể dùng cho khám phá dữ liệu nhẹ, chẳng hạn truy vấn nhanh tệp CSV từ dòng lệnh

Các đặc điểm chính

  • Tốc độ

    • DuckDB là một trong những công cụ xử lý dữ liệu mã nguồn mở nhanh nhất, luôn nằm trong nhóm đầu ở các benchmark
    • Khi so sánh với Polars, DataFusion, Spark, Dask, DuckDB vượt trội với dữ liệu nhỏ, còn với dữ liệu lớn thì Spark và Dask vẫn có sức cạnh tranh

  • Cài đặt đơn giản và không có phụ thuộc

    • DuckDB được cung cấp dưới dạng một tệp nhị phân biên dịch sẵn duy nhất, và trong Python có thể cài ngay bằng pip install duckdb
    • Không có phụ thuộc, nên cài đặt đơn giản hơn nhiều so với các framework lớn như Spark
    • Khi kết hợp với uv, có thể thiết lập môi trường Python trong dưới 1 giây

  • CI và kiểm thử

    • Nhờ khởi động nhanh và nhẹ, DuckDB rất phù hợp cho môi trường CI và kiểm thử của pipeline dữ liệu
    • Trước đây, kiểm thử dựa trên Spark thường chậm và phức tạp, nhưng DuckDB giúp đơn giản hóa cấu hình môi trường và duy trì tính nhất quán với production dễ hơn

  • Trải nghiệm viết SQL

    • DuckDB cho phép viết SQL và kiểm tra cú pháp rất nhanh
    • Có lợi thế hơn Spark local mode hoặc AWS Athena về thực thi tức thì và phát triển lặp
    • Có giao diện người dùng với tính năng tự động hoàn thành

  • Cú pháp SQL thân thiện

    • DuckDB bao gồm nhiều mở rộng SQL thân thiện với người dùng
      • Hỗ trợ EXCLUDE, COLUMNS, QUALIFY, modifier tổng hợp cho hàm cửa sổ, chuỗi hàm (first_name.lower().trim()), v.v.
    • Những tính năng này giúp thực hiện các tác vụ chọn và biến đổi cột phức tạp một cách ngắn gọn

  • Hỗ trợ nhiều định dạng tệp

    • Có thể truy vấn dữ liệu trực tiếp từ S3, URL web, tệp cục bộ
    • Cung cấp tùy chọn độ nghiêm ngặt kiểu dữ liệu cho CSV để ngăn lỗi do dữ liệu đầu vào phi cấu trúc

  • Python API

    • Trong Python, có thể định nghĩa pipeline dựa trên CTE theo từng bước và dễ dàng kiểm tra dữ liệu ở mỗi bước
      • Kết nối SQL theo dạng chain bằng lời gọi duckdb.sql()
      • Có thể xem kết quả trung gian mà không mất hiệu năng nhờ thực thi trì hoãn (lazy execution)
    • Có thể kiểm thử hàm ở từng bước, từ đó nâng cao hiệu quả kiểm thử CI

  • Tuân thủ ACID

    • DuckDB đảm bảo ACID đầy đủ ngay cả khi xử lý dữ liệu khối lượng lớn
    • Nhờ đặc tính này, nó có thể được dùng như giải pháp thay thế quy mô trung bình cho các định dạng lakehouse như Iceberg và Delta Lake

  • UDF hiệu năng cao và mở rộng cộng đồng

    • Có thể viết hàm do người dùng định nghĩa (UDF) hiệu năng cao bằng C++
    • Thông qua Community Extensions, có thể cài tiện ích mở rộng ngay bằng lệnh như INSTALL h3 FROM community
      • Ví dụ: hỗ trợ đánh chỉ mục lục giác (h3) cho dữ liệu không gian địa lý

  • Tài liệu hóa

    • Toàn bộ tài liệu được cung cấp dưới dạng một tệp Markdown duy nhất, thuận tiện cho huấn luyện LLM hoặc tìm kiếm ngay trong trình soạn thảo mã
    • Tính năng gập mã giúp dễ dàng sao chép chỉ những phần cần thiết

Ứng dụng thực tế và hiệu quả

  • Trong dự án mã nguồn mở Splink, việc chọn DuckDB làm backend mặc định đã mang lại
    • giảm vấn đề cho người dùng, tăng tốc độ làm việc, và đơn giản hóa phát triển tính năng cũng như kiểm thử

Các tiện ích mở rộng đáng chú ý

  • PostgreSQL Extension: cho phép kết nối và truy vấn trực tiếp cơ sở dữ liệu Postgres từ DuckDB
  • pg_duckdb: nhúng công cụ DuckDB vào bên trong Postgres để xử lý giao dịch và phân tích song song
    • Trong tương lai, sau khi tối ưu hóa chỉ mục Postgres và cải thiện filter pushup, khả năng được chấp nhận rộng rãi là rất lớn

Bài viết liên quan

2 bình luận

 
kaydash 2026-01-18

Thật mỉa mai khi dùng parq vốn dành cho xử lý phân tán với mục đích xử lý trên một máy đơn.
 
GN⁺ 2026-01-18
Ý kiến trên Hacker News

  • Có nhiều lý do khiến tôi thích DuckDB
    Nó hỗ trợ cả tệp .parquet, .json, .csv, và có thể đọc glob như select * from 'tsa20*.csv', nên có thể xử lý hàng trăm tệp như thể là một
    Dù schema khác nhau, vẫn có thể gộp dễ dàng bằng union_by_name, và trình phân tích CSV tự động suy luận kiểu rất tốt
    Bản WebAssembly chỉ 2MB, CLI chỉ 16MB nên cực kỳ nhỏ gọn
    Nhờ vậy có thể nhúng trực tiếp vào sản phẩm. Ví dụ như Malloy
    Malloy giống như phiên bản dành cho dân kỹ thuật của PowerBI hay Tableau, nhưng dùng mô hình ngữ nghĩa để giúp AI viết truy vấn tốt hơn. Cảm giác như giúp viết SQL dễ hơn gấp 10 lần

    • Nhờ hỗ trợ CSV của DuckDB mà cách tôi khám phá dữ liệu đã thay đổi hoàn toàn
      Trước đây tôi thường mất thời gian để hiểu schema trước, còn giờ thì nạp dữ liệu vào, viết các truy vấn khám phá, kiểm chứng giả định, rồi lặp lại quá trình làm sạch, biến đổi và tạo bảng
      Nhờ đó tôi có thể đào sâu nhanh hơn nhiều, đồng thời phát hiện ngõ cụt sớm để bớt lãng phí thời gian
      Tôi có nghe nói có một bài báo nói về cách trình phân tích CSV này hoạt động và các ý tưởng cải tiến trong tương lai, nhưng vẫn chưa tìm ra
    • Gần đây tôi dùng ClickHouse khá nhiều, và nó cũng có nhiều ưu điểm tương tự DuckDB
      Đặc biệt là việc ingest Parquet và JSON rất tiện, còn clickhouse-local thì khá giống ý tưởng nhúng DuckDB
      Cú pháp SELECT ... FROM s3Cluster(...) cho phép ingest bằng wildcard từ bucket S3, đồng thời phân tán xử lý lên các node trong cluster
      Có vẻ nó cũng hỗ trợ schema_inference_mode
      ClickHouse cũng đã triển khai tính năng tương tự union_by_name
      Tài liệu liên quan: hàm s3Cluster, schema inference, PR #55892
    • Tôi đã tạo ra Shaper, kết hợp truy vấn dữ liệu và trực quan hóa theo ý tưởng giống Malloy
      Nhưng Shaper dùng SQL thay vì một ngôn ngữ riêng
      Nó cho phép tạo dashboard chỉ bằng SQL trên nền DuckDB
      Shaper GitHub
    • Tôi đã tạo ZenQuery và dùng DuckDB cho phần xử lý bên trong
      Tốc độ của nó thật đáng kinh ngạc, và tự động phát hiện schema hoạt động chính xác trong phần lớn trường hợp
      LLM cũng có thể tạo đúng SQL từ truy vấn ngôn ngữ tự nhiên
    • Đây thực sự là một phần giới thiệu tuyệt vời
      Trước đây tôi làm theo kiểu import thủ công vào SQLite, nhưng DuckDB đã khiến mọi thứ đơn giản hơn rất nhiều

  • Tôi cũng là người rất thích dùng DuckDB
    Khi làm việc với các nhà khoa học nghiên cứu môi trường ven biển ở British Columbia, tôi phải xử lý một lượng dữ liệu khổng lồ, từ quan trắc sông băng đến dữ liệu drone biển sâu
    Chúng tôi đã chọn DuckDB làm engine cho công cụ chuyển đổi dữ liệu đa dạng sinh học mới, với mục tiêu chuyển đổi và kiểm định dữ liệu theo chuẩn Darwin Core
    Chúng tôi tạo bảng DuckDB động dựa trên schema rồi import dữ liệu. Nếu thất bại, hệ thống sẽ cho biết lý do ở cấp từng dòng
    Toàn bộ quá trình chuyển đổi và kiểm định cũng đều được thực hiện bên trong DuckDB
    Nhờ đó chúng tôi đã tạo được một ứng dụng nhanh hơn nhiều, mạnh mẽ hơn, và có thể chạy ngay trong trình duyệt
    Các nhà nghiên cứu thực địa thậm chí có thể dùng offline ngay trên trình duyệt iPad
    DuckDB mang lại cho tôi niềm tin rằng SQL có thể gánh phần việc nặng
    Những chỗ còn thiếu an toàn kiểu dữ liệu thì chúng tôi bù lại bằng parsing và test
    Mục tiêu của dự án này là giúp các nhà khoa học phân tích dữ liệu đa dạng sinh học và hệ gen bằng công cụ chung, rồi công bố lên kho lưu trữ công khai

    • Tôi tò mò không biết các dataset hiện có đang ở định dạng nào
      Tôi thường xử lý HDF5 trong dữ liệu khoa học, nhưng DuckDB mặc định không hỗ trợ HDF5
      Các extension hiện có vừa chậm vừa thiếu tính năng, nên tôi đã tự tạo một extension mới bằng template C++
      Tôi đang tìm người quan tâm đến việc cộng tác
    • Tôi tò mò không biết nếu dùng Polars cho cùng công việc thì sẽ có lợi thế gì
      Cá nhân tôi thấy cú pháp Polars dễ chịu hơn SQL rất nhiều, nên đang cân nhắc liệu có đáng để thử DuckDB hay không

  • Chúng tôi xử lý phân tích và feed của Bluesky bằng DuckDB
    Để có kết quả nhanh, chúng tôi dùng giao diện Apache Arrow, và dùng SQG để sinh code trực tiếp từ truy vấn DuckDB SQL

    • Tôi tò mò về stack kỹ thuật. Không biết có bài viết nào nói về kiến trúc nội bộ không. Công cụ HN cũng rất ấn tượng

  • Tôi muốn giới thiệu dự án Java manifold-sql
    Nó cho phép viết DuckDB SQL inline theo kiểu type-safe
    Bạn có thể đặt SQL trực tiếp trong code và duyệt kết quả bằng .fetch(), rất gọn gàng mà không cần tầng trung gian

  • Lập luận của tác giả hợp lý với các tác vụ xử lý dữ liệu cơ bản, nhưng
    ý “phần lớn dữ liệu dạng bảng đều có thể xử lý trên một máy đơn” vẫn còn gây tranh cãi
    Khi mở rộng, pivot hoặc tăng cường dữ liệu, rất dễ gặp tràn bộ nhớ (OOM)
    Ngoài ra, quan điểm “SQL nên là lựa chọn đầu tiên mới cho data engineering” cũng không thực sự phù hợp với các phân tích phức tạp

    • Tôi là chính tác giả đây
      Dataframe API như Polars hay pandas cũng có nhiều ưu điểm, nhưng vấn đề là hệ sinh thái chưa được chuẩn hóa nên pipeline thường xuyên phải viết lại
      Phần lớn dữ liệu đều dưới 10GB, nên hoàn toàn có thể xử lý tốt trên một máy đơn
      Nhiều trường hợp đang dùng Spark quá mức cần thiết
      Quan điểm của tôi là “hãy thử DuckDB trước”. Với các trường hợp đơn giản, nó rất nhanh và hiệu quả
    • Với các phân tích nâng cao như ML hay trực quan hóa, dataframe phù hợp hơn
      SQL tốt cho các pipeline đơn giản, nhưng tính dễ đọc còn tùy người
      Cá nhân tôi thấy phía dataframe dễ đọc hơn nhiều
    • SQL vẫn dễ học, và phần lớn việc mô hình hóa dữ liệu vẫn được thực hiện bằng SQL
      Phía ingestion có thể dùng nhiều Python hay Scala hơn, nhưng SQL sẽ không biến mất
    • Tôi đang xử lý 500GB dữ liệu Parquet bằng DuckDB, và trên desktop 50GB RAM nó vẫn chạy mượt và nhanh
      OOM có lẽ chỉ là vấn đề trong các trường hợp cực đoan
    • Polars cũng có hầu hết các ưu điểm này, thậm chí còn hỗ trợ backend GPU và phân tán
      Trong khi DuckDB được chú ý nhiều, Polars dường như đang bị đánh giá thấp

  • Tôi xử lý dữ liệu rất nhiều, và chủ yếu dùng Polars
    Nó cực nhanh, lại có nhiều hàm mà pandas hay SQL khó biểu đạt
    Có thể dùng trực tiếp cả hàm Python
    Dù DuckDB có cùng hiệu năng đi nữa, tôi vẫn ngần ngại vì thấy SQL có vẻ có giới hạn về khả năng biểu đạt

    • Theo kinh nghiệm của tôi thì DuckDB nhanh hơn và gọn hơn hẳn
      Nó là ứng dụng độc lập nên cài đặt cũng đơn giản, gần như không có nhu cầu tuning hay đường cong học tập

  • Tôi đã nạp một tệp Excel có định dạng lộn xộn do mainframe tạo ra vào DuckDB,
    và với tùy chọn all_varchar thì nó được load trong chưa đến 1 giây
    Trong khi đó Excel vẫn còn đang mở tệp

  • DuckDB rất tuyệt, nhưng việc nạp extension động xung đột với code signing nên khó dùng trong ứng dụng thương mại
    Ngoài ra extension không gian còn dùng thành phần LGPL nên có vấn đề về giấy phép
    Sẽ tốt hơn nếu có thể ghép tính năng theo từng package giống Apache Arrow
    Ví dụ: truyền mảng qua HTTP ở tốc độ GB/s thì dùng Arrow Flight, chia sẻ tệp thì dùng Arrow IPC, đọc Parquet thì thêm một trait riêng
    Hệ thống kiểu SQL của DuckDB khác Arrow nên có thể phát sinh vấn đề không khớp kiểu dữ liệu
    Arrow cung cấp thư viện native cho hầu hết các ngôn ngữ

  • Tôi tò mò liệu với một bảng đơn chứa hàng tỷ giao dịch, 30 cột,
    có thể truy xuất nhanh các trang đã được lọc bằng điều kiện WHERE hay không
    Ở Postgres thì ngay cả count(*) đơn giản cũng mất nhiều thời gian

    • Với quy mô này thì ngay cả DuckDB cũng có lẽ sẽ xong trong vài giây
      Những lúc tôi thấy chậm thường chỉ là khi join phức tạp hoặc xử lý glob trên nhiều tệp
    • Nếu muốn tăng tốc độ count, có lẽ cache định kỳ sẽ tốt hơn dùng index
      Nếu điều kiện WHERE chỉ là các cặp cột-giá trị đơn giản thì có thể xử lý khá nhanh

  • DuckDB không chỉ là một DB nhanh, mà còn có trải nghiệm nhà phát triển (devx) rất xuất sắc
    Nó dễ bắt đầu nên hệ sinh thái mở rộng rất nhanh
    Tích hợp Web/WASM cũng rất ấn tượng
    Tôi hy vọng sẽ có thêm nhiều engine nhỏ gọn như thế này xuất hiện để thúc đẩy cạnh tranh và đổi mới