ClickHouse vs DuckDB: So sánh sâu về kiến trúc và benchmark trong môi trường production

Giám đốc sản phẩm của bạn vừa đưa ra một yêu cầu mới: một dashboard phân tích thời gian thực về các chỉ số tương tác của người dùng, hiển thị trực tiếp trong ứng dụng. Tập dữ liệu hiện tại là 500GB log sự kiện dưới dạng file Parquet trên S3 và đang tăng thêm 10GB mỗi ngày. Ban lãnh đạo cấp cao muốn độ trễ truy vấn dưới một giây trên các biểu đồ tương tác. Đội của bạn đang đứng trước một ngã rẽ quan trọng về mặt kiến trúc. Bạn sẽ chọn DuckDB, engine in-process nhanh như chớp hứa hẹn đọc dữ liệu Parquet mà không cần sao chép (zero-copy)? Hay bạn sẽ triển khai ClickHouse, gã khổng lồ columnar phân tán được xây dựng cho việc nhập dữ liệu thông lượng cao và quy mô lớn? Đây không chỉ là lựa chọn giữa hai công cụ; đó là một quyết định nền tảng giữa hai triết lý xử lý dữ liệu khác biệt: song song hóa trên một node nhúng so với lưu trữ bền vững phân tán thời gian thực. Lựa chọn sai có thể dẫn đến chi phí vận hành tăng vọt, không đạt được mục tiêu về độ trễ, và một cuộc tái kiến trúc đau đớn sau này.

Đối đầu Kiến trúc Cốt lõi

Nhìn bề ngoài, cả ClickHouse và DuckDB đều là cơ sở dữ liệu phân tích dạng cột (columnar) và được vector hóa (vectorized). Cả hai đều sử dụng các chỉ thị SIMD (Single Instruction, Multiple Data) để xử lý dữ liệu theo lô, tránh được chi phí xử lý từng dòng một vốn làm tê liệt các cơ sở dữ liệu OLTP truyền thống trong các workload phân tích. Nhưng đó là nơi mà những điểm tương đồng kết thúc. Mục tiêu thiết kế, mô hình thực thi và storage engine của chúng về cơ bản là khác nhau, được tối ưu hóa cho những góc hoàn toàn riêng biệt của vũ trụ kỹ thuật dữ liệu.

Triết lý & Phổ Dụng dụng

DuckDB: SQLite cho ngành Phân tích DuckDB là một cơ sở dữ liệu OLAP trong tiến trình (in-process). Nó không phải là một server mà bạn kết nối đến; nó là một thư viện (libduckdb) bạn liên kết với ứng dụng của mình. Không có tiến trình riêng biệt nào để quản lý, không có chi phí mạng cho các truy vấn cục bộ, và không có cấu hình phức tạp. Các mục tiêu thiết kế chính của nó là:

• Tính di động & Đơn giản: Không có dependency bên ngoài. pip install duckdb là tất cả những gì bạn cần.
• Hiệu suất trên một Node duy nhất: Tối đa hóa việc sử dụng CPU và RAM của một máy duy nhất.
• Thực thi trực tiếp trên định dạng dữ liệu: Là công dân hạng nhất cho việc truy vấn các file Parquet, Arrow, CSV, và JSON mà không cần bước import bắt buộc.

Điều này làm cho DuckDB trở thành một người khổng lồ trong phân tích dữ liệu tương tác (thay thế cho các hoạt động chậm hơn của Pandas), phân tích ứng dụng nhúng (cung cấp năng lượng cho dashboard trong một ứng dụng Node.js hoặc Python), và các tác vụ ETL/chuyển đổi dữ liệu hiệu quả trên một node duy nhất.

ClickHouse: Engine OLAP Phân tán Thời gian thực ClickHouse là một hệ quản trị cơ sở dữ liệu (DBMS) phân tán, đầy đủ tính năng, chạy như một tiến trình server riêng biệt. Nó được xây dựng tại Yandex để cung cấp năng lượng cho nền tảng phân tích web thời gian thực của họ, một trường hợp sử dụng đòi hỏi:

