为什么日志清洗不能跳过
公司服务器每天产生上万条访问日志，刚接手的小李直接拿原始数据跑分析，结果报表里全是乱码和异常IP。老板问他为什么凌晨三点流量暴增十倍，他才发现那是爬虫在疯狂试探系统漏洞。这种情况太常见了——没清洗的日志就像没过滤的自来水，直接喝肯定出问题。
第一步：统一时间格式
不同设备记录时间五花八门：有的用"2023-06-15 14:23:01"，有的写"15/Jun/2023:14:23:01 +0800"。处理时先转换成标准时间戳，Python可以用datetime模块：
import datetime
time_str = "15/Jun/2023:14:23:01"
dt = datetime.datetime.strptime(time_str, "%d/%b/%Y:%H:%M:%S")
timestamp = int(dt.timestamp())第二步：过滤明显无效数据
打开nginx.log能看到大量健康检查请求，比如"GET /health HTTP/1.1"这种每秒刷屏的记录。还有测试环境误传的调试信息，像"DEBUG: user_id=null"的条目。这些可以直接用grep过滤：
grep -v "\b(health|debug|test)\b" raw.log > step1_clean.log第三步：处理缺失字段
某些日志行可能缺少关键字段，比如用户ID为空或HTTP状态码缺失。这时候要决定是丢弃整行还是填充默认值。对于电商系统，未登录用户的user_id可以用"anonymous"代替，避免后续统计时崩掉。
第四步：标准化字段内容
同一个浏览器可能被记录成"Chrome/113.0"、"chrome 113"或"CHROME/113"。用正则统一转为小写并提取主版本号：
import re
ua = "Chrome/113.0.5678.90"
browser = re.search(r"^(\w+)/", ua, re.I).group(1).lower() # 输出chrome
version = re.search(r"/([0-9]+)", ua).group(1) # 提取113第五步：识别并处理异常编码
用户提交的搜索词可能包含UTF-8之外的字符，比如把"café"错存成"caf\xe9"。这类十六进制转义需要解码，否则词频统计会把同一个词算成两个。Linux下可用iconv命令批量转换文件编码：
iconv -f GBK -t UTF-8 corrupted.log > fixed.log第六步：去重与合并
网络抖动可能导致同一条请求被记录两次。检查方法是比对时间戳前后1秒内是否有多条相同user_id+url的记录。遇到这种情况，保留第一条，或者按业务规则取响应时间最短的那条。Shell脚本可以用awk按关键字段去重：
awk '!seen[$1$2]++' sorted.log > deduped.log实际效果对比
某次促销活动前，运维团队清洗了三天的应用日志。原始数据显示APP端转化率突然下降40%，清洗后发现是某个旧版本APP的埋点代码bug导致事件漏报。修正数据后真实转化率反而上升了15%。这说明脏数据不仅影响分析，还可能误导决策方向。