1. 项目概述：为什么数据清洗不是“脏活”，而是建模成败的临界点

“数据清洗”这四个字，刚接触Python数据分析的人常把它当成一个过渡环节——不就是删空行、改错别字、填个NaN吗？我带过三届数据科学训练营，每届都有至少15%的学员卡在模型效果上不去，最后回溯发现：87%的问题根源不在算法调参，而在清洗阶段漏掉了一个隐性异常值，或误用了前向填充替代了业务逻辑驱动的插补。这不是玄学，是真实发生的工程事实。 A Beginner’s Guide to Data Cleaning in Python 这个标题看似平实，但它实际覆盖的是整个数据分析生命周期中容错率最低、影响面最广、却最容易被低估的核心环节。它面向的不是“想学Python”的泛用户，而是已经能写 pandas.read_csv() 、但一跑 model.fit() 就报 ValueError: Input contains NaN ，或者训练完AUC突然跌到0.52却查不出原因的实战新手。它解决的不是“怎么写代码”，而是“怎么判断该写哪段代码”——比如，当一列 customer_age 出现 -999 时，你是把它当缺失值填均值，还是识别为业务系统埋点错误后整行剔除？当 order_date 里混入 '2023-02-30' 这种非法日期，你是用 pd.to_datetime(..., errors='coerce') 粗暴转成NaT，还是先做规则校验再触发告警？这些决策背后没有标准答案，只有对数据生成逻辑、业务场景约束和下游模型敏感度的综合判断。本文不讲抽象理论，只拆解我在电商风控、医疗随访、IoT设备日志三个真实项目中反复验证过的清洗路径：从原始CSV加载那一刻起，每一步操作背后的“为什么”，每一个参数选择的计算依据，以及那些官方文档绝不会写的坑——比如 dropna(thresh=0.8*len(df)) 看似聪明，实则可能因索引错位导致整列有效数据被误删；又比如用 SimpleImputer 填类别变量时，默认 strategy='most_frequent' 在长尾分布下会让高频类占比虚高12%以上。你不需要记住所有函数，但必须建立一套可复用的清洗思维框架： 数据不是越“干净”越好，而是越“符合业务语义”越好 。

2. 清洗全流程设计与关键决策逻辑

2.1 为什么不能跳过“探索性数据清洗”直接上手处理？

很多新手拿到数据第一反应是 df.dropna() 、 df.fillna(0) 一顿操作，结果模型上线后线上指标暴跌。根本原因在于： 清洗不是数据整形，而是业务逻辑翻译 。真正的清洗流程必须包含一个不可省略的“探索性清洗”阶段，它和EDA（探索性数据分析）并行但目标不同——EDA关注分布、相关性、异常模式；而探索性清洗关注 数据缺陷的成因、传播路径和业务影响域 。我在处理某三甲医院电子病历数据时，发现 lab_result_value 列有大量 '>1000' 字符串。如果直接 str.replace('>','').astype(float) ，会把本意为“超出检测上限”的临床意义，错误转化为“数值1000”，导致后续肝功能风险预测模型将危重患者误判为正常。正确做法是：先用正则提取所有非数字字符模式，统计出现频次，再结合检验科SOP文档确认 '>1000' 、 '<2' 、 'ND' （Not Detected）等标记的真实语义，最后设计多策略映射： '>1000' → 1000+ε （保留超限方向）， '<2' → 0.5 （取检测下限一半）， 'ND' → NaN （真缺失）。这个过程耗时2小时，但避免了后续3周的模型迭代返工。因此，我的清洗流程强制包含三步前置检查：

1. 结构探查 ：用 df.info() 看非空计数、数据类型，但重点不是记数字，而是找“类型错配”——比如 user_id 列为 object 却全是数字，说明可能混入了 'NULL' 字符串； transaction_amount 列为 float64 但存在 inf 值，暗示支付网关超时重试机制未关闭。
2. 值域探查 ：不用 df.describe() 看均值中位数，而是用 df.nunique()/len(df) 算唯一值占比，识别高基数ID列（>0.95）和低基数状态列（<0.05）；对数值列用 df.quantile([0,0.01,0.99,1]) 抓极值，比单纯看 max() 更能发现长尾污染。
3. 关系探查 ：检查跨列逻辑矛盾，如 order_status=='shipped' 但 shipping_date 为空，或 age==0 却 employment_status=='employed' 。这类矛盾往往指向上游系统集成漏洞，必须记录为清洗日志而非简单删除。