• Nhập dữ liệu lớn, thời gian thực: Có khả năng nhập hàng triệu dòng mỗi giây từ các nguồn khác nhau như Kafka.
• Khả năng mở rộng theo chiều ngang: Mở rộng đến petabyte dữ liệu trên hàng trăm server bằng cách sử dụng sharding và replication.
• Truy vấn độ trễ thấp trên Dữ liệu lớn: Được thiết kế để trả lời các truy vấn tổng hợp trên các tập dữ liệu khổng lồ trong vài mili giây.
• Tính bền vững và sẵn sàng cao: Các tính năng sản xuất như replication, backup, và chịu lỗi (fault tolerance) được tích hợp sẵn.

ClickHouse là vũ khí được lựa chọn cho các tác vụ phân tích log quy mô lớn, business intelligence thời gian thực, dashboard phân tích hướng tới người dùng, và bất kỳ kịch bản nào liên quan đến các tập dữ liệu từ terabyte đến petabyte với yêu cầu tương tranh cao.

Lưu trữ & Đánh chỉ mục Dữ liệu: MergeTree vs. Khối Columnar Thích ứng

Sự khác biệt sâu sắc nhất nằm ở cách chúng lưu trữ dữ liệu trên đĩa.

ClickHouse: Gã khổng lồ Log-Structured Merge-Tree (LSM-Tree)

Sức mạnh của ClickHouse đến từ họ storage engine MergeTree của nó. Đây không phải là B-Tree tiêu chuẩn của bạn. Nó là một biến thể của Log-Structured Merge-Tree, được tối ưu hóa cho dữ liệu columnar và các lần chèn hàng loạt (bulk inserts).

Khi bạn chèn dữ liệu, ClickHouse ghi nó vào một "data part" mới trên đĩa - một tập hợp các file columnar bất biến. Một tiến trình nền liên tục hợp nhất các part nhỏ này thành các part lớn hơn, được tối ưu hóa hơn.

Phép màu nằm ở chỉ mục chính thưa thớt (sparse primary index). Khi bạn định nghĩa một bảng, bạn chỉ định một mệnh đề ORDER BY. Điều này không chỉ để sắp xếp kết quả; nó là khóa sắp xếp vật lý cho dữ liệu của bạn trên đĩa.

CREATE TABLE user_events (
    `event_time` DateTime,
    `user_id` UInt64,
    `event_type` String,
    `payload` Map(String, String)
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_time)
ORDER BY (user_id, event_time);

Ở đây, dữ liệu được sắp xếp vật lý theo user_id, sau đó là event_time. ClickHouse tạo ra một chỉ mục chính thưa thớt trên khóa này. Nó không đánh chỉ mục cho mọi dòng; thay vào đó, nó ghi lại giá trị khóa cho phần đầu của mỗi khối dữ liệu thứ N (một "granule," thường là 8,192 dòng).

Khi bạn chạy một truy vấn như WHERE user_id = 123, ClickHouse thực hiện tìm kiếm nhị phân trên file chỉ mục chính nhỏ để tìm ra một vài granule có thể chứa user_id này. Sau đó, nó chỉ đọc những granule đó từ đĩa, bỏ qua hàng terabyte dữ liệu không liên quan. Đây là lý do tại sao ClickHouse cực kỳ nhanh cho các truy vấn lọc trên khóa sắp xếp của nó, đặc biệt là dữ liệu chuỗi thời gian.

DuckDB: Các khối tối ưu và Thực thi Parquet trực tiếp

Định dạng lưu trữ gốc của DuckDB bao gồm các khối dữ liệu columnar. Đối với mỗi cột, nó lưu trữ một tập hợp các khối trên đĩa. Sự đổi mới quan trọng là việc sử dụng Zone Maps cho mỗi khối. Một zone map là siêu dữ liệu nhẹ lưu trữ giá trị tối thiểu và tối đa cho khối dữ liệu đó.

