CentOS 7.9 Python Scikit-learn這套組合在我接觸過的企業(yè)生產(chǎn)環(huán)境里占了相當(dāng)大的比例。很多團(tuán)隊(duì)不是沒有機(jī)器學(xué)習(xí)能力而是卡在“環(huán)境裝不起來”“數(shù)據(jù)稍微一大就跑不動(dòng)”“代碼寫完換臺(tái)機(jī)器就廢”這些工程化問題上。這篇文章就從CentOS 7.9這個(gè)非常常見的服務(wù)器系統(tǒng)出發(fā)把數(shù)據(jù)處理到模型訓(xùn)練這一段拆開揉碎講一講怎么用Python和Scikit-learn搭出一條真正能跑、能擴(kuò)展、能排查的機(jī)器學(xué)習(xí)流水線。內(nèi)容適合正在把機(jī)器學(xué)習(xí)模型搬到生產(chǎn)環(huán)境的工程師也適合剛接觸這套技術(shù)棧的團(tuán)隊(duì)。 你不需要有分布式系統(tǒng)經(jīng)驗(yàn)但要會(huì)基本的Linux命令和Python語法。讀完你會(huì)掌握一套從環(huán)境搭建到流水線落地的完整方法論包括我自己在實(shí)際項(xiàng)目中踩過的坑和驗(yàn)證過的調(diào)優(yōu)手段。1. 整體架構(gòu)與設(shè)計(jì)思路1.1 先搞清楚“大規(guī)?！钡降资鞘裁匆馑己芏嗳艘惶岬酱笠?guī)模機(jī)器學(xué)習(xí)第一反應(yīng)就是上Spark、上分布式集群。但我實(shí)際看過不少項(xiàng)目數(shù)據(jù)量只有幾百M(fèi)B團(tuán)隊(duì)卻已經(jīng)搭了三臺(tái)Hadoop節(jié)點(diǎn)最后大部分時(shí)間都在處理集群本身的故障真正用來做算法的時(shí)間少得可憐。這里有個(gè)認(rèn)知要修正在絕大多數(shù)業(yè)務(wù)場(chǎng)景里數(shù)據(jù)量級(jí)在幾GB到幾十GB之間單機(jī)優(yōu)化遠(yuǎn)比上分布式劃算。Sklearn的單機(jī)能力被嚴(yán)重低估了配合Pandas和NumPy8核16G內(nèi)存的服務(wù)器處理GB級(jí)數(shù)據(jù)做常規(guī)建模完全夠用。大規(guī)模的第二層含義是“流程的復(fù)雜度”。數(shù)據(jù)源多、特征維度高、預(yù)處理環(huán)節(jié)多、模型迭代頻繁這才是流水線真正要解決的問題。 所以設(shè)計(jì)的第一步是給自己的數(shù)據(jù)量和計(jì)算資源做一個(gè)判斷單機(jī)能扛住的沒必要上分布式單機(jī)扛不住的也要先優(yōu)化單機(jī)實(shí)在不行再考慮擴(kuò)展。這個(gè)判斷直接決定了后續(xù)架構(gòu)的復(fù)雜度。1.2 流水線的分層與解耦我習(xí)慣把一個(gè)完整的機(jī)器學(xué)習(xí)流水線拆成四層數(shù)據(jù)接入層負(fù)責(zé)讀取CSV、Parquet、數(shù)據(jù)庫數(shù)據(jù)做格式統(tǒng)一和基礎(chǔ)清洗特征工程層處理缺失值、編碼類別變量、做數(shù)值特征縮放、特征篩選模型訓(xùn)練層選擇算法、超參調(diào)優(yōu)、交叉驗(yàn)證、訓(xùn)練模型評(píng)估與產(chǎn)出層計(jì)算指標(biāo)、保存模型、生成預(yù)測(cè)結(jié)果每一層之間通過統(tǒng)一的中間數(shù)據(jù)格式銜接比如數(shù)據(jù)接入層的輸出一定是Parquet格式的DataFrame特征工程層的輸出一定是一個(gè)數(shù)值型的二維ndarray或稀疏矩陣。這樣做的最大好處是任何一個(gè)環(huán)節(jié)出了問題都能單獨(dú)替換和重跑不需要從頭再來。實(shí)際項(xiàng)目中我強(qiáng)烈建議把ETL數(shù)據(jù)抽取轉(zhuǎn)換過程和建模過程分開。 ETL跑一次產(chǎn)出干凈的數(shù)據(jù)文件建模腳本從干凈數(shù)據(jù)讀入快速迭代實(shí)驗(yàn)。如果你每次調(diào)參都要重新跑一遍全量數(shù)據(jù)的清洗邏輯效率會(huì)低到懷疑人生。1.3 為什么必須用Pipeline而不是手動(dòng)拼接初學(xué)者最喜歡這么寫df pd.read_csv(data.csv) df[age].fillna(df[age].mean(), inplaceTrue) # 用全量均值填充 # 后面直接訓(xùn)練這段代碼在生產(chǎn)環(huán)境里是致命的。如果訓(xùn)練前用全量數(shù)據(jù)的均值填充缺失值模型在評(píng)估階段看到的“已填好的特征”其實(shí)是包含了測(cè)試集信息的這叫數(shù)據(jù)泄漏。 短期內(nèi)交叉驗(yàn)證分?jǐn)?shù)會(huì)虛高一旦上線真實(shí)數(shù)據(jù)一來效果立刻崩盤。用Sklearn的Pipeline和ColumnTransformer就能徹底解決這個(gè)問題。預(yù)處理器在每一折交叉驗(yàn)證里只會(huì)fit訓(xùn)練部分的參數(shù)然后transform驗(yàn)證集從機(jī)制上杜絕泄漏。這不是風(fēng)格偏好而是正確性問題。2. CentOS 7.9環(huán)境準(zhǔn)備與依賴管理2.1 千萬不要?jiǎng)酉到y(tǒng)自帶的PythonCentOS 7.9默認(rèn)自帶Python 2.7yum、firewalld這些系統(tǒng)工具都依賴它。你要是手賤把默認(rèn)python替換成Python 3輕則yum失靈重則系統(tǒng)管理功能崩潰。正確做法是裝一個(gè)獨(dú)立的Python環(huán)境互不干擾。我推薦用Miniconda而不是源碼編譯。有人說源碼編譯更“純凈”但CentOS 7.9的編譯坑太多了openssl、bzip2、zlib任何一個(gè)基礎(chǔ)庫缺失都會(huì)導(dǎo)致后續(xù)pip安裝失敗排查起來非常耗時(shí)。 Miniconda直接提供預(yù)編譯的numpy、scipy、scikit-learn二進(jìn)制包開箱即用省掉的排錯(cuò)時(shí)間絕對(duì)值得。安裝步驟如下# 下載Miniconda wget https://mirrors.tuna.tsinghua.edu.cn/anaconda/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p /opt/miniconda3 # 配置環(huán)境變量 echo export PATH/opt/miniconda3/bin:$PATH ~/.bashrc source ~/.bashrc # 校驗(yàn) conda --version這里有兩個(gè)細(xì)節(jié)安裝包優(yōu)先選清華鏡像源官網(wǎng)下載速度在部分網(wǎng)絡(luò)環(huán)境下慢到無法忍受用-b參數(shù)靜默安裝指定安裝目錄避免交互式步驟在SSH會(huì)話里卡住2.2 創(chuàng)建獨(dú)立環(huán)境并安裝機(jī)器學(xué)習(xí)依賴我習(xí)慣為每個(gè)項(xiàng)目建獨(dú)立環(huán)境而不是直接在base環(huán)境里裝庫。環(huán)境隔離看起來多了一步操作但后續(xù)升級(jí)依賴、排查版本沖突時(shí)會(huì)省下大量時(shí)間。conda create -n ml python3.8 -y conda activate ml pip install numpy pandas scikit-learn joblib pip install pyarrow matplotlib dask如果你在公司內(nèi)網(wǎng)pip默認(rèn)源可能很慢建議配置國內(nèi)鏡像源pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple另外要注意如果你用conda創(chuàng)建了環(huán)境就不要用conda install來裝Python包也不要手動(dòng)混用pip和conda。 兩者混裝容易把環(huán)境元數(shù)據(jù)搞亂出現(xiàn)一些詭異的依賴沖突。我在項(xiàng)目里統(tǒng)一用pip安裝Python包c(diǎn)onda只負(fù)責(zé)創(chuàng)建環(huán)境。2.3 環(huán)境搭建階段的經(jīng)典翻車現(xiàn)場(chǎng)pip安裝報(bào)“Could not find a version that satisfies the requirement”多數(shù)情況是網(wǎng)絡(luò)問題換鏡像源即可。但如果鏡像源也失敗就要檢查Python版本是否太老。Sklearn從1.0版本開始需要Python 3.8以上如果你在CentOS 7.9上只裝了Python 3.6很多新包都裝不上。python --version # 如果是3.6建議升到3.8或3.9 conda create -n ml python3.9 -y導(dǎo)入sklearn時(shí)報(bào)錯(cuò)“GLIBCXX_3.4.21 not found”CentOS 7.9自帶的gcc版本較老默認(rèn)的libstdc.so.6里缺少新版Sklearn依賴的符號(hào)。這個(gè)問題用conda環(huán)境不會(huì)遇到因?yàn)镸iniconda自帶較新的運(yùn)行時(shí)庫。如果你堅(jiān)持用系統(tǒng)Python就需要手動(dòng)升級(jí)gcc工具鏈非常折騰這也是我推薦Miniconda的核心原因之一。pandas讀取大文件內(nèi)存直接爆掉這個(gè)放第三章詳細(xì)講這里先說結(jié)論read_csv默認(rèn)會(huì)用Python對(duì)象存儲(chǔ)字符串列內(nèi)存開銷是C數(shù)據(jù)類型的好幾倍。 指定dtype參數(shù)和enginec能顯著降低內(nèi)存。2.4 環(huán)境變量與多線程配置CentOS服務(wù)器通常CPU核心數(shù)不少但Sklearn底層通過OpenMP做并行計(jì)算的時(shí)候如果和BLAS庫的線程數(shù)設(shè)置沖突性能反而會(huì)下降。出現(xiàn)過“明明20核機(jī)器訓(xùn)練速度還不如8核筆記本”的情況。我一般在 ~/.bashrc 后面加上export OPENBLAS_NUM_THREADS8 export OMP_NUM_THREADS8不要把所有核心都占滿。機(jī)器上還有其他服務(wù)在跑如果CPU被打滿整個(gè)服務(wù)器卡到SSH都連不上運(yùn)維同學(xué)會(huì)來找你算賬的。3. 高效數(shù)據(jù)處理與特征構(gòu)建實(shí)戰(zhàn)3.1 數(shù)據(jù)接入層的優(yōu)化技巧流水線的第一步是讀數(shù)據(jù)看起來簡單實(shí)際上優(yōu)化的空間最大。先說CSV讀取。Sklearn官方示例里直接用pd.read_csv讀數(shù)據(jù)但生產(chǎn)環(huán)境的數(shù)據(jù)文件動(dòng)不動(dòng)幾個(gè)GB直接讀會(huì)有兩個(gè)問題類型推斷耗時(shí)內(nèi)存占用過高推薦做法import pandas as pd dtype_dict { user_id: int32, age: int8, income: float32, province: category, signup_date: str } df pd.read_csv(raw_data.csv, dtypedtype_dict, enginec, encodingutf-8) print(df.info(memory_usagedeep))關(guān)鍵點(diǎn)int32和int8比默認(rèn)的int64省4到8倍內(nèi)存前提是你確認(rèn)取值范圍不會(huì)溢出category類型對(duì)低基數(shù)字符串列極有效比如省份、性別這類列Pandas內(nèi)部會(huì)整數(shù)編碼內(nèi)存占用大幅降低指定enginec避免Python解釋器逐行解析接下來重點(diǎn)推薦Parquet格式。我在實(shí)際項(xiàng)目里ETL階段出來的中間數(shù)據(jù)一律存Parquet不用CSV。df.to_parquet(cleaned_data.parquet, indexFalse) df_loaded pd.read_parquet(cleaned_data.parquet)Parquet是列式存儲(chǔ)格式相同數(shù)據(jù)比CSV小很多讀入速度也快得多。 我第一次把一個(gè)2.3GB的CSV轉(zhuǎn)成Parquet后大小變成480MB加載時(shí)間從35秒降到6秒效果極其明顯。如果你的數(shù)據(jù)量在GB級(jí)別這個(gè)改動(dòng)收益最大。當(dāng)數(shù)據(jù)大到連Parquet都一次性讀不進(jìn)內(nèi)存時(shí)用chunksize分批處理chunk_iter pd.read_csv(huge_data.csv, chunksize100000) cleaned_chunks [] for chunk in chunk_iter: chunk chunk.dropna(subset[label]) chunk chunk[chunk[age] 0] cleaned_chunks.append(chunk) df pd.concat(cleaned_chunks, ignore_indexTrue)3.2 特征工程里的類型與編碼處理Sklearn的模型要求輸入特征矩陣全部是數(shù)值類型。字符串列不能直接丟進(jìn)模型。所以特征工程要完成兩件事處理缺失值、編碼類別特征。一個(gè)常見的坑直接用pd.get_dummies做獨(dú)熱編碼在訓(xùn)練集和測(cè)試集上分別執(zhí)行時(shí)類別集合可能不一致導(dǎo)致列數(shù)不同。 上線預(yù)測(cè)時(shí)報(bào)維度不匹配。正確做法是把編碼器放進(jìn)Pipeline讓Sklearn統(tǒng)一管理。Sklearn 1.0之后的ColumnTransformer讓這個(gè)流程變得非常清晰?？催@段完整示例import numpy as np import pandas as pd from sklearn.compose import ColumnTransformer from sklearn.pipeline import Pipeline from sklearn.impute import SimpleImputer from sklearn.preprocessing import StandardScaler, OneHotEncoder from sklearn.linear_model import LogisticRegression # 假設(shè)數(shù)值列和類別列 numeric_features [age, income, spend_score] categorical_features [province, gender, channel] numeric_transformer Pipeline(steps[ (imputer, SimpleImputer(strategymedian)), (scaler, StandardScaler()) ]) categorical_transformer Pipeline(steps[ (imputer, SimpleImputer(strategyconstant, fill_valuemissing)), (onehot, OneHotEncoder(handle_unknownignore, sparse_outputFalse)) ]) preprocessor ColumnTransformer( transformers[ (num, numeric_transformer, numeric_features), (cat, categorical_transformer, categorical_features) ] ) model Pipeline(steps[ (preprocessor, preprocessor), (classifier, LogisticRegression(max_iter1000)) ])這段代碼的核心價(jià)值在于所有預(yù)處理參數(shù)都會(huì)在訓(xùn)練時(shí)擬合并固定在模型內(nèi)部。 預(yù)測(cè)時(shí)你只需要給模型傳原始DataFrame模型會(huì)自動(dòng)完成同樣的填充、縮放和編碼。換了一批數(shù)據(jù)只要特征是同樣的列就永遠(yuǎn)不會(huì)出現(xiàn)“訓(xùn)練和預(yù)測(cè)預(yù)處理不一致”的問題。再說幾個(gè)細(xì)節(jié)數(shù)值列缺失值用中位數(shù)填充而不是均值。中位數(shù)對(duì)異常值不敏感在很多業(yè)務(wù)數(shù)據(jù)里更穩(wěn)類別列填充缺失作為一個(gè)獨(dú)立類別而不是刪掉模型能學(xué)到“缺失”本身可能是有效信號(hào)OneHotEncoder的handle_unknownignore保證線上新出現(xiàn)的類別不會(huì)報(bào)錯(cuò)而是全部變成0向量3.3 處理數(shù)據(jù)集不平衡與特征篩選分類模型在正負(fù)樣本極度不平衡的業(yè)務(wù)場(chǎng)景里直接訓(xùn)練模型會(huì)偏向多數(shù)類。體現(xiàn)在結(jié)果上就是“準(zhǔn)確率看著還行但實(shí)際上少數(shù)類一個(gè)都沒預(yù)測(cè)出來”。處理手段里最省事的是在Pipeline里加Scale_pos_weight或調(diào)整class_weight參數(shù)from sklearn.ensemble import RandomForestClassifier model Pipeline(steps[ (preprocessor, preprocessor), (clf, RandomForestClassifier(n_estimators300, class_weightbalanced, n_jobs-1)) ])class_weightbalanced會(huì)自動(dòng)按類別頻率反比加權(quán)相當(dāng)于告訴模型“少數(shù)的樣本錯(cuò)了要多罰點(diǎn)”。特征篩選方面如果特征維度很高建議先用SelectFromModel或RFECV做降維。我之前有個(gè)項(xiàng)目原本600多個(gè)特征用帶L1懲罰的線性模型篩完只剩70多個(gè)效果不變訓(xùn)練時(shí)間從40分鐘降到6分鐘。4. 模型訓(xùn)練、調(diào)參與產(chǎn)物管理4.1 讓網(wǎng)格搜索與交叉驗(yàn)證一體化流水線建好之后調(diào)參就變成了參數(shù)空間搜索問題。Pipeline對(duì)象的好處在這里充分體現(xiàn)了你要調(diào)的不只是模型的參數(shù)還有預(yù)處理器的參數(shù)比如“填充缺失值用中位數(shù)還是均值”“標(biāo)準(zhǔn)化用StandardScaler還是RobustScaler”這些問題都可以放進(jìn)搜索空間。寫法是這樣from sklearn.model_selection import GridSearchCV param_grid { classifier__C: [0.01, 0.1, 1, 10], classifier__penalty: [l2], preprocessor__num__imputer__strategy: [median, mean], preprocessor__cat__onehot__handle_unknown: [ignore] } grid_search GridSearchCV( model, param_gridparam_grid, cv5, scoringf1_macro, n_jobs-1, refitTrue, verbose1 ) grid_search.fit(X_train, y_train)注意參數(shù)名用雙下劃線連接classifier__C表示Pipeline里名為classifier的步驟的C參數(shù)preprocessor__num__imputer__strategy表示一層層往里深入。 這種命名方式是Sklearn Pipeline的參數(shù)尋址機(jī)制理解之后你會(huì)發(fā)現(xiàn)它能調(diào)的范圍遠(yuǎn)超模型本身。如果參數(shù)空間太大GridSearchCV會(huì)變得極其緩慢。參數(shù)多的時(shí)候我改用RandomizedSearchCV它不窮舉所有組合而是從分布中隨機(jī)采樣固定次數(shù)比如n_iter50通常能找到性能接近的參數(shù)但耗時(shí)少一個(gè)量級(jí)。調(diào)參完之后使用交叉驗(yàn)證得分而不是測(cè)試集得分來選模型。測(cè)試集只在最終驗(yàn)證時(shí)碰一次否則選出來的模型是對(duì)測(cè)試集過擬合的。4.2 最佳實(shí)踐用joblib替代pickle保存模型訓(xùn)練完模型接下來要保存和部署。Sklearn官方推薦使用joblib不推薦pickle。joblib對(duì)包含大量numpy數(shù)組的模型對(duì)象做了專門的序列化優(yōu)化速度更快文件更小。import joblib # 保存 joblib.dump(grid_search.best_estimator_, model_v3.joblib, compress3) # 加載預(yù)測(cè) loaded_model joblib.load(model_v3.joblib) pred loaded_model.predict(new_data_df)compress3是壓縮級(jí)別模型文件能縮小到原來的三分之一到五分之一。 如果不設(shè)置一個(gè)300MB的模型文件可能讓你的磁盤和傳輸都很難受。還有一個(gè)容易忽略的點(diǎn)保存模型時(shí)要一并保存特征列清單和預(yù)處理字典。 我見過項(xiàng)目從開發(fā)環(huán)境到生產(chǎn)環(huán)境字段名變了不重新訓(xùn)練就直接load模型結(jié)果預(yù)測(cè)全部報(bào)錯(cuò)。模型文件本身只存儲(chǔ)數(shù)值矩陣結(jié)構(gòu)它不關(guān)心你之前的DataFrame列名是什么。所以加載后要做一個(gè)列名校驗(yàn)expected_columns joblib.load(feature_columns.pkl) assert set(expected_columns).issubset(set(df.columns)), 特征列缺失4.3 模型評(píng)估階段該看哪些指標(biāo)單一準(zhǔn)確率在生產(chǎn)環(huán)境誤導(dǎo)性極強(qiáng)。 如果你的數(shù)據(jù)集里99%是負(fù)樣本一個(gè)全預(yù)測(cè)負(fù)類的“廢柴模型”準(zhǔn)確率也能到99%。我習(xí)慣交叉驗(yàn)證輸出一份完整報(bào)告from sklearn.metrics import classification_report, confusion_matrix from sklearn.model_selection import cross_validate scores cross_validate( grid_search.best_estimator_, X_train, y_train, cv5, scoring[accuracy, precision_macro, recall_macro, f1_macro], return_train_scoreTrue ) print(pd.DataFrame(scores).describe()) y_pred grid_search.predict(X_val) print(classification_report(y_val, y_pred)) print(confusion_matrix(y_val, y_pred))重點(diǎn)關(guān)注召回率和F1而不是準(zhǔn)確率。在欺詐識(shí)別、故障預(yù)測(cè)這類場(chǎng)景里少報(bào)一個(gè)壞樣本的代價(jià)遠(yuǎn)高于多報(bào)幾個(gè)好樣本。5. 性能優(yōu)化與走向分布式5.1 單機(jī)并行n_jobs不是萬能的Sklearn里很多模型支持n_jobs-1表示使用所有CPU核心。模型訓(xùn)練層面沒問題但有兩個(gè)隱藏風(fēng)險(xiǎn)嵌套并行導(dǎo)致資源爭搶。比如GridSearchCV設(shè)了n_jobs-1里面的隨機(jī)森林又設(shè)了n_jobs-1每個(gè)搜索任務(wù)都會(huì)嘗試用滿所有核造成大量線程切換性能反而下降內(nèi)存翻倍。并行任務(wù)會(huì)fork進(jìn)程每個(gè)進(jìn)程復(fù)制一份數(shù)據(jù)。如果原始數(shù)據(jù)10GB開8個(gè)進(jìn)程就是80GB內(nèi)存服務(wù)器直接OOM正確的做法是控制并行層級(jí)只在最外層開并行。例如GridSearchCV設(shè)n_jobs4模型內(nèi)部的n_jobs設(shè)為1或2。 在管線運(yùn)行時(shí)間瓶頸分析上不要一上來就跑完整模型先用少量數(shù)據(jù)構(gòu)建一個(gè)最簡模型跑通流程再逐步放大。5.2 數(shù)據(jù)量超內(nèi)存的實(shí)戰(zhàn)方案如果單機(jī)內(nèi)存實(shí)在塞不下全部數(shù)據(jù)有兩個(gè)路線路線一使用sklearn的增量學(xué)習(xí)接口。Sklearn里有一部分模型支持partial_fit可以分批訓(xùn)練。典型的如SGDClassifier、SGDRegressor、MiniBatchKMeans。from sklearn.linear_model import SGDClassifier from sklearn.preprocessing import StandardScaler scaler StandardScaler() model SGDClassifier(losslog_loss, max_iter1000, tol1e-3) # 分塊讀取并逐步訓(xùn)練 for chunk in pd.read_csv(big_data.csv, chunksize10000): X_chunk chunk[numeric_features categorical_features] y_chunk chunk[label] # 數(shù)值列標(biāo)準(zhǔn)化需要累積統(tǒng)計(jì)量實(shí)際項(xiàng)目中用 partial_fit 與 scaler 配合 model.partial_fit(X_chunk_scaled, y_chunk, classes[0, 1])注意partial_fit第一次調(diào)用時(shí)要傳classes參數(shù)。增量學(xué)習(xí)適合線性模型復(fù)雜樹模型沒有官方partial_fit接口。路線二用Dask處理分布式DataFrame。Dask的核心思路是“延遲計(jì)算”它把大文件切塊在集群或多進(jìn)程上并行處理API和Pandas非常接近import dask.dataframe as dd ddf dd.read_csv(huge_data.csv, blocksize64MB) # Dask會(huì)按塊分布到多個(gè)進(jìn)程 df ddf.compute() # 這里才真正觸發(fā)計(jì)算Dask不是直接用Sklearn訓(xùn)練的替代品但對(duì)于“數(shù)據(jù)大到內(nèi)存放不下”的痛點(diǎn)非常有效。 執(zhí)行清洗、篩選、聚合、特征生成這些操作時(shí)Dask能按塊處理并合并結(jié)果。5.3 什么情況下必須上分布式框架如果你的數(shù)據(jù)量到了數(shù)百GB甚至TB級(jí)別或者特征數(shù)到了百萬級(jí)Sklearn就不夠用了。這時(shí)候選型要考慮自己的場(chǎng)景需求場(chǎng)景推薦方案原因大規(guī)模特征工程、SQL化數(shù)據(jù)清洗Spark MLlib生態(tài)成熟、與數(shù)據(jù)倉庫集成好GBDT類模型、大規(guī)模表格數(shù)據(jù)XGBoost / LightGBM 分布式訓(xùn)練訓(xùn)練效率極高支持并行和GPU深度學(xué)習(xí)、非結(jié)構(gòu)化數(shù)據(jù)PyTorch / TensorFlow天然支持分布式訓(xùn)練中小規(guī)模數(shù)據(jù)、快速實(shí)驗(yàn)迭代Sklearn Pipeline開發(fā)效率高、維護(hù)成本低我的建議是不要急著上分布式。 先做單機(jī)版本用真實(shí)數(shù)據(jù)量跑通找到瓶頸在哪里。很多時(shí)候瓶頸根本不在訓(xùn)練而在數(shù)據(jù)讀取和預(yù)處理階段。把ETL輸出Parquet、特征工程并行化之后單機(jī)能扛的數(shù)據(jù)量上限會(huì)大幅提高。只有當(dāng)單機(jī)優(yōu)化做盡、硬件加到極限仍然不行時(shí)再引入分布式方案。5.4 加速樹模型的一個(gè)關(guān)鍵選擇如果你用的是樹模型換用HistGradientBoosting系列能帶來顯著的訓(xùn)練速度提升。Sklearn從0.24版本開始內(nèi)置了直方圖梯度提升算法也就是和LightGBM同源的思路from sklearn.ensemble import HistGradientBoostingClassifier model HistGradientBoostingClassifier( max_iter200, learning_rate0.05, max_leaf_nodes31, categorical_featuresfrom_dtype )對(duì)比傳統(tǒng)GradientBoostingClassifier這個(gè)模型在幾萬條數(shù)據(jù)上可能差距不明顯但數(shù)據(jù)量到百萬級(jí)時(shí)訓(xùn)練時(shí)間可以從幾小時(shí)縮短到十幾分鐘。 因?yàn)樗鼘?duì)特征值做了分箱binning不需要為每個(gè)樣本的每個(gè)特征值計(jì)算分裂點(diǎn)計(jì)算復(fù)雜度大幅下降。6. 常見問題與排查技巧實(shí)錄6.1 高頻問題速查表現(xiàn)象可能原因排查與解決sklearn導(dǎo)入報(bào)GLIBCXX錯(cuò)誤系統(tǒng)libstdc版本過舊使用conda環(huán)境或升級(jí)gcc工具鏈pandas中文列名讀取亂碼文件編碼不是UTF-8read_csv指定encodinggbk或utf-8訓(xùn)練時(shí)內(nèi)存持續(xù)上漲直到OOMn_jobs開太大或數(shù)據(jù)類型未優(yōu)化調(diào)小n_jobs、指定dtype、用category類型預(yù)測(cè)時(shí)提示特征維度不匹配OneHotEncoder在訓(xùn)練/預(yù)測(cè)時(shí)列不一致使用Pipeline或設(shè)置handle_unknownignore模型訓(xùn)練幾分鐘后“被殺”服務(wù)器內(nèi)存不足OOM killer介入查看dmesg日志追加swap空間或降低數(shù)據(jù)量GridSearchCV速度極慢參數(shù)組合多、n_jobs設(shè)置不當(dāng)用RandomizedSearchCV、縮小搜索空間joblib.load后預(yù)測(cè)結(jié)果全是一個(gè)值模型文件損壞或features順序變化重新訓(xùn)練并校驗(yàn)特征列清單針對(duì)“模型訓(xùn)練被殺”這個(gè)現(xiàn)象多說一句。CentOS 7.9服務(wù)器一般沒有Swap或Swap很小數(shù)據(jù)量大的時(shí)候OOM Killer會(huì)直接殺死Python進(jìn)程。 排查時(shí)先執(zhí)行dmesg | tail -50看有沒有“Out of memory: Kill process”字樣。如果有優(yōu)先優(yōu)化數(shù)據(jù)類型和分批處理再考慮加Swap# 創(chuàng)建8G Swap文件 fallocate -l 8G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile none swap sw 0 0 /etc/fstabSwap不是萬能的但能有效防止進(jìn)程被立即殺死保住中間計(jì)算結(jié)果。6.2 使用早期停止縮短調(diào)參時(shí)間調(diào)參階段最耗時(shí)間的部分是參數(shù)組合搜索。Sklearn的HistGradientBoosting支持early_stoppingGridSearchCV配合NFL增量評(píng)估也能加速。from sklearn.model_selection import GridSearchCV from sklearn.ensemble import HistGradientBoostingClassifier model Pipeline(steps[ (preprocessor, preprocessor), (clf, HistGradientBoostingClassifier( early_stoppingTrue, validation_fraction0.1, n_iter_no_change10 )) ])early_stopping會(huì)在驗(yàn)證集分?jǐn)?shù)連續(xù)10輪不提升時(shí)提前終止訓(xùn)練避免無效的迭代。 我實(shí)測(cè)過一個(gè)項(xiàng)目加了early_stopping之后單次模型訓(xùn)練時(shí)間縮短了50%以上基本不影響最終效果。6.3 排查“訓(xùn)練很慢但不知道慢在哪”如果流水線整體很慢不要猜用Profiler采樣。一個(gè)簡單做法在Pipeline的每個(gè)步驟外面打時(shí)間戳。我習(xí)慣用一個(gè)小工具函數(shù)import time from contextlib import contextmanager contextmanager def timeit(step_name): start time.time() yield elapsed time.time() - start print(f{step_name} 耗時(shí) {elapsed:.2f}s)然后在每個(gè)環(huán)節(jié)包一層。跑完后你會(huì)清晰地看到瓶頸在數(shù)據(jù)讀取、特征處理還是模型訓(xùn)練。很多時(shí)候你以為慢在訓(xùn)練實(shí)際上慢在read_csv的類型推斷。先消除明顯瓶頸再去優(yōu)化模型算法不要一開始就動(dòng)最復(fù)雜的部分。6.4 線上和線下環(huán)境不一致的坑開發(fā)機(jī)是Mac或Windows生產(chǎn)環(huán)境是CentOS 7.9。代碼在開發(fā)機(jī)跑得好好的一到服務(wù)器就報(bào)錯(cuò)。多數(shù)是因?yàn)榘姹静灰恢隆?解決方法是在代碼倉庫里固定依賴版本pip freeze requirements.txt生產(chǎn)環(huán)境部署時(shí)pip install -r requirements.txt --no-cache-dir另外Sklearn版本1.0和1.2之間的API有少量變化比如OneHotEncoder的sparse參數(shù)改成了sparse_output。 如果模型文件是用老版本訓(xùn)練的新版本加載時(shí)偶爾會(huì)有兼容告警。建議用joblib加載時(shí)捕獲異常并做版本記錄把模型版本號(hào)和Sklearn版本號(hào)一起存入元數(shù)據(jù)。到了這一步整條流水線從環(huán)境到數(shù)據(jù)、從特征到模型、從調(diào)參到部署已經(jīng)能形成一個(gè)完整的閉環(huán)。我在CentOS 7.9上跑過的最重的一個(gè)任務(wù)是3.5億行用戶行為數(shù)據(jù)做特征聚合優(yōu)化完類型和Parquet存儲(chǔ)后單機(jī)16G內(nèi)存的服務(wù)器能穩(wěn)定扛下來。所以我的經(jīng)驗(yàn)是先用好單機(jī)做足優(yōu)化再談分布式。真實(shí)項(xiàng)目里把這幾件事做扎實(shí)比盲目引入Spark之類的框架要有效得多。這條流水線搭好之后后續(xù)換數(shù)據(jù)源、加特征、換模型都是在同一套框架里改配置的事不會(huì)再讓你從頭再來。