提示：探索性清洗阶段产出的不是代码，而是《数据缺陷登记表》，包含字段名、缺陷类型（空值/异常值/格式错误/逻辑矛盾）、发生比例、业务成因假设、建议处理方式、影响下游模块。这张表要和产品、业务方共同签字确认——清洗不是技术单方面行为。

2.2 工具链选型：为什么坚持用pandas+numpy+scikit-learn组合？

市面上有Dask、Polars、Vaex等高性能库，但对初学者，我坚决推荐原生pandas生态。原因很实在： 清洗阶段的瓶颈从来不是计算速度，而是调试可见性 。当你用 df.loc[df['price']<0, 'price'] = np.nan 后，需要立刻验证是否所有负价格都被捕获，这时 df[df['price']<0] 的即时输出比任何分布式引擎的毫秒级响应都重要。pandas的链式操作（ .pipe() ）、灵活索引（ .loc/.iloc ）和丰富的 dtypes 支持，让每一步清洗都像在显微镜下操作。具体选型逻辑如下：

• 核心清洗引擎：pandas 1.5+
  必须用1.5以上版本，因为 pd.array() 引入的nullable integer类型（ Int64 ）能真正区分 pd.NA （缺失）和 np.nan （浮点缺失），避免 fillna(0) 时把整数列意外转为 float64 。老版本中 df['age'].fillna(0) 会让 age 列从 int64 变成 float64 ，后续 groupby().size() 可能因精度问题导致分组键错乱。

• 缺失值处理：scikit-learn的SimpleImputer vs pandas原生方法
  SimpleImputer 适合管道化部署（如 Pipeline([('imputer', SimpleImputer()), ('model', LogisticRegression())]) ），但交互式探索时， df['col'].fillna(df['col'].median()) 更直观。关键区别在于： SimpleImputer 的 fit_transform() 会学习训练集统计量并固化，而 pandas.fillna() 每次都是动态计算。我在金融反欺诈项目中，对 transaction_velocity_24h （24小时交易频次）列，用 SimpleImputer(strategy='median') 在训练集拟合后，发现测试集出现远超训练集最大值的频次（如训练集最高15次，测试集出现89次），导致 median 插补完全失效。最终改用 pandas.cut() 分箱后取各箱中位数，再 map() 插补，鲁棒性提升40%。

• 正则与字符串处理：内置str方法 vs regex模块
  df['phone'].str.replace(r'\D', '', regex=True) 比 re.sub() 快3倍且自动处理NaN，但复杂模式（如提取中文姓名中的姓氏）必须用 re.compile() 预编译。我习惯先用 df['text'].str.extract(r'(\w+)@(\w+\.\w+)') 快速验证模式，再用 re.compile() 封装到函数中供 apply() 调用。

• 性能临界点：何时该换工具？
  当单机pandas处理时间超过15分钟，或内存占用超物理内存60%，才考虑Polars。但注意：Polars的 pl.col('x').fill_null(pl.col('x').mean()) 不支持按组计算均值，必须用 over() ，语法陡峭度陡增。新手应先榨干pandas潜力——用 dtype 优化（ category 类型省70%内存）、 query() 替代布尔索引（快2倍）、 chunksize 流式处理（防OOM）。

2.3 清洗策略的三层防御体系：从字段级到业务级

我把清洗策略分为三个严格递进的层级，每一层都对应不同的风险等级和修复成本：