Khi một truy vấn chứa một vị từ (predicate) như WHERE column_a > 100, DuckDB trước tiên kiểm tra các zone map. Nếu zone map của một khối cho biết giá trị tối đa của nó là 99, toàn bộ khối đó sẽ được bỏ qua mà không bao giờ được đọc từ đĩa. Đây là một dạng của predicate pushdown.

Hơn nữa, DuckDB xây dựng các chỉ mục Adaptive Radix Tree (ART) trên các khóa chính hoặc cho các hoạt động join nội bộ, cung cấp các tra cứu điểm nhanh chóng.

Nhưng tính năng sát thủ của DuckDB là khả năng áp dụng các nguyên tắc tương tự này trực tiếp lên các định dạng dữ liệu bên ngoài. Khi bạn chạy SELECT COUNT(*) FROM 'data.parquet' WHERE ..., DuckDB không quét file một cách ngây thơ. Nó tận dụng siêu dữ liệu nội bộ bên trong chính file Parquet - cụ thể là các thống kê của row group (về cơ bản là các zone map) - để bỏ qua các phần lớn của file. Điều này làm cho việc phân tích ad-hoc trên các data lake hiện có trở nên cực kỳ nhanh chóng.

Thực thi Truy vấn: Morsel-Driven Parallelism vs. Pipeline Vector hóa Cổ điển

Cả hai engine đều được vector hóa, nhưng chúng song song hóa việc thực thi rất khác nhau trên một máy duy nhất.

ClickHouse: Pipeline Parallelism

ClickHouse sử dụng một mô hình vector hóa dựa trên pull truyền thống, bị ảnh hưởng nặng nề bởi mô hình Volcano/MonetDB. Mỗi truy vấn được chuyển thành một pipeline các toán tử (ví dụ: Scan -> Filter -> Aggregate). Trong quá trình thực thi, toán tử cấp cao nhất yêu cầu một khối dữ liệu từ con của nó, con lại yêu cầu từ con của nó, và cứ thế tiếp tục.

Song song hóa được thực hiện bằng cách nhân đôi pipeline này cho nhiều thread worker. Nguồn dữ liệu được phân chia, và mỗi thread làm việc trên phân đoạn dữ liệu của riêng mình, xử lý các khối đầy đủ ở mỗi giai đoạn. Điều này rất hiệu quả cho các truy vấn đơn giản, thẳng hàng nhưng có thể gây ra chi phí đồng bộ hóa và mất cân bằng tải trong các kế hoạch phức tạp hơn với các phép join và tổng hợp có độ phân giải cao (high-cardinality).

DuckDB: Morsel-Driven Parallelism

DuckDB triển khai một mô hình hiện đại và linh hoạt hơn được gọi là "Morsel-Driven Parallelism."

1. Phá vỡ Pipeline (Pipeline Breaking): Kế hoạch truy vấn được chia thành nhiều pipeline tại các điểm đồng bộ hóa (ví dụ: xây dựng bảng băm tổng hợp).
2. Morsels: Dữ liệu được xử lý theo các khối nhỏ, kích thước cố định gọi là "morsels" (khoảng 100k dòng).
3. Lập lịch động (Dynamic Scheduling): Một bộ lập lịch tác vụ toàn cục gán các morsel cho các thread worker có sẵn. Khi một thread hoàn thành việc xử lý một morsel thông qua một pipeline, nó quay lại bộ lập lịch và yêu cầu một morsel khác.

Cách tiếp cận này mang lại những lợi thế đáng kể trên một node duy nhất:

• Tính cục bộ của Cache (Cache Locality): Việc xử lý các morsel nhỏ hơn phù hợp hơn với các bộ nhớ đệm của CPU.
• Cân bằng tải (Load Balancing): Các thread nhanh có thể xử lý nhiều morsel hơn các thread chậm, tự nhiên cân bằng khối lượng công việc.
• Pipelining: Nó cho phép pipelining truy vấn đầy đủ, nơi kết quả từ một toán tử ngay lập tức có sẵn cho toán tử tiếp theo mà không cần vật chất hóa toàn bộ kết quả trung gian, ngay cả đối với các truy vấn song song phức tạp.

