Wes McKinney 如何用 pandas 與 Apache Arrow 改造 AI 資料層？

Wes McKinney 如何用 pandas 與 Apache Arrow 改造 AI 資料層？

先講結論： Wes McKinney 把 DataFrame、pandas 與 Apache Arrow 接成現代資料分析的共同語言；AI 資料層的效率不只取決於格式，也要處理型別、缺失值、跨工具互通、GPU、版本與資料品質。

Wes McKinney 是誰？ 他是 pandas 創作者、Apache Arrow 共同創作者，文章依官方資料整理其在分析與資料處理工具的工作。

pandas 解決什麼問題？ DataFrame 把欄位、索引、型別、缺失值與向量化運算組合成容易探索與轉換的表格抽象。

DataFrame 為何不只是二維陣列？ 欄位可有不同型別、列欄帶有 label，運算會依索引對齊，因此形狀相同不代表一定按位置相加。

Apache Arrow 的核心價值是什麼？ 它提供欄式記憶體與跨語言共享格式，降低 Python、Spark、Rust 與資料庫間的序列化與搬運成本。

零拷貝一定比較快嗎？ 不一定；效能仍受資料型別、快取、壓縮、查詢、硬體、版本與實際轉換路徑影響。

缺失值為什麼需要治理？ NaN、nullable integer、字串缺失與 NaT 可能代表不同狀態，全部填零會把未蒐集、不適用與失敗混在一起。

GPU 或分散式處理能直接加速 pandas 嗎？ 不能保證；只有適合的工作負載、資料布局、引擎與轉換路徑才可能獲得加速。

AI 資料管線還要記錄什麼？ 保存資料來源、schema、特徵、切分、版本、標籤與轉換步驟，才能重現訓練與排查漂移。

如何公平比較 pandas 與 Arrow 效能？ 標示資料量、硬體、版本、操作、記憶體布局與是否包含讀取／轉換成本，不能只引用單一 benchmark。

AI 團隊常把資料前處理視為模型之外的雜務，但真實系統花大量時間在讀檔、型別轉換、缺失值、字串、時間與跨程序交換。Wes McKinney 先以 pandas 建立廣泛使用的表格分析介面，再共同發起 Apache Arrow，處理不同語言與引擎之間反覆複製資料的底層成本。

文章實體化：pandas 與 Apache Arrow 資料層

Wes McKinney 的實體貢獻，不只是寫出一個 Python 資料分析套件，而是把表格資料的索引、型別、缺失值與記憶體處理帶進日常工作，再透過 Apache Arrow 把資料交換提升到欄式記憶體、跨語言與零拷貝傳輸的層次。

• pandas：理解 DataFrame、索引、型別轉換與缺失值處理為何成為資料科學入口。
• Apache Arrow：以欄式記憶體、共享格式與跨語言交換降低 Python、Spark、Rust 與資料庫之間的搬運成本。
• AI 資料層：看資料讀取、批次切分、特徵處理與訓練輸入如何受到記憶體布局影響。

本文以「Wes McKinney、pandas、Apache Arrow、欄式記憶體、零拷貝與 AI 資料管線」為主線，補回人物、組織、產品、技術節點與它們之間的因果關係，讓讀者能從具名實體一路追到實際工作流程與產業影響。

Wes McKinney 的工作連接介面與記憶體

Wes McKinney 官方簡介記錄他是 pandas 創作者、Apache Arrow 共同創作者，現任 Posit Principal Architect，並持續投入分析與資料處理工具。這條路徑從 Python 使用者體驗一路深入跨語言欄式記憶體，範圍涵蓋資料科學與系統工程。

他的代表性在於看見兩層問題必須一起解。沒有好介面，分析人員難以表達工作；沒有共同資料格式，介面背後的每個 library 又要複製、序列化與轉換。AI 資料平台同樣需要兼顧開發速度與執行效率。

pandas 讓表格資料成為 Python 的一級物件

DataFrame 把有名稱的欄、索引、缺失值與向量化運算組合成一個可互動抽象。使用者能篩選、聚合、join、reshape 與時間序列處理，而不必為每個步驟寫低階 loop。這降低探索資料與建立特徵的門檻。