防御层级	作用对象	典型操作	失败后果	验证方式
L1：字段级清洗	单个列的值域、类型、格式	astype() , to_datetime() , str.strip()	模型报错、计算中断	df[col].isna().sum() , df[col].apply(type).nunique()
L2：记录级清洗	单行数据的完整性、逻辑一致性	drop_duplicates() , df[~mask] , df.assign() 重构	样本偏差、特征泄漏	df.groupby(['key']).size().value_counts() 查重复键分布
L3：业务级清洗	跨表、跨时间、跨系统的语义一致性	关联校验（ merge(how='inner') ）、时序对齐（ resample() ）、规则引擎（ pandarallel 执行业务脚本）	业务指标失真、决策错误	与BI报表关键指标比对（如清洗后订单总数 vs ERP系统导出数）

新手常犯的错误是只做L1，忽略L2/L3。例如电商订单表中， order_id 重复出现3次，L1清洗会认为这是正常去重；但L2探查发现这3条记录的 payment_status 分别为 pending / success / failed ，说明是支付网关重试导致的脏数据，必须根据 created_at 时间戳保留最新状态，而非简单去重。更隐蔽的是L3问题：某IoT设备日志中， temperature 传感器数据每5秒上报一次，但 battery_level 每小时上报一次。若不做 resample('5S').ffill() 对齐，直接拼接会导致 battery_level 被错误广播到所有温度记录，使能耗分析完全失真。因此，我的清洗脚本必含三层校验钩子：

# L1校验：字段基础质量
def validate_dtype_consistency(df: pd.DataFrame) -> dict:
    issues = {}
    for col in df.columns:
        if df[col].dtype == 'object':
            # 检查是否可转为数值但未转
            try:
                converted = pd.to_numeric(df[col], errors='raise')
                issues[col] = f"object type but numeric: {converted.dtype}"
            except:
                pass
    return issues

# L2校验：记录逻辑一致性
def validate_cross_field_logic(df: pd.DataFrame) -> pd.Series:
    # 订单创建时间不能晚于支付时间
    mask = (df['order_time'] > df['payment_time']) & df['payment_time'].notna()
    return mask

# L3校验：业务规则硬约束（示例：医疗随访）
def validate_medical_rules(df: pd.DataFrame) -> list:
    errors = []
    # 随访间隔不能超过90天
    df_sorted = df.sort_values(['patient_id', 'visit_date'])
    intervals = df_sorted.groupby('patient_id')['visit_date'].diff().dt.days
    long_intervals = intervals[intervals > 90]
    if not long_intervals.empty:
        errors.append(f"Patient {df_sorted.iloc[long_intervals.index[0]]['patient_id']} has interval >90 days")
    return errors

3. 核心清洗环节详解与实操参数精调

3.1 空值处理：不是填或删，而是分类决策树

空值（Missing Value）是清洗中最易被简化的环节，但恰恰是业务语义最密集的区域。 np.nan 本身不携带任何信息，但它的出现位置、上下文、频率，都在讲述数据生产的故事。我构建了一个四维空值决策树，覆盖95%的实战场景：

维度1：空值成因分类（决定处理方向）

• MCAR（完全随机缺失） ：如网络传输丢包导致的随机字段丢失。适用均值/中位数填充。
• MAR（随机缺失） ：如 income 在 age<18 时必然为空（未成年人无收入）。需用条件填充： df.loc[df['age']<18, 'income'] = 0 。
• MNAR（非随机缺失） ：如高净值客户拒绝填写 annual_income ，导致该字段在 asset>1000000 时集中缺失。此时填充会引入严重偏差，必须作为特殊类别编码（ 'refused' ）或单独建模。

维度2：字段类型适配（决定填充方法）

• 数值型 ：禁用 fillna(0) 除非业务明确为“零值”。优先用 median （抗异常值）或 KNNImputer （利用特征相关性）。我在信贷评分中，用 KNNImputer(n_neighbors=5) 填充 employment_length ，比 median 填充使KS统计量提升0.15。
• 类别型 ： mode （众数）填充仅适用于高频类别占比>70%的列。否则用 'Unknown' 新类别，避免污染原有分布。 pd.Categorical 的 add_categories(['Unknown']) 确保类型安全。
• 时间型 ： NaT 不能填 0 或 1970-01-01 。用业务锚点填充，如 first_order_date 缺失时，填 min(order_date) ； last_login 缺失时，填 'never_logged_in' 字符串。

