DuckLake Spec 的 DataFrame 延伸：幾天內用 Python 實作與 DuckDB 相同的讀寫路徑
ducklake.select · 2026-05-04
Pedro Holanda 與 Peter van Holland 在 2026 年 5 月 4 日發布了 ducklake-dataframe，展示 DuckLake 規格的 Python 實作，支援 Pandas、Polars 與 PySpark，並在數天內達到與 DuckDB 官方 DuckLake v1.0 相同的讀寫對等性（parity）。這項成果的意義在於驗證了 DuckLake 規格設計的簡潔性。
DuckLake 規格的核心概念
DuckLake 是一個以 SQL 為基礎構建的 Lakehouse 格式規格。其核心職責明確：對於給定查詢，告訴你需要讀取哪些 Parquet 檔案；對於寫入操作，接收你產生的 Parquet 檔案清單。這個設計讓 DuckLake 成為一個編排器（orchestrator），而非一個完整的執行引擎。
規格不強制要求特定的目錄後端，支援 DuckDB、PostgreSQL 與 SQLite 作為目錄資料庫，PyArrow 負責實際的 Parquet 讀寫。這種關注點分離使得 DuckLake 可以在不依賴執行時 DuckDB 的情況下實作，增強了跨框架可攜性。
與 Iceberg 的設計對比
文章指出：從零開始 vibe-coding DuckLake 讀取路徑，比實作 Iceberg 需要的引導更少。這個對比直接指向兩個規格的複雜度差距：Iceberg 的元數據系統（manifest files、snapshot、schema evolution）需要大量實作細節；DuckLake 則用 SQL 查詢協調操作，規格更容易獨立實作。
ducklake-dataframe 的技術架構
Python 實作的資料流如下：
- 讀取路徑：查詢目錄資料庫（DuckDB/PostgreSQL/SQLite）取得 Parquet 檔案清單 → 用 PyArrow 讀取 → 轉換為 Pandas/Polars/PySpark DataFrame
- 寫入路徑：DataFrame 序列化為 Parquet → 回報檔案路徑給目錄資料庫 → 目錄更新元數據
達到讀寫對等性僅耗費數天，顯示規格設計在複雜度控制上的成功。ducklake-dataframe 的發布代表 DuckLake 生態系向多語言、多框架互通邁出了具體一步，也為 Lakehouse 格式競爭提供了一個以規格簡潔性為核心競爭力的新選手。
原始來源：ducklake.select
mssql-python 支援 Apache Arrow：零拷貝 SQL Server 資料列轉 Polars DataFrame
Microsoft Python Developer Blog · 2026-05-03
Microsoft 正式在 mssql-python（SQL Server 的 Python 驅動程式）中加入 Apache Arrow 原生支援，透過 Arrow C Data Interface 實現跨語言零拷貝記憶體共享，大幅降低從 SQL Server 獲取資料到 Polars 或 Pandas 的轉換開銷。
技術基礎：Arrow C Data Interface
Apache Arrow 以欄位式（columnar）記憶體佈局儲存資料：每個欄位的所有值連續排列在一個型別化緩衝區中，Null 值用緊湊位元圖（bitmap）追蹤，而非每個 cell 獨立的 `None` Python 物件。Arrow C Data Interface 是一個跨語言二進位規格，允許不同執行時（C++、Python、Rust 等）直接共享同一塊記憶體，無需序列化或拷貝。
這解決了傳統 Python DB-API 2.0 驅動程式的核心問題：逐列 fetch 會為每一行建立 Python 物件，產生大量 GC 壓力；欄位式 fetch 一次性傳送整欄資料，消除了 per-row 的物件建立開銷。
三個新 API
# 單一 RecordBatch，適合增量處理
batch = cursor.arrow_batch(batch_size=8192)
# 積極式 fetch，回傳 pyarrow.Table
table = cursor.arrow(batch_size=8192)
# 惰性串流，適合大型資料集
reader = cursor.arrow_reader(batch_size=8192)三個 API 對應不同的資料規模需求。零拷貝移交讓轉換到 Polars 只需一行：
df = pl.DataFrame(cursor.arrow())效能表現與已知限制
測試結果顯示跨 SQL Server 型別均有明顯加速，其中時間型別（`DATETIME`、`DATETIMEOFFSET`）效益最顯著，原因是這些型別在傳統 Python 物件轉換時需要額外的解析邏輯，欄位式批次處理可以繞過這個開銷。已知限制：Linux 上 NVARCHAR 效能較慢，因需要 UTF-16 → UTF-8 轉換，修復已在開發中。Arrow 支援同時適用於 Pandas（透過 `ArrowDtype`），不限於 Polars 使用者。