CSV加載慢13倍被踢出生產線，Parquet用0.06秒完成逆

0.78秒 vs 0.06秒。這不是什么實驗室數據，是Sakshaleni在處理時間序列數據時真實測出來的差距。CSV用了將近1秒，Parquet眨眼就完事。文件體積更夸張，同樣一份數據，Parquet能壓縮到CSV的幾分之一。

這事聽起來像老生常談——"換格式能快多少？"但真踩過坑的人知道，當數據量從MB滾到GB，加載時間從"等一杯咖啡"變成"等外賣送達"，整個分析流程就癱了。Saksheni的經歷很典型：初期CSV完美夠用，數據膨脹后成了瓶頸。

為什么CSV會越跑越慢

CSV是行式存儲（row-based format），讀數據時得整行掃描。你想查某一列？先把整行拖進內存，再挑出要的字段。數據量小的時候無所謂，百萬行以后這就是災難。

Parquet玩的是列式存儲（columnar storage）。數據按列存，查詢只讀需要的列，I/O直接砍半再砍半。更狠的是它內置的壓縮和編碼——同一列的數據類型一致，壓縮率比行式高出一個數量級。

Sakshaleni的測試代碼很直白：pd.read_parquet()和pd.read_csv()各跑一遍，時間差擺在臺面上。13倍的速度差距，沒有玄學，就是存儲結構決定的。

Parquet的隱藏技能：不只是快

很多人把Parquet當"壓縮包"用，其實它是個查詢優化器。列式存儲配合謂詞下推（predicate pushdown），能在文件層面過濾數據，不用等全表進內存。

PyArrow是背后的關鍵工具。這個Python庫封裝了Apache Arrow的列式內存格式，讓Parquet的讀寫效率能真正落地到日常代碼里。Sakshaleni沒提具體壓縮算法，但Parquet默認支持的Snappy、GZIP、ZSTD都是工業級方案，選哪個看你要速度還是要體積。

時間序列數據有個特點：時間戳一列、數值一列、標簽一列，列之間關聯性弱但列內重復度高。這種結構簡直是給Parquet送分——時間戳用Delta編碼，重復標簽用字典編碼，壓縮率能再往上躥。

遷移成本：比你想象的低

Pandas用戶換Parquet幾乎無痛。to_parquet()和read_parquet()的API設計跟CSV保持一致，代碼改動量以行計。真正的門檻在思維轉換：從"打開文件"變成"設計查詢模式"。

Parquet不是萬能藥。小文件場景下，它的元數據開銷反而拖后腿；頻繁隨機寫的工作負載，列式格式也不擅長。但時間序列分析通常是"一次寫入、多次讀取、列式查詢"，正好踩中Parquet的甜點區。

Sakshaleni沒公布具體的數據集規模，但從MB級CSV的加載時間反推，大概是幾十萬到百萬行的量級。這個區間很多人還在硬撐CSV，覺得"不至于換格式"——直到某天數據翻倍，腳本跑崩了才后悔。

一個值得追問的細節

測試里Parquet的0.06秒是冷啟動還是熱緩存？文件有沒有分區？這些Sakshaleni沒展開，但生產環境里的性能差距往往比實驗室更極端——或者更微妙。你手上的時間序列數據，現在多大體積了？