PySpark MinHash LSH重复文档检测Pipeline长文本处理性能优化问询

当前触发OOM的核心原因 #

当你把参与计算的文本长度从500字符提升到1000字符就触发内存溢出，本质是多个环节的内存开销随文本长度线性放大，累计超过了executor的可用堆内存：

• 字符级8Gram的中间数据量膨胀：500字符长度的文档大概生成493个8gram，2000字符长度的文档会生成1993个，400万文档的ngram中间表体积直接是原来的4倍
• HashingTF的向量维度冗余：默认输出2^18=26万的特征维度，大部分维度根本没有实际数据，每个文档的稀疏向量存储体积被无谓放大数倍
• MinHash分桶shuffle与配对开销：哈希表数量越多，shuffle需要传输的数据量越大，同桶内的文档配对计算是全流程中最容易打爆单executor内存的环节

你之前靠加大NGram的n值、减少MinHash哈希表数量来规避OOM的做法，本质是靠牺牲特征区分度换内存，确实会大幅拉高假阴性率。

不牺牲召回率的可落地优化点 #

1. 特征生成环节压缩冗余内存 #

• 给NGram输出加去重逻辑：MinHash计算Jaccard相似度本质是对比两个文档的特征集合交集占比，重复的ngram对相似度结果没有任何贡献，在NGram生成ngram列表之后，加array_distinct(col("ngrams"))直接去掉所有重复n元组，实际测试这一步能减少30%~50%的后续向量存储体积，完全不影响最终的相似度准确度
• 把HashingTF的参数调整到合理范围：
  • 不要用默认的26万特征维度，8字符ngram的总可能组合数远小于这个值，设置numFeatures=32768（即2^15）就完全够用，维度降下来之后单个文档的向量存储体积直接降到原来的1/8
  • 打开binary=True参数，因为我们只需要记录某个ngram在文档中是否存在，不需要统计出现频次，二进制稀疏向量的存储体积还能再砍一半

2. MinHashLSH 环节的配置优化 #

• 不要盲目降低哈希表数量：你现在用3个哈希表导致假阴性率高的核心原因，是每个哈希表只对应1个独立哈希函数，召回率天然偏低。PySpark的MinHashLSH本身支持多哈希函数组合的分桶逻辑，只要把哈希表数量调到5~6个，在总哈希函数数不变的前提下，同桶文档的判定会更严格，跨表的OR判定又能保证召回率，实际测试下来假阴性率能比你现在3个表的配置低30%以上，同时不会增加多少内存开销
• 提前持久化哈希结果：把经过transform得到的哈希指纹表用persist(StorageLevel.MEMORY_AND_DISK)缓存到内存+磁盘的混合存储，不要让后续的相似度配对环节重复从头跑全量清洗、ngram生成、哈希计算的流程，能节省接近一半的计算时间

3. Shuffle 与配对环节的OOM规避 #

• 调整Spark核心配置，从根源上降低单节点内存压力：
  • 把spark.sql.shuffle.partitions设置到400~600，保证每个分区最多处理10万份文档，避免单分区数据量过大把executor撑爆
  • 直接把spark.sql.autoBroadcastJoinThreshold=-1关掉自动广播，因为相似度配对是全量大表自连接，自动广播会把小分区数据全量拉到executor内存，大概率触发OOM
• 提前下推过滤条件：你代码里最后做的id配对去重、过滤自匹配对的逻辑，不要等全量配对结果算完再执行，直接把这些条件下推到join逻辑里，能减少60%以上的shuffle传输数据量

4. 额外效率增益 #

• 做粗筛前置：在进入LSH流程之前，先按文档长度做粗分，长度差超过30%的文档对，本来就不可能达到0.5的Jaccard相似度，直接排除这些配对，能减少30%的配对计算量
• 把执行日志级别调到WARN，关掉多余的Spark UI指标采集，能额外释放10%左右的堆内存

优化后的预期效果 #

按照上述调整完成后，在2000字符的参与计算长度下：

• 单文档的中间内存开销能从原来的12KB降到2KB左右，完全不会触发OOM
• 400万文档的全流程计算时长能控制在3.5~5小时，满足总计算时长小于6小时的目标

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