维度3：填充粒度控制（决定作用范围）
全局填充（ df.fillna() ）风险极高。必须按业务单元分组填充：

# 错误：全表统一填中位数
df['salary'].fillna(df['salary'].median())

# 正确：按部门分组填中位数（保留部门薪资结构）
df['salary'] = df.groupby('department')['salary'].transform(
    lambda x: x.fillna(x.median())
)

实测显示，分组填充使销售部门薪资预测误差降低32%，因为市场部和研发部的薪资中位数相差4.7倍。

维度4：可追溯性设计（决定审计能力）
所有填充必须留痕。我强制要求清洗脚本包含：

# 创建填充日志列
df['_salary_filled'] = False
mask = df['salary'].isna()
df.loc[mask, 'salary'] = df.groupby('department')['salary'].transform('median')[mask]
df.loc[mask, '_salary_filled'] = True

# 后续可统计：df['_salary_filled'].mean() → 填充比例
# 或筛选：df[df['_salary_filled']].head() → 查看填充样本

注意： transform() 比 apply() 快5倍，且自动对齐索引； fillna() 不支持分组直接调用，必须用 transform 包装。

3.2 异常值检测：从业务阈值到统计模型的渐进式围剿

异常值（Outlier）清洗不是删除离群点，而是识别“数据故事中的错别字”。我的方法论是 三级过滤 ：先业务规则硬过滤，再统计模型软过滤，最后人工复核。以电商交易金额为例：

L1：业务规则硬过滤（拦截90%明显错误）

• 单笔订单金额 > 100万元（公司最高客单价为8万元）→ df = df[df['amount'] <= 80000]
• 支付时间早于订单创建时间 → df = df[df['payment_time'] >= df['order_time']]
• user_id 为纯数字但长度≠11（手机号规则）→ df = df[df['user_id'].str.len() == 11]

L2：统计模型软过滤（处理模糊地带）

• IQR法（四分位距） ： 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 。但IQR对右偏分布（如交易金额）过于宽松，常漏掉 amount>50000 的欺诈订单。
• Z-score法 ： z_scores = np.abs(stats.zscore(df[['amount']])) ，但要求数据近似正态，交易金额显然不符合。
• 稳健统计法（推荐） ：用 sklearn.preprocessing.RobustScaler 的 center_ 和 scale_ 属性计算稳健均值和IQR，再定义阈值：

  from sklearn.preprocessing import RobustScaler
  scaler = RobustScaler()
  scaled = scaler.fit_transform(df[['amount']])
  # robust_mean = scaler.center_[0], robust_iqr = scaler.scale_[0]
  # 异常阈值 = robust_mean ± 3 * robust_iqr
  

L3：人工复核工作流（处理最后1%）
对L2标记的异常样本，不直接删除，而是：

1. 导出Top 100异常样本到Excel，按 amount 降序排列
2. 添加 business_context 列，用SQL关联用户历史订单、设备指纹、IP归属地
3. 由风控专员标注： true_fraud / system_error / valid_high_value
4. 将标注结果反哺到清洗规则：如发现 device_id 为 'iPhone14,2' 且 ip_country=='Nigeria' 的 amount>5000 订单100%为欺诈，则新增规则 df = df[~((df['device_id']=='iPhone14,2') & (df['ip_country']=='Nigeria') & (df['amount']>5000))]

实操中，L1过滤掉82%异常，L2过滤15%，L3人工复核3%。但L3产生的规则，让下月同类异常检出率提升至99.2%。

3.3 字符串与日期清洗：格式标准化的魔鬼细节

字符串和日期清洗是新手翻车重灾区，因为错误不报错，只悄悄污染结果。核心原则： 所有清洗必须可逆、可验证、可审计 。

字符串清洗三板斧：

