如何对超百万行数据分批次应用Apriori算法解决内存分配报错

这种分片逐跑再合并的方案不是通用解法，存在明确的适用边界，直接套用很容易踩坑：

• 存在系统性计算偏差：Apriori的频繁项集判定核心是全局支持度阈值，直接逐片跑Apriori拿到的分片频繁项集，要么会混入单分片内高频、但全局总支持度达不达标的无效项，要么会漏掉单分片计数不高、但累加后够阈值的有效频繁项，最终输出的关联规则根本不准。
• 解决不了当前的内存报错根源：碰到的无法为形状为(3741, 2, 1424744)、数据类型为int64的数组分配79.4GiB内存报错，本质是Apriori生成候选项集时的笛卡尔积膨胀——如果每个分片还是沿用原来的候选项集生成逻辑，单分片内照样会生成同量级的大数组，拆片根本压不住内存占用。

只有当设置的最小支持度阈值非常高（比如高于总数据集规模的1%）时，分片频繁项集和全局频繁项集的偏差可以忽略，这时候逐片跑Apriori、合并后按全局阈值二次筛选的操作才靠谱，低支持度场景下完全不推荐这么干。

多数人在Dask上跑Apriori的操作，只是把原始数据的读取、加载环节换成了Dask DataFrame，核心的候选项集生成、匹配计算逻辑还是在单节点本地内存里串行执行——前面提到的79GiB大数组，根本没被拆成分布式计算任务，还是在单节点上生成的，自然会触发内存不足。

• 重构为两遍扫描流程：第一阶段遍历所有分片，只统计每个单项的全局出现次数，提前把全局支持度达不到阈值的低频项全部过滤掉。从报错的数组维度看，142万量级的项维度里，绝大多数都是根本过不了支持度阈值的无效项，提前过滤通常能把有效维度压掉90%以上，从根源上缩小候选项集的笛卡尔积规模。
• 改造分片计算逻辑：不要让每个分片独立跑完整的Apriori流程，要全局维护统一的项集计数器。每个分片只对第一阶段筛出来的有效项，计算所有k阶项集的出现次数，把每个分片的计数结果上报，累加出全局的项集计数后，再统一按支持度阈值筛频繁项集。这种方式算出来的结果和单机全量跑Apriori的结果完全一致，没有偏差，而且全程不会生成百万维度的稠密大数组。
• 替换存储结构：把原来存储候选项集匹配结果的稠密int64数组，换成稀疏字典结构存项集和对应计数的映射。那79.4GiB的内存占用，本质是用稠密格式存高度稀疏的匹配结果，换成稀疏结构后实际内存占用通常能降两个数量级，很多场景下几百MB就能搞定。
• 做好分布式适配：如果单节点内存还是扛不住，要手动把项集计数任务拆分给Dask的各个worker节点，每个节点只处理分配到的分片，算完只返回计数结果，不在节点间传原始数据或者大体积的中间数组。

注意：分片跑完拿到的结果不要直接取并集输出，必须经过全局支持度的统一校准，不然最后出来的关联规则准确率会完全失真。

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