简介面向大数据应用人才与数据分析初学者的数据清洗实战数据源包聚焦数据质量评估、缺失值处理、异常值检测、一致性检查和格式转换等核心步骤解决练习时缺乏多格式真实数据的问题。压缩包共 11 个文件、约 96KB包含 3 个 SQL、2 个 CSV、2 个 TXT、1 个 XLSX、1 个 XLS、1 个 JSON 与 1 个 XML覆盖数据库脚本、表格文件和半结构化数据可满足不同清洗工具与场景的训练需求。包内涉及课程信息、学生信息、58 同城租房等多类业务数据SQL 文件便于直接建表与查询JSON/XML 可锻炼解析与嵌套字段处理TXT/CSV 则适合编码识别与分隔符清洗xlsx/xls 可用于 Excel 表格规范化和去重。目前已有 528 人学习下载适合高校学生、转行人员及培训机构学员通过真实数据动手演练快速构建从数据理解到清洗落地的完整能力。1. 拿到“数据清洗数据源.zip”之后先想清楚这三件事做数据的人隔三差五就会收到这类包一个 zip名字里写着“数据清洗”和“数据源”多半是同事或甲方把一堆 CSV、配置文件、脚本模板打包丢了过来。第一反应别急着解压双击跑——先想清楚这个包到底要解决什么问题。数据清洗的本质不是把数据变干净而是把多个来源的数据标准化到同一套口径上让后续统计、建模、报表不再翻车。这个 zip 大概率装的就是“喂给清洗流程的原料”和“清洗规则本身”。读这篇文章的人可能是刚接手清洗任务的初级数据工程师也可能是被困在多表合并、脏值替换里的分析师。我会带你从拆包、盘点数据源开始一路走到清洗逻辑的组织和参数调优最后落在可复验的批处理方案上。2. 拆包之前先确认文件身份压缩包不等于数据源2.1 用文件头和大小判断 zip 类型别急着解压拿到“数据清洗数据源.zip”第一步不是双击解压而是先看文件头。zip 文件的标准魔数是50 4B 03 04即PK\x03\x04用十六进制查看器或xxd前几个字节就能确认。这个习惯能帮你躲开两类坑一类是扩展名被改过的假 zip实际是 rar 或 7z另一类是 zip 伪加密——某些打包工具会把“加密标志位”置位但没真正加密内容解压时弹密码框其实换个解压参数就能绕过。文件大小也要先看。一个声称包含多数据源的 zip 如果只有几百 KB那大概率是配置模板而不是原始数据反过来几个 GB 的 zip 解压前要确认磁盘剩余空间和文件系统是否支持大文件。我一般会先执行ls -lh 数据清洗数据源.zip file 数据清洗数据源.zip unzip -l 数据清洗数据源.zip | head -50参数说明ls -lh看文件大小和修改时间修改时间能侧面反映数据源是否被更新过。file命令输出文件真实类型防止伪装的 zip。unzip -l列出 zip 内部的目录结构不解压就能看到有哪些文件避免解压出一个脏乱差的大目录。这个动作花不了十秒但能让你在解压前就知道包里有几张表、几个脚本、有没有 README。很多翻车现场都是在“先解压”之后才发现的解压出来发现 JSON 是损坏的或者 CSV 编码是 GBK 而脚本用 UTF-8 读白折腾半小时。2.2 解压后的第一轮档案盘点建一个清洗工作目录确认是正经 zip 之后解压到一个独立的工作目录别直接解压到桌面或下载文件夹。我通常按“原始数据 / 清洗脚本 / 中间结果 / 输出”四个子目录组织这样清洗流程的每个阶段都有独立空间避免把源数据误覆盖。一个顺手的三行命令序列mkdir -p ~/projects/data_cleaning/{raw,scripts,intermediate,output} unzip 数据清洗数据源.zip -d ~/projects/data_cleaning/raw tree ~/projects/data_cleaning/raw -L 2参数说明-d指定解压目标目录不指定的话会原地解压当前目录容易和项目文件混在一起。tree -L 2只展示两层目录先看整体结构再逐层深入。解压之后先找两个文件数据字典和 README。数据字典告诉你每个字段的业务含义和取值约束README 告诉你这个包是哪个业务线的、数据更新周期是什么。找不到这两样东西稍后做清洗就是在猜。如果包里有 Excel 格式的字典却打不开常见原因不是文件坏了而是 CSV 被 Excel 打开后转成了 GBK 编码后面用 Python 读取时记得指定编码。3. 把多数据源接进来入口统一了清洗才有得做3.1 先摸清数据源的类型文件源、数据库源、接口源“数据清洗数据源”这个命名的关键不在“清洗”而在“数据源”。清洗规则的复杂度多半取决于数据源的类型种类。常见的数据源有三类它们的接入方式和坑点完全不同数据源类型常见形式读取方式主要坑点文件源CSV、Excel、JSON、logpandas / csv 模块编码混杂、分隔符不一致、字段包含换行符数据库源MySQL、PostgreSQL、SQL ServerSQLAlchemy / JDBC字符集设置、空值与 NULL 混用、时间时区偏差接口源REST API、消息队列requests / websocket返回结构嵌套、限流、字段命名不稳定拿文件源来说最常见的症状就是“同一个字段上半个月是字符串下半个月是数字”。如果 zip 里只是几张 CSV问题相对可控一旦涉及数据库源SELECT出来是一回事落到 CSV 再读进来又是另一回事。接口源更麻烦字段名可能从userName变成user_name清洗脚本就会直接把新字段丢掉。所以接入阶段的目标只有一个把结构不同的数据源映射成一张统一的中间表。3.2 用 pandas 统一接入多数据源的模板不管数据源是 CSV、Excel 还是 MySQL我都习惯用 pandas 先读成 DataFrame再统一字段名。以下是一个可以抄作业的接入模板import pandas as pd from sqlalchemy import create_engine # 文件源CSV注意编码和分隔符 df_csv pd.read_csv( raw/customer_2024.csv, encodingutf-8, # 读出来乱码就试 gbk / gb18030 sep,, # 字段里有逗号时该参数会失效见下方注意 dtype{phone: str}, # 手机号等长数字列强制转字符串防止科学计数法 keep_default_naFalse, # 把空字符串和 NA 先原样保留清洗阶段再处理 ) # 数据库源MySQL 示例 engine create_engine(mysqlpymysql://user:passhost:3306/dbname?charsetutf8mb4) df_db pd.read_sql(SELECT id, name, created_at FROM orders WHERE created_at 2024-01-01, engine) # 接口源JSON 响应 import requests resp requests.get(https://api.example.com/orders, params{page: 1}, timeout10) df_api pd.json_normalize(resp.json(), record_pathdata)逻辑说明keep_default_naFalse是个容易忽略但很实用的参数。pandas 默认把空字符串、NA、N/A全部读成NaN但“空字符串”和“缺失值”在业务上含义不同清洗阶段要分开处理所以先关掉默认行为。dtype{phone: str}强制把手机号当字符串读否则 11 位数字在 pandas 里会被解析成 int64前面的 0 直接丢失。数据库查询时把过滤条件下推给 SQL 引擎而不是先全表读进来再清洗能省大量内存。这段模板解决的是“接入统一”的问题。后面无论再加什么源只要多写一个分支输出都追加到一个公共 DataFrame 列表里最后pd.concat到一张大表。3.3 数据源连接串参数不把账号密码写死在脚本里数据源一多连接串管理就成了新的脏活。常见做法是把数据库账号、端口、字符集写成配置文件脚本运行时读取环境变量或本地配置文件。不要直接写在代码里不然仓库一旦分享出去账号也跟着泄露。一个简单的 YAML 配置示例mysql_source: host: 127.0.0.1 port: 3306 user: ${DB_USER} password: ${DB_PASS} charset: utf8mb4 connect_timeout: 5 csv_source: path: raw/ encoding: auto sep: ,连接串里的connect_timeout建议设置某些数据库负载高时握手会卡很久默认 30 秒的超时会让清洗脚本在凌晨跑批时看起来像“死机”。设置成 5 秒快速失败、主动重试比干等更省心。3.4 字段再少也要做类型探测接入阶段最后一个动作是类型探测。每个字段读进来之后用df.dtypes和df.head(20)肉眼过一遍再加一条自动化检查字段的非空率、唯一率、最大最小长度。尤其是日期字段CSV 里读进来全是字符串不转成datetime64后面做去重和排序全乱套。for col in [created_at, birth_date]: df[col] pd.to_datetime(df[col], errorscoerce, format%Y-%m-%d %H:%M:%S) print(col, 解析失败行数:, df[col].isna().sum())errorscoerce的意思是解析失败的那一行置为NaT空时间。这里故意不用errorsraise因为清洗阶段本来就要处理脏日期先标出来再处理比让脚本中断更合理。但要顺手统计失败行数心里有数失败行太多说明日期格式判断错了应该先看几种样例格式再决定按什么格式解析。4. 清洗逻辑怎么组织正向洗一套、反向验一份4.1 把清洗拆成八步每步一个函数不写流水账清洗代码最常见的翻车写法是把所有操作堆在一个 DataFrame 上连续赋值去掉重、补缺失、替换脏值、删异常值全塞在一个函数里跑完也就忘记了每一步到底处理了多少行。我习惯把清洗拆成八个独立步骤每步一个函数每个函数接收 DataFrame 并返回处理后的 DataFrame 和处理日志去重按业务主键处理缺失值区分“该有而没有”和“可接受的空”格式统一日期格式、数字格式、文本大小写替换多个脏值同义词映射、枚举标准化剔除异常值按业务规则限定范围修正逻辑矛盾如订单金额为负但状态是“成功”字段派生从原始字段计算新字段抽样校对输出结果给人工复核4.2 替换多个脏值怎么写别用逐个 replace用映射表一次性解决热词里经常搜“替换多个怎么写函数”这个需求在清洗中的出现频率非常高。比如订单状态字段的值五花八门“待支付”写成了“待付”、“未支付”、“PAY_PENDING”。逐个replace会写出大量重复代码而且新值需要统一时改动很麻烦。正确的做法是建立映射表、一次替换# 定义清洗映射表 STATUS_MAP { 待付: 待支付, 未支付: 待支付, PAY_PENDING: 待支付, 支付完成: 已支付, 支付成功: 已支付, PAID: 已支付, 已取消: 已取消, null: pd.NA, # 字符串 null 视为缺失值 } def normalize_status(df): before df[status].value_counts(dropnaFalse).to_dict() df[status] df[status].replace(STATUS_MAP) after df[status].value_counts(dropnaFalse).to_dict() return df, {status_before: before, status_after: after} df, log normalize_status(df) print(log)逻辑说明replace在没有regexTrue的情况下做的是精确匹配所以“待付”和“支付完成”这种不同变体全部进映射表即可。把null字符串映射成pd.NA是为了和真正的NonePython 空对象、NaN浮点缺失值统一成 pandas 的新式缺失值后续集中处理。返回before/after分布字典这是清洗日志的核心素材。用户问“这字段怎么多了这么多已支付”时直接看分布变化就能回答不需要重新跑代码。4.3 清洗规则与原始数据分离保留一条后悔药你会注意到上面映射表是一个独立字典而不是写在函数里的魔法值。这个习惯非常重要。清洗规则是业务口径的产物它会随业务调整而变。把规则抽出来放到配置模块或 YAML 文件里改规则时不用动代码非技术人员也能维护。同时原始 DataFrame 在清洗前要保留一份df_original df.copy()防止洗完发现口径搞错时无法回退。这个“后悔药”动作在数据量不大时毫无成本却在逻辑矛盾排查时能省半天。4.4 用断言函数给清洗结果上保险清洗代码跑完不是结束结果必须能被“证伪”。我常做的做法是写几个断言检查清洗后数据是否符合预期。比如def assert_clean_result(df): # 断言1业务主键不能为空 assert df[order_id].notna().all(), 存在空订单号 # 断言2金额必须在合理区间 assert df[amount].between(0, 100000).all(), 金额超出合理范围 # 断言3状态字段只剩枚举值 assert set(df[status].dropna().unique()) {待支付, 已支付, 已取消}, 存在未知状态 # 断言4日期字段全部能解析 assert pd.api.types.is_datetime64_any_dtype(df[created_at]), created_at 未转为日期类型 print(清洗结果校验通过)参数说明断言本身就是一种验证机制断言失败时抛出的异常直接告诉你哪个业务规则被违反了。这里故意选了四个不同维度的检查空值、范围、枚举、类型。单一维度检查通过不代表数据可信多维度合起来才能算有效校验。5. 数据清洗避坑五条真实的翻车记录5.1 解压数据源 zip 后文件名全乱码现象unzip解压后文件名变成客户_订单_2024_客...打开文件内容正常但文件名没法用脚本引用。原因zip 包内记录文件名用的编码不是 UTF-8而是 GBK 或系统默认编码。Windows 上打包的文件用 macOS 或 Linux 解压容易出现这种编码错位。解决用unzip -O gbk指定解码方式或者用 Python 的 zipfile 模块手动解压并重命名import zipfile with zipfile.ZipFile(数据清洗数据源.zip) as zf: for info in zf.infolist(): # 尝试用 GBK 解码文件名 decoded_name info.filename.encode(cp437).decode(gbk, errorsreplace) zf.extract(info, raw/ decoded_name)这段代码的关键是cp437到gbk的编码链条。zipfile 默认按cp437解释文件名但要正确显示中文需要gbk解码。顺带提醒解压前先zipinfo看一眼文件名长度有时文件名乱码是被截断导致的那种情况重命名也救不回来只能重新要文件。5.2 同一份 CSV本地读出来 10 万行服务器上读出来 99000 行现象同一个数据源 zip在 Windows 本地用 Excel 打开是 10 万行放到 Linux 服务器上用 pandas 读取只有 99000 行少了 1000 行。原因CSV 文件里某些字段包含换行符Excel 能正确识别引号包裹的换行但 pandas 在某些参数组合下把\r\n内部换行误判成新记录或者最后一行缺少结尾换行符被忽略。解决读 CSV 时显式指定解析器参数df pd.read_csv( raw/orders_2024.csv, encodingutf-8, quotechar, # 引号包裹的字段内部允许换行 escapechar\\, # 部分工具用反斜杠转义引号 enginepython, # 对换行符处理更符合直觉 )参数说明默认enginec速度快但这类边角情况容易踩坑enginepython慢一些但对畸形 CSV 容错更好。验证是否读少了行用 Python 原生的csv.reader单独读一遍统计行数和 pandas 的结果对比。两个数不一致说明解析器判定记录边界的方式不同。5.3 用 drop_duplicates 去重后行数不降反升现象对订单表执行df.drop_duplicates()去重后行数反而比去重前多。原因去重前用fillna把空值补成了None而drop_duplicates把None和NaN当成不同对象处理。如果原表里既有NaN又有None它们本来被视为同一行去重时却被拆成两行——这就是“去重后变多”的真相。解决去重前先统一缺失值表示# 把所有空值形态统一为 pd.NA df df.replace([, None, null, NaN], pd.NA) # 再指定业务主键去重 df df.drop_duplicates(subset[order_id, customer_id], keepfirst) print(去重后行数:, len(df))注意指定subset比直接按全字段去重更符合业务语义。全字段去重的前提是“两行完全相同才算重复”但真实场景更常见的是“同一订单号出现多次”配合keepfirst保留第一条清洗结果更可控。5.4 用 replace 替换脏值的时候把空值也替换掉了现象执行df[status].replace({待付: 待支付})后原本为NaN的行变成了待支付。原因pandas 的replace在未指定value时对NaN的行为在不同版本里不一致。某些版本会将NaN被匹配成“空字符串”参与映射结果把缺失值覆盖成了业务值这锅背着实在冤枉。解决替换前先单独处理缺失值或者用na参数控制# 推荐写法缺失值单独标记 df[status_missing] df[status].isna() df[status] df[status].replace(STATUS_MAP) # 恢复缺失标记 df.loc[df[status_missing], status] pd.NA这段代码先记录缺失标记替换完成后把缺失值再盖回去。业务语义上脏值和缺失值是两种不同的需要前者是“有但错”后者是“本就没有”处理方式和结果检验标准完全不同。别在一行代码里同时解决否则排查时很难分清到底哪些行是被替换的、哪些行是被补值的。5.5 清洗脚本能跑但结果对不上业务报表现象清洗后的订单总额和财务部门从另一个系统导出的报表对不上差了几十万。原因两边使用的清洗规则不同。比如这边把“退款金额”从订单金额里减去了而财务报表没有或者那边单独统计了“已取消订单”而这边把它们过滤掉了。这种情况不是代码 bug是口径不一致。解决清洗脚本输出一份“规则变更说明”说白了就是before/after的统计对比表import json cleaning_report { input_rows: len(df_original), output_rows: len(df), removed_duplicates: len(df_original) - len(df), step_logs: logs, } with open(output/cleaning_report.json, w, encodingutf-8) as f: json.dump(cleaning_report, f, ensure_asciiFalse, indent2)这份报告就是对账的依据。任何数字对不上时先让两边把各自的cleaning_report拿出来逐条对比看是哪一步处理有差异。这也是我早年间踩过的坑花了一晚上排查为什么总额不一致最后发现是对方没有执行“剔除退款订单”这一条规则。6. 把清洗任务封装成批处理从一次性脚本到可持续运行清洗做到这里其实还没完真正的价值在于把整套流程固定下来、定时跑、自动验收。我会把前面所有步骤包装成一个main()入口每个阶段输出一段日志最终生成“清洗报告”并支持传入新数据文件路径作为参数。这样同一个日志文件里能看到每一批数据的处理记录后补的数据源也能沿用同一套规则。一个值得说的技巧是把清洗函数按“字段”分组而不是按“数据源”分组。同一个字段在不同数据源里出现的脏值往往高度一致比如手机号到处都有加号、横杠、空格日期到处都有“2024年1月1日”和“2024-01-01”两种写法。按字段组织清洗规则遇到新数据源时直接复用字段清洗函数比每个数据源都写一套完整流程要省事得多。字段分组的另一个好处是调整规则时只看字段的映射表就行不必翻整段代码找替换逻辑。我在自己的批次清洗脚本里维护着一个FIELD_RULES字典键是字段名值是该字段的所有清洗配置——包括缺失值策略、占位符、枚举映射、边界校验。新来的数据源只要字段名对得上清洗函数自动生效对不上的字段会记一条警告但不会让整个任务中断。最后的验证动作我会建议加一个“反向检查表”把清洗前后各字段的均值、非空率、唯一率对比打印出来人工瞄一眼就能知道有没有离谱的结构性变化。这个表格永远存放在清洗报告里不删留着给后来人当参考。写到现在回想自己接手过的清洗项目最感激的都是那些把规则和日志留下来的人。愿你也能把数据清洗这件事做得严谨、可追溯。希望帮到你。本文还有配套的精品资源点击获取
简介面向大数据应用人才与数据分析初学者的数据清洗实战数据源包聚焦数据质量评估、缺失值处理、异常值检测、一致性检查和格式转换等核心步骤解决练习时缺乏多格式真实数据的问题。压缩包共 11 个文件、约 96KB包含 3 个 SQL、2 个 CSV、2 个 TXT、1 个 XLSX、1 个 XLS、1 个 JSON 与 1 个 XML覆盖数据库脚本、表格文件和半结构化数据可满足不同清洗工具与场景的训练需求。包内涉及课程信息、学生信息、58 同城租房等多类业务数据SQL 文件便于直接建表与查询JSON/XML 可锻炼解析与嵌套字段处理TXT/CSV 则适合编码识别与分隔符清洗xlsx/xls 可用于 Excel 表格规范化和去重。目前已有 528 人学习下载适合高校学生、转行人员及培训机构学员通过真实数据动手演练快速构建从数据理解到清洗落地的完整能力。1. 拿到“数据清洗数据源.zip”之后先想清楚这三件事做数据的人隔三差五就会收到这类包一个 zip名字里写着“数据清洗”和“数据源”多半是同事或甲方把一堆 CSV、配置文件、脚本模板打包丢了过来。第一反应别急着解压双击跑——先想清楚这个包到底要解决什么问题。数据清洗的本质不是把数据变干净而是把多个来源的数据标准化到同一套口径上让后续统计、建模、报表不再翻车。这个 zip 大概率装的就是“喂给清洗流程的原料”和“清洗规则本身”。读这篇文章的人可能是刚接手清洗任务的初级数据工程师也可能是被困在多表合并、脏值替换里的分析师。我会带你从拆包、盘点数据源开始一路走到清洗逻辑的组织和参数调优最后落在可复验的批处理方案上。2. 拆包之前先确认文件身份压缩包不等于数据源2.1 用文件头和大小判断 zip 类型别急着解压拿到“数据清洗数据源.zip”第一步不是双击解压而是先看文件头。zip 文件的标准魔数是50 4B 03 04即PK\x03\x04用十六进制查看器或xxd前几个字节就能确认。这个习惯能帮你躲开两类坑一类是扩展名被改过的假 zip实际是 rar 或 7z另一类是 zip 伪加密——某些打包工具会把“加密标志位”置位但没真正加密内容解压时弹密码框其实换个解压参数就能绕过。文件大小也要先看。一个声称包含多数据源的 zip 如果只有几百 KB那大概率是配置模板而不是原始数据反过来几个 GB 的 zip 解压前要确认磁盘剩余空间和文件系统是否支持大文件。我一般会先执行ls -lh 数据清洗数据源.zip file 数据清洗数据源.zip unzip -l 数据清洗数据源.zip | head -50参数说明ls -lh看文件大小和修改时间修改时间能侧面反映数据源是否被更新过。file命令输出文件真实类型防止伪装的 zip。unzip -l列出 zip 内部的目录结构不解压就能看到有哪些文件避免解压出一个脏乱差的大目录。这个动作花不了十秒但能让你在解压前就知道包里有几张表、几个脚本、有没有 README。很多翻车现场都是在“先解压”之后才发现的解压出来发现 JSON 是损坏的或者 CSV 编码是 GBK 而脚本用 UTF-8 读白折腾半小时。2.2 解压后的第一轮档案盘点建一个清洗工作目录确认是正经 zip 之后解压到一个独立的工作目录别直接解压到桌面或下载文件夹。我通常按“原始数据 / 清洗脚本 / 中间结果 / 输出”四个子目录组织这样清洗流程的每个阶段都有独立空间避免把源数据误覆盖。一个顺手的三行命令序列mkdir -p ~/projects/data_cleaning/{raw,scripts,intermediate,output} unzip 数据清洗数据源.zip -d ~/projects/data_cleaning/raw tree ~/projects/data_cleaning/raw -L 2参数说明-d指定解压目标目录不指定的话会原地解压当前目录容易和项目文件混在一起。tree -L 2只展示两层目录先看整体结构再逐层深入。解压之后先找两个文件数据字典和 README。数据字典告诉你每个字段的业务含义和取值约束README 告诉你这个包是哪个业务线的、数据更新周期是什么。找不到这两样东西稍后做清洗就是在猜。如果包里有 Excel 格式的字典却打不开常见原因不是文件坏了而是 CSV 被 Excel 打开后转成了 GBK 编码后面用 Python 读取时记得指定编码。3. 把多数据源接进来入口统一了清洗才有得做3.1 先摸清数据源的类型文件源、数据库源、接口源“数据清洗数据源”这个命名的关键不在“清洗”而在“数据源”。清洗规则的复杂度多半取决于数据源的类型种类。常见的数据源有三类它们的接入方式和坑点完全不同数据源类型常见形式读取方式主要坑点文件源CSV、Excel、JSON、logpandas / csv 模块编码混杂、分隔符不一致、字段包含换行符数据库源MySQL、PostgreSQL、SQL ServerSQLAlchemy / JDBC字符集设置、空值与 NULL 混用、时间时区偏差接口源REST API、消息队列requests / websocket返回结构嵌套、限流、字段命名不稳定拿文件源来说最常见的症状就是“同一个字段上半个月是字符串下半个月是数字”。如果 zip 里只是几张 CSV问题相对可控一旦涉及数据库源SELECT出来是一回事落到 CSV 再读进来又是另一回事。接口源更麻烦字段名可能从userName变成user_name清洗脚本就会直接把新字段丢掉。所以接入阶段的目标只有一个把结构不同的数据源映射成一张统一的中间表。3.2 用 pandas 统一接入多数据源的模板不管数据源是 CSV、Excel 还是 MySQL我都习惯用 pandas 先读成 DataFrame再统一字段名。以下是一个可以抄作业的接入模板import pandas as pd from sqlalchemy import create_engine # 文件源CSV注意编码和分隔符 df_csv pd.read_csv( raw/customer_2024.csv, encodingutf-8, # 读出来乱码就试 gbk / gb18030 sep,, # 字段里有逗号时该参数会失效见下方注意 dtype{phone: str}, # 手机号等长数字列强制转字符串防止科学计数法 keep_default_naFalse, # 把空字符串和 NA 先原样保留清洗阶段再处理 ) # 数据库源MySQL 示例 engine create_engine(mysqlpymysql://user:passhost:3306/dbname?charsetutf8mb4) df_db pd.read_sql(SELECT id, name, created_at FROM orders WHERE created_at 2024-01-01, engine) # 接口源JSON 响应 import requests resp requests.get(https://api.example.com/orders, params{page: 1}, timeout10) df_api pd.json_normalize(resp.json(), record_pathdata)逻辑说明keep_default_naFalse是个容易忽略但很实用的参数。pandas 默认把空字符串、NA、N/A全部读成NaN但“空字符串”和“缺失值”在业务上含义不同清洗阶段要分开处理所以先关掉默认行为。dtype{phone: str}强制把手机号当字符串读否则 11 位数字在 pandas 里会被解析成 int64前面的 0 直接丢失。数据库查询时把过滤条件下推给 SQL 引擎而不是先全表读进来再清洗能省大量内存。这段模板解决的是“接入统一”的问题。后面无论再加什么源只要多写一个分支输出都追加到一个公共 DataFrame 列表里最后pd.concat到一张大表。3.3 数据源连接串参数不把账号密码写死在脚本里数据源一多连接串管理就成了新的脏活。常见做法是把数据库账号、端口、字符集写成配置文件脚本运行时读取环境变量或本地配置文件。不要直接写在代码里不然仓库一旦分享出去账号也跟着泄露。一个简单的 YAML 配置示例mysql_source: host: 127.0.0.1 port: 3306 user: ${DB_USER} password: ${DB_PASS} charset: utf8mb4 connect_timeout: 5 csv_source: path: raw/ encoding: auto sep: ,连接串里的connect_timeout建议设置某些数据库负载高时握手会卡很久默认 30 秒的超时会让清洗脚本在凌晨跑批时看起来像“死机”。设置成 5 秒快速失败、主动重试比干等更省心。3.4 字段再少也要做类型探测接入阶段最后一个动作是类型探测。每个字段读进来之后用df.dtypes和df.head(20)肉眼过一遍再加一条自动化检查字段的非空率、唯一率、最大最小长度。尤其是日期字段CSV 里读进来全是字符串不转成datetime64后面做去重和排序全乱套。for col in [created_at, birth_date]: df[col] pd.to_datetime(df[col], errorscoerce, format%Y-%m-%d %H:%M:%S) print(col, 解析失败行数:, df[col].isna().sum())errorscoerce的意思是解析失败的那一行置为NaT空时间。这里故意不用errorsraise因为清洗阶段本来就要处理脏日期先标出来再处理比让脚本中断更合理。但要顺手统计失败行数心里有数失败行太多说明日期格式判断错了应该先看几种样例格式再决定按什么格式解析。4. 清洗逻辑怎么组织正向洗一套、反向验一份4.1 把清洗拆成八步每步一个函数不写流水账清洗代码最常见的翻车写法是把所有操作堆在一个 DataFrame 上连续赋值去掉重、补缺失、替换脏值、删异常值全塞在一个函数里跑完也就忘记了每一步到底处理了多少行。我习惯把清洗拆成八个独立步骤每步一个函数每个函数接收 DataFrame 并返回处理后的 DataFrame 和处理日志去重按业务主键处理缺失值区分“该有而没有”和“可接受的空”格式统一日期格式、数字格式、文本大小写替换多个脏值同义词映射、枚举标准化剔除异常值按业务规则限定范围修正逻辑矛盾如订单金额为负但状态是“成功”字段派生从原始字段计算新字段抽样校对输出结果给人工复核4.2 替换多个脏值怎么写别用逐个 replace用映射表一次性解决热词里经常搜“替换多个怎么写函数”这个需求在清洗中的出现频率非常高。比如订单状态字段的值五花八门“待支付”写成了“待付”、“未支付”、“PAY_PENDING”。逐个replace会写出大量重复代码而且新值需要统一时改动很麻烦。正确的做法是建立映射表、一次替换# 定义清洗映射表 STATUS_MAP { 待付: 待支付, 未支付: 待支付, PAY_PENDING: 待支付, 支付完成: 已支付, 支付成功: 已支付, PAID: 已支付, 已取消: 已取消, null: pd.NA, # 字符串 null 视为缺失值 } def normalize_status(df): before df[status].value_counts(dropnaFalse).to_dict() df[status] df[status].replace(STATUS_MAP) after df[status].value_counts(dropnaFalse).to_dict() return df, {status_before: before, status_after: after} df, log normalize_status(df) print(log)逻辑说明replace在没有regexTrue的情况下做的是精确匹配所以“待付”和“支付完成”这种不同变体全部进映射表即可。把null字符串映射成pd.NA是为了和真正的NonePython 空对象、NaN浮点缺失值统一成 pandas 的新式缺失值后续集中处理。返回before/after分布字典这是清洗日志的核心素材。用户问“这字段怎么多了这么多已支付”时直接看分布变化就能回答不需要重新跑代码。4.3 清洗规则与原始数据分离保留一条后悔药你会注意到上面映射表是一个独立字典而不是写在函数里的魔法值。这个习惯非常重要。清洗规则是业务口径的产物它会随业务调整而变。把规则抽出来放到配置模块或 YAML 文件里改规则时不用动代码非技术人员也能维护。同时原始 DataFrame 在清洗前要保留一份df_original df.copy()防止洗完发现口径搞错时无法回退。这个“后悔药”动作在数据量不大时毫无成本却在逻辑矛盾排查时能省半天。4.4 用断言函数给清洗结果上保险清洗代码跑完不是结束结果必须能被“证伪”。我常做的做法是写几个断言检查清洗后数据是否符合预期。比如def assert_clean_result(df): # 断言1业务主键不能为空 assert df[order_id].notna().all(), 存在空订单号 # 断言2金额必须在合理区间 assert df[amount].between(0, 100000).all(), 金额超出合理范围 # 断言3状态字段只剩枚举值 assert set(df[status].dropna().unique()) {待支付, 已支付, 已取消}, 存在未知状态 # 断言4日期字段全部能解析 assert pd.api.types.is_datetime64_any_dtype(df[created_at]), created_at 未转为日期类型 print(清洗结果校验通过)参数说明断言本身就是一种验证机制断言失败时抛出的异常直接告诉你哪个业务规则被违反了。这里故意选了四个不同维度的检查空值、范围、枚举、类型。单一维度检查通过不代表数据可信多维度合起来才能算有效校验。5. 数据清洗避坑五条真实的翻车记录5.1 解压数据源 zip 后文件名全乱码现象unzip解压后文件名变成客户_订单_2024_客...打开文件内容正常但文件名没法用脚本引用。原因zip 包内记录文件名用的编码不是 UTF-8而是 GBK 或系统默认编码。Windows 上打包的文件用 macOS 或 Linux 解压容易出现这种编码错位。解决用unzip -O gbk指定解码方式或者用 Python 的 zipfile 模块手动解压并重命名import zipfile with zipfile.ZipFile(数据清洗数据源.zip) as zf: for info in zf.infolist(): # 尝试用 GBK 解码文件名 decoded_name info.filename.encode(cp437).decode(gbk, errorsreplace) zf.extract(info, raw/ decoded_name)这段代码的关键是cp437到gbk的编码链条。zipfile 默认按cp437解释文件名但要正确显示中文需要gbk解码。顺带提醒解压前先zipinfo看一眼文件名长度有时文件名乱码是被截断导致的那种情况重命名也救不回来只能重新要文件。5.2 同一份 CSV本地读出来 10 万行服务器上读出来 99000 行现象同一个数据源 zip在 Windows 本地用 Excel 打开是 10 万行放到 Linux 服务器上用 pandas 读取只有 99000 行少了 1000 行。原因CSV 文件里某些字段包含换行符Excel 能正确识别引号包裹的换行但 pandas 在某些参数组合下把\r\n内部换行误判成新记录或者最后一行缺少结尾换行符被忽略。解决读 CSV 时显式指定解析器参数df pd.read_csv( raw/orders_2024.csv, encodingutf-8, quotechar, # 引号包裹的字段内部允许换行 escapechar\\, # 部分工具用反斜杠转义引号 enginepython, # 对换行符处理更符合直觉 )参数说明默认enginec速度快但这类边角情况容易踩坑enginepython慢一些但对畸形 CSV 容错更好。验证是否读少了行用 Python 原生的csv.reader单独读一遍统计行数和 pandas 的结果对比。两个数不一致说明解析器判定记录边界的方式不同。5.3 用 drop_duplicates 去重后行数不降反升现象对订单表执行df.drop_duplicates()去重后行数反而比去重前多。原因去重前用fillna把空值补成了None而drop_duplicates把None和NaN当成不同对象处理。如果原表里既有NaN又有None它们本来被视为同一行去重时却被拆成两行——这就是“去重后变多”的真相。解决去重前先统一缺失值表示# 把所有空值形态统一为 pd.NA df df.replace([, None, null, NaN], pd.NA) # 再指定业务主键去重 df df.drop_duplicates(subset[order_id, customer_id], keepfirst) print(去重后行数:, len(df))注意指定subset比直接按全字段去重更符合业务语义。全字段去重的前提是“两行完全相同才算重复”但真实场景更常见的是“同一订单号出现多次”配合keepfirst保留第一条清洗结果更可控。5.4 用 replace 替换脏值的时候把空值也替换掉了现象执行df[status].replace({待付: 待支付})后原本为NaN的行变成了待支付。原因pandas 的replace在未指定value时对NaN的行为在不同版本里不一致。某些版本会将NaN被匹配成“空字符串”参与映射结果把缺失值覆盖成了业务值这锅背着实在冤枉。解决替换前先单独处理缺失值或者用na参数控制# 推荐写法缺失值单独标记 df[status_missing] df[status].isna() df[status] df[status].replace(STATUS_MAP) # 恢复缺失标记 df.loc[df[status_missing], status] pd.NA这段代码先记录缺失标记替换完成后把缺失值再盖回去。业务语义上脏值和缺失值是两种不同的需要前者是“有但错”后者是“本就没有”处理方式和结果检验标准完全不同。别在一行代码里同时解决否则排查时很难分清到底哪些行是被替换的、哪些行是被补值的。5.5 清洗脚本能跑但结果对不上业务报表现象清洗后的订单总额和财务部门从另一个系统导出的报表对不上差了几十万。原因两边使用的清洗规则不同。比如这边把“退款金额”从订单金额里减去了而财务报表没有或者那边单独统计了“已取消订单”而这边把它们过滤掉了。这种情况不是代码 bug是口径不一致。解决清洗脚本输出一份“规则变更说明”说白了就是before/after的统计对比表import json cleaning_report { input_rows: len(df_original), output_rows: len(df), removed_duplicates: len(df_original) - len(df), step_logs: logs, } with open(output/cleaning_report.json, w, encodingutf-8) as f: json.dump(cleaning_report, f, ensure_asciiFalse, indent2)这份报告就是对账的依据。任何数字对不上时先让两边把各自的cleaning_report拿出来逐条对比看是哪一步处理有差异。这也是我早年间踩过的坑花了一晚上排查为什么总额不一致最后发现是对方没有执行“剔除退款订单”这一条规则。6. 把清洗任务封装成批处理从一次性脚本到可持续运行清洗做到这里其实还没完真正的价值在于把整套流程固定下来、定时跑、自动验收。我会把前面所有步骤包装成一个main()入口每个阶段输出一段日志最终生成“清洗报告”并支持传入新数据文件路径作为参数。这样同一个日志文件里能看到每一批数据的处理记录后补的数据源也能沿用同一套规则。一个值得说的技巧是把清洗函数按“字段”分组而不是按“数据源”分组。同一个字段在不同数据源里出现的脏值往往高度一致比如手机号到处都有加号、横杠、空格日期到处都有“2024年1月1日”和“2024-01-01”两种写法。按字段组织清洗规则遇到新数据源时直接复用字段清洗函数比每个数据源都写一套完整流程要省事得多。字段分组的另一个好处是调整规则时只看字段的映射表就行不必翻整段代码找替换逻辑。我在自己的批次清洗脚本里维护着一个FIELD_RULES字典键是字段名值是该字段的所有清洗配置——包括缺失值策略、占位符、枚举映射、边界校验。新来的数据源只要字段名对得上清洗函数自动生效对不上的字段会记一条警告但不会让整个任务中断。最后的验证动作我会建议加一个“反向检查表”把清洗前后各字段的均值、非空率、唯一率对比打印出来人工瞄一眼就能知道有没有离谱的结构性变化。这个表格永远存放在清洗报告里不删留着给后来人当参考。写到现在回想自己接手过的清洗项目最感激的都是那些把规则和日志留下来的人。愿你也能把数据清洗这件事做得严谨、可追溯。希望帮到你。本文还有配套的精品资源点击获取
