數(shù)據(jù)清洗占掉分析師80%的時(shí)間，這不是段子。Juliana Albertyn在GitHub開源了她的首個(gè)Python項(xiàng)目，專門啃這塊硬骨頭——把亂七八糟的Excel直接灌進(jìn)SQL數(shù)據(jù)庫。

她遇到的問題，每個(gè)和數(shù)據(jù)打交道的人都懂：表頭藏在第3行、日期格式寫成"2024年3月15號"和"15-Mar-24"混用、空單元格和"N/A"和"-"三足鼎立。

手動清理？可以。第三次凌晨兩點(diǎn)改同一個(gè)模板的時(shí)候，Juliana決定寫代碼。

這個(gè)管道到底管什么

項(xiàng)目核心就三件事。自動檢測表頭位置，不用你數(shù)第幾行開始；統(tǒng)一數(shù)據(jù)類型，把文本里的日期、數(shù)字里的逗號全扒干凈；報(bào)錯要具體，哪張表的哪一列出了問題，直接指出來。

Juliana的原話：「讓管道可預(yù)測，出錯時(shí)容易調(diào)試?！?/p>

這話聽著樸素，做過ETL的人都知道分量。很多開源工具追求"一鍵搞定"，真報(bào)錯時(shí)你對著Traceback發(fā)呆半小時(shí)。她的設(shè)計(jì)是反過來的：每一步都留痕跡，臟數(shù)據(jù)進(jìn)，干凈數(shù)據(jù)出，中間哪一步卡住一目了然。

目前代碼還在迭代。Juliana列了三個(gè)最想聽反饋的方向：配置文件的寫法是否直觀、異常處理夠不夠細(xì)、類型推斷的準(zhǔn)確率。

為什么選Excel開刀

企業(yè)數(shù)據(jù)系統(tǒng)的真相是：ERP再貴，最后數(shù)據(jù)還是從Excel匯總上來的。銷售報(bào)表、財(cái)務(wù)月結(jié)、庫存盤點(diǎn)，全是表格飛來飛去。

Python生態(tài)里，Pandas讀Excel不難，難的是應(yīng)對"人類智慧"——合并單元格、顏色標(biāo)記優(yōu)先級、批注里藏關(guān)鍵信息。Juliana的管道沒試圖解決所有問題，她把邊界劃得很清楚：先搞定結(jié)構(gòu)混亂，再談?wù)Z義理解。

下一階段她要寫SQL寫入層。現(xiàn)在清洗完的數(shù)據(jù)還得手動建表、導(dǎo)數(shù)，下一步是讓管道直連SQL Server，自動建表、自動映射字段類型。

新手做開源的誠實(shí)樣本

Juliana在README里寫了三遍"還在學(xué)習(xí)，歡迎批評"。這種姿態(tài)在GitHub不多見。

多數(shù)首秀項(xiàng)目要么過度包裝，要么干脆棄坑。她選了中間路線：功能聚焦、文檔誠實(shí)、迭代節(jié)奏公開。47個(gè)commit（提交記錄）分布在三個(gè)月里，不是心血來潮的周末項(xiàng)目。

代碼量不大，但結(jié)構(gòu)清晰。配置用YAML，清洗邏輯拆成獨(dú)立模塊，測試覆蓋核心路徑。對于"第一個(gè) substantial 項(xiàng)目"來說，工程意識已經(jīng)到位。

項(xiàng)目地址扔在GitHub：juliana-albertyn/excel-to-sql。如果你也被Excel折磨過，會去試這個(gè)管道，還是覺得自己寫的腳本更順手？