抽象也會產生隱性成本。相同語法可能因 dtype、索引對齊或 view/copy 規則得到不同效能；一行操作可能建立大型暫存。可靠 pipeline 需要把 notebook 中的探索轉成有 schema、測試與資源界線的程式。

DataFrame 不只是二維陣列

每一欄可有不同型別，列與欄有 label，運算會依索引對齊。這讓金融、實驗與營運資料容易表達，卻也意味著兩個形狀相同的物件相加，不一定按位置進行。重複索引或未排序時間更可能產生意外。

工程團隊應在資料入口驗證欄名、唯一鍵、順序與型別，避免依賴推論。對訓練資料要保存 schema fingerprint 與統計；模型服務收到的 DataFrame 必須和訓練契約比較，不能只確認欄數相同。

缺失值有多種語意

浮點 NaN、nullable integer、字串缺失與時間 NaT 在儲存和比較上不完全相同。缺失可能代表未蒐集、不適用、被刪除或處理失敗，若全部填零，模型會把不同原因混在一起。

Schema 應區分 nullable 與 required，轉換時保留 validity。特徵工程可另外產生 missing indicator，但要防止洩漏，例如只有違約後才補登的欄位。資料品質報告按來源與租戶追蹤缺失率漂移。

向量化的收益來自批次與底層 kernel

Python loop 每個元素都經過動態物件與解譯器開銷；向量化把一批資料交給 NumPy、C 或其他 kernel，提高記憶體局部性並減少呼叫。這是 pandas 能處理大量表格資料的重要基礎。

但向量化可能為每個中間運算配置整欄，複雜 chaining 會增加峰值記憶體。團隊需用 profiler 看 allocation 與 copy，必要時分批、使用 expression engine 或改到更合適的執行框架。語法短不代表資源少。

索引對齊同時是便利與陷阱

pandas 在算術與合併時會依 label 對齊，能避免不同順序資料被錯配。但若索引含意不清、重複或跨 batch 重設，對齊可能產生大量缺失或笛卡兒結果。模型特徵和 label 一旦錯位，訓練仍可完成卻學到錯誤關係。

訓練資料應以明確 entity key 與 event time join，合併前後檢查 row count、唯一性和 unmatched rate。不要依賴當前列順序；輸出給 tensor 前，保存 key 到 row 的映射，以便錯誤分析可回到來源。

時間序列需要處理時區與事件時間

Timestamp 可能沒有時區、含 UTC offset 或處於 daylight saving 的模糊時刻。直接移除 timezone 會改變時間語意。Resample、rolling window 與 as-of join 又取決於排序和封閉區間。

AI 特徵應以 UTC 保存事件時間，另保留來源 timezone 與接收時間。建立「過去七天」特徵時，必須只讀預測當下已知資料，避免 future leakage。測試跨越夏令時間、月底與晚到事件。

GroupBy 與 join 是最容易放大資料量的操作

GroupBy 可能建立大量 group state，高基數 key 會消耗記憶體；many-to-many join 則可能讓輸出以乘法成長。小樣本看似正常，上線到真實客戶資料便 OOM 或產生重複樣本。

合併前聲明預期 cardinality，例如 one-to-one 或 many-to-one，並驗證。對高基數聚合可分區、預聚合或使用外部排序。每步記錄列數與 key 數，任何超過合理倍率的變化都應停止 pipeline。

pandas 的單機邊界需要被誠實看待

pandas 主要面向單機記憶體內分析。資料超過 RAM 時，swap、暫存與 copy 會使效能急遽惡化。把更大機器當唯一方案，可能忽略可以投影欄位、下推過濾或以分區讀取解決的問題。

合理路徑是先縮小資料：只讀需要的欄與列，使用 Parquet 統計下推，按時間或租戶分批。若工作天然需要全域 shuffle 或超過單機，選擇分散式引擎；不要用手寫多程序勉強複製 DataFrame。

跨語言交換曾是資料平台的複製稅

