数据分析实战：数据收集与清洗全流程指南（附pandas代码）

做数据分析这几年我最大的一个感受是真正让你熬夜到凌晨的往往不是模型跑不出结果而是手里的数据脏到让你怀疑人生。市面上的“数据分析学习大纲”一抓一大把但很多一上来就直接教 Python、讲可视化、上机器学习把最要命的数据收集和数据清洗轻描淡写带过了。可你去问任何一个有三年以上经验的数据分析师他都会告诉你一个商业数据分析项目里数据收集和数据清洗通常要占用六成以上的时间真正做分析和出结论反而可能只需要几行代码。所以这篇大纲我想把“数据收集与清洗”这部分单独拎出来按我实际做项目的执行顺序把数据从哪来、到手里怎么体检、用什么姿势洗干净、中间踩过哪些坑一条线完整讲透。核心就围绕三个词数据分析、数据收集、数据清洗。适合正在学 Python 数据分析的初学者也适合已经做过一两个项目但流程还比较乱的从业者你可以把它当成一份能直接照着做的操作手册而不是那种收藏完就吃灰的目录。1. 数据收集先解决“数据从哪来”这个根本问题很多人做数据分析项目第一步就卡在没数据。这不是你能力不行而是大多数教程默认你手里已经有一份漂亮的 CSV。现实里数据往往散落在各个系统、各个平台甚至根本不存在需要你自己想办法搞到手。1.1 三种数据来源与适用场景我一般把数据来源分成三类它们的获取方式、可信度和清洗难度完全不同。一类是内部业务数据比如公司数据库、数据仓库、埋点日志。这类数据质量相对可控字段含义有业务文档支撑但缺点是想拿到权限往往要走流程而且不同部门对同一个字段的定义可能都不一样。比如“用户”到底是注册用户、活跃用户还是付费用户口径不统一后期清洗时非常容易踩坑。另一类是公开数据集比如政府统计部门发布的开放数据、数据竞赛平台的公开数据集Kaggle、天池这类、行业报告附带的表格。这类数据好处是拿起来就能用适合练习和学习坏处是质量参差不齐字段缺失、编码混乱、更新时间不明确是家常便饭你得自己花时间做“数据预处理之数据清洗”的整套流程。还有一类是接口采集和爬虫抓取。通过 API 获取是最规范的路径数据以结构化格式返回字段含义也相对清晰爬虫则是最后的手段能拿到别的渠道拿不到的数据但稳定性差、维护成本高还可能涉及合规问题。我建议初学者优先练前两类第三类单独抽时间系统学不要在项目刚开始时让它拖慢你的主线。1.2 挑选公开数据集的四个判断标准既然公开数据集是练手的主力我分享几个自己的选择标准。第一看有没有字段说明文档。一份连字段含义都不写清楚的数据集你再有本事也得靠猜清洗起来事倍功半。第二看数据的采集周期和更新频率。如果是做用户行为分析数据是十年前采集的结论基本没有现实参考价值。第三看样本量。几百条数据练练语法还行想得出可信的结论根本不现实至少也得几千条起步。第四看数据脱敏程度。尤其是医疗健康数据分析、金融数据分析这类项目如果数据里带着明显的个人信息且没有做脱敏处理我建议直接换一份这不仅是技术问题也是责任问题。网上常有人把“旅游网站大数据分析 - 数据清洗”这类项目当练习题这种场景数据不复杂但订单金额、用户来源、入住时间这些字段里会藏非常多坑非常适合刚入门的人拿来练手。1.3 API优先、爬虫兜底采集工具怎么选如果你决定通过接口采集数据我建议用 Python 的 requests 库就够了不需要一上来就引入太重的框架。核心流程就是拼参数、发请求、解析返回结果、落盘。这里给一个简单的示例框架import requests import pandas as pd import time url https://api.example.com/v1/order/list params { start_date: 2024-01-01, page: 1, page_size: 100 } headers {Authorization: Bearer YOUR_API_TOKEN} all_data [] for page in range(1, 21): params[page] page resp requests.get(url, paramsparams, headersheaders, timeout10) if resp.status_code ! 200: print(fpage {page} 请求失败: {resp.status_code}) break items resp.json().get(items, []) if not items: break all_data.extend(items) time.sleep(0.5) # 注意限流别把接口打挂了 df pd.DataFrame(all_data) df.to_csv(raw_data.csv, indexFalse, encodingutf-8-sig)这段代码里我特意加了 time.sleep(0.5)就是想提醒你很多接口都有访问频率限制不加节流地连续请求很快会被封掉或者限流。另外解析返回值时别只取字典里内容先用 resp.json() 看看真正的字段结构是什么再决定怎么落表。爬虫的逻辑其实和 API 类似只是多了解析 HTML 这一步。我的经验是如果目标网站存在底层接口很多网站的列表页都有接口优先抓接口不要用浏览器自动化框架硬来后者速度慢、耗资源、还容易被反爬策略识别。爬虫的数据很容易带进来大量无关标签后面清洗环节里“清洗 HTML 文档中无意义数据”基本是躲不掉的。2. 拿到数据先别急着洗数据体检与业务口径数据刚到手里最重要的一件事不是立刻写清洗代码而是先摸清文件里到底有什么。很多人一上来就 dropna、fillna结果把有价值的样本全删了回头发现数据量急剧缩水但根本不知道原因。2.1 四行代码完成数据体检我自己拿到任何一份数据都会先用 pandas 做一套固定动作基本上四行代码就能把数据的情况摸个大概import pandas as pd df pd.read_csv(raw_data.csv, encodingutf-8-sig) print(数据形状, df.shape) # 行列数先心中有数 print(字段列表, df.columns.tolist()) # 看看有没有乱码列名 print(df.info()) # 每列的类型、非空值数量 print(df.describe()) # 数值列的分布统计量很多人忽略 df.info() 的输出其实这是发现问题最快的方式。比如一个“用户年龄”列info 显示它的 dtype 是 object 而不是 int那基本可以确定里面混了文本或异常字符再比如“下单时间”列的非空数量明显少于其他列说明这里存在缺失值。df.describe() 则能帮你快速看出数值列的大致范围和均值是否合理比如“订单金额”最小值为负数、最大值为几千万这种一眼就能看出异常的数据就是后面清洗时需要特别关注的对象。除了这几行我还会顺手看一下缺失情况print(df.isnull().sum())如果有列的缺失数量非常多比如超过总数的一半那这列基本进入“考虑删除”的候选列表。体检这一步不复杂但能帮你建立对数据集的整体感知避免清洗时盲目操作。2.2 清洗之前先对齐业务口径这一步看起来跟“代码”无关但我认为它是整个数据清洗过程中最容易翻车的地方。技术手段只能帮你识别“格式不对”的数据而“值不对”的数据必须靠业务知识判断。举个例子电商订单表里订单金额出现负数能不能直接当异常值删掉如果直接删退款的订单就没了如果全保留统计销售额时又把退款算进去了。正确做法是先确认这个字段的定义它到底是支付金额、退款金额还是净额再决定清洗策略。再比如“年龄”列出现 0 或 200大概率是录入错误但“用户停留时长”为 0 可能只是用户秒退并非脏数据。很多初学者上来就把这些值用 mean 或者 0 抹掉反而把真实业务信息清洗没了。所以我的习惯是在处理任何字段之前先找出项目文档、数据字典或者业务方把口径问清楚。如果实在没有文档就先用分组统计看看异常值的分布不要急着下结论。数据分析的学习曲线里这属于最容易被忽略但作用又极大的一环尤其是在做金融数据分析、风控数据分析这类对数字敏感的项目时。3. pandas实操数据清洗六大步一步都不能少数据体检做完进入核心环节。我把日常数据清洗流程归纳成六个步骤每一步都有明确的动作和适用场景你可以按顺序执行也可以根据数据情况只挑需要的部分来做。3.1 缺失值处理删除、填充和标记的边界缺失值是最常见的脏数据形态但处理方式不能一概而论。我的判断依据是缺失率。如果某列缺失率低于 5%并且该列不是关键字段直接丢弃这些行问题不大。如果缺失率在 5% 到 30% 之间更稳妥的做法是填充。数值列优先用中位数而不是均值因为均值容易受极端值影响——比如订单金额列里有一个超大额订单均值会被拉得很高而中位数更稳。分类列可以填“未知”或众数但要小心众数填充会让该类别占比虚高尤其是在做分布分析时这种影响会被放大。如果缺失率超过 50%通常我会选择删除该列除非它确实是核心字段这时候必须跟业务方确认缺失的具体原因。# 查看缺失率 missing_rate df.isnull().mean().sort_values(ascendingFalse) print(missing_rate) # 删除缺失率超过50%的列 drop_cols missing_rate[missing_rate 0.5].index df.drop(columnsdrop_cols, inplaceTrue) # 数值列用中位数填充 df[age] df[age].fillna(df[age].median()) # 分类列填充“未知” df[city] df[city].fillna(未知) # 时间序列数据可以向前填充 df[price] df[price].ffill()除了删和填还有一种操作叫“标记”。有时候缺失本身也是一种信号比如用户没有填写职业信息这可能和用户身份有关。你可以新建一列 is_missing 标记缺失状态再把原始列填充掉这样模型或分析时既能利用其他字段又不会丢失“缺失”这个信息。3.2 重复值处理去重键选不对结果就错了重复值处理看起来最简单一个 drop_duplicates 就完事但真正的坑在“去重键怎么选”。如果不指定 subset 参数pandas 会认为整行完全相同才是重复这在很多场景下不够用。比如用户行为日志里同一个人可能今天点了两次、明天又点了一次行的其他字段不同但用户 ID 是重复的。如果按用户 ID 去重你想得到的是“唯一用户数”如果按时间加用户 ID 一起去重你想得到的是“独立访问明细”两种需求对应的 subset 完全不一样。我自己在项目里常用的方式是先查重复情况再决定# 统计整行重复数 print(df.duplicated().sum()) # 按业务主键去重保留最后一条 df.drop_duplicates(subset[order_id, user_id], keeplast, inplaceTrue)如果你不确定去重后数据量会不会剧烈变化可以先跑一下 df.duplicated(subset[...]).sum() 看看重复量心里有数再执行。直接无脑去重最后发现数据少了一半排查起来是非常痛苦的。3.3 异常值处理先问业务再谈删除异常值分两种一种是录入错误造成的比如身高 280 cm一种是真实但极端的值比如促销活动期间订单量暴涨 10 倍。后者如果被当作异常值清洗掉了分析结论必然失真。我常用的两种定量判断方法是 3σ 法和 IQR 法。3σ 法把超出均值左右三倍标准差的点视为异常IQR 法用四分位距来判断把低于 Q1-1.5IQR 或高于 Q31.5IQR 的点视为异常。代码都能写得很简单# 3σ法 mean, std df[sales].mean(), df[sales].std() df_normal_3sigma df[(df[sales] mean - 3 * std) (df[sales] mean 3 * std)] # IQR法 q1, q3 df[sales].quantile(0.25), df[sales].quantile(0.75) iqr q3 - q1 df_normal_iqr df[(df[sales] q1 - 1.5 * iqr) (df[sales] q3 1.5 * iqr)]但在我做过的真实项目里我很少直接执行上面任何一行清洗代码当作最终结果。我会先通过箱线图或 describe 找出异常样本打印出来看它是不是某种业务规律。正常的做法是先把异常区间标记出来新建一个列如 is_abnormal然后带着这些样本去找业务方确认是数据采集错误还是业务本身有极端波动确认后在前决定是删除是保留还是单独分析。金融和风控领域尤其如此一笔看似异常的大额交易可能才是真正值得分析的重点。3.4 文本清洗与批量替换正则和自定义函数是主力文本脏数据常见的问题包括首尾空格、连续空格、混入 HTML 标签、全角半角不统一、同一含义的多种写法等。pandas 的 str 方法配合正则表达式可以解决九成问题。# 去除首尾空格 df[title] df[title].str.strip() # 去除HTML标签 df[title] df[title].str.replace(r[^], , regexTrue) # 合并连续空格 df[title] df[title].str.replace(r\s, , regexTrue) # 统一城市写法 df[city] df[city].replace({北京: 北京市, 上海: 上海市})这里特别说一下网上经常有人问的“替换多个怎么写函数”这个点。这个问题的准确答案是有多种写法取决于你的替换规则。如果是简单的等值映射用字典传给 replace 是最省事的上面第三段代码就是例子。但如果替换规则复杂比如你需要根据是否包含某个关键词来决定替换结果或者需要清洗后再映射那更稳的方式是写一个自定义函数配合 apply 使用def clean_city(x): if pd.isna(x): return 未知 x str(x).strip() if x in [None, , NULL, null, nan]: return 未知 if x in [北京, 北京市, BJ, 010]: return 北京市 if x in [上海, 上海市, SH, 021]: return 上海市 if 广州 in x or GZ in x: return 广州市 return x df[city] df[city].apply(clean_city)这种写法最好维护因为每一条规则都是显式的而且可以处理“多个条件同时存在”的情况也是我自己的首选方案。遇到文本里夹杂复杂格式时善用正则表达式并配合 str.extract 或 str.contains往往能起奇效。3.5 类型转换与日期统一脏数据一大半是格式问题在 pandas 里最常见的类型问题有两种日期被识别成字符串、数值里混入了千分位逗号或货币符号。这两类问题处理不好后面做可视化、做时间序列分析时会反复报错。日期统一处理代码很简单df[order_time] pd.to_datetime(df[order_time], errorscoerce)注意 errorscoerce 这个参数非常重要。它的意思是解析失败时直接置为 NaT而不是报错中断。如果不用这个参数一条异常日期格式可能让整段代码崩溃。解析完之后可以再单独看看有多少 NaT如果占比很小就填充或删除如果占比很大就要回去检查源文件里的日期格式到底有几种。数值类型的处理类似# 把“1,234.56”这种千分位字符串变成数值 df[amount] pd.to_numeric(df[amount].str.replace(,, ), errorscoerce) # 把分类型字段显式转换为category节省内存 df[channel] df[channel].astype(category)列类型统一后的好处不只是方便计算。比如 channel 字段转成 category 类型后后续 groupby 和 value_counts 的性能会提升同时在内存占用上也有直观的改善。这种优化在大数据集上感受尤其明显。3.6 字段命名与编码规范前期不顺手后期很痛苦清洗数据时顺手把字段名统一成小写加下划线的风格是我个人的强烈建议。比如把“用户ID”改成 user_id、“下单时间”改成 order_time。这个动作不直接提升分析质量但能让后续所有代码少很多麻烦df.rename(columns{用户ID: user_id, 下单时间: order_time}, inplaceTrue)还有一个特别容易被忽略的编码问题。用 pandas 读写 CSV 文件时如果你的数据里有中文读入时建议用 encodingutf-8-sig而不是 utf-8。原因在于 Windows 下 Excel 保存的 CSV 常常带 BOM 头用 utf-8 直接读会出现首列名称前面带乱码符号的问题。如果读入还是乱码再尝试 encodinggbk 或 encodinggb2312这两类编码在国内数据文件里非常常见。这个细节看起来小但几乎每个入门 pandas 数据清洗的人都会碰到。4. 不写代码也能清洗Excel和SQL的实用打法不是所有数据清洗场景都适合写 Python。数据量小的时候Excel 的效率高到惊人数据量大的时候直接在数据库里清洗比导出到本地再用 pandas 处理要快得多。这两种路径是 Python 的有效补充。4.1 Excel清洗五件套小数据量效率惊人如果你手里的数据是几千行、几十列用 Excel 手工清洗几分钟就能搞定。第一个功能是分列适用于时间字段和一列里塞了多个信息的情况。第二个是删除重复项在“数据”选项卡里直接操作跟 pandas 的 drop_duplicates 效果一样。第三个是 TRIM 函数专门处理首尾空格等价于 strip。第四个是查找替换配合通配符可以批量修正一些固定规则的问题字符。第五个是条件格式把空值、异常值、重复值高亮出来肉眼扫一眼就能定位问题区域。我特别推荐在 Excel 里用 IFERROR 加 VLOOKUP 的组合来做字段映射。比如订单表里的“渠道编号”是一串编码你想映射成“自然搜索”“广告投放”“人工推广”这样的可读名称只需要建一张映射表再用 VLOOKUP 关联即可。这个思路和 pandas 里的 merge 是一样的逻辑但操作门槛低很多。用 Excel 做清洗时的原则是所有操作都要结果可控做完后另存为一个清洗后的新文件不要直接覆盖原始文件万一洗错了还能回退。4.2 SQL清洗三板斧大数据量优先在库内处理当数据量大到几个 G 甚至几十个 G 时用 pandas 读进本地内存动不动就卡死这时候直接在数据库里用 SQL 清洗几乎是唯一理性的选择。我常用的 SQL 清洗手段可以归纳成三板斧。第一板斧是 COALESCE 处理空值把 NULL 替换成默认值。第二板斧是用 DISTINCT 或 ROW_NUMBER 窗口函数做去重按业务主键分组后保留最新一条记录。第三板斧是用 CASE WHEN 做字段映射和状态标准化。一个典型的 SQL 清洗示例SELECT COALESCE(user_id, UNKNOWN) AS user_id, MAX(create_time) AS latest_time, CASE WHEN status IN (1, paid, PAID) THEN 已支付 WHEN status IN (0, unpaid, UNPAID) THEN 未支付 ELSE 未知状态 END AS status_label FROM orders GROUP BY user_id;这个查询做了三件典型的事填充空值、按用户聚合去重、把状态值映射成统一标准。放到 pandas 里做同样的事不是不行但在数据量大的时候SQL 几乎不用考虑内存问题直接跑在数据库引擎里效率是数量级的差距。做数据分析与数据挖掘实战项目时我倾向于把清洗尽量前移能在 SQL 里处理完的就不拖到 Python 里再处理。5. 常见问题排查与避坑记录分享一些我在实际项目中反复遇到、并且大概率你也会踩的坑。这一节先整理一个速查表再挑几个真实场景展开说。5.1 高频坑位速查表现象可能原因排查思路与解决方式中文乱码CSV编码不一致尝试 utf-8-sig、gbk、gb2312 逐个测试Excel时间变成44562时间被存成序列号需按 1899-12-30 作为起始日转换清洗后对不上业务数去重键或过滤条件不完整先分组输出中间结果再逐层核对明明删了空值还有空行字段里混入空格或不可见字符先 str.strip() 再判空内存爆掉数据量大且读入全字段分批读入、只选所需列、压缩dtype替换多个条件后结果混乱多种规则串行执行覆盖改用自定义函数统一处理缺失值删完数据量骤减缺失率太高删除策略太激进先算缺失率再考虑填充或标记5.2 几个真实场景的排查思路第一个经典场景是“读取 Excel 导出的 CSV 时日期列变成一串数字”。这是 Excel 的日期序列值常规解析方式是根据它的起始日期做偏移换算。在 pandas 里处理比较简单尝试用 pd.to_datetime(df[date], unitD, origin1899-12-30) 转换基本能还原。但更省事的做法是从根源上避免导出前先把 Excel 里的日期列设置成文本格式。第二个场景是“清洗完的数据和业务方统计的总数对不上”。大多数情况下差异出在去重键或过滤条件上。比如你统计用户数时按 user_id 去重但业务方统计的是注册用户数注册用户的定义可能只包含状态为“已激活”的用户而你包含了所有状态。这种问题不是代码 bug而是口径不一致解决方式就是回到业务口径那一步再核对一遍。第三个场景是内存爆掉。数据量一大pandas 默认全列读入非常容易把内存吃满。我的常规方案是读入时指定 usecols 只取所需列再通过 dtype 参数把能降的精度降下来比如一个大整数列用 int32 而不是 int64内存直接砍半。如果数据实在太大用 chunksize 分块读取处理完再汇总。Python做数据分析与可视化时这个问题会在数据量上来后突然出现提前做好准备能省很多麻烦。第四个场景是分析的项目里涉及敏感字段比如手机号、身份证号、医疗记录。数据清洗阶段就要做脱敏处理不能把原始字段完整保留在中间文件里。常用的做法是对敏感字段做哈希打码、掩码展示或者干脆在清洗早期就丢弃不需要的敏感列。做医疗健康数据分析毕业设计之类的项目时这一点尤其需要提前规划。最后再说一个我自己踩过很多次才长记性的坑清洗步骤必须留痕。每执行一个删除或填充动作我都会顺手把处理的行数和规则记录在一个 markdown 文件里甚至把每步处理前后的 DataFrame 形状打印出来。这样一旦发现清洗结果不符合预期能快速判断是哪一步引入的问题。数据分析不怕脏数据怕的是脏得没有记录、没有规则。你清洗的过程越透明后续分析和向别人解释结论时就越省力。