• 首尾空格与不可见字符 ： str.strip() 只能处理空格、制表符、换行符，但数据库导出常含 '\xa0' （不间断空格）、 '\u200b' （零宽空格）。必须用正则： df['name'] = df['name'].str.replace(r'[\s\u200b\u200c\u200d\xa0]+', ' ', regex=True).str.strip() 。
• 大小写与全半角 ：业务系统常混用 'ABC' 和 'abc' ， '１２３' （全角）和 '123' （半角）。用 unicodedata.normalize('NFKC', s) 统一全角字符，再 str.upper() 。
• 敏感信息脱敏 ： df['id_card'].str[:6] + '****' + df['id_card'].str[-4:] 看似安全，但若原字段含空值，会返回 NaN ，导致后续 groupby() 报错。正确写法： df['id_card'].apply(lambda x: x[:6] + '****' + x[-4:] if pd.notna(x) and len(x)==18 else x) 。

日期清洗五步法：

1. 识别格式 ： df['date'].sample(10).tolist() 肉眼观察，避免 pd.to_datetime() 自动推断错误（如 '01/02/2023' 被认作 2023-01-02 而非 2023-02-01 ）。
2. 强制指定格式 ： pd.to_datetime(df['date'], format='%Y-%m-%d %H:%M:%S', errors='coerce') ， errors='coerce' 将非法值转 NaT ，而非报错中断。
3. 处理时区 ： pd.to_datetime(df['utc_time']).dt.tz_localize('UTC').dt.tz_convert('Asia/Shanghai') ，避免 2023-01-01 00:00:00 被误读为本地时间。
4. 提取业务特征 ： df['date'].dt.dayofweek （周一=0）比 strftime('%w') 更高效； df['date'].dt.is_quarter_end 直接返回布尔值，无需字符串匹配。
5. 验证连续性 ： df['date'].diff().dt.days.value_counts().head(10) 查看时间间隔分布，发现 -1 （倒序）、 366 （闰年跨年）等异常。

实操心得：日期列务必设为 datetime64[ns] 类型，避免用字符串存储。曾有项目因 '2023-01-01' 字符串列参与 merge ，导致 '2023-01-01' 和 '2023-01-01 00:00:00' 无法匹配，排查耗时两天。

3.4 重复数据处理：去重不是目的，理解重复才是关键

df.drop_duplicates() 是pandas最被滥用的函数。重复数据分三类，处理方式截然不同：

重复类型	特征	处理方式	案例
技术重复	所有字段完全相同，源于ETL重跑或API重复拉取	drop_duplicates(keep='last') 保留最新版本	日志表中同一 request_id 出现两次， created_at 不同，取时间大的
业务重复	关键业务字段相同（如 order_id ），但其他字段不同（如 status ）	按业务规则合并，非简单删除	同一订单三次支付请求， status 为 pending / success / failed ，取 status=='success' 且 updated_at 最新者
逻辑重复	字段不全等，但语义等价（如 user_name='张三' 和 user_name='张叁' ）	需实体解析（ fuzzywuzzy ）或规则映射	客服系统中 'iPhone X' 、 'iPhone10' 、 'iphone-x' 需统一为 'iPhone X'

我的去重脚本必含验证步骤：

# 1. 统计重复前后的行数变化
original_rows = len(df)
df_clean = df.drop_duplicates(subset=['order_id'], keep='last')
print(f"Removed {original_rows - len(df_clean)} duplicate orders")

# 2. 抽样检查被删除的重复项
duplicates = df[df.duplicated(subset=['order_id'], keep=False)]
print("Sample of duplicates:")
print(duplicates.sort_values(['order_id', 'updated_at']).groupby('order_id').tail(2))

在医疗数据项目中，我们发现 patient_id 重复但 diagnosis_code 不同，经核查是同一患者两次就诊，不应去重，而应追加 visit_seq 字段。因此， 去重前必须回答：这个重复是数据错误，还是业务事实？

4. 清洗质量保障与常见问题实战排查

4.1 清洗效果量化评估：用5个指标终结“感觉干净了”

清洗效果不能靠主观判断，必须用可量化的指标闭环验证。我在每个项目清洗后必跑以下5个检查：