Python、R、Java、C++ 與資料庫各自有記憶體表示。一個引擎產生結果後，常要序列化成 bytes，另一端再解析並配置新物件。對寬表、大字串或高頻批次，資料搬移可能比實際計算更昂貴。

更麻煩的是型別語意不完全相同。Nullable integer、timestamp、decimal、dictionary 與 nested data 在轉換時可能降級。若每個 pair 都做專用 adapter，組合數快速增加，且容易出現不一致。

Apache Arrow 提供共同欄式記憶體格式

Arrow 定義語言無關的 columnar memory format，讓多個系統可在共享結構上讀取資料。Primitive values、offsets、validity bitmap 與 buffers 有清楚 layout；實作可建立 zero-copy view 或以極少轉換交換。

共同格式不等於所有交換都零複製。程序、機器、裝置與記憶體 allocator 不同時仍可能 copy；壓縮資料也需解壓。平台應量實際 buffer ownership 與 transfer，而不是只因 API 名稱含 Arrow 就宣稱 zero-copy。

欄式配置符合分析 workload

分析查詢常只讀少數欄並對大量列聚合。連續欄 buffer 讓 CPU cache、SIMD 與壓縮更有效，也能跳過不需要欄位。相較逐列物件，型別一致的 buffer 減少 pointer chasing。

但逐列更新或取回完整 entity 時，row-oriented store 可能更合適。AI 平台通常以 row store 保留交易來源，以 columnar file 或 memory 做分析與訓練。不要把同一格式強迫到所有階段。

Validity bitmap 把 null 與值分開

Arrow 以 bitmap 表示某位置是否有效，value buffer 可維持固定型別。這比把整數轉成浮點 NaN 更能保存語意，也利於向量化 kernel。Slice 可共享既有 buffers，不必複製整欄。

Kernel 仍要正確傳播 null。聚合是忽略、計數還是回傳 null，應有明確契約。從 pandas、SQL 或模型 tensor 轉換時，測試全 null、無 null 和 sparse null，避免 validity 在邊界遺失。

Variable-length 資料由 offsets 與 values 組成

字串和 binary 通常以 offset buffer 指向連續 values buffer，避免每個元素是一個獨立物件。這降低配置與指標成本，也讓 slice 可以共享底層資料。Nested list 也可遞迴使用相似結構。

不可信資料可能提供越界或非單調 offset，因此 reader 必須驗證。超長單一字串也能耗盡記憶體；服務端對 batch bytes、元素長度和 nesting depth 設限。高效格式同時是 native parser 的安全邊界。

Dictionary encoding 降低重複分類值成本

國家、產品或狀態等低基數字串可以字典加整數 index 表示，減少記憶體並加速比較。跨 batch 時字典可能不同，合併需要 unify 或保留各自 dictionary。

若把 index 數字直接送進模型，不同 batch 的同一數字可能代表不同類別。特徵工程要以穩定 vocabulary 或顯式 decode 處理；未知類別與 vocabulary 版本也要保存，避免線上和訓練錯配。

Arrow type system 是互通契約

共同 schema 可以表達 signed/unsigned integer、floating point、decimal、timestamp、duration、struct、list 與 dictionary 等型別。每種語言仍可能只有部分原生對應，需要 extension type 或保守轉換。

平台應在交換前協商 schema，拒絕不安全 narrowing，例如 int64 到 int32 或帶時區 timestamp 變成無時區。對 extension type 保存名稱與 metadata；接收端不理解時 fail clearly，不要默默變成 opaque string。

RecordBatch 是流式交換的實用單位

一次把整個 dataset 放進記憶體不可擴充。RecordBatch 以固定 schema 傳送一批列，讓 producer 與 consumer 以 bounded memory pipeline 處理。Batch 大小影響向量化效率、延遲與背壓。

太小會增加呼叫和 metadata，太大會提高峰值與取消成本。應以真實欄寬和 kernel 量測，不只用列數。跨服務傳送時設最大 bytes，並讓取消能釋放 buffer，避免慢 consumer 使 allocator 持續成長。