Đây là một lý do chính tại sao DuckDB thường vượt trội hơn các engine khác trên các truy vấn TPC-H phức tạp trên một máy mạnh duy nhất.

Benchmark trong Production: TPC-H SF100

Nói suông thì rẻ. Hãy benchmark hai engine này trên một workload phân tích phổ biến. Chúng tôi sử dụng bộ dữ liệu TPC-H ở Scale Factor 100 (~100GB dữ liệu thô) trên một máy AWS m6i.8xlarge (32 vCPU, 128 GiB RAM, lưu trữ NVMe).

Các truy vấn:

• Q1: Một truy vấn tổng hợp nặng với nhiều phép toán SUM, AVG, COUNT và một GROUP BY. Thử nghiệm tốc độ tổng hợp và quét thô.
• Q6: Một truy vấn quét toàn bộ bảng đơn giản với mệnh đề WHERE. Thử nghiệm tốc độ quét thuần túy và predicate pushdown.

Kịch bản 1: Truy vấn File Thô (Sân nhà của DuckDB)

Ở đây, chúng ta truy vấn 100GB dữ liệu TPC-H được lưu trữ dưới dạng file Parquet trực tiếp từ đĩa. ClickHouse sử dụng hàm bảng s3 của nó, trong khi DuckDB truy vấn các file một cách tự nhiên.

# DuckDB Direct Parquet Query
import duckdb

con = duckdb.connect()
# For multi-file datasets
con.execute("SET a_fancy_option=42;")
result = con.execute("""
    SELECT
        l_returnflag,
        l_linestatus,
        SUM(l_quantity) AS sum_qty,
        SUM(l_extendedprice) AS sum_base_price,
        SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
        SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
        AVG(l_quantity) AS avg_qty,
        AVG(l_extendedprice) AS avg_price,
        AVG(l_discount) AS avg_disc,
        COUNT(*) AS count_order
    FROM 'lineitem.parquet'
    GROUP BY l_returnflag, l_linestatus
    ORDER BY l_returnflag, l_linestatus;
""").fetchall()

-- ClickHouse S3 Table Function Query
SELECT
    l_returnflag,
    l_linestatus,
    ... -- same aggregations as above
FROM s3('https://my-bucket.s3.amazonaws.com/tpc-h-100/lineitem.parquet', 'Parquet')
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus;

Phân tích: DuckDB là nhà vô địch không thể tranh cãi của các truy vấn ad-hoc trên file Parquet. Sự tích hợp sâu của nó với định dạng Parquet, cho phép nó đẩy các vị từ (predicate pushdown) và bỏ qua toàn bộ các row group dựa trên metadata của file, mang lại cho nó một lợi thế lớn. Hàm s3 của ClickHouse rất mạnh mẽ nhưng được xem như một foreign data wrapper; nó không thể sánh được với hiệu suất gốc của DuckDB trong kịch bản này.

Kịch bản 2: Truy vấn trên Lưu trữ Gốc (Sân nhà của ClickHouse)

Bây giờ, chúng ta trước tiên nhập dữ liệu vào định dạng gốc của mỗi cơ sở dữ liệu. Đây là cách bạn sẽ sử dụng các hệ thống này trong một ứng dụng production nơi dữ liệu được quản lý bền vững.

• ClickHouse: Dữ liệu được tải vào một bảng MergeTree, ORDER BY (l_shipdate).
• DuckDB: Dữ liệu được tải vào một bảng DuckDB gốc bằng cách sử dụng CREATE TABLE lineitem AS SELECT * FROM 'lineitem.parquet'.

Phân tích: Kết quả bây giờ phức tạp hơn nhiều.

