Python内置map/reduce无法处理海量日志，因其仅支持单机内存运算，无分片、并行、容错、Shuffle等MapReduce核心能力；需用Hadoop Streaming将Python脚本作为Mapper/Reducer分布式执行。
直接用 Python 的 map 和 reduce 函数处理海量日志数据，基本不可行——它们只在单机内存里跑，遇到几十 GB 的日志会直接 OOM 或卡死。真要处理海量日志，必须借力 Hadoop Streaming，把 Python 脚本当 Mapper/Reducer 交给分布式集群执行。
为什么不能直接用 Python 内置的 map/reduce 处理日志？
Python 的 map 和 reduce 是函数式工具，作用对象是本地内存中的可迭代对象（比如列表）。日志文件一旦超过几百 MB，list(open('access.log')) 就可能撑爆内存；更别说按行解析、提取 IP/URL/状态码后再聚合统计，中间数据膨胀极快。
-
map不会自动分片，也不会跨进程/机器并行 -
reduce要求所有中间结果一次性加载进内存才能折叠，无法流式聚合 - 没有容错、重试、Shuffle 排序、键值分组等 MapReduce 核心能力
用 Hadoop Streaming 启动 Python MapReduce 的最小必要命令
真正起作用的是 Hadoop 自带的 hadoop-streaming-*.jar，它把你的 Python 脚本当黑盒进程，用标准输入输出桥接 MapReduce 框架。
关键命令结构如下：
立即学习“Python免费学习笔记（深入）”；
hadoop jar $HADOOP_HOME/share/hadoop/tools/lib/hadoop-streaming-*.jar \ -files mapper.py, reducer.py \ -mapper "python mapper.py" \ -reducer "python reducer.py" \ -input /logs/nginx/2026-06-01 \ -output /output/log_stats_20260601
-
-files必须显式列出所有依赖脚本，Hadoop 才会分发到各节点 -
-mapper和-reducer的值是 shell 命令字符串，不是文件路径 - 输入路径必须是 HDFS 路径（如
/logs/...），不能写本地./logs - 输出路径必须不存在，Hadoop 不允许覆盖
mapper.py 必须遵守的三条铁律
Hadoop Streaming 对 Mapper 的唯一要求：从 sys.stdin 读行，向 sys.stdout 写 key\tvalue 格式文本。任何额外 print、空行、编码错误都会导致整个任务失败。
- 每行输出严格用
\t分隔，不能用空格或逗号——print(f"{ip}\t1")是对的，print(ip, 1)默认空格分隔，会出错 - 必须处理异常字段：日志可能有缺失段、乱码、非 UTF-8 编码，
line.strip()后要加if len(parts) 类型守卫 - 不要在 mapper 里做复杂解析（比如正则匹配时间戳），能用
split()定位就别用re.search()——性能差一个数量级
reducer.py 如何避免 reduce 端 OOM？
Reducer 收到的数据是按 key 排好序的键值对流，但同一 key 的 value 列表可能极大（比如某个热门 URL 被访问百万次）。不能一股脑 list(values) 全读进内存。
- 用生成器逐个迭代：
for line in sys.stdin:解析每行，用字典累加计数，而不是先 collect 再 reduce - 如果要做 TopK，别用
sorted(..., key=lambda x: x[1], reverse=True)[:10]——全排序开销大，改用heapq.nlargest(10, counter.items(), key=lambda x: x[1]) - 输出前确保 key 和 value 都是字符串，
print(f"{url}\t{count}")，避免print(url, count)多余空格
最易被忽略的一点：Hadoop Streaming 默认按字典序排序 key，而你想要的“按访问量降序”必须靠 Reducer 自己实现。MapReduce 框架不负责业务逻辑排序，只保证相同 key 的 value 被发到同一个 reducer 进程——其余全是你的事。
