这项工作得到了 Anaconda Inc. 的支持。

历史

在 Dask 诞生后的第一年，它完全专注于单节点并行性。当时我们认为，在个人笔记本电脑上高效支持 100GB+ 数据集或在大型工作站上支持 1TB 数据集是提高工作效率的最佳选择，尤其是在避免部署和配置分布式系统的痛苦时。我们仍然相信单节点并行性的效率，但这些年来，Dask 已经扩展到支持更大的分布式系统。

第一年之后，Dask 开始同等重视单节点并行性和分布式并行性。我们维护了 两个完全独立的调度器，每个都针对一种情况进行了优化。这使得 Dask 在单机上非常易于使用，同时在需要时也能用相同的 API 扩展到数千个节点和 100TB+ 数据集。

Dask 的分布式系统有一个中心调度器和许多分布式工作节点。这是当今一种常见的架构，可以扩展到几千个节点。大致来说，Dask 的扩展能力与 Apache Spark 等系统相似，但不如 MPI 等高性能系统。

一个例子

博客文章或演讲中大多数 Dask 示例都在中等规模的数据集上，通常在 10-50GB 范围内。这一点，再加上 Dask 在单节点中等数据方面的历史，可能让人们对 Dask 的印象比实际情况要谦逊得多。

作为一个小小的提示，这里有一个使用 Dask 与人工创建的太字节数据集上的 50 个 36 核节点进行交互的示例。

对于一个典型的中等规模 Dask 集群来说，这是一个常见的规模。我们通常看到的 Dask 部署规模要么在几十台机器（通常是 Hadoop 风格或临时企业集群），要么在几千台（通常是高性能计算或云部署）。我们在这里展示中等规模的例子仅仅是因为资源有限。该示例中的所有内容都应该可以在再扩展几个数量级时正常工作。

横向扩展的挑战

本文其余部分将讨论我们今天看到的阻碍横向扩展的常见原因。这些原因收集自与开源社区成员以及私有合同合作的经验。

简单的 Map-Reduce 风格

如果您正在进行简单的 Map-Reduce 风格并行计算，那么扩展到大量节点会非常顺畅。但是，仍有一些需要注意的限制：

1. 调度器将至少与每个工作节点建立一个（可能几个）连接。您需要确保您的机器可以同时打开许多文件句柄。某些 Linux 发行版默认将其限制为 1024，但这很容易更改。
2. 调度器的每个任务开销约为 200 微秒。因此，如果每个任务需要一秒钟，调度器可以饱和 5000 个核心；但如果每个任务只需要 100 毫秒，调度器只能饱和大约 500 个核心，依此类推。任务持续时间对扩展施加了反比限制。
3. 如果您想扩展到更大规模，您的任务需要开始在每个任务中做更多工作以避免开销。这通常涉及将内部 for 循环移动到任务内，而不是将它们分散到许多任务中。

更复杂的算法

如果您正在使用更复杂的算法（这在 Dask 用户中很常见），那么沿途可能会出现更多问题。高性能计算不是把某件事做得很好，而是把*所有事情都做得不差*。本节列出了在大规模部署中出现的一些问题：

1. Dask 集合算法可能不是最优的。
2. Dask-array/bag/dataframe/ml 中的并行算法*相当*不错，但随着 Dask 扩展到更大的集群，其算法被更多领域使用，我们总是发现 API 的某些小角落会在某个点后失效。幸运的是，这些问题通常在报告后很容易修复。
4. 图的大小对调度器来说可能过大
5. 描述您计算的元数据必须全部存储在一台机器上，即 Dask 调度器。如果您不小心，这个元数据（任务图）会变得很大。如果您要处理百万节点的任务图，最好有一个拥有至少几 GB 内存的调度器进程。如果您小心避免捕获任何不必要的本地数据，一个任务大约占用 1kB 内存。
7. 图序列化时间对于交互使用可能变得令人不快
8. 同样，如果您有百万节点的任务图，您将需要对其进行序列化并将其从客户端传递给调度器。这*没问题*，前提是它们在两端都能容纳，但这会花费一些时间并限制交互性。如果您按下 compute 按钮后一两分钟仪表盘上没有任何显示，这就是正在发生的事情。
10. 交互式仪表盘图表不再那么有用
11. 仪表盘上那些漂亮的图表主要设计用于 1-100 个节点的部署，而不是 1000 个。看到百万任务计算中每个任务的开始和结束时间，这并不是我们的大脑能完全理解的东西。
13. 这是我们希望改进的地方。如果有人对可扩展的性能诊断感兴趣，请加入我们。
15. 您依赖的其他组件，如分布式存储，也可能开始出现问题
16. Dask 为用户提供了比他们习惯的更多的能力。他们很容易不小心用过多的请求压垮系统的其他组件，例如分布式存储、本地数据库、网络等等。
18. 许多这些系统提供了在正常单机使用中经过良好测试和稳定的抽象，但当您有上千台机器以新手用户的全部创造力对其进行操作时，它们很快就会变得脆弱。Dask 提供了一些原语，如分布式锁和队列，以帮助控制对这些资源的访问，但这取决于用户能否良好地使用它们并且不破坏东西。

结论

Dask 可以轻松地扩展到几十个节点，就像上面的例子一样，或者数千个节点，我在这里没有展示仅仅是因为资源有限。

Dask 在提供可扩展性的同时，仍然保持了自项目开始以来就定义的灵活性和自由度，以构建自定义系统。然而，可扩展性和自由度的结合使得 Dask 很难完全保护用户不破坏东西。当你能限制用户能做什么时，保护用户会容易得多。当用户遵循 Dask dataframe 或 Dask array 等标准工作流程时，他们可能会没问题，但在千节点规模下以全部创造力进行操作时，必然需要一些专业知识。我们努力提供诊断工具和必要工具来调查问题和控制操作。该项目在这方面每天都在进步，这很大程度上归功于一些外部的专家用户。

征集使用案例

您是否在多台机器上使用 Dask 进行有趣的工作？我们很乐意在下面的评论区或通过此在线表格了解情况。