Arrow IPC 與 Flight 解決不同層次

Arrow IPC 定義 record batch 與 schema 的序列化，適合檔案或 stream；Arrow Flight 建立在網路傳輸之上，提供高吞吐資料服務介面。它們使用共同 columnar 表示，減少傳統 JSON 或逐列 protocol 的成本。

網路服務仍需要認證、授權、租戶配額、TLS 與審計。Ticket 或 descriptor 不能直接信任；server 應把租戶條件下推查詢，避免先送出整批再過濾。壓縮與加密也會影響 zero-copy 假設。

Parquet 與 Arrow 是儲存和記憶體的搭配

Parquet 是持久化欄式檔案格式，包含 row group、page、encoding、compression 與統計；Arrow 是記憶體格式。讀取 Parquet 後常產生 Arrow arrays，但兩者 layout 並不完全相同，仍需要解碼。

資料湖設計應選合適 row-group size、partition 與排序，使查詢能 predicate pushdown。大量小檔會增加 metadata 與開啟成本，需 compaction；過大檔案又降低平行與更新彈性。訓練 pipeline 保存檔案清單與 snapshot。

pandas 與 Arrow 的整合改善型別與交換

pandas 可透過 Arrow-backed dtype、Parquet 與相關介面使用 Arrow buffers，改善字串、nullable type 與跨系統交換。具體行為依 pandas、PyArrow 與資料型別版本而變，不能假設所有 operation 都留在 Arrow。

導入前建立 compatibility matrix，覆蓋讀寫、groupby、join、timezone、decimal、nested 與第三方 library。Profiler 驗證 copy 數和 peak memory；不支援操作可能 materialize 成舊 dtype，效能與語意都要被觀測。

Dataframe interchange 需要比 API 名稱更嚴格

不同 DataFrame library 若能交換 column buffers、dtype 與 null metadata，就可降低轉成 pandas 的成本。實際上 allocator、chunking、device 和 string encoding 都會影響是否零複製。

交換契約要說明誰擁有記憶體、consumer 使用多久、原物件釋放後 view 是否有效。非同步 GPU 工作尤其可能在 buffer 已釋放後才讀取。生命週期錯誤常表現為偶發 corruption，需要壓力與 sanitizer 測試。

CPU 與 GPU 之間仍有裝置邊界

Arrow 的共同概念能幫助 GPU 資料框架互通，但 host memory 與 device memory 不在同一位置。PCIe 或 NVLink transfer、pinning、stream synchronization 仍是成本。零 CPU copy 不代表零 device copy。

AI pipeline 應把 decode、filter、batch 與 tensor conversion 排程在最合適裝置，避免資料來回搬。使用 profiler 記錄 H2D/D2H bytes 與等待；如果 GPU kernel 很快但長時間等資料，優化模型不會改善端到端吞吐。

LLM 資料不是只有文字欄位

一筆訓練或評估資料還包含 document_id、language、license、source、timestamp、tenant、policy、token count 與多個版本。若全部包成任意 JSON，查詢與驗證困難；若過早固定成 tensor，又會失去治理 metadata。

可用 schema 化 columnar table 保存資料集，文字與 metadata 一起版本化，訓練前再轉成 token buffers。Nested 欄可表達 message sequence 或工具呼叫，但要限制深度。每個 dataset snapshot 保存 schema、檔案與內容 hash。

批次 tokenization 要對齊資料系統

Tokenizer 通常對大量文字批次更有效，但句長差異會造成 padding 或不平衡。可先用字元或歷史 token 統計分桶，再以 RecordBatch 供給 worker。輸出保存 tokenizer 名稱、revision 與 special-token policy。

模型 context 限制不能只用平均值。對超長文件要明確切塊、重疊與截斷，並記錄來源範圍。任何過濾都輸出原因計數，避免大量特定語言或租戶被靜默丟棄，造成資料偏差。

線上特徵與離線訓練要共享語意

離線 pandas pipeline 和線上服務若分別實作，容易產生 training-serving skew。相同欄名可能用不同 timezone、缺失預設或 category vocabulary。共享 Arrow schema 只能對齊表示，仍需共享轉換定義。

