Dask 工作笔记

Dask 扩展限制

本工作由 Anaconda Inc. 支持。

历史

在 Dask 存在的最初一年里，它完全专注于单节点并行计算。我们当时认为，在个人笔记本电脑上高效支持 100GB+ 的数据集，或在大型工作站上高效支持 1TB 的数据集，是提高生产力的一个理想领域，尤其是在避免部署和配置分布式系统的痛苦时。我们仍然相信单节点并行计算的效率，但在随后的几年里，Dask 已经扩展到支持更大的分布式系统。

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

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

一个例子

大多数博客文章或讲座中的 Dask 示例都使用适中大小的数据集，通常在 10-50GB 的范围。这，再加上 Dask 在单节点上处理中等规模数据的历史，可能使人们对 Dask 的印象比实际情况更为谦逊。

作为一点提示，这里有一个使用 Dask 在一个人造 TB 级数据集上与 50 个 36 核节点交互的例子。

这是典型适中规模 Dask 集群的常见大小。我们通常看到 Dask 部署的规模要么是几十台机器（通常是 Hadoop 式或临时企业集群），要么是几千台（通常是高性能计算或云部署）。我们在这里展示适中规模的情况仅仅是因为资源不足。该示例中的所有内容都应该可以很好地再扩展几个数量级。

扩展面临的挑战

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

简单的 Map-Reduce 风格

如果你正在进行简单的 Map-Reduce 风格并行计算，那么扩展到大量节点会非常顺利。然而，仍然有一些限制需要记住

  1. 调度器将至少有一个，可能对每个工作节点有几个打开的连接。你需要确保你的机器可以同时打开许多文件句柄。一些 Linux 发行版默认将此限制在 1024 个，但这很容易更改。

  2. 调度器对每个任务有大约 200 微秒的开销。因此，如果每个任务需要一秒钟，那么你的调度器可以饱和 5000 个核心；但如果每个任务只需要 100 毫秒，那么你的调度器只能饱和大约 500 个核心，依此类推。任务持续时间对扩展施加了反比约束。

    如果你想比这更大规模地扩展，那么你的任务需要在每个任务中做更多的工作以避免开销。这通常涉及将内部的 for 循环移动到任务内部，而不是将它们分散到许多任务中。

更复杂的算法

如果你正在使用更复杂的算法（这在 Dask 用户中很常见），那么在这个过程中可能会遇到更多的问题。高性能计算不是要把任何一件事情做得特别好，而是要做到没有什么事情做得不好。本节列举了一些在更大规模部署中出现的问题

  1. Dask 集合算法可能不是最优的。

    Dask-array/bag/dataframe/ml 中的并行算法相当不错，但随着 Dask 扩展到更大的集群，并且其算法被更多领域使用，我们总是会发现 API 的某些小角落会在某个点之后失效。幸运的是，这些问题通常在报告后很容易修复。

  2. 图的大小可能对调度器来说变得过大

    描述计算的元数据必须全部适合一台机器，即 Dask 调度器。如果你不小心，这个元数据，也就是任务图，会变得很大。如果你要处理百万节点任务图，最好有一个至少有几 GB 内存的调度器进程。一个任务大约占用 1kB 的内存，前提是你小心地避免捕获任何不必要的本地数据。

  3. 图的序列化时间可能对交互式使用造成困扰

    再次，如果你有百万节点的任务图，你需要将它们序列化并从客户端传递给调度器。这没问题，前提是它们都能容纳，但这可能会花费一些时间并限制交互性。如果你按下 compute 后一两分钟内仪表盘上什么都没有显示，就是这种情况。

  4. 交互式仪表盘图表不再那么有用

    仪表盘上那些漂亮的图表主要设计用于 1-100 个节点的部署，而不是数千个。查看百万任务计算中每个任务的开始和停止时间，我们的头脑根本无法完全理解。

    这是我们希望改进的地方。如果有人对可扩展的性能诊断感兴趣，请参与进来。

  5. 您依赖的其他组件，例如分布式存储，也可能开始出现问题

    Dask 为用户提供了比他们习惯的更多的能力。用户很容易意外地用过多的请求破坏其系统的其他组件，例如分布式存储、本地数据库、网络等等。

    许多这些系统提供了经过充分测试且对于正常的单机使用非常稳定的抽象，但当你有一千台机器以新手用户的全部创造力对它们进行操作时，它们很快就会变得脆弱。Dask 提供了一些原语，如分布式锁和队列，以帮助控制对这些资源的访问，但用户有责任善加利用它们，而不是破坏东西。

结论

Dask 可以轻松地扩展到几十个节点，就像上面的例子一样，也可以扩展到数千个节点，这里没有展示只是因为资源不足。

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

征集示例

您是否在多台机器上使用 Dask 完成有趣的工作？我们很想了解您的经历，请在下方评论区或通过这个在线表格告诉我们。

博客评论由 Disqus 提供支持