为什么无论数据帧大小如何，dask 都需要很长时间来计算

Question

无论数据帧大小如何，dask 数据帧都需要很长时间来计算的原因是什么。 如何避免这种情况的发生？其背后的原因是什么？

编辑：

我目前正在使用 ml.c5.2xlarge 实例类型使用 AWS Sagemaker，数据位于 S3 存储桶中。 我没有连接到客户端，因为我无法连接到。当我通过本地集群运行客户端时出现此错误 --> AttributeError: MaterializedLayer' 对象没有属性 'pack_annotations'

因此，我在没有连接任何特定内容的情况下继续操作，现在它处于默认状态。 （集群，工作线程：4，核心：8，内存：16.22 GB）

shape = df.shape
nrows = shape[0].compute()
print("nrows",nrows)
print(df.npartitions) 

我尝试对 24700000 条记录（~27M）执行计算，有 23 个分区，执行时间为 CPU时间：用户4分钟48秒，系统：12.9秒，总计：5分钟1秒 Wall time: 4min 46s

对于 nrows 5120000 (~5M)，有 23 个分区，执行时间为 CPU times: user 4min 50s, sys: 12 s, Total: 5min 2s Wall time: 4min 46s

对于 nrows 7697351 (~7M) with 1 Partition, 花费的时间为 CPU时间：用户5分钟4秒，系统：10.6秒，总计：5分钟14秒 Wall time：4min 52s

我在 Pandas 中用 7690000 (~7M) 执行了相同的操作，执行时间为 CPU 时间：用户 502 µs，系统：0 ns，总计：502 µs 挂起时间：402 µs 对于上述所有情况，列数仍然为 5，

我只是想找到数据的形状，但在 Dask 中，无论操作类型如何，dask 都花费相同的时间来执行一项计算操作。

我可以知道这背后的原因是什么以及我需要做什么来避免这种情况并优化计算时间

Answer 1

一般来说，给定的计算将具有可以分布（并行）的部分和必须顺序完成的部分，请参阅 阿姆达尔定律。如果给定的算法具有较大的串行组件，那么分布/缩放的收益将会很小。

在不知道任务图的具体情况的情况下，很难说到底是什么导致了瓶颈，但更广泛地说，即使输入相对较小，也可能有几个导致性能缓慢的原因：

• 生成大量分区或涉及跨多个分区的通信的计算（例如排序、对分类列进行一致编码）；
• 慢速 IO（例如，如果必须通过使用慢速网络连接轮询远程数据库来构建数据帧）；
• 涉及具有固定构建成本的模拟的计算（例如，如果数据帧是应根据必须为多个种子构建的特定随机图进行检查的边列表）。

上面列出的原因仍会随着数据而扩展，因此这并不完全是您问题的答案（“无论数据帧的大小如何”），但可能会有所帮助。

为了解决（或避免）这个问题，人们通常必须检查算法/代码，识别性能瓶颈，弄清楚它们是否可以并行化或者它们本质上是否是串行的。

Answer 2

dask 数据帧花费更多时间来计算（形状或任何操作）的原因是，当调用计算操作时，dask 尝试执行从当前数据帧或其祖先的创建到调用compute() 的操作。

在问题中提出的场景中，dask 尝试从 S3 存储桶读取数据（从 s3 存储桶读取数据需要相当长的时间）。因此，当调用compute（以查找形状或任何其他操作）时，dask 尝试执行从 s3 读取 csv 数据文件的所有操作，这会增加执行时间。

应尽量少用compute()，但如果任何形式的计算操作都必须在当前或其子数据帧上一遍又一遍地执行，则保留数据帧会有所帮助。 persist() 允许数据存储在分布式内存中，因此它不会执行其祖先的所有操作，而是从数据保存的位置执行。