Pandas 數(shù)據(jù)處理指南異常值、抽樣和數(shù)據(jù)聚合前陣子幫一個做電商數(shù)據(jù)的朋友看報表他拿一份兩百多萬行的訂單明細跑groupby(channel).agg({amount:sum})出來的 GMV 跟業(yè)務方口徑差了將近三成。他一開始懷疑是 SQL 導出口徑不一致翻來覆去對了兩天最后定位到三個問題疊在一起幾條測試賬號的大額訂單沒剔掉一批amount為空的記錄被sum當 0 算進了分母還有一個渠道因為抽樣的關系樣本量只有幾十條卻被當成正常渠道參與排名。這三個問題分別對應數(shù)據(jù)處理的三個基本功——異常值處理、抽樣、聚合恰好也是絕大多數(shù)人覺得自己會用、真到業(yè)務里卻頻繁翻車的三個地方。這篇內容想聊的就是這三件事。它適合已經能寫df.groupby()、df.sample()但經常在結果對不上、口徑說不清、跑得慢這幾件事上卡住的人。我會把每個環(huán)節(jié)里那些文檔上不寫、但實際項目里一定會遇到的東西講透包括檢測方法什么條件下會失效、抽樣參數(shù)背后代表什么、聚合結果怎么組織才能直接進報表。文中用到的代碼都可以直接復制到 Notebook 里跑數(shù)據(jù)表結構我盡量寫得通用換成你自己的字段名就能用。1. 異常值先分三類錯誤值、極端值、結構性偏移處理方式完全不同很多人對異常值的處理方式是跑個 describe看到最大值離譜就刪掉這個做法在真實業(yè)務里十次有八次會出錯。異常值不是一個統(tǒng)計學概念它是統(tǒng)計概念和業(yè)務語義的交叉點同樣一個數(shù)值在不同的字段上有完全不同的含義。我習慣先把它分成三類因為這三類的處置邏輯是互斥的。第一類是錯誤值本質是數(shù)據(jù)在采集、傳輸、錄入環(huán)節(jié)出了問題。典型表現(xiàn)是單位錯位金額字段里混進了一條以分為單位的記錄、編碼錯誤缺失被填成-1、9999、0而不是NaN、類型錯位日期列里混進了字符串。這類值不屬于偏大偏小它壓根就是錯的處理方式應該是修正或者置空而不是簡單刪除。第二類是極端值數(shù)據(jù)本身是對的只是落在分布尾部。比如某個大客戶單筆下了五十萬的訂單這個值真實發(fā)生了刪掉它等于把真實業(yè)務抹掉。這類值要考慮的是它對我要算的指標有沒有影響——算平均值它影響巨大算中位數(shù)幾乎沒影響。第三類是結構性偏移指的不是單條記錄異常而是某個分組的整體分布和其他分組不在一個量級上。比如某個渠道的客單價整體是其他渠道的十倍這往往不是渠道用戶質量高而是這個渠道的金額字段包含了運費或者稅費采集口徑跟別人不一樣。這類問題用單變量檢測方法根本發(fā)現(xiàn)不了必須按分組切開看。1.1 用 describe 和 value_counts 做第一輪體檢動手之前先做體檢不要上來就寫過濾條件。我通常跑這么幾行import pandas as pd import numpy as np df.info() df.describe(includeall).T df[amount].value_counts().head(20) df[amount].value_counts().tail(20)describe看的是分布輪廓重點看三個數(shù)min是不是負數(shù)金額類字段出現(xiàn)負數(shù)通常意味著退款混進來了、max是不是比75%分位大出好幾個數(shù)量級、mean和50%分位的差距有多大。均值遠大于中位數(shù)說明右偏嚴重后面選檢測方法時就不能用基于正態(tài)假設的那套。value_counts的頭部和尾部是在找哨兵值。所謂哨兵值就是用特定數(shù)字表示特殊含義的約定-1表示未填寫、0表示未知、9999表示不適用。這類值在統(tǒng)計上看起來可能不離譜-1甚至不大但它會嚴重污染均值。我遇到過age字段大量填0的情況算出來平均年齡 26 歲實際主力用戶是 35 歲以上就是被這批 0 拉下去的。這一步的經驗是先看value_counts的尾部再看describe。因為哨兵值往往在尾部出現(xiàn)得很突然比如正常金額都是幾十到幾千尾部突然出現(xiàn)一個-999一眼就能看出來。而describe只會告訴你最小值是 -999不會告訴你這個值出現(xiàn)了 800 次。1.2 IQR 的上下界怎么算什么時候它會騙你IQR 法是箱線圖的數(shù)學基礎計算很直接q1 df[amount].quantile(0.25) q3 df[amount].quantile(0.75) iqr q3 - q1 lower q1 - 1.5 * iqr upper q3 1.5 * iqr mask_normal df[amount].between(lower, upper) print(f下界 {lower:.2f} 上界 {upper:.2f} 異常占比 {(~mask_normal).mean():.2%})1.5這個系數(shù)不是拍腦袋的在正態(tài)分布下它對應的區(qū)間大約覆蓋 99.3% 的數(shù)據(jù)所以正常數(shù)據(jù)被判為異常的比例應該在 1% 以內。這個數(shù)字很重要——如果你用 IQR 算出來的異常比例是 15%那不是數(shù)據(jù)有問題是方法用錯了說明數(shù)據(jù)分布嚴重偏離正態(tài)或者 Q1、Q3 本身就被污染了。IQR 最容易騙人的場景是右偏嚴重的數(shù)據(jù)比如訂單金額、用戶消費額、頁面停留時長。這類數(shù)據(jù) Q1 和 Q3 都擠在左側IQR 很小算出來的上界就會很低把大量正常的大額訂單判成異常。我實測過一份客單價數(shù)據(jù)Q1 是 38Q3 是 96上界算出來只有 183但實際上千的單子占了 8%這些全是真實的大客戶訂單。通用的補救辦法是先做對數(shù)變換再算 IQR或者直接用分位數(shù)縮尾比如把上下 1% 的值截斷到 1% 和 99% 分位的值上后者對業(yè)務解釋更友好因為它不改變數(shù)據(jù)的單調性lo, hi df[amount].quantile([0.01, 0.99]) df[amount_winsor] df[amount].clip(lowerlo, upperhi)1.3 刪除、縮尾、標記、分箱四種處置各自適用什么場景檢測出來之后怎么處理這是最見功力的地方。我整理了一張對照表基本覆蓋了日常遇到的場景處置方式適用場景風險點直接刪除確認為錯誤值且占比低于 1%占比高時會造成樣本偏差縮尾clip極端值真實存在但要算均值類指標會壓縮真實差異需在報告里注明打標記不刪極端值本身是分析對象如大客戶識別下游所有計算都要帶上標記過濾分箱處理用于建模特征或做分布對比分箱邊界選擇主觀性強單獨分組結構性偏移如某渠道口徑不同需要額外解釋容易讓報表難讀刪除這條我想多說一句。很多教程寫刪除 3σ 之外的記錄但從來沒說刪完之后必須重新檢查分布。原因很簡單刪掉尾部會改變均值、方差、分位數(shù)如果下游還有別的過濾條件兩次過濾疊加可能把某個分組刪空。我的習慣是刪除前后各跑一次groupby.size()確認每個分組的剩余量都還夠做結論經驗閾值是單組不低于 30 條不夠就別刪改成標記。還有一個更隱蔽的坑刪除操作會破壞索引連續(xù)性。如果后續(xù)用位置索引iloc或者把索引當成 ID 用刪完就容易錯位。所以刪除之后一律加.reset_index(dropTrue)或者干脆養(yǎng)成習慣任何過濾之后都重置一次。2. 檢測手段的選型從 MAD 到孤立森林每種方法的失效條件是什么搞清楚異常值的分類之后接下來的問題是用什么方法找出來。這里有個很普遍的誤區(qū)方法越復雜越好。實際上孤立森林、LOF 這些算法在業(yè)務數(shù)據(jù)上的表現(xiàn)經常不如一個老老實實的分位數(shù)閾值原因是它們對參數(shù)和數(shù)據(jù)尺度非常敏感而業(yè)務數(shù)據(jù)往往是臟的、混合分布的、量綱不統(tǒng)一的。我的選型邏輯是按數(shù)據(jù)形態(tài)走單變量近似對稱的用 Z-score單變量偏態(tài)的用 MAD多變量相關的用馬氏距離或孤立森林時間序列用滾動統(tǒng)計量。下面逐個說清楚它們的前提和失效邊界。2.1 Z-score 的前提是近似正態(tài)偏態(tài)數(shù)據(jù)上它會誤傷Z-score 就是標準分(x - mean) / std閾值一般取 3z (df[amount] - df[amount].mean()) / df[amount].std() outliers df[z.abs() 3]寫法簡單到沒什么可說問題在于它的兩個隱含假設均值能代表中心標準差能代表離散程度。這兩個假設只有在分布近似對稱時才成立。右偏數(shù)據(jù)里尾部的大值會把均值往上拉同時把標準差撐大結果是真正的異常反而算不出高分。這個現(xiàn)象叫掩蔽效應是 Z-score 在業(yè)務數(shù)據(jù)上最致命的問題。還有一個技術細節(jié)容易被忽略std()默認是樣本標準差ddof1如果跟別的系統(tǒng)比對結果時對方用的是總體標準差閾值會有一點差異。數(shù)據(jù)量大的時候影響可以忽略數(shù)據(jù)量小的時候比如幾百條值得注意。2.2 修正 Z-score 用中位數(shù)和 MAD抗噪但要注意 MAD 為 0修正 Z-score 把均值和標準差換成中位數(shù)和絕對中位差MAD這兩個統(tǒng)計量的崩潰點高得多少量極端值影響不了它們med df[amount].median() mad (df[amount] - med).abs().median() modified_z 0.6745 * (df[amount] - med) / mad outliers df[modified_z.abs() 3.5]0.6745這個常數(shù)是為了讓 MAD 在正態(tài)分布下和標準差可比等價于1 / 1.4826。閾值3.5是文獻里通用的經驗值對應正態(tài)分布下大約 0.02% 的比例。這個方法有一個必須處理的邊界情況MAD 等于 0。當超過一半的數(shù)據(jù)取值完全相同時就會發(fā)生典型場景是大量用戶的下單次數(shù)都是 1此時(x - med)對大多數(shù)記錄是 0MAD 就是 0除零之后全是inf或nan。處理方式是加一個極小值保護或者在這種場景下?lián)Q成基于計數(shù)的異常定義mad max(mad, 1e-9)我個人的經驗是對于次數(shù)型字段下單次數(shù)、登錄次數(shù)、點擊次數(shù)MAD 和 IQR 都不太好使因為分布是離散且高度集中的。這時候更靠譜的做法是直接用業(yè)務規(guī)則比如下單次數(shù)大于 50 次且 7 天內完成這類組合條件。2.3 多變量異常馬氏距離和孤立森林的落地寫法單變量檢測看不到組合起來才異常的記錄。比如一個用戶年齡 25 歲、年消費 80 萬這兩個值單獨看都不算極端但放在一起就非常可疑。這類問題需要多變量方法。馬氏距離考慮變量間的相關性要求數(shù)據(jù)近似多元正態(tài)而且樣本量要大于特征數(shù)否則協(xié)方差矩陣不可逆from scipy.spatial.distance import mahalanobis cols [age, amount, order_cnt] X df[cols].dropna().to_numpy() mu X.mean(axis0) cov_inv np.linalg.pinv(np.cov(X, rowvarFalse)) d np.array([mahalanobis(row, mu, cov_inv) for row in X]) threshold np.quantile(d, 0.99)注意這里用了pinv而不是inv因為特征之間高度相關時協(xié)方差矩陣奇異inv會直接報錯。另外mahalanobis是逐行調用的幾百萬行會非常慢實際項目里建議用矩陣運算重寫d np.sqrt(np.einsum(ij,jk,ik-i, X - mu, cov_inv, X - mu))。孤立森林不依賴分布假設思路是隨機切分空間異常點因為稀疏所以更容易被孤立出來路徑更短。落地寫法from sklearn.ensemble import IsolationForest model IsolationForest( n_estimators200, contamination0.01, max_samplesauto, random_state42, n_jobs-1, ) model.fit(df[cols].fillna(0)) df[if_flag] model.predict(df[cols].fillna(0)) # -1 為異常 df[if_score] model.score_samples(df[cols].fillna(0))contamination是最關鍵的參數(shù)它直接決定判定比例設成 0.01 就意味著一定有 1% 的記錄被判為異常不管數(shù)據(jù)里到底有沒有這么多。這是一個很強的先驗假設所以我一般不用predict的硬標簽而是用score_samples拿連續(xù)分數(shù)再結合業(yè)務規(guī)則人工圈定閾值。這樣既能利用算法的排序能力又不會因為參數(shù)設置錯誤而誤刪大量正常數(shù)據(jù)。2.4 時間序列上的異常滾動統(tǒng)計量比全局閾值靠譜時間序列的異常判定不能用全局閾值因為業(yè)務本身有周期性和趨勢。春節(jié)期間的訂單量比平時高五倍那是正常的但某個工作日的訂單量突然掉了一半那才是異常。常用做法是滾動中位數(shù)加滾動 MAD用局部統(tǒng)計量代替全局統(tǒng)計量df df.sort_values(dt).reset_index(dropTrue) roll_med df[amount].rolling(window7, min_periods3).median() roll_mad (df[amount] - roll_med).abs().rolling(window7, min_periods3).median() score 0.6745 * (df[amount] - roll_med) / roll_mad.replace(0, np.nan) df[ts_flag] score.abs() 3.5min_periods必須顯式設置否則前 6 行的結果全是NaN容易在后面被誤當成正常值。窗口大小按業(yè)務周期定日數(shù)據(jù)用 7周數(shù)據(jù)用 4 到 8太小容易把正常波動判成異常太大會讓異常點污染窗口內的統(tǒng)計量導致檢測滯后。還有一個更實用的做法是同比環(huán)比結合即(今日 - 上周同日) / 上周同日超過某個比例就標記。這個方法業(yè)務解釋性極強報表上可以直接展示較上周同日下降 62%比一堆統(tǒng)計量更容易讓人相信。3. sample 不只是隨機抽幾行抽樣參數(shù)、分層方案與代表性校驗抽樣這件事在很多人心里就是數(shù)據(jù)太大跑不動抽一萬行先看看。但抽樣的目的是讓樣本能代表總體一旦這個前提不成立后面所有的分析結論都是廢的。我見過最典型的翻車是拿df.sample(1000)抽出來的樣本去評估轉化率抽出來的結果比全量高了兩個百分點查到最后是因為原始數(shù)據(jù)按時間排序隨機抽樣恰好抽到了一個促銷時段。3.1 n、frac、weights、replace 的實際含義sample的參數(shù)不多但每個都有實際影響df.sample(n1000, random_state42) # 固定條數(shù) df.sample(frac0.1, random_state42) # 固定比例 df.sample(n1000, replaceTrue, random_state42) # 有放回 df.sample(n1000, weightsweight_col, random_state42) # 加權random_state在需要復現(xiàn)的場景必須固定尤其是做 A/B 對比分析時兩次抽樣用了不同的種子結果差異可能完全來自抽樣本身而不是業(yè)務變化。replaceTrue只在一種情況下需要樣本量要超過總體或者要做 Bootstrap 估計。日常抽樣基本不用因為重復樣本會讓統(tǒng)計量的方差被低估。weights是加權抽樣適合做重要性抽樣或者過采樣。有個坑值得說weights可以傳列名也可以傳數(shù)組但如果傳入的 Series 索引和 DataFrame 索引不一致pandas 會按位置對齊而不是按索引結果可能完全錯亂。穩(wěn)妥做法是直接傳.to_numpy()。frac和n不能同時指定這個大家都知道。但有個隱蔽問題frac大于 1 且沒設replaceTrue時會報錯而frac1返回的是打亂后的全量數(shù)據(jù)不是原始順序很多人在這一步誤以為數(shù)據(jù)被改了。3.2 分層抽樣手寫循環(huán)比 groupby.apply 更省心分層抽樣保證每個分組在樣本里的比例和總體一致這是報表抽樣幾乎必做的事。常見寫法有兩種我更推薦手寫循環(huán)def stratified_sample(df, col, n_per_groupNone, fracNone, seed42): parts [] for key, g in df.groupby(col, observedTrue, sortFalse): if n_per_group is not None: k min(n_per_group, len(g)) parts.append(g.sample(nk, random_stateseed)) else: parts.append(g.sample(fracfrac, random_stateseed)) return pd.concat(parts, ignore_indexTrue) sample_df stratified_sample(df, channel, frac0.05)為什么不用groupby.apply(lambda x: x.sample(...))兩個原因。一是新版 pandas 對返回結果形狀不一致的apply會有棄用警告行為在版本間有變化維護成本高。二是apply會把每個分組當獨立函數(shù)調用幾萬個分組的時候速度慢一個數(shù)量級。手寫循環(huán)雖然多幾行但行為完全可控出問題好排查。min(n_per_group, len(g))這個保護必須加。小分組的數(shù)據(jù)量小于要求抽樣量時sample(nk)會直接拋ValueError整個流程中斷。用min兜底配合后面的一致性核對能馬上發(fā)現(xiàn)哪些分組樣本不足。observedTrue也不能省。如果你的分組字段是category類型默認行為會把所有類別組合都列出來包括數(shù)據(jù)里根本不存在的組合白跑一堆空分組。新版 pandas 里這個默認值已經改了但如果代碼要兼容老版本顯式寫上更保險。3.3 樣本量怎么估以及抽完必須做的一致性核對樣本量不是拍腦袋定的。判斷比例類指標比如轉化率時用這個公式n z2 × p × (1-p) / e2z是置信水平對應的分位數(shù)95% 對應 1.96p是預期比例不知道就取 0.5此時方差最大e是允許誤差。取p0.5、e0.03算出來 n 約等于 1067。如果總體本身不大還要做有限總體修正n_adj n / (1 (n - 1) / N)總體 5000 條時修正后的樣本量是 878比 1067 小了不少。這個修正很容易被忽略導致對小數(shù)據(jù)集做了不必要的過度抽樣。抽完之后必須做一致性核對這一步比抽樣本身更重要。我通常跑三件事分組占比對比、關鍵字段的分位數(shù)對比、空值率對比。total_ratio df[channel].value_counts(normalizeTrue) sample_ratio sample_df[channel].value_counts(normalizeTrue) compare pd.DataFrame({總體: total_ratio, 樣本: sample_ratio}) compare[偏差] (compare[樣本] - compare[總體]).round(4) print(compare.sort_values(偏差, keyabs, ascendingFalse))偏差超過 1 個百分點就要警惕。如果發(fā)現(xiàn)某個分組偏差明顯先檢查這個分組的總量是不是太小小于 100 條時抽樣波動本身就大排除之后再考慮加大樣本量或者改成按權重抽樣。對連續(xù)型字段用quantile([0.1, 0.25, 0.5, 0.75, 0.9])對比總體和樣本兩列并排看。這一步能發(fā)現(xiàn)隨機抽樣抽偏了分布的情況比如整體樣本量夠了但高分位被系統(tǒng)性低估。3.4 分層抽樣的一個變體按業(yè)務重要性分配配額嚴格按比例分層有時候不實用。比如做渠道分析時主力渠道占 90% 的量長尾渠道加起來只占 10% 但包含幾十個渠道按比例抽的話每個長尾渠道只能分到幾條根本沒法單獨看。這時候用配額抽樣更合理主力渠道按比例抽長尾渠道強制保底若干條。big stratified_sample(df[df[channel].isin([A, B])], channel, frac0.02) small stratified_sample(df[~df[channel].isin([A, B])], channel, n_per_group50) sample_df pd.concat([big, small], ignore_indexTrue)這樣做出來的樣本不能直接用來算整體均值因為它經過了人為加權。但如果用途是看每個渠道的畫像那完全合理。關鍵在于樣本用途決定了抽樣方案而不是反過來。這一點我會在交付分析結果時明確寫出來避免下游拿著加權樣本去算全站 GMV。4. groupby 的執(zhí)行邏輯與 agg 寫法把聚合結果做成能直接進報表的形狀聚合是三個環(huán)節(jié)里最常用的也是最容易產生結果對不上的環(huán)節(jié)。原因往往不在groupby本身而在于 NaN 的處理、索引的形狀、以及聚合函數(shù)的語義選擇——sum()對全 NaN 分組返回 0mean()對全 NaN 分組返回 NaN這兩個行為的差異能讓報表數(shù)字出現(xiàn)明顯偏差。4.1 groupby 到底做了什么為什么要關注 as_index 和 observedgroupby的執(zhí)行過程是拆分-應用-合并按 key 把數(shù)據(jù)切成若干塊對每塊執(zhí)行聚合函數(shù)再把結果拼成新表。理解這一點很多行為的來源就清楚了。as_indexFalse決定了分組字段是留在索引上還是變成普通列。大多數(shù)接報表的場景都應該設成False因為后續(xù)要merge、要導出 Excel、要寫進數(shù)據(jù)庫索引里的列很麻煩result df.groupby(channel, as_indexFalse).agg(gmv(amount, sum))dropna決定分組字段為 NaN 的記錄要不要參與。默認是丟棄這在統(tǒng)計上合理但在業(yè)務上經常出問題——空的分組字段往往代表未歸類直接丟掉會讓總數(shù)對不上。我一般會先把空值填成未知再分組這樣總量是守恒的。observedTrue前面提過主要影響 categorical 類型。還有一個相關的坑如果分組字段的 dtype 是object但實際取值只有少數(shù)幾個可以先轉成category分組速度能快好幾倍內存也能省一半以上。4.2 命名聚合比傳字典更清晰也更好接下游聚合的寫法有好幾種從差到好排下來# 寫法一多函數(shù)聚合結果是 MultiIndex 列 df.groupby(channel).agg({amount: [sum, mean, count]}) # 寫法二傳字典只能給一列配一個函數(shù)或函數(shù)列表 df.groupby(channel).agg({amount: sum, order_id: nunique}) # 寫法三命名聚合推薦 summary df.groupby(channel, as_indexFalse).agg( gmv(amount, sum), order_cnt(order_id, nunique), avg_price(amount, mean), p90(amount, lambda x: x.quantile(0.9)), )寫法一的問題是多函數(shù)聚合出來是二級列名result[amount][sum]這種取法在導出、重命名、拼接時都很別扭得用flatten處理。寫法三直接給每個聚合結果命名列名是扁平的可以直接進報表。用lambda算分位數(shù)很方便但性能很差——它是逐組調用 Python 函數(shù)幾萬個分組時能慢十倍以上。數(shù)據(jù)量大時改用functools.partial或者先算分位數(shù)列再聚合from functools import partial q90 partial(pd.Series.quantile, q0.9) summary df.groupby(channel, as_indexFalse).agg(p90(amount, q90))另外還有一個語義陷阱count和size的區(qū)別。count統(tǒng)計非空值數(shù)量size統(tǒng)計行數(shù)含空值。做訂單數(shù)統(tǒng)計時如果用錯空值多的分組會少算。nunique默認不統(tǒng)計空值這個行為一般符合預期但如果需要把空值也算一種取值得顯式dropnaFalse。4.3 transform 和 apply 的分工以及性能差距transform的作用是按組計算但結果保持原表形狀用來做組內標準化、組內占比、缺失值組內填充特別方便df[channel_avg] df.groupby(channel)[amount].transform(mean) df[amount_ratio] df[amount] / df[channel_avg] df[rank_in_channel] df.groupby(channel)[amount].rank(ascendingFalse, methoddense)如果不要求保留原形狀只是想拿到每組一個值那就用agg它比transform快因為不需要把結果廣播回每一行。apply最靈活可以返回任意形狀但也是三者里最慢的。它的價值在于邏輯復雜、沒法用內置函數(shù)表達的場景比如組內要做時間序列插值、要做排序后取第 N 行top3 df.groupby(channel, group_keysFalse).apply( lambda g: g.nlargest(3, amount), include_groupsFalse )新版 pandas 里apply作用在 DataFrame 上時分組列默認會包含在數(shù)據(jù)里需要在函數(shù)里排除否則會報錯或者產生重復列。加include_groupsFalse是比較穩(wěn)妥的寫法老版本沒有這個參數(shù)需要用g.drop(columns...)手動剔除。4.4 pivot_table 和 crosstab 的適用邊界pivot_table本質上是groupby加透視適合做二維交叉表。跟groupby的區(qū)別在于它能一次把行維度、列維度都鋪開適合直接給人看pivot pd.pivot_table( df, indexchannel, columnsmonth, valuesamount, aggfuncsum, fill_value0, marginsTrue, margins_name合計 )fill_value0很重要否則交叉表里沒有數(shù)據(jù)的位置是NaN做后續(xù)計算時會傳播。marginsTrue會自動加行列合計省去手工算總數(shù)的一步但要注意合計行在索引里叫All可以自定義跟數(shù)據(jù)行混在一起如果后面還要做運算記得先剔除。crosstab適合算頻次分布比pivot_table寫起來簡潔pd.crosstab(df[channel], df[status], normalizeindex, marginsFalse)normalizeindex按行歸一化輸出的就是每個渠道里各狀態(tài)的占比做轉化率分析很方便。normalizecolumns按列normalizeTrue按總數(shù)。這三個值容易搞混我的記法是歸一化的方向就是分母所在的方向。5. 三個環(huán)節(jié)串成一條流水線可復用函數(shù)與幾個高頻報錯分開看每個環(huán)節(jié)都不難真到項目里麻煩出在三者交織的地方。異常值處理改變了分布抽樣就要重新校驗抽樣讓部分分組數(shù)據(jù)變少聚合時就要處理小樣本分組聚合結果又要回到異常值判斷里做交叉驗證。把這些串起來我的做法是把每一步寫成獨立函數(shù)中間產物落盤方便回溯。5.1 函數(shù)拆分與參數(shù)設計整條流水線拆成四個函數(shù)每個函數(shù)只做一件事參數(shù)顯式傳入不依賴全局變量def profile(df, cols): 輸出字段體檢表空值率、唯一值數(shù)、分位數(shù)、疑似哨兵值 rows [] for c in cols: s df[c] rows.append({ col: c, dtype: str(s.dtype), null_rate: round(s.isna().mean(), 4), nunique: s.nunique(), min: s.min() if pd.api.types.is_numeric_dtype(s) else None, p01: s.quantile(0.01) if pd.api.types.is_numeric_dtype(s) else None, p50: s.quantile(0.5) if pd.api.types.is_numeric_dtype(s) else None, p99: s.quantile(0.99) if pd.api.types.is_numeric_dtype(s) else None, max: s.max() if pd.api.types.is_numeric_dtype(s) else None, }) return pd.DataFrame(rows) def flag_outliers(df, col, methodmad, k3.5): 只打標記不刪數(shù)據(jù) s df[col] if method mad: med s.median() mad max((s - med).abs().median(), 1e-9) score 0.6745 * (s - med) / mad return (score.abs() k).fillna(False) if method iqr: q1, q3 s.quantile([0.25, 0.75]) iqr q3 - q1 return ~s.between(q1 - 1.5 * iqr, q3 1.5 * iqr) raise ValueError(funknown method: {method}) def build_sample(df, group_col, frac0.05, min_n30, seed42): 分層抽樣小分組保底 min_n 條 parts [] for key, g in df.groupby(group_col, observedTrue, sortFalse): k max(min_n, int(round(len(g) * frac))) parts.append(g.sample(nmin(k, len(g)), random_stateseed)) return pd.concat(parts, ignore_indexTrue) def build_summary(df, group_col, value_col, id_col): return df.groupby(group_col, as_indexFalse).agg( cnt(id_col, nunique), total(value_col, sum), avg(value_col, mean), p50(value_col, median), )這樣拆的好處是每一步都能單獨驗證。profile的輸出可以直接貼進分析報告當數(shù)據(jù)質量說明flag_outliers加了_flag列而不刪數(shù)據(jù)出問題隨時能切換策略重跑。5.2 SettingWithCopyWarning 的根因和三種消除方式這個警告幾乎人人都見過很多人直接warnings.filterwarnings(ignore)了事但它是真實問題的信號。根因在于 pandas 無法確定你拿到的 DataFrame 是原始數(shù)據(jù)的視圖還是副本賦值操作可能改了原表也可能沒改行為不確定。最常見的觸發(fā)寫法是鏈式索引# 觸發(fā)警告 df[df[status] paid][discount] 0.9 # 正確寫法一先 copy sub df[df[status] paid].copy() sub[discount] 0.9 # 正確寫法二用 loc 一次定位 df.loc[df[status] paid, discount] 0.9寫法二最推薦一次完成定位和賦值不會產生中間對象。寫法的關鍵是copy()不能省很多人覺得加了copy()會多占內存實際上 pandas 3.0 之后寫時復制是默認行為copy()的開銷比想象中小得多而且能避免一堆難以排查的問題。還有一類更隱蔽的情況merge之后修改某一列時觸發(fā)這個警告。原因是merge結果的某些塊可能跟原始 DataFrame 共享內存。處理方法一樣merge之后如果要做原地修改先.copy()。5.3 dtype 被悄悄改掉整數(shù)變浮點、空值被當成 0這個坑比上一個大得多因為它不報警告只給你一個錯誤的數(shù)字。第一個典型場景原本是int64的列里出現(xiàn)空值pandas 會自動把它轉成float64?？雌饋碇皇穷愋妥兞藢嶋H影響是id列變成浮點之后作為字典鍵或者跟字符串拼接會出現(xiàn)123.0這種結果去重、關聯(lián)、導出全都會出問題。解法是用可空整型df[qty] df[qty].astype(Int64) # 注意大寫 IInt64大寫是 pandas 擴展類型支持pd.NAint64小寫是 numpy 類型不支持。這個大小寫區(qū)別坑過很多人。同理還有string和object、boolean和bool。第二個場景sum()把 NaN 當 0 加。這是sum的設計行為skipnaTrue是默認值。影響在于分母——如果算客單價時用amount_sum / order_count而amount有一批是 NaN那分子少算、分母照算客單價就被系統(tǒng)性低估。正確做法是先把空值處理掉再算或者在聚合里顯式指定df.groupby(channel).agg( gmv(amount, lambda x: x.sum(min_count1)), # 全空時返回 NaN 而不是 0 cnt(order_id, nunique), )min_count1的意思是至少要有 1 個非空值才計算結果全空分組返回 NaN這樣在報表里一眼就能看出哪些分組數(shù)據(jù)缺失而不是被 0 悄悄糊過去。第三個場景groupby之后 dtype 發(fā)生變化。分類字段轉成索引之后類型可能變尤其是用了category的地方。做完聚合之后加一句print(result.dtypes)檢查一下養(yǎng)成習慣能省掉大量為什么數(shù)字不對的排查時間。5.4 內存與速度category 和避免 apply 的實測差距數(shù)據(jù)量上到千萬行之后性能就變成必須考慮的事。我做過一輪對比同一份 800 萬行的訂單數(shù)據(jù)幾個改動帶來的差異很明顯改動大致效果說明分組字段轉category分組耗時下降 40%–60%取值基數(shù)低時收益最大用agg命名聚合替代apply聚合耗時下降一個數(shù)量級apply是逐組 Python 調用數(shù)值列降精度float32內存占用減少約一半精度要求不高的場景可用讀數(shù)據(jù)時指定dtype和usecols讀取階段內存減少 60% 以上從源頭控制最有效用pd.NA替代np.nan語義更清晰內存略增整數(shù)列可空時必需category的收益來自兩點一是值實際只存一份每個位置存的是整數(shù)編碼內存從每行一個字符串變成每行一個小整數(shù)二是分組時可以直接按整數(shù)編碼做哈希比字符串比較快得多。轉的時候要注意如果某列取值基數(shù)接近行數(shù)比如用戶 ID轉成 category 反而更慢更占內存轉之前先看nunique() / len(df)這個比值低于 0.1 再考慮。讀取階段優(yōu)化是最劃算的因為省的是全流程的內存峰值dtype_map { order_id: string, channel: category, qty: Int32, amount: float32, } df pd.read_csv(orders.csv, usecolslist(dtype_map), dtypedtype_map)usecols只讀需要的列這一步經常能省掉一半以上的內存和時間。很多人的習慣是先全量讀進來再刪列實際上源頭就過濾掉更高效。float32要注意精度金額類字段如果對小數(shù)位有嚴格要求比如到分用float32可能產生累積誤差建議保留float64或者干脆用整數(shù)存分。最后提一個容易被忽略的性能陷阱在groupby之后鏈式調用多次聚合不如一次agg里全寫完。每次鏈式調用都會重新觸發(fā)一次分組計算雖然 pandas 內部有一些優(yōu)化但顯式一次寫完更穩(wěn)定。我在幾個項目里對比過把三次獨立的groupby().sum()、groupby().mean()、groupby().count()合并成一個agg耗時大約能降到三分之一。還有一個我個人的小習慣所有聚合結果在導出之前先跑一次總量守衡校驗——用原始數(shù)據(jù)的amount.sum()和聚合結果的total.sum()對比兩者必須完全相等浮點用np.isclose。這一步能抓出絕大多數(shù)過濾條件寫錯、空值被丟棄、分組字段意外為 NaN 的問題。寫完一條流水線加上這個校驗交付時心里就有底了。