DuckDB 檔案只存 view，一個 URL 就能分享整座資料湖目錄
duckdb.org · 2026-10-07
DuckDB 資料庫檔不必存任何資料：只放 CREATE VIEW 定義，指向物件儲存上的 Parquet，檔案就只有數百 KB，卻能當成整座資料湖的共用目錄（catalog）。這取代了「把一長串檔案路徑貼給對方」的分享方式。
DuckDB 團隊在 2026-10-07 的官方部落格示範這個做法。要注意它是既有功能的組合用法，文章並未宣告新的 SQL 語法或版本旗標。
原本的問題
分享 Parquet 資料集時，對方得知道有幾個檔案、放在哪個 bucket、欄位叫什麼名字。資料方一旦把單一檔案拆成每年一檔，或把欄位改名，所有下游查詢都得跟著改。
DuckDB 的 table 把資料列存在資料庫檔內，view 只存查詢文字。所以只含 view 的資料庫檔沒有任何資料列，它只是一份「已命名、可直接查詢的關聯」清單。
這個想法源自 Nikolas Goebel 的 DuckDB doesn't need data：儲存位置與讀取方式已經分離，資料庫不一定要自己持有資料。DuckDB 在這個視角下像一個「資料雲的瀏覽器」，你用 URL 存取資料集，而不是在本機放一份副本。發布方因此能把它當成策展過的語意層，由 view 決定 join、過濾與欄位命名，消費者只看到整理好的關聯。
做法
先安裝 httpfs 擴充套件，再建立持久化檔案並定義 view。文中強調要用完整位置（遠端 URL 或絕對路徑），這樣不論客戶端的工作目錄在哪，view 都能解析。
INSTALL httpfs;
ATTACH 'rail_catalog.duckdb' AS rail;
USE rail;
CREATE VIEW services AS
SELECT * FROM 'https://blobs.duckdb.org/train_services.parquet';文中的範例資料是荷蘭鐵路的停靠紀錄，train_services.parquet 有 380,959 列，但承載它的 catalog 檔只有數百 KB。把檔案上傳到任何 DuckDB 能讀的位置（s3:// 或 https://），消費端用唯讀方式掛載即可：
ATTACH 'https://example.com/rail_catalog.duckdb' AS rail (READ_ONLY);
SELECT station_name, count(*) AS calls
FROM rail.services GROUP BY station_name
ORDER BY calls DESC LIMIT 3;每次查詢都讀物件儲存上當下的資料，結果不會過期。DuckDB 只讀查詢需要的欄位與 row group，所以過濾或聚合大型遠端資料集，不會把整份下載。
資料佈局變動時
因為查詢走 view 而不是直接讀檔，發布方能在不動查詢的情況下改檔案。文中舉兩個例子：
| 情境 | catalog 端的改法 |
|---|---|
| 單檔拆成每年一檔 | CREATE OR REPLACE VIEW，改讀 read_parquet('s3://my-bucket/rail/services/year=*/*.parquet') |
新批次把 station_name 改名為 station | view 內 station AS station_name，並 EXCLUDE (station) |
搬 bucket 或重新分區也一樣，只要更新 catalog，下游查詢維持原樣。換句話說，檔案佈局成為發布方的內部細節，不再是需要對外溝通的合約，這是它比直接分享路徑更好維護的地方。
影響範圍與限制
- 資料平台與分析團隊：想提供「語意層」的人，可以把 join、過濾條件與欄位命名寫進 view，不必複製資料。
- 消費端：必須同時有權限讀 catalog 檔，以及每個 view 引用的資料來源；
s3://來源還需要對底層資料有效的憑證，並安裝httpfs。 - 發布端：透過 HTTPS 與 S3 API 的連線是唯讀，catalog 不能就地修改。要改 view，得改本機副本再重新上傳。
- 效能：取決於網路與被引用檔案的佈局，文中建議參考官方「查詢遠端檔案」的調校建議。
如果你現在是用文件列檔案路徑、或在每個下游專案各寫一份 read_parquet 路徑，這個做法可以把路徑集中到一個檔。但文章只談 view 與唯讀掛載，並未討論版本管理或存取控管，所以不要把它當成 lakehouse 表格格式的替代品。