1. 先把地基打牢版本選擇、虛擬環(huán)境與編輯器聯(lián)調(diào)1.1 版本選擇不要一上來就追最新很多人剛開始學(xué)Python會(huì)直接去官網(wǎng)下載最新版裝完再裝numpy、pandas發(fā)現(xiàn)一切正常于是覺得“版本無所謂”。直到有一天你需要在公司集群上跑PySpark或者在Linux服務(wù)器上部署一個(gè)老項(xiàng)目才發(fā)現(xiàn)服務(wù)器里裝的是Python 3.8你本地用的卻是3.12接口差異、依賴沖突、編譯錯(cuò)誤一起涌上來。我在實(shí)際工作中被這個(gè)事坑過不止一次后來給自己定了一條規(guī)矩做數(shù)據(jù)分析優(yōu)先選生態(tài)兼容性最好的穩(wěn)定版本而不是最新版本。如果你不依賴特別老的內(nèi)部庫(kù)Python 3.10或3.11是比較舒服的選擇pandas、numpy、scikit-learn、matplotlib這些核心庫(kù)都維護(hù)得很好Spark和Hive相關(guān)的客戶端也不容易出兼容問題。千萬別小看這一步版本選錯(cuò)后面所有包都可能連鎖報(bào)錯(cuò)。真實(shí)場(chǎng)景里某個(gè)同事用3.13裝了一個(gè)依賴Cython的老庫(kù)編譯直接失敗折騰一下午最后換回3.10就好。另一個(gè)容易被忽略的點(diǎn)是機(jī)器位數(shù)和操作系統(tǒng)的差異。Windows、macOS、Linux三套環(huán)境里同一條pip install命令的行為可能完全不同。比如opencv-python在普通Linux服務(wù)器上經(jīng)常缺libGL庫(kù)一旦你拿它處理圖片一運(yùn)行就報(bào)錯(cuò)。這時(shí)候裝opencv-python-headless反而更省事。數(shù)據(jù)分析師不一定天天寫圖像代碼但這一類“環(huán)境差異”問題會(huì)反復(fù)出現(xiàn)提早了解能省下大量排查時(shí)間。1.2 從官網(wǎng)下載到環(huán)境變量配置的完整鏈路安裝Python這件事看起來就是“下一步、下一步、完成”但有一個(gè)關(guān)鍵選項(xiàng)很多人會(huì)漏Windows安裝包第一頁(yè)底部的“Add Python to PATH”必須勾選。沒勾選的話你打開命令行輸入python系統(tǒng)會(huì)一臉茫然地告訴你“不是內(nèi)部或外部命令”。這就是網(wǎng)上大量“python安裝教程”帖子存在的意義。勾選之后你的電腦才能直接在終端里喚起Python。裝完以后建議你順手驗(yàn)證三件事python --version pip --version python -m pip install --upgrade pip第一條看版本第二條看pip是否可用第三條把pip更新到穩(wěn)定版本。別小看第三條老版本pip在裝某些帶二進(jìn)制依賴的庫(kù)時(shí)會(huì)莫名解析出錯(cuò)升級(jí)之后問題直接消失。Linux系統(tǒng)下安裝又不一樣。大多數(shù)發(fā)行版自帶Python 3但自帶的版本可能偏舊而且系統(tǒng)包管理器里的Python和pip經(jīng)常受系統(tǒng)權(quán)限保護(hù)你直接往里裝包會(huì)污染系統(tǒng)環(huán)境。我的做法是用apt安裝python3-venv或者直接下載官方二進(jìn)制包解壓到個(gè)人目錄再手動(dòng)配置PATH和PYTHONPATH。這樣既不影響系統(tǒng)自帶的Python又能給數(shù)據(jù)分析環(huán)境一個(gè)獨(dú)立空間。環(huán)境變量配置也值得多寫一句PATH決定你在終端里輸入python時(shí)系統(tǒng)去哪里找解釋器PYTHONPATH則決定import包時(shí)去哪里找模塊。很多人遇到“明明裝了pandasimport卻說找不到”就是因?yàn)樵诹硪粋€(gè)Python解釋器下運(yùn)行。所以每次換環(huán)境前先在終端里敲一下which python確認(rèn)自己到底在用哪個(gè)解釋器。1.3 vscode配置和Jupyter的取舍文本編輯器我推薦vscode不是因?yàn)樗δ茏疃喽且驗(yàn)樗选皩懩_本、跑代碼、看數(shù)據(jù)”放進(jìn)同一個(gè)窗口。你在vscode里安裝Python擴(kuò)展后重點(diǎn)是學(xué)會(huì)切換解釋器按CtrlShiftP輸入“Python: Select Interpreter”選你創(chuàng)建的那個(gè)虛擬環(huán)境。這一步?jīng)]做對(duì)后面代碼跑起來沒問題但一import就報(bào)ModuleNotFoundError根源多半是解釋器選錯(cuò)了。分析工作還有一個(gè)高頻工具是Jupyter Notebook。它適合探索性分析一段段跑、邊跑邊看中間結(jié)果、隨時(shí)把圖表插到代碼之間。缺點(diǎn)也很明顯代碼順序一旦混亂變量狀態(tài)容易“串味”。我的習(xí)慣是探索階段用Notebook整理成正式腳本時(shí)切回vscode把驗(yàn)證過的邏輯寫成函數(shù)。兩套工具配合使用比在Notebook里堆幾千行代碼舒服得多。1.4 安裝numpy、cv2、PySpark等包時(shí)最常見的翻車現(xiàn)場(chǎng)網(wǎng)上搜索“python安裝numpy庫(kù)的方法”通常給出的答案就是pip install numpy。實(shí)際做的時(shí)候你可能遇到兩種情況第一種是網(wǎng)絡(luò)超時(shí)pip一直轉(zhuǎn)圈最后報(bào)ReadTimeoutError第二種是編譯錯(cuò)誤提示缺少M(fèi)icrosoft Visual C或gcc。超時(shí)可以切換國(guó)內(nèi)PyPI鏡像比如執(zhí)行pip install numpy -i https://pypi.tuna.tsinghua.edu.cn/simple速度立刻不一樣。編譯錯(cuò)誤則通常說明當(dāng)前環(huán)境缺少預(yù)編譯好的wheel包優(yōu)先升級(jí)pip再不行就裝對(duì)應(yīng)系統(tǒng)版本的編譯器工具。安裝PySpark比安裝普通庫(kù)多一道門檻它依賴Java運(yùn)行環(huán)境。很多人在沒有任何JDK的機(jī)器上執(zhí)行pip install pyspark裝完以為自己能跑了一import就拋java.io.FileNotFoundException或者顯示找不到JAVA_HOME。解決辦法是先裝JDK配置好JAVA_HOME再裝pyspark。凡是跟Java綁定的庫(kù)都必須先確認(rèn)Java環(huán)境這是這類場(chǎng)景最常見的坑。還有一個(gè)習(xí)慣我強(qiáng)烈建議不要在base環(huán)境里無腦裝包。用conda或venv創(chuàng)建獨(dú)立環(huán)境比如conda create -n analysis python3.10然后激活它再裝pandas、numpy、matplotlib、pyspark。獨(dú)立環(huán)境的好處是項(xiàng)目A升級(jí)某個(gè)庫(kù)不會(huì)把項(xiàng)目B的環(huán)境搞壞哪天環(huán)境被搞亂了直接刪掉重建幾分鐘就能恢復(fù)。數(shù)據(jù)分析師的項(xiàng)目周期短、需求多變這一套“隔離”思路能幫你省下大量返工時(shí)間。2. 數(shù)據(jù)讀取與清洗把臟活干得優(yōu)雅一點(diǎn)2.1 讀CSV、Excel、數(shù)據(jù)庫(kù)時(shí)的常見小脾氣做數(shù)據(jù)分析的人每天面對(duì)的數(shù)據(jù)源繞不開CSV、Excel和數(shù)據(jù)庫(kù)這三種。CSV是最常見的但也是坑最多的。第一個(gè)坑是編碼Windows下的CSV經(jīng)常是gbk編碼直接用pandas默認(rèn)的utf-8去讀滿屏都是UnicodeDecodeError。我的習(xí)慣是一開始就指定encodingutf-8-sig如果是gbk再換成encodinggbk。第二個(gè)坑是列類型訂單號(hào)的長(zhǎng)度超過15位時(shí)Excel和CSV會(huì)把后幾位變成0讀進(jìn)pandas后變成浮點(diǎn)數(shù)。所以讀訂單表我通常在read_csv里指定dtype把訂單號(hào)強(qiáng)制讀成字符串import pandas as pd df pd.read_csv( orders_2025.csv, encodingutf-8-sig, dtype{order_id: str, amount: float, city: str} )讀Excel要記住一個(gè)前提pandas本身不直接支持xlsx需要先裝openpyxl或xlrd。很多人沒裝擴(kuò)展包就調(diào)用read_excel報(bào)錯(cuò)后以為是函數(shù)用錯(cuò)了。數(shù)據(jù)庫(kù)讀取稍微復(fù)雜一點(diǎn)一般需要SQLAlchemy連接串比如pd.read_sql(select * from orders limit 1000, conengine)。這里建議先做limit抽樣確認(rèn)數(shù)據(jù)量級(jí)和字段含義再?zèng)Q定是全量拉取還是分批拉取。做商業(yè)數(shù)據(jù)分析時(shí)動(dòng)不動(dòng)就全表掃描是最容易拖垮數(shù)據(jù)庫(kù)的行為。2.2 去重、缺失值和“看起來一模一樣”的數(shù)據(jù)數(shù)據(jù)清洗里的去重比你想象中要復(fù)雜。直接調(diào)用df.drop_duplicates()確實(shí)能按整行去重但業(yè)務(wù)上的重復(fù)經(jīng)常只針對(duì)某些關(guān)鍵字段比如一個(gè)訂單號(hào)出現(xiàn)在兩行但金額和收貨地址不完全相同這時(shí)候你要按訂單號(hào)去重并且自己定義保留策略保留最新時(shí)間、保留金額較大的、保留下單狀態(tài)更完整的。建議先執(zhí)行df[df.duplicated([order_id], keepFalse)]把重復(fù)樣本單獨(dú)撈出來看幾行而不是盲目刪除。缺失值處理也是同理別一見到NaN就fillna(0)。連續(xù)型指標(biāo)像金額、時(shí)長(zhǎng)更適合用中位數(shù)填充因?yàn)橹形粩?shù)不容易被極端值帶偏。離散型指標(biāo)像城市、渠道我會(huì)先看缺失比例如果缺失比例太高直接補(bǔ)“未知”比猜一個(gè)值更誠(chéng)實(shí)如果缺失比例很低可以用眾數(shù)填充。有一個(gè)小技巧我很常用先df.isna().sum()統(tǒng)計(jì)每一列的缺失數(shù)量再按缺失原因決定策略。這個(gè)順序能避免“拍腦袋處理”。還有一種更隱蔽的重復(fù)內(nèi)容幾乎一樣但寫法不同。比如“北京市朝陽區(qū)”和“北京朝陽區(qū)”“張三”和“張先生”算法層面不好直接判斷。遇到這種數(shù)據(jù)我一般用difflib庫(kù)里基于文本相似度的工具做初步聚類把相似度大于90%的樣本篩出來再人工確認(rèn)。數(shù)據(jù)清洗最核心的思維不是“把數(shù)據(jù)變沒”而是“把不可比的數(shù)據(jù)變成可比的數(shù)據(jù)”這個(gè)思路在處理地址、產(chǎn)品名、渠道名時(shí)特別管用。2.3 從訂單表到鄰接矩陣一種常用關(guān)系轉(zhuǎn)換很多人在網(wǎng)上搜“python構(gòu)建鄰接矩陣”一看到矩陣和networkx就頭大其實(shí)在數(shù)據(jù)分析場(chǎng)景里鄰接矩陣就是一張寬表行是起點(diǎn)列是終點(diǎn)單元格里是關(guān)系強(qiáng)度。拿訂單數(shù)據(jù)舉例子假設(shè)你有一張“客戶-商品”購(gòu)買記錄表里面有customer_id和product_id你想知道哪些客戶同時(shí)買過哪些商品最簡(jiǎn)單的一步就是把長(zhǎng)表轉(zhuǎn)成寬表也就是交叉表。用pandas可以一行完成matrix pd.crosstab(orders[customer_id], orders[product_id])這個(gè)m*n的矩陣?yán)镄惺强蛻袅惺巧唐分凳窃摽蛻糍?gòu)買該商品的次數(shù)。你別看這個(gè)簡(jiǎn)單操作它背后是很多分析項(xiàng)目的地基商品協(xié)同過濾、客戶分群、關(guān)聯(lián)分析全都從這張矩陣開始。如果你的原始數(shù)據(jù)是網(wǎng)絡(luò)關(guān)系表比如兩列分別是“起點(diǎn)”和“終點(diǎn)”用networkx里的from_pandas_edgelist也能直接構(gòu)建圖對(duì)象后面算節(jié)點(diǎn)度、找連通分量都很方便。構(gòu)建鄰接矩陣前我建議先做一步檢查用pivot_table還是crosstab取決于你的數(shù)據(jù)是否有重復(fù)行。若有重復(fù)crosstab會(huì)直接計(jì)數(shù)若想自定義聚合方式比如算平均消費(fèi)先groupby再pivot會(huì)更穩(wěn)。把這一步想清楚矩陣?yán)锞筒粫?huì)出現(xiàn)莫名其妙的重復(fù)累計(jì)。2.4 單個(gè)文件讀取慢用線程池把多個(gè)文件并行讀進(jìn)來做數(shù)據(jù)分析時(shí)我經(jīng)常遇到“一天一個(gè)文件一個(gè)月30個(gè)文件每個(gè)幾十MB”的情況。如果你寫for循環(huán)一個(gè)一個(gè)讀耗時(shí)線性增長(zhǎng)讀30個(gè)文件就得等幾分鐘。好消息是這類讀取是I/O密集型操作不需要等上一個(gè)文件讀完再開下一個(gè)。pandas的read_csv本身是帶緩沖的但如果文件數(shù)量多用concurrent.futures的ThreadPoolExecutor可以明顯提速。from concurrent.futures import ThreadPoolExecutor import glob import pandas as pd def read_one(path): return pd.read_csv(path, encodingutf-8-sig) files glob.glob(data/2025_*.csv) with ThreadPoolExecutor(max_workers8) as executor: frames list(executor.map(read_one, files)) df pd.concat(frames, ignore_indexTrue)用這招要留個(gè)心眼線程數(shù)不是越大越好一般8到16個(gè)就夠再大反而會(huì)因磁盤讀寫競(jìng)爭(zhēng)而變慢如果機(jī)器內(nèi)存比較小一次讀全部文件到內(nèi)存可能直接。穩(wěn)妥的做法是先看文件總大小總大小在2GB以內(nèi)通常沒問題超過這個(gè)量級(jí)就應(yīng)該考慮分塊讀取或轉(zhuǎn)用大數(shù)據(jù)工具。這里順便提一句Python協(xié)程適合網(wǎng)絡(luò)請(qǐng)求這類等待型任務(wù)而多線程更適合本地文件讀取別把兩個(gè)概念搞混。網(wǎng)上搜“python隊(duì)列queue不堵塞”本質(zhì)也是把任務(wù)放進(jìn)隊(duì)列、讓多個(gè)worker并行消費(fèi)只是在不同場(chǎng)景下線程池更直接。3. 分析計(jì)算與業(yè)務(wù)指標(biāo)的落地3.1 groupby聚合分析師的“透視表”如果只能保留一個(gè)pandas函數(shù)我一定選groupby。它就像Excel里的透視表但更靈活也更適合寫進(jìn)自動(dòng)化流程。比如你要看每個(gè)城市、每個(gè)月的訂單量和GMV代碼其實(shí)非常直白summary df.groupby([city, order_month]).agg( order_cnt(order_id, count), gmv(amount, sum), avg_order(amount, mean), ).reset_index()這里有個(gè)細(xì)節(jié)agg里的寫法是“新列名 (原列名, 聚合方式)”pandas會(huì)一次生成多列比分別groupby后merge效率高得多也更不容易寫錯(cuò)。我見過很多新手先groupby再.reset_index又因?yàn)樗饕龁栴}報(bào)錯(cuò)其實(shí)只要記住agg之后用reset_index把分組鍵變回普通列后續(xù)操作就不用跟索引較勁。groupby之后最常見的需求是算占比和環(huán)比。算城市占比可以先groupby得到城市GMV再除以GMV總和算環(huán)比一般用shift配合groupbymonthly[gmv_prev] monthly.groupby(city)[gmv].shift(1) monthly[mom] (monthly[gmv] / monthly[gmv_prev] - 1) * 100注意這里shift是按城市分組后各自向后平移一行所以每個(gè)城市的第一個(gè)月gmv_prev是NaN不能直接參與計(jì)算。數(shù)據(jù)量不大時(shí)這么寫很舒服數(shù)據(jù)量大到幾千萬行時(shí)groupby會(huì)明顯吃力這時(shí)候就該把計(jì)算推給Spark或數(shù)據(jù)庫(kù)引擎Python只負(fù)責(zé)拿最終結(jié)果做可視化千萬別在內(nèi)存里硬扛。3.2 用“李白打酒”這一類小問題訓(xùn)練分析思維網(wǎng)上有個(gè)經(jīng)典題目叫“李白打酒”很多學(xué)Python的人都刷到過。題目大意是李白酒壺里有一定量的酒他遇到酒店酒量加倍遇到花喝掉一斗最后經(jīng)過若干次遇店和見花酒正好喝光。問初始酒量是多少或者符合條件的情況有多少種。第一次看這道題你會(huì)覺得它只是一個(gè)算法練習(xí)題但把它寫一次遞歸代碼之后你會(huì)發(fā)現(xiàn)它訓(xùn)練的是“約束條件下窮舉”的能力def dfs(dian, hua, wine): if dian 0 and hua 0: return 1 if wine 0 else 0 res 0 if dian 0: res dfs(dian - 1, hua, wine * 2) if hua 0 and wine 0: res dfs(dian, hua - 1, wine - 1) return res在真實(shí)業(yè)務(wù)里這種“狀態(tài)搜索”思維特別有用。比如物流調(diào)撥問題給定一個(gè)中轉(zhuǎn)節(jié)點(diǎn)網(wǎng)絡(luò)貨物從A到B在有限中轉(zhuǎn)次數(shù)里能否到達(dá)這跟李白打酒里的“店”和“花”其實(shí)是同一類問題——每一步都有規(guī)則約束節(jié)點(diǎn)之間靠遞歸或隊(duì)列一層一層探索直到找到所有可能路徑。你不必把DFS背下來但你要能識(shí)別“這類問題可以用窮舉和狀態(tài)轉(zhuǎn)移來處理”這是數(shù)據(jù)分析師和只會(huì)套函數(shù)的人之間最大的差別。3.3 量化策略回測(cè)的最小框架把想法快速驗(yàn)證一遍量化交易是Python在金融領(lǐng)域最出圈的應(yīng)用之一網(wǎng)上搜“python量化交易策略代碼”會(huì)得到大量復(fù)雜框架。但作為數(shù)據(jù)分析師你不需要一步到位搭出生產(chǎn)級(jí)回測(cè)系統(tǒng)只要把“信號(hào)—持倉(cāng)—收益”這條鏈路跑通就能在實(shí)際操盤前驗(yàn)證大量想法。最小框架就是一個(gè)數(shù)據(jù)表加三列收盤價(jià)、信號(hào)、策略收益。def backtest(price_df, signal): ret price_df[close].pct_change().fillna(0) strategy_ret signal.shift(1).fillna(0) * ret return (1 strategy_ret).cumprod()這里最關(guān)鍵的是shift(1)用當(dāng)天的信號(hào)去預(yù)測(cè)次日的收益避免“用未來數(shù)據(jù)做決策”的前視偏差。哪怕只是寫個(gè)小策略我也提醒自己檢查三件事有沒有未來函數(shù)、有沒有把交易成本算進(jìn)去、信號(hào)是不是建立在成交量或價(jià)格的事后統(tǒng)計(jì)上。這三個(gè)坑不排掉回測(cè)出來曲線再漂亮實(shí)盤里也可能徹底變形。量化回測(cè)的本質(zhì)不是預(yù)測(cè)股價(jià)而是檢驗(yàn)?zāi)愕募僭O(shè)在歷史數(shù)據(jù)上是否成立這個(gè)思路完全遷移到業(yè)務(wù)分析里比如預(yù)測(cè)庫(kù)存周轉(zhuǎn)、判斷營(yíng)銷活動(dòng)的用戶響應(yīng)率同樣適用。3.4 數(shù)據(jù)定義與口徑比代碼更重要的分析模型代碼寫得好不代表分析做得對(duì)。我在實(shí)際項(xiàng)目里見過太多“兩個(gè)分析師算出兩個(gè)答案”的情況原因不是語法錯(cuò)誤而是口徑不一致。比如計(jì)算GMV是按下單時(shí)間算還是按支付時(shí)間算取消訂單算不算退款單算不算這些定義一旦不同同樣的SQL和Python跑出來的結(jié)果天差地別。所以每次分析開始前我會(huì)先把指標(biāo)口徑寫成一份幾十字的小說明發(fā)到協(xié)作群里確認(rèn)確認(rèn)后才動(dòng)手寫代碼。這個(gè)習(xí)慣相當(dāng)于給自己的Python工具箱配了一份“說明書”。工具本身再?gòu)?qiáng)口徑錯(cuò)了就是給業(yè)務(wù)方遞了一把傷人的刀。你的pandas聚合寫得再熟練也不如分析前多問一句“你到底想要什么”。這是商業(yè)數(shù)據(jù)分析里最值錢的經(jīng)驗(yàn)之一。4. 可視化別讓你的圖在PPT里活不過三秒4.1 橫坐標(biāo)太密集日期軸怎么治理用matplotlib畫時(shí)間序列時(shí)最常出現(xiàn)的問題就是橫坐標(biāo)擠成一團(tuán)日期太多刻度標(biāo)簽全部疊在一起黑乎乎一片。同事看了皺眉頭業(yè)務(wù)方看了搖頭。這個(gè)問題在網(wǎng)上反復(fù)被搜解法其實(shí)不復(fù)雜。先確保你的x軸是datetime類型然后用matplotlib.dates設(shè)置刻度間隔和格式import matplotlib.pyplot as plt import matplotlib.dates as mdates fig, ax plt.subplots(figsize(10, 4)) ax.plot(df[date], df[gmv]) ax.xaxis.set_major_locator(mdates.MonthLocator()) ax.xaxis.set_major_formatter(mdates.DateFormatter(%Y-%m)) plt.xticks(rotation45) plt.tight_layout() plt.show()如果你不需要那么細(xì)的粒度更簡(jiǎn)單的辦法是先用pandas把數(shù)據(jù)按周或按月光滑聚合減少點(diǎn)數(shù)之后再畫。比如df.resample(W-MON, ondate)[gmv].sum()把日粒度匯總成周粒度圖里的線條既平滑又不會(huì)丟失業(yè)務(wù)趨勢(shì)。畫圖的第一原則永遠(yuǎn)是“讓讀者一眼抓住想看的信息”而不是“把每個(gè)數(shù)據(jù)點(diǎn)都擺上去”。4.2 五種常見的業(yè)務(wù)圖形及選型邏輯不同分析問題應(yīng)該用不同圖形我給自己整理了一個(gè)選型表基本能覆蓋90%的業(yè)務(wù)場(chǎng)景分析目的推薦圖形使用要點(diǎn)看時(shí)間趨勢(shì)折線圖別超過3條線突出關(guān)鍵轉(zhuǎn)折點(diǎn)看構(gòu)成占比柱狀圖或堆疊柱狀圖類別超過5個(gè)時(shí)優(yōu)先用柱狀圖看數(shù)據(jù)分布直方圖或箱線圖箱線圖能看出異常值看變量關(guān)系散點(diǎn)圖加趨勢(shì)線先看相關(guān)系數(shù)再看圖看地域分布地圖或熱力圖數(shù)據(jù)量少時(shí)用熱力圖更直觀這里特別提醒餅圖不是不能用但只適合2到4個(gè)大類的占比。你硬要放一個(gè)12個(gè)部門的餅圖那只是把報(bào)告變成調(diào)色盤業(yè)務(wù)方根本看不出重點(diǎn)。還有柱狀圖和折線圖的混搭除非確認(rèn)兩個(gè)指標(biāo)在同一個(gè)量級(jí)否則別輕易用次坐標(biāo)軸次坐標(biāo)軸用不好就是“看圖說話的工具”。4.3 圖表細(xì)節(jié)標(biāo)題、單位和圖例要讓業(yè)務(wù)不猜一個(gè)合格的分析圖應(yīng)該是“不解釋也能看懂”。我每次出圖前都會(huì)看三處標(biāo)題寫的是不是結(jié)論而不是“銷售數(shù)據(jù)圖”坐標(biāo)軸有沒有單位圖例是不是和業(yè)務(wù)命名一致。比如標(biāo)題應(yīng)該寫“華東區(qū)GMV連續(xù)三個(gè)月下滑需關(guān)注競(jìng)品影響”而不是“華東區(qū)GMV變化”。分析圖是為了傳遞結(jié)論不是為了展示你matplotlib用得熟。還有一個(gè)小細(xì)節(jié)常被人忽略負(fù)號(hào)和中文。matplotlib默認(rèn)字體可能顯示不了中文還會(huì)把負(fù)號(hào)顯示成方塊。很多新手在論壇問為什么圖里都是方框多半是沒處理字體。常規(guī)寫法是plt.rcParams[font.sans-serif] [SimHei, Microsoft YaHei] plt.rcParams[axes.unicode_minus] False這兩行放在腳本開頭能解決大部分中文顯示問題。不同操作系統(tǒng)可用的字體不一樣Windows下SimHei和Microsoft YaHei通常沒問題macOS可以換成PingFang SC。我一般建議在vscode腳本里統(tǒng)一配置而不是每張圖都手動(dòng)改。4.4 從Notebook到正式報(bào)表別讓可視化變成一次性工作在Notebook里畫圖很方便但項(xiàng)目要交付時(shí)我通常會(huì)把畫圖代碼整理成函數(shù)比如plot_gmv_trend(df, city)這樣一份周報(bào)數(shù)據(jù)更新后只需要重新跑一遍腳本所有圖會(huì)自動(dòng)刷新。這個(gè)思維來自“數(shù)據(jù)分析項(xiàng)目實(shí)踐”里最常見的需求同一個(gè)分析業(yè)務(wù)方每周都要看一次。與其每周重新操作一遍不如把流程固化成本地腳本用定時(shí)任務(wù)去執(zhí)行。這個(gè)能力才是“數(shù)據(jù)分析師的Python工具箱”和普通Excel報(bào)表之間的分水嶺。5. 爬蟲、自動(dòng)化與大數(shù)據(jù)工具箱的上層聯(lián)動(dòng)5.1 合法取數(shù)只拿公開數(shù)據(jù)守住三條邊界數(shù)據(jù)分析師經(jīng)常需要補(bǔ)充外部數(shù)據(jù)比如競(jìng)品公開價(jià)格、行業(yè)政策、公開榜單這時(shí)候就需要爬蟲。網(wǎng)上有大量“python爬蟲”教程但我要先潑一盆冷水爬蟲最大的風(fēng)險(xiǎn)不是技術(shù)而是合規(guī)。我只做三種數(shù)據(jù)不需要登錄的公開頁(yè)面、有官方API的數(shù)據(jù)源、平臺(tái)明確允許下載的數(shù)據(jù)集。絕不碰登錄繞過、驗(yàn)證碼破解、高頻并發(fā)抓取這三件事任何一條都足夠讓你陷入麻煩。技術(shù)本身不復(fù)雜requests負(fù)責(zé)下載網(wǎng)頁(yè)BeautifulSoup或lxml負(fù)責(zé)解析結(jié)構(gòu)如果你要抓的是JSON接口直接用requests拿到response.json()更省事。一個(gè)最小化爬蟲長(zhǎng)這樣import requests from bs4 import BeautifulSoup headers {User-Agent: Mozilla/5.0} resp requests.get(url, headersheaders, timeout10) soup BeautifulSoup(resp.text, html.parser) titles soup.select(.product-title)這里有一個(gè)重要習(xí)慣每個(gè)請(qǐng)求之間加延時(shí)比如time.sleep(1)既是對(duì)對(duì)方服務(wù)器的尊重也能降低被封的風(fēng)險(xiǎn)。抓10個(gè)頁(yè)面和抓10萬個(gè)頁(yè)面的技術(shù)棧差別不大差別在于你是否把頻率控制住了。爬下來的數(shù)據(jù)一定要落盤不要停在內(nèi)存里用pd.DataFrame.to_csv()或直接寫入數(shù)據(jù)庫(kù)讓后續(xù)分析有據(jù)可查。5.2 電商快遞賬單、網(wǎng)約車訂單這類項(xiàng)目的數(shù)據(jù)結(jié)構(gòu)怎么拆在網(wǎng)上搜“電商快遞賬單數(shù)據(jù)分析”“網(wǎng)約車數(shù)據(jù)分析”會(huì)看到很多項(xiàng)目案例這些項(xiàng)目的數(shù)據(jù)結(jié)構(gòu)其實(shí)高度相似。它們通常都是明細(xì)級(jí)大表一單一行關(guān)鍵字段包括時(shí)間、地點(diǎn)、主體、金額、數(shù)量。電商快遞賬單關(guān)心的維度是計(jì)費(fèi)重量段、寄遞區(qū)域、產(chǎn)品類型、是否偏遠(yuǎn)地區(qū)網(wǎng)約車訂單關(guān)心的維度是高峰時(shí)段、起終點(diǎn)區(qū)域、里程區(qū)間、司機(jī)乘客分層。這類分析的第一步不是寫Python而是先把表結(jié)構(gòu)畫清楚搞清楚誰是事實(shí)表、誰是維度表。數(shù)據(jù)量小的時(shí)候pandas完全扛得住。數(shù)據(jù)量一旦到幾千萬行python跑groupby會(huì)變得非常吃力。這時(shí)候就要引入Hive或SparkHive負(fù)責(zé)把數(shù)據(jù)從原始日志清洗成明細(xì)寬表Spark負(fù)責(zé)做復(fù)雜聚合Python負(fù)責(zé)把聚合后的結(jié)果拿回本地做可視化。分工明確誰都不拖后腿。比如網(wǎng)約車訂單數(shù)據(jù)原始表可能有幾百個(gè)字段清洗后保留核心字段并分區(qū)存儲(chǔ)按“城市具體城市”“日期具體日期”分區(qū)分析人員要取數(shù)時(shí)先做分區(qū)裁剪再處理效率能提升數(shù)倍。5.3 數(shù)據(jù)分析項(xiàng)目的標(biāo)準(zhǔn)流程從需求到交付一個(gè)數(shù)據(jù)分析項(xiàng)目看起來是從“寫代碼”開始的實(shí)際上是從“定義問題”開始的。我常用的流程是五步確認(rèn)口徑、探查數(shù)據(jù)、清洗加工、分析建模、輸出結(jié)論。每一個(gè)步驟都要有可交付的產(chǎn)物口徑說明、字段清單、清洗腳本、分析報(bào)告和圖表。這樣哪怕項(xiàng)目中途換人接手也不至于從零開始。這套流程放在“數(shù)據(jù)分析項(xiàng)目實(shí)踐”里尤其重要。比如接到一個(gè)商業(yè)數(shù)據(jù)分析需求業(yè)務(wù)方說“想看看最近客戶流失情況”你不能直接跑代碼而要先問他怎么定義流失是連續(xù)30天未下單還是連續(xù)90天未登錄是一種口徑還是多種口徑一旦定義清楚了后面的Python代碼只是按定義翻譯成統(tǒng)計(jì)邏輯而已。這個(gè)“翻譯”能力才是數(shù)據(jù)分析師的核心競(jìng)爭(zhēng)力。5.4 報(bào)表自動(dòng)化的最小落地方案把周報(bào)做成自動(dòng)化是每個(gè)數(shù)據(jù)分析師都想做的事。最簡(jiǎn)單可靠的方案是寫一個(gè)Python腳本從數(shù)據(jù)庫(kù)或文件讀取數(shù)據(jù)、生成圖表、匯總成Markdown或Excel再用系統(tǒng)自帶的任務(wù)計(jì)劃每天或每周執(zhí)行。腳本里記得用絕對(duì)路徑或者以腳本所在目錄為基準(zhǔn)拼路徑否則定時(shí)任務(wù)在另一個(gè)目錄啟動(dòng)時(shí)會(huì)找不到文件。推送方式上現(xiàn)在很多團(tuán)隊(duì)用的是企業(yè)微信機(jī)器人或釘釘機(jī)器人只需要一個(gè)webhook地址腳本里用requests POST一段消息或圖片比配置郵件服務(wù)器簡(jiǎn)單得多。我以前還花時(shí)間研究怎么用smtplib發(fā)郵件后來發(fā)現(xiàn)webhook才是效率最高的方式。定時(shí)任務(wù)執(zhí)行完以后先寫日志、再推結(jié)果日志里記錄執(zhí)行時(shí)間、處理行數(shù)、是否成功這樣第二天發(fā)現(xiàn)問題全靠日志定位。6. 排查和優(yōu)化在“卡死”面前別慌6.1 慢、卡、內(nèi)存爆95%的根源就這幾類數(shù)據(jù)分析師最常見的崩潰時(shí)刻就是運(yùn)行一個(gè)腳本等了五分鐘還沒結(jié)果然后系統(tǒng)提示內(nèi)存不足。這種問題95%可以歸到幾類不該循環(huán)的地方用了循環(huán)、讀了不需要的全量列、兩個(gè)大表生成了數(shù)據(jù)量爆炸的中間結(jié)果、或者groupby后沒有及時(shí)釋放中間變量。我見過最典型的錯(cuò)誤是有人用for循環(huán)一行一行地改DataFrame里的值比如給每個(gè)訂單打標(biāo)簽以為這是理所當(dāng)然的。實(shí)際上只要能向量化就不要循環(huán)。pandas里的np.where、df.apply、map、merge都是替代循環(huán)的方案一行代碼能完成的事情為什么要讓CPU跑十萬次循環(huán)這就像走路能到的地方非要繞遍全城。記住一個(gè)原則能用內(nèi)置函數(shù)解決就不自己寫循環(huán)能用SQL和Spark解決就不把全量數(shù)據(jù)拉到本地內(nèi)存。6.2 用計(jì)時(shí)與profile定位瓶頸遇到慢腳本先別急著優(yōu)化先用最簡(jiǎn)單的方法定位打點(diǎn)計(jì)時(shí)。在關(guān)鍵步驟前后用time.perf_counter()計(jì)算耗時(shí)打印出來用數(shù)據(jù)說話。很多你以為很慢的步驟其實(shí)極快反而是你沒注意到的某個(gè)concat拖慢了整個(gè)流程。如果腳本里函數(shù)很多建議用cProfile跑一遍它會(huì)告訴你每個(gè)函數(shù)調(diào)用次數(shù)和累計(jì)耗時(shí)瞬間暴露瓶頸。內(nèi)存方面可以給系統(tǒng)加一點(diǎn)監(jiān)控或者定期輸出DataFrame的內(nèi)存占用df.memory_usage(deepTrue).sum() / 1024**2看到具體數(shù)值你就知道哪些列是內(nèi)存殺手。比如一個(gè)列明明是分類卻存成了字符串對(duì)象內(nèi)存開銷能高出好幾倍改成category類型或數(shù)值編碼后內(nèi)存直接下降。6.3 看機(jī)器負(fù)載和程序耗時(shí)的對(duì)應(yīng)關(guān)系在服務(wù)器上跑分析任務(wù)時(shí)我習(xí)慣同時(shí)觀察CPU負(fù)載和內(nèi)存占用。你打開系統(tǒng)的監(jiān)控工具看到load average飆高不要慌張先判斷是CPU密集導(dǎo)致的正常現(xiàn)象還是內(nèi)存耗盡觸發(fā)了持續(xù)交換。數(shù)據(jù)分析腳本常見的狀態(tài)是Python進(jìn)程占內(nèi)存好幾個(gè)GBCPU用不滿這時(shí)候并行也沒有意義因?yàn)槠款i在內(nèi)存帶寬和I/O上而不是計(jì)算核心數(shù)。一個(gè)實(shí)用的方法是先在一個(gè)小樣本上跑通邏輯并計(jì)時(shí)再按數(shù)據(jù)量估算全量耗時(shí)。比如100萬行的groupby耗時(shí)1秒不代表1000萬行只要10秒因?yàn)閮?nèi)存交換和GC一摻和耗時(shí)可能變成30秒甚至更久。所以我會(huì)在小樣本上記錄峰值內(nèi)存再估算機(jī)器是否能扛住扛不住就直接換大數(shù)據(jù)鏈路別硬等。6.4 用Spark和Hive處理大數(shù)據(jù)時(shí)的優(yōu)化小技巧當(dāng)你發(fā)現(xiàn)單機(jī)Python已經(jīng)頂不住就該考慮把計(jì)算下推到Spark或Hive里。先記住一個(gè)原則聚合能下推就下推最終返回Python的結(jié)果越小越好。用PySpark寫聚合常見模式是這樣的from pyspark.sql import functions as F df spark.read.parquet(hdfs://.../orders) result (df .filter(F.col(dt) 2025-01-01) .groupBy(city) .agg(F.sum(amount).alias(gmv)) .toPandas())這里最關(guān)鍵的優(yōu)化點(diǎn)是filter先執(zhí)行減少參與計(jì)算的數(shù)據(jù)量groupBy之后再做toPandas而不是先把整個(gè)大表拉回本地再聚合。真實(shí)項(xiàng)目里經(jīng)常會(huì)遇到某個(gè)熱點(diǎn)城市的數(shù)據(jù)量占了一半導(dǎo)致reduce階段數(shù)據(jù)傾斜任務(wù)卡在最后一步。處理方法通常是對(duì)城市加隨機(jī)前綴打散再二次聚合或者廣播小表做join。這些都是Spark性能調(diào)優(yōu)的常規(guī)動(dòng)作但你要知道一個(gè)事實(shí)數(shù)據(jù)量不大時(shí)Spark不一定比pandas快只有數(shù)據(jù)量大到單機(jī)內(nèi)存明顯不夠時(shí)分布式計(jì)算的優(yōu)勢(shì)才會(huì)真正顯現(xiàn)。寫在最后把工具箱整理成自己的語言我個(gè)人的經(jīng)驗(yàn)是數(shù)據(jù)分析師的Python能力不是靠看一遍教程就能提升的而是在一次次“被報(bào)表毒打”之后練出來的。你裝好環(huán)境、能跑通pandas、畫出第一張圖這只是第一步真正讓你成長(zhǎng)為“工具箱主人”的是你遇到報(bào)錯(cuò)后不慌、遇到慢腳本知道從哪里查、遇到業(yè)務(wù)方口徑不一致時(shí)能先停下來對(duì)齊定義。這也是為什么我一直不建議大家去下載所謂的“現(xiàn)成源碼大全”那些代碼不能幫你建立排查問題的能力反而容易把你帶進(jìn)別人的坑。相信你把自己做過的數(shù)據(jù)清洗、聚合、可視化腳本沉淀成一堆可復(fù)用的小函數(shù)之后會(huì)明顯感覺到效率質(zhì)變。下一次再遇到新需求不是從零開始查文檔而是翻出自己的工具箱改改參數(shù)就能用。這個(gè)過程沒什么捷徑但絕對(duì)是數(shù)據(jù)分析這條路上最值得投入的一段時(shí)間。