• Nhập dữ liệu: Cấu trúc MergeTree của ClickHouse được xây dựng có mục đích để hấp thụ các luồng dữ liệu tốc độ cao, và nó dễ dàng chiến thắng trong benchmark nhập dữ liệu.
• Q1 (Tổng hợp nặng): DuckDB vẫn giữ vị trí dẫn đầu. Trên một node mạnh duy nhất, cơ chế morsel-driven parallelism và việc sử dụng cache hiệu quả hơn cho các phép tổng hợp và join phức tạp của nó rất khó bị đánh bại.
• Q6 (Quét có chọn lọc): ClickHouse thể hiện sự thiên tài về kiến trúc của mình. Bởi vì bảng của chúng ta được sắp xếp theo l_shipdate, truy vấn Q6 (WHERE l_shipdate >= '1994-01-01' AND l_shipdate < '1995-01-01') có thể sử dụng chỉ mục chính thưa thớt để xác định vị trí và quét chỉ các data part và granule có liên quan. Nó đọc một phần nhỏ dữ liệu từ đĩa, dẫn đến thời gian truy vấn dưới 200ms trên một tập dữ liệu 100GB. DuckDB, mặc dù vẫn nhanh nhờ zone map, nhưng phải quét nhiều dữ liệu hơn.

Kịch bản 3: Độ tương tranh cao

Thử nghiệm này mang tính khái niệm hơn. Chúng tôi mô phỏng 100 client đồng thời chạy một truy vấn tổng hợp đơn giản (SELECT COUNT(*) FROM lineitem WHERE <random_filter>).

• DuckDB: Là một thư viện nhúng, việc quản lý tương tranh là trách nhiệm của ứng dụng. Bạn có thể đạt được điều đó với nhiều thread trỏ đến cùng một file cơ sở dữ liệu (ở chế độ chỉ đọc) hoặc bằng cách khởi chạy nhiều tiến trình. Tuy nhiên, quản lý tài nguyên (CPU, RAM) trở thành một mối quan tâm phức tạp ở cấp độ ứng dụng. Một truy vấn "nặng" từ một người dùng có thể làm đói tất cả những người khác trong cùng một tiến trình.
• ClickHouse: Là một server, đây là sở trường của nó. Nó xử lý mỗi trong số 100 kết nối trong các thread riêng biệt, quản lý một hàng đợi truy vấn, và thực thi các giới hạn bộ nhớ và CPU cho mỗi người dùng. Nó cung cấp hiệu suất ổn định, có thể dự đoán được dưới tải tương tranh cao, trong khi mô hình DuckDB nhúng sẽ đòi hỏi kỹ thuật tùy chỉnh đáng kể để đạt được sự mạnh mẽ tương tự.

Phán quyết: Khi nào nên dùng cái nào?

Đây không phải là một cuộc thi mà một engine "tốt hơn". Chúng là những chuyên gia được thiết kế cho các nhiệm vụ khác nhau trên phổ xử lý dữ liệu.

Chọn DuckDB khi:

1. Phân tích Tương tác: Bạn là một nhà khoa học dữ liệu hoặc nhà phân tích làm việc trong một notebook Python/R. DuckDB cung cấp tốc độ nhanh hơn Pandas cả một bậc về thao tác và tổng hợp dữ liệu trên các tập dữ liệu lên đến ~100 GB.
2. Phân tích Nhúng: Ứng dụng của bạn cần cung cấp các truy vấn phân tích nhanh, nhưng bạn không muốn gánh nặng vận hành của một server cơ sở dữ liệu riêng biệt. Một web server có thể sử dụng DuckDB để cung cấp năng lượng cho một dashboard trực tiếp từ một file Parquet trên đĩa.
3. ETL Nhẹ: pipeline chuyển đổi dữ liệu của bạn chạy trên một máy duy nhất và cần xử lý hiệu quả các file Parquet, CSV, hoặc JSON. DuckDB có thể hoạt động như một engine chuyển đổi dựa trên SQL mạnh mẽ.

# Một trường hợp sử dụng điển hình của DuckDB: xử lý dữ liệu trong Python
import duckdb
import pandas as pd

# Đọc không cần sao chép từ Pandas DataFrame
df = pd.DataFrame({'a': [1, 2, 3], 'b': [4, 5, 6]})
con = duckdb.connect()

# Truy vấn trực tiếp DataFrame bằng SQL
result_df = con.execute("""
    SELECT a, b * 2 AS b_doubled
    FROM df
    WHERE a > 1
""").fetch_df()

print(result_df)

