2026-05-24 — ClickHouse SAMPLE BY 抽樣查詢加速 80%、整合 Rust Delta Kernel

ClickHouse SAMPLE BY：大資料集的原生隨機抽樣與查詢加速

ClickHouse Blog · 2026-05-22

ClickHouse 的 SAMPLE BY 子句允許查詢只掃描資料集的隨機子集，在可接受的精度損失下大幅降低查詢延遲。以 3,045 萬筆英國房價資料集為測試，10% 抽樣將查詢平均時間從 687ms 壓縮至 141ms，改善幅度約 80%，同時主要統計量的誤差控制在 7-8% 以內。

抽樣鍵的技術要求

SAMPLE BY 的抽樣鍵必須滿足三個條件：無符號整數表達式、高基數、以及值在全域範圍內均勻分佈。實際使用時常以 sipHash64(id)（64 位元加密雜湊）作為鍵值。最關鍵的限制是：抽樣鍵必須包含在主 ORDER BY 表達式中，才能讓引擎透過 primary key index 直接定位對應的粒度（granule）。

建表語法示例：

CREATE TABLE uk_price_paid (
  ...
  hash UInt64 MATERIALIZED sipHash64(id)
) ENGINE = MergeTree
ORDER BY (town, hash)
SAMPLE BY hash;

兩種抽樣模式

比例模式：SAMPLE 0.1 查詢雜湊值域的前 10%，適合需要固定比例的情境
行數模式：指定最小行數，引擎自動計算 (desired_rows / estimated_rows) × 2⁶⁴ 的雜湊閾值，適合需要固定樣本量的情境

_sample_factor 虛擬欄位

每筆抽樣資料列都附帶 _sample_factor 虛擬欄位，代表該列在完整資料集中的代表倍率。10% 抽樣時 factor 為 10。需要總量的聚合（如 sum）必須乘上此因子才能還原至全體估計值；avg 與 count distinct 等統計量則不需調整。執行計劃驗證顯示，10% 抽樣查詢僅掃描 384/3,719 個 granule，充分利用 primary key 索引。

原始來源：ClickHouse Blog

ClickHouse 整合 Rust Delta Kernel：協定層外包與 C++/Rust 互操作實戰

ClickHouse Blog · 2026-05-22

ClickHouse 將原生 Delta Lake 實作替換為 Rust 撰寫的 delta-kernel-rs，目的是降低維護負擔，同時獲得寫入、schema evolution、time travel 與 partition pruning 等進階功能。這篇工程文章記錄了在 ClickHouse 嚴格建構約束下完成整合的過程與五個主要技術障礙。

Delta Kernel 的角色

Delta Kernel 是 Delta Lake 協定的參考實作抽象層，負責解析 JSON transaction log、讀取 metadata、解析 snapshot 與決定資料檔案，並應用統計型資料跳過（data skipping）。引擎只需呼叫標準介面，不需自行實作協定細節，消除各查詢引擎的重複實作。

五個建構障礙與解法

Workspace 結構：delta-kernel-rs 依賴路徑內部引用，無法複製源碼。解法：原地建構並生成客製 Cargo.toml，避免修改源碼。
OpenSSL 傳遞依賴：使用 rustls 改引入 aws-lc-sys 連結失敗。解法：透過 CMake 配置讓 Corrosion 連結靜態 OpenSSL。
跨平台編譯：Cargo 嘗試建置動態函式庫並引用不存在的系統函式庫。解法：限制 staticlib 輸出，過程中發現並回報 Cargo bug（已修正）。
Sanitizer 符號缺失：CI 隨機失敗追查到 sccache 快取污染，升級至 0.10.0 後改善，最終停用 sccache。
Vendoring：使用 cargo-local-registry 配合客製 config.toml，確保無網路環境下每日數千次建置正常運作。

回饋上游

ClickHouse 向 delta-kernel-rs 貢獻了兩項功能：動態 logging 配置（便於大型 metadata 部署的除錯），以及非同步 metadata 處理（透過 FFI handle 傳遞而非引用，使物件儲存讀取可並行化）。未來路線圖包含 Change Data Feed 工作流與系統表暴露 Delta table 歷史和提交時間線。