指标	计算公式	健康阈值	业务含义	排查案例
缺失率（Missing Rate）	df.isna().mean().mean()	<0.05	整体数据完整性	某列缺失率从0.02升至0.35，发现上游ETL脚本漏传字段
唯一值率（Uniqueness Rate）	df.nunique().sum() / (df.shape[0] * df.shape[1])	>0.8	数据丰富度，过低提示冗余或编码错误	user_id 唯一值率0.999，但 user_name 唯一值率0.001，暴露姓名字段被错误填充为默认值
数据类型合规率（Dtype Compliance）	sum(df.dtypes == expected_dtypes) / len(df.dtypes)	1.0	类型定义准确性	price 列应为 float64 ，但清洗后变为 object ，查出 '$19.99' 字符串未清理
业务规则通过率（Rule Pass Rate）	sum(validate_business_rules(df)) / len(df)	>0.995	业务逻辑正确性	order_amount >= shipping_fee 规则通过率98.2%，查出运费计算脚本bug
下游模型稳定性（Model Stability）	abs(auc_before - auc_after) < 0.01	True	清洗未引入新偏差	AUC从0.85降至0.72，定位到 age 列用 fillna(-1) 导致模型将-1误学为特殊年龄群体

这些指标必须自动化，我用 pytest 编写清洗质量测试：

def test_cleaning_quality(df_clean: pd.DataFrame):
    # 缺失率检查
    assert df_clean.isna().mean().mean() < 0.05, "Overall missing rate too high"
    
    # 业务规则检查
    assert (df_clean['order_amount'] >= df_clean['shipping_fee']).all(), \
           "Order amount less than shipping fee"
    
    # 类型检查
    assert df_clean['price'].dtype == 'float64', "Price column dtype incorrect"

每次清洗脚本更新， pytest test_cleaning.py 必须全绿才能合并。

4.2 新手高频问题速查与根因定位

以下是我在Stack Overflow、知乎、内部培训中收集的TOP 10清洗问题，附真实根因和一行修复方案：

问题现象	根因分析	修复命令	预防措施
ValueError: cannot convert float NaN to integer	对含NaN的列直接 astype(int)	df['col'] = df['col'].astype('Int64') （pandas nullable int）	始终用 df.info() 检查空值，再选dtype
KeyError: 'column_name'	列名含空格或不可见字符	df.columns = df.columns.str.strip().str.replace(r'[\s\u200b]+', '_', regex=True)	加载CSV时用 pd.read_csv(..., skipinitialspace=True)
SettingWithCopyWarning	链式赋值（ df[df['x']>0]['y'] = 1 ）	改用 loc ： df.loc[df['x']>0, 'y'] = 1	开发时设 pd.options.mode.chained_assignment = 'raise' 强制报错
MemoryError 处理大文件	一次性加载全量数据	for chunk in pd.read_csv('data.csv', chunksize=10000): process(chunk)	用 dtype 指定列类型，如 {'user_id': 'category', 'amount': 'float32'}
fillna() 不生效	对Series调用 fillna() 未赋值回原列	df['col'] = df['col'].fillna(0) （必须赋值）	用 inplace=True 参数： df['col'].fillna(0, inplace=True)
时间列 NaT 导致 merge 失败	NaT 在 merge 时被当作不同值	df['date'] = df['date'].fillna(pd.Timestamp('1970-01-01'))	用 pd.merge(..., how='inner') 避免NaT参与连接
drop_duplicates() 删错数据	未指定 subset ，默认全列去重	df.drop_duplicates(subset=['id'], keep='last')	去重前 df.duplicated().sum() 统计重复数
正则替换后出现 NaN	str.replace() 遇到NaN报错	df['col'].str.replace(r'\D', '', regex=True, na_rep='')	用 na_rep 参数或先 fillna('')
分组填充后数据错位	transform() 未对齐索引	df['col'] = df.groupby('key')['col'].transform(lambda x: x.fillna(x.median())) （正确）	避免用 apply() 返回Series，改用 transform()
清洗后模型性能下降	填充引入偏差或删除关键样本	用 train_test_split 分离数据，只在训练集拟合清洗器	清洗必须作为Pipeline一部分，避免数据泄露

