Git仓库分支处理场景下，如何用ThreadPoolExecutor聚合多线程DataFrame？

场景背景 #

用GitPython遍历一批Git仓库，执行浅克隆后遍历每个分支，对分支内容做指定操作，每个操作输出带固定列的DataFrame。打算用ThreadPoolExecutor并行处理，纠结三种聚合方式的优缺点：内存直接收集合并、线程写入共享DataFrame、生成CSV后再合并。

方案1：内存收集单个DataFrame后统一聚合 #

• 实现方式：每个线程处理完对应仓库/分支后，返回生成的DataFrame；所有线程执行完毕后，用pd.concat()将所有独立的DataFrame合并成一个大的DataFrame。
• 优点：
  • 全程内存操作，无磁盘IO开销，速度最快
  • 线程间无共享数据，不需要处理锁或线程安全问题，代码逻辑简单直接
  • 聚合操作集中在主线程，便于统一处理格式、缺失值等问题
• 缺点：
  • 若仓库数量多、每个分支生成的DataFrame数据量极大，会瞬间占用大量内存，可能触发内存不足
  • 必须等待所有线程跑完才能拿到最终结果，无法实时查看进度或部分结果

方案2：线程直接写入共享DataFrame #

• 实现方式：主线程先初始化一个空的DataFrame，每个线程处理完结果后，通过加锁（比如threading.Lock()）的方式，用pd.concat()或者df.loc[len(df)] = new_row将新数据写入共享DataFrame。
• 优点：
  • 可以实时聚合结果，不用等所有线程结束就能看到部分数据
  • 不需要存储中间文件，磁盘占用为0
• 缺点：
  • Pandas的DataFrame本身不是线程安全的，必须加锁保护写入操作，锁会拖慢并行效率，线程越多开销越大
  • 频繁的追加操作效率极低，每次concat都会创建新的DataFrame对象，还会产生内存碎片
  • 代码复杂度上升，需要手动处理锁的获取和释放，容易出现死锁、数据覆盖等问题

方案3：生成单个CSV文件后合并 #

• 实现方式：每个线程处理完仓库/分支后，将对应的DataFrame写入单独的CSV文件（可以按仓库+分支命名）；所有线程执行完毕后，批量读取所有CSV文件，用pd.concat()合并成最终DataFrame。
• 优点：
  • 内存占用最低，每个线程只需要处理当前任务的DataFrame，写完文件就释放内存，适合处理超大规模数据
  • 线程间完全独立，没有共享状态，不存在线程安全问题
  • 中间CSV文件可以保留，方便后续排查问题、重新聚合或者单独分析某仓库/分支的数据
• 缺点：
  • 存在磁盘IO开销，速度是三个方案里最慢的，仓库数量越多越明显
  • 需要额外管理临时文件，比如创建临时目录、清理过期文件，增加了代码的维护成本
  • 若磁盘空间不足，会导致写入失败，需要额外处理异常

内容的提问来源于stack exchange，提问作者iwonder