光学并行度答案

【问题标题】：OPTICS parallelism光学并行度
【发布时间】：2020-05-03 01:32:19
【问题描述】：

我有以下脚本 (optics.py) 来估计具有预先计算距离的聚类：

from sklearn.cluster import OPTICS
import numpy as np

distances = np.load(r'distances.npy')
clust = OPTICS(metric='precomputed', n_jobs=-1)
clust = clust.fit(distances)

查看 htop 结果我可以看到只使用了一个 CPU 内核

尽管 scikit 在多个进程中运行集群：

为什么n_jobs=-1 没有导致使用所有 CPU 内核？

【问题讨论】：

您可以查看：joblib.readthedocs.io/en/latest/…
@PV8 joblib 上下文在这里如何关联？ OPTICS 中 n_jobs 参数的 documentation 表示：“为邻居搜索运行的并行作业数。无表示 1，除非在 joblib.parallel_backend 上下文中。-1 表示使用所有处理器。”。我没有使用任何 joblib.parallel_backend 上下文，所以我希望 -1 使用所有 CPU 内核。除非有错误或某些限制。
在该文本的后面还提到他们仍在研究它，并且有一个 github 链接列出所有错误，我认为有一个错误
HDBSCAN 在此期间可能是一个不错的选择。两种方法都试图解决相同的问题（具有可变集群密度的 DBSCAN），并且 - 至少在我手中 - 通常会给出非常相似的结果。 HDBSCAN 实现目前使用up to 4 cores。

标签： python numpy scikit-learn optics-algorithm

【解决方案1】：

我是 sklearn OPTICS 模块的主要作者。并行是困难的，因为有一个不能并行运行的排序循环；也就是说，计算量最大的任务是距离计算，这些可以并行运行。更具体地说，sklearn OPTICS 一次计算一行上三角距离矩阵，从“n”个距离查找开始，然后减少到“n-1，n-2”个查找，总共 n-squared / 2 距离计算。 ..问题是sklearn中的并行性通常由joblib处理，它使用进程（而不是线程），当在循环中使用时，创建和销毁的开销相当高。（即，您在遍历数据集时创建和销毁每行的进程工作者，并且进程的“n”个设置/拆卸具有更多的开销，然后您从 joblib 获得的并行性好处——这就是为什么 njobs 对 OPTICS 被禁用的原因)

在 OPTICS 中“强制”并行性的最佳方法可能是定义一个并行运行的自定义距离度量 - 请参阅这篇文章以获得一个很好的示例：

https://medium.com/aspectum/acceleration-for-the-nearest-neighbor-search-on-earths-surface-using-python-513fc75984aa

上述示例中的一个实际上将距离计算强制到 GPU 上，但仍使用 sklearn 执行算法。

【讨论】：

能否请您对这个光学问题给出提示？ stackoverflow.com/q/66682120/9404261

【解决方案2】：

OPTICS 和 HDBSCAN 都缺乏并行化。它们本质上都是顺序的，因此不能像 DBSCAN 那样传递到简单的 joblib.Parallel 上。

如果您希望提高速度，HDBSCAN 的优势之一是能够创建推理模型，您可以使用该模型进行预测，而无需再次运行整个集群。这就是我用来避免每次需要对数据进行分类时都运行非常慢的集群操作的方法。

【讨论】：

【解决方案3】：

我也面临这个问题。根据一些论文（例如this，参见摘要），OPTICS 因其顺序性而被称为并行执行它具有挑战性。因此，当您使用 n_jobs=-1 时，sklearn 可能会尝试使用所有内核，但在额外的内核上没有任何东西可以运行。

您可能应该考虑其他对并行性更友好的聚类算法，例如 cmets 中的@paul-brodersen 建议使用 HDBSCAN。但是好像sklearn没有这种并行的光学替代方案，所以你需要使用其他的包。

【讨论】：