大矩阵物品协同过滤推荐系统报Kernel dead、Killed问题咨询

进程被Killed、Jupyter Kernel直接挂掉是典型的OOM（内存不足）触发系统OOM Killer强制终止进程，和协同过滤算法逻辑本身无关，核心问题是你的实现完全没有用到Spark的分布式计算能力，所有计算全在Driver节点单机运行，内存撑爆了：

• 你代码里的LabelEncoder、scipy CSR矩阵运算、自定义相似度计算、pandas DataFrame操作全是单机计算逻辑，运行时会把全量800多万条交互数据全部拉到Driver节点内存，分配给Spark Executor的资源完全没被用到
• 计算环节如果没有做稀疏裁剪，9755个商品的全量item相似度矩阵、47万用户的全量商品推荐得分矩阵会产生几十G的临时内存占用，远超普通容器默认分配的内存上限，必然被杀。

你可以根据自己的技术栈选择两种可行方案：

方案1：保留现有单机Python逻辑，优化内存占用 #

如果不想改现有代码结构，做这几个调整就能跑通：

• 调大Docker容器的内存上限，至少分配12G以上内存给运行Python进程的容器，避免被cgroup内存限制杀掉进程
• 全程保持矩阵稀疏格式，不要转稠密矩阵：计算item相似度时，每个item只保留Top20-50最相似的item，直接裁剪掉相似度极低的冗余项，相似度矩阵内存占用可以降低99%以上
• 生成推荐时不要存全量用户*商品的得分表，通过稀疏矩阵乘法直接算完就取每个用户的Top K推荐结果，不要保留中间得分矩阵
• 去掉逐列做inverse_transform的循环，直接把整列数组传入编码器批量转换，减少pandas产生的临时内存拷贝

方案2：改用Spark MLlib原生API，走分布式计算 #

既然已经部署了Spark环境，直接用MLlib的分布式推荐API，数据分散在集群节点计算，不会把压力全压在单机上，稳定性和速度都好很多，核心代码参考：

from pyspark.ml.recommendation import ALS
from pyspark.ml.feature import StringIndexer

# 分布式ID编码，替代单机的LabelEncoder
user_idx_model = StringIndexer(inputCol="CustomerID", outputCol="user_id").fit(data2)
product_idx_model = StringIndexer(inputCol="ProductId", outputCol="product_id").fit(data2)
indexed_data = user_idx_model.transform(product_idx_model.transform(data2))
# 购买行为属于隐式反馈，开启implicitPrefs参数
als = ALS(
    maxIter=10,
    rank=32,
    implicitPrefs=True,
    userCol="user_id",
    itemCol="product_id",
    ratingCol="buy_cnt", # 用购买次数/是否购买作为反馈值，没有的话所有交互赋值1即可
    coldStartStrategy="drop"
)
cf_model = als.fit(indexed_data)
# 批量给每个用户生成Top10推荐
recs = cf_model.recommendForAllUsers(10)
# 最后把索引映射回原始ID就能得到目标格式的结果

不要在Spark环境里把全量数据转成pandas DataFrame做单机计算，这种用法下Spark只充当了数据读取的角色，所有计算负载全在Driver节点，给集群加再多Executor都没用。

内容的提问来源于stack exchange，提问作者Zehra N.