# Hoặc thực hiện một phép tổng hợp phức tạp trên một file Parquet khổng lồ
# mà có thể làm sập Pandas
con.execute("SELECT COUNT(DISTINCT user_id) FROM 'events.parquet'")

Chọn ClickHouse khi:

1. Phân tích Thời gian thực Quy mô lớn: Bạn đang xây dựng một hệ thống để nhập và phân tích các luồng dữ liệu (log, metrics, sự kiện IoT, click của người dùng) ở quy mô lớn. Dữ liệu của bạn >1TB và đang tăng lên.
2. Dashboard hướng tới người dùng: Bạn cần cung cấp năng lượng cho một công cụ BI hoặc một dashboard ứng dụng sẽ được nhiều người dùng đồng thời sử dụng, đòi hỏi độ trễ truy vấn thấp một cách nhất quán (dưới một giây).
3. Một Kho phân tích tập trung: Bạn yêu cầu một cơ sở dữ liệu phân tích "nguồn chân lý" bền vững, được nhân bản và có thể mở rộng cho tổ chức của bạn, tách biệt khỏi logic ứng dụng của bạn.

-- Một trường hợp sử dụng điển hình của ClickHouse: bảng phân tích thời gian thực
-- DDL cho một bảng để lưu trữ lượt xem trang web
CREATE TABLE page_views (
    `view_time` DateTime,
    `url` String,
    `user_id` String,
    `device_type` LowCardinality(String), -- Tối ưu hóa đặc biệt cho các giá trị riêng biệt ít
    `response_ms` UInt16
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(view_time)
ORDER BY (device_type, url, view_time); -- Khóa sắp xếp để lọc nhanh

-- Truy vấn ví dụ cho dashboard: Lấy thời gian phản hồi phân vị thứ 95 theo thiết bị
SELECT
    device_type,
    quantile(0.95)(response_ms) AS p95_response
FROM page_views
WHERE view_time >= now() - INTERVAL 1 DAY
GROUP BY device_type;

Suy ngẫm cuối cùng & Đọc thêm

Sự trỗi dậy của cả ClickHouse và DuckDB báo hiệu một sự thay đổi mô hình trong phân tích dữ liệu. Cơ sở dữ liệu một kích cỡ cho tất cả đã chết. Chúng ta hiện đang ở trong một kỷ nguyên của các công cụ chuyên dụng, và việc biết được những đánh đổi về kiến trúc là điều tối quan trọng đối với bất kỳ kỹ sư cấp cao nào.

• DuckDB là một kiệt tác của việc thực thi truy vấn in-process. Nó hoàn thiện nghệ thuật đưa tính toán đến với dữ liệu, loại bỏ chi phí và tối đa hóa hiệu quả trên một node duy nhất cho các trường hợp sử dụng tương tác và nhúng.
• ClickHouse là một minh chứng cho thiết kế hệ thống phân tán. Nó hoàn thiện nghệ thuật đưa dữ liệu đến một engine tính toán chuyên dụng, có thể mở rộng, cung cấp hiệu suất không đối thủ cho phân tích thời gian thực ở quy mô lớn.

Kỹ sư dữ liệu thông minh không xem chúng là đối thủ cạnh tranh. Họ xem chúng là hai công cụ thiết yếu, bổ sung cho nhau trong một ngăn xếp dữ liệu hiện đại. Bạn có thể sử dụng DuckDB trong pipeline chuyển đổi dbt của mình để xử lý các file Parquet trên S3, và sau đó tải các mô hình dữ liệu cuối cùng, đã được làm sạch vào ClickHouse để cung cấp năng lượng cho các dashboard nhanh nhất và quan trọng nhất của công ty bạn.

Tài liệu kỹ thuật liên quan để đọc thêm:

• ClickHouse MergeTree Engine Documentation
• The DuckDB "Morsel-Driven Parallelism" Paper
• Architecture of the MonetDB System (Một nguồn ảnh hưởng quan trọng đến các engine vector hóa hiện đại)
• Comparing Columnar Formats (Parquet, Arrow, ORC)

Kiểm tra kiến thức