python - 在 Dask 中预先分散数据对象是否有优势？

Question

如果我在工作节点之间预先分散一个数据对象，它是否会被完整地复制到每个工作节点？如果该数据对象很大，这样做是否有优势？

使用 futures以界面为例:

client.scatter(data, broadcast=True)
results = dict()
for i in tqdm_notebook(range(replicates)):
    results[i] = client.submit(nn_train_func, data, **params)

使用 delayed以界面为例:

client.scatter(data, broadcast=True)
results = dict()
for i in tqdm_notebook(range(replicates)):
    results[i] = delayed(nn_train_func, data, **params)

我之所以这么问，是因为我注意到了以下现象:

如果我预先分散数据，delayed似乎将数据重新发送到工作节点，因此内存使用量大约增加了一倍。看起来预分散没有做我期望它做的事情，这允许工作节点引用预分散数据。

futures interface 需要很长时间才能遍历循环(明显更长)。我目前不确定如何确定这里的瓶颈在哪里。

使用 delayed界面，从时间compute()函数被调用到事件反射(reflect)在仪表板上的时间，有一个广泛的延迟，我怀疑是由于数据复制。

Answer 1

预分散旨在避免将大对象数据放入任务图中。

x = np.array(lots_of_data)
a = client.submit(add, x, 1)  # have to send all of x to the scheduler
b = client.submit(add, x, 2)  # again
c = client.submit(add, x, 3)  # and again

你会感受到这种痛苦，因为 client.submit返回会很慢，Dask 甚至可能会抛出警告。

所以相反，我们分散我们的数据，得到一个 future 的返回

x = np.array(lots_of_data)
x_future = client.scatter(x)
a = client.submit(add, x_future, 1)  # Only have to send the future/pointer
b = client.submit(add, x_future, 2)  # so this is fast
c = client.submit(add, x_future, 3)  # and this

在您的情况下，您几乎要这样做，唯一的区别是您分散数据，然后忘记它返回的 future ，然后再次发送数据。

client.scatter(data, broadcast=True)  # whoops!  forgot to capture the output
data = client.scatter(data, broadcast=True)  # data is now a future pointing to its remote value

您可以选择 broadcast或不。如果您知道您的所有员工都需要这些数据，那么这样做并不是一件坏事，但无论如何一切都会好起来的。