可靠做法是把 transformation version 化，對固定輸入產生 golden output，離線與線上都跑。發布模型時鎖定 feature schema 和程式版本；服務收到不相容資料就拒絕或走清楚 fallback，而非自動填補未知欄。

資料品質檢查要進入每個 batch

只在資料集建立完成後檢查，會讓錯誤傳播很遠。每個 RecordBatch 可驗證 schema、range、null、unique 與分布摘要，並累積到 dataset report。失敗資料隔離並保留安全參照，不讓整批無界重試。

品質門檻要區分 hard invariant 和 drift warning。跨租戶洩漏、主鍵重複或 label 在特徵時間之後屬於 hard stop；分布小幅改變可以告警並比較。所有門檻保存版本與 owner。

Native columnar parser 是供應鏈邊界

Parquet、Arrow IPC 與壓縮 codec 常由 C/C++ 或 Rust 實作，解析不可信檔案時可能遇到記憶體安全或資源耗盡風險。套件版本、binary wheel 與 transitive dependency 都需要鎖定與掃描。

入口限制檔案大小、schema 寬度、nesting、row group 與解壓比例，在隔離 worker 解析外部資料。Fuzz parser 和異常 metadata，設定 CPU、記憶體與時間上限。高效資料格式不能繞過安全審核。

Benchmark 必須同時量計算與搬移

比較 pandas、Arrow 或其他引擎時，要使用相同資料、schema、null 與輸出語意。只量 operator kernel，可能忽略讀檔、轉換、序列化與結果 materialization。Warm cache 和 cold cache 也應分開。

報告 wall time、CPU、peak memory、bytes copied、檔案大小與 correctness。不同資料寬度、字串基數與 batch size 會改變結論；列出收益適用範圍，而不是用單一最大加速代表所有 workload。

可重現資料管線需要固定的不只程式碼

同一程式讀到不同檔案清單、schema inference、timezone database 或 category dictionary，結果就可能改變。每次執行保存 input manifest、版本、參數與環境，輸出以內容 hash 或 immutable URI 定位。

隨機抽樣和 shuffle 使用顯式 seed，但仍要注意多執行緒與分區順序。重要統計允許浮點容差並跨版本比較。發現差異時，能定位是資料、library、硬體還是演算法，而不是重跑直到通過。

Wes McKinney 留給 AI 資料層的核心方法

第一，分析介面要讓人能快速表達資料工作；第二，底層表示要讓系統少做無意義的複製與轉換；第三，互通需要公開 schema、buffer 與生命週期契約。pandas 和 Arrow 分別從使用者層與系統層處理這些問題。

在 AI 平台中，模型訓練、RAG、評估與線上特徵都依賴相同資料底座。若每個框架擁有孤立格式，團隊會把算力浪費在搬移，也更難保存型別、權限與來源。共同 columnar 語言不是最終答案，卻是建立可組合生態的重要基礎。

給導入團隊的實作順序

先盤點最大資料交換邊界，量 copy、serialization 和 peak memory；選一條低風險 pipeline，以明確 Arrow schema 交換 RecordBatch，保留原路徑作 reference。確認 null、time、decimal 與 nested data 完全一致後再擴大。

第二階段整合 Parquet pushdown、批次 tokenization 與資料品質 gate；第三階段才處理跨語言服務、GPU 與 Flight。每一步都要有 correctness、資源與 rollback 證據。零複製是結果，不是需求文件上的形容詞。

延伸閱讀

若想把DataFrame與columnar資料層放進分析資料庫的演進脈絡，可以接著閱讀Jordan Tigani如何從BigQuery到MotherDuck重寫AI分析資料庫，對照資料格式、查詢引擎與成本治理。

官方資料與延伸閱讀

• Wes McKinney 個人官方簡介
• pandas 官方專案介紹
• Apache Arrow 官方 overview
• Apache Arrow Columnar Format 規格
• Apache Arrow 官方 committers 名單
• Ibis 官方專案網站
• Posit 官方網站