Python 大数据作业的资源隔离

应使用 processpoolexecutor 实现资源隔离：进程级隔离确保内存、解释器、全局变量独立；需设 spawn 启动方式、显式指定临时目录、主动管理内存生命周期，否则易致 oom 或静默错误。

用 concurrent.futures.ProcessPoolExecutor 而不是 ThreadPoolExecutor

python 的 GIL 让多线程在 CPU 密集型任务（比如大数据清洗、聚合、编码）中几乎不提速，还共享内存，容易互相干扰。资源隔离的核心是进程级隔离——每个子进程有独立内存空间、独立 Python 解释器实例、独立的全局变量和缓存。

实操建议：

• ProcessPoolExecutor 启动的是新进程，天然隔离；ThreadPoolExecutor 只是多线程，数据仍在同一地址空间里，一个作业把 sys.setrecursionlimit 改了，可能影响其他作业
• 传参必须可序列化（pickleable），避免传入类实例、Lambda、文件句柄或数据库连接对象
• 默认启动进程数为 os.cpu_count()，大数据作业常需显式设为 max_workers=2 或 3，防止内存爆满（10GB 数据 × 8 进程 = 直接 OOM）

multiprocessing.set_start_method('spawn') 必须在入口点前调用

windows 和部分 macos 环境下，默认 fork 方式会复制父进程的整个内存镜像（含已加载的大模型、缓存数据、打开的文件描述符），导致子进程启动慢、内存占用翻倍、甚至死锁。而 spawn 是干净启动新解释器，只导入必要模块，真正实现资源“从零开始”。

常见错误现象：本地跑得通，提交到集群就卡在 executor.submit(...) 不返回；或报错 RuntimeError: context has already been set。

立即学习“Python免费学习笔记（深入）”；

实操建议：

• 必须放在 if __name__ == '__main__': 下方第一行，且早于任何 import multiprocessing 以外的导入（尤其不能在 import pandas/numpy 之后）
• 如果用了 PySpark 或 Dask，它们内部也调用 multiprocessing，此时要统一 start method，否则混合使用 fork 和 spawn 会崩溃
• 注意：spawn 启动略慢，但换来的是确定性隔离——这对作业调度系统（如 Airflow、Slurm）更友好

临时目录和缓存路径必须显式指定，不能依赖默认 tempfile.gettempdir()

多个大数据作业并发运行时，若都往系统默认临时目录（如 /tmp）写中间文件，极易发生文件名冲突、权限拒绝、磁盘满等问题。更隐蔽的是：某些库（如 joblib、dask）会悄悄缓存计算结果到临时目录，不同作业相互污染。

实操建议：

• 为每个作业生成唯一工作目录：work_dir = Path('/path/to/jobs') / f'job_{os.getpid()}_{int(time.time())}'，然后设置 os.environ['TMPDIR'] = str(work_dir)
• 显式传给关键库：pandas 的 read_parquet(..., Filesystem=...) 避免走默认缓存；joblib.Memory(location=work_dir / 'cache')
• 作业结束务必清理：shutil.rmtree(work_dir, ignore_errors=True)，否则磁盘悄悄被占满，下一轮作业直接失败

内存泄漏比 CPU 超用更难察觉，重点盯住 gc.collect() 和 del 后的对象引用

大数据作业常反复读取、转换、合并 DataFrame，但 pandas/Numpy 对象背后持有大量 C 级内存，Python 的引用计数+垃圾回收不一定及时释放。一个没被清除的 df 变量，可能让整个 5GB 数据块一直驻留内存，跨作业累积后直接触发 linux OOM Killer 杀进程。

常见错误现象：单次运行内存正常，连续跑 3 个作业后第 4 个莫名 Killed；ps aux --sort=-%mem 显示 Python 进程内存持续上涨不回落。

实操建议：

• 显式删除大对象：del df; del large_array，再立刻调用 gc.collect()，不要等函数退出自动回收
• 避免闭包捕获大对象：写成 def worker(data_chunk): ... 而不是 def make_worker(big_df): return lambda x: big_df.merge(x)
• 用 tracemalloc 定位泄漏点：tracemalloc.start(); ... ; snapshot = tracemalloc.take_snapshot()，比看 top 更准

资源隔离不是加个 if __name__ == '__main__' 就完事的事。进程边界、临时路径、内存生命周期，三个地方漏一个，作业就可能在半夜三点静默崩掉——而且不会报错，只会悄无声息地少算两千万条记录。