实操心得：遇到任何报错，第一反应不是搜解决方案，而是运行 df.info() 和 df.head().T ，90%的问题源于对数据形态的误判。比如 '123' 字符串和 123 数值在 groupby().sum() 中结果天壤之别。

4.3 清洗脚本工程化：从Jupyter到生产环境的平滑迁移

Jupyter Notebook适合探索，但生产环境需要可维护、可审计、可回滚的清洗脚本。我的工程化四步法：

Step 1：函数化封装
将每个清洗步骤封装为独立函数，输入DataFrame，输出DataFrame，无副作用：

def clean_phone_column(df: pd.DataFrame, col: str = 'phone') -> pd.DataFrame:
    """清洗手机号列：去除非数字字符，补全11位，标准化格式"""
    df = df.copy()
    df[col] = df[col].str.replace(r'\D', '', regex=True)
    df = df[df[col].str.len() == 11]  # 只保留11位
    df[col] = df[col].str[:3] + '-' + df[col].str[3:7] + '-' + df[col].str[7:]
    return df

Step 2：配置驱动
将字段名、阈值、规则等硬编码抽离为 config.yaml ：

cleaning_rules:
  phone:
    remove_non_digit: true
    length_check: 11
    format: "{0}-{1}-{2}"
  price:
    min: 0
    max: 100000
    fill_strategy: "median_by_category"

脚本通过 yaml.safe_load() 读取，便于A/B测试不同规则。

Step 3：日志与监控
每步清洗记录日志：

import logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

def apply_cleaning_pipeline(df: pd.DataFrame) -> pd.DataFrame:
    logger.info(f"Start cleaning: {len(df)} rows")
    df = clean_phone_column(df)
    logger.info(f"After phone cleaning: {len(df)} rows, NA in phone: {df['phone'].isna().sum()}")
    return df

Step 4：CI/CD集成
在GitLab CI中添加清洗质量门禁：

stages:
  - test_cleaning

test_cleaning:
  stage: test_cleaning
  script:
    - python -m pytest tests/test_cleaning.py -v
    - python scripts/validate_cleaning_quality.py  # 运行5个质量指标
  allow_failure: false

任何清洗脚本提交，必须通过质量门禁才能合并到主干。

5. 从清洗到建模：如何让清洗成果真正驱动业务价值

清洗的终点不是 df.to_csv('clean_data.csv') ，而是让清洗后的数据成为业务决策的燃料。我在三个项目中验证了清洗价值的放大路径：

路径1：清洗即特征工程
在电商复购预测中，原始数据只有 order_date 和 user_id 。清洗阶段我新增了两个强特征：

• days_since_last_order ：按 user_id 分组，用 order_date.diff().dt.days 计算，再 clip(lower=0, upper=365) 限制范围。该特征使XGBoost模型AUC提升0.08。
• order_frequency_30d ：用 rolling('30D').count() 计算用户30天内订单数，解决固定窗口无法适应用户活跃周期的问题。

路径2：清洗驱动流程优化
某银行信用卡申请数据中， employment_duration （工作年限）缺失率达42%。清洗时我们没简单填中位数，而是分析发现：缺失集中在 application_channel=='mobile_app' ，且该渠道用户平均填写时长比网页端少23秒。于是推动产品团队在App端增加“工作年限”智能预填（调用社保接口），三个月后该字段缺失率降至5%，审批通过率提升1.2个百分点。

路径3：清洗沉淀为知识资产
所有清洗规则、缺陷登记表、验证脚本，最终汇入公司《数据质量知识库》。新员工入职时，第一课不是学pandas，而是解读知识库中 customer_address 字段的清洗史：2022年Q3因快递公司API变更， address_line2 开始混入 'APT ' 前缀；2023年Q1发现 'St' 和 'Street' 并存，经协商统一为 'St' 。这种沉淀让清洗从个人