如何在单Docker容器中运行PySpark并优化NLP批处理性能

这套实现的问题本质不是代码写得不好，是从架构上就把Spark用在了完全不匹配的场景上，才会出现“处理2条数据都要跑几分钟、内存占满”的异常表现：

• 固定开销占比极高：Spark的核心设计目标是处理TB/PB级别的分布式批任务，哪怕在单Docker容器里跑local伪分布式模式，初始化上下文、建立driver和executor通信、解析执行计划、序列化分发任务这些固定流程，本身就要几秒到几十秒的耗时——你单次只处理2条数据，这些框架固定开销占了总耗时的95%以上，业务本身的模型计算可能连100毫秒都用不到。
• 资源配置完全脱离实际负载：单容器本来的内存资源就有限，你给driver配8g、executor配4g，这些内存是Spark启动时就直接预留占住的，不会因为实际处理的数据只有几十KB就释放，这就是你看到“内存占用极高”的核心原因——不是业务数据吃了内存，是框架预留的闲置内存占了大头。
• 逻辑顺序存在冗余浪费：代码里是先对全量nlpRequests做模型transform，最后才过滤出需要的ESID对应数据，相当于把完全不需要的请求也全跑了一遍模型推理，平白增加了无意义的计算量。
• Arrow加速在当前负载下反而拖慢速度：你开启的PySpark Arrow优化，是为了加速大规模DataFrame转Pandas的序列化过程，但对个位数条数的小数据集来说，Arrow本身的初始化、协议协商的开销，比直接转数据的耗时还要高，属于负优化。

配置侧调整（单容器场景下砍掉无意义的框架开销） #

• 把资源配置从“分布式集群规格”降到匹配小负载的水平：
  • 原配置的spark.driver.memory 8g调整为spark.driver.memory 1g
  • 原配置的spark.executor.memory 4g调整为spark.executor.memory 1g
  • 强制设置运行模式为spark.master local[1]，不要开多线程executor，减少不必要的线程切换开销
• 关掉对小负载无用的优化和冗余服务：
  • 暂时设置spark.sql.execution.arrow.pyspark.enabled false，等单次处理数据量突破万条规模再重新开启
  • 配置spark.ui.enabled false，关掉Spark WebUI的资源占用
  • 设置日志级别为WARN：spark.log.level WARN，避免DEBUG级别的日志IO拖慢执行速度
• 最关键的配置优化：把SparkSession做成全局单例复用，不要每消费一次消息、每调用一次call_nlp函数就重新初始化Spark上下文，这一步能直接砍掉90%以上的固定启动耗时。

代码侧逻辑优化 #

• 调整过滤顺序：拿到原始dataframe之后，第一时间过滤出目标ESID对应的请求行，再调用model.transform做推理，避免对无关数据做冗余计算。
• 彻底脱离Spark链路跑小负载：如果单次从消息队列消费的批处理量始终在个位数、几十条的规模，完全可以把模型推理逻辑从Spark执行链路里拆出来——直接用Python本地调用模型接口做推理，不需要把数据套进DataFrame走Spark调度流程。这种规模的负载下，本地Python推理的速度比Spark链路快2~3个数量级，内存占用也能从十几G降到几百MB。
• 取消无意义的算子调度：当前代码里从生成dataframe、transform到toPandas的全流程，对2条数据的规模来说，Spark要走完SQL解析、逻辑计划优化、物理计划生成、任务序列化、executor执行、结果回传全链路，这些步骤的耗时本身就远高于实际的模型计算，小数据量下属于完全无意义的开销。

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