年度 Dask 用户调查正在进行中，目前正在接受回复，地址为 dask.org/survey。
本文提供了早期结果的预览，重点关注趣闻轶事方面的回复。
Dask 用户调查帮助开发者集中精力并优先处理我们更重要的工作。 它也是一个关于人们如今如何使用 Dask 的趣闻轶事用例的迷人且有益的数据集。 感谢迄今为止参与的每个人，你们带来了改变。
调查仍在进行中，我鼓励大家踊跃表达自己的使用体验。 这篇博文旨在通过让大家了解调查如何影响开发，以及分享调查中提供的用户故事来鼓励大家参与。
本文省略了我们收集的所有定量数据，重点关注最终评论中列出的直接反馈。 如需更全面的定量分析，请参阅 Tom 前几年发布的博文，链接分别为 2020 年 Dask 用户调查结果 和 2019 年 Dask 用户调查结果。
在这篇博文中，我们将研究对这一个问题的回答。这是一个长格式的回复字段，提出的问题是 “Dask 如何改进？”。浏览了一些回复后，我们发现其中一些属于常见的主题。我将它们归类如下。
在每个部分，我们将列出原始回复，然后是我的一些评论作为回应。
更多关于 Dask 内部的长篇文章，以理解何时出现问题以及原因。Dask 2021 峰会中的“Hacking Dask”教程正是我真正需要的那种内容，因为我使用 Dask 的 90% 时间都花在不理解为什么会内存不足上，我觉得自己已经读了所有文档页面 5 遍了（尽管有时我也会偶然发现以前从未见过的有用页面）。
此外，dask.array 中缺少像 blockwise 这样的进阶主题的文档。（我想我最终是通过文档、GitHub issue 评论、阅读代码以及使用不同函数进行黑盒逆向工程才最终“弄懂”它是如何工作的。）
改进文档和错误消息，以涵盖人们在初级教程示例之外遇到的更多二级问题。
为复杂概念（例如，将元数据传递给自定义函数）提供更多示例。提供更多使用 dask 数组和 cupy 的示例/支持。
我认为使用 Dask 最困难的事情是调试 dask delayed 的性能问题以及与其他库的复杂混合，并且不知道何时进行或未进行序列化（pickling）。我正在学习更好地阅读性能报告，但我认为围绕理解报告提供更好的文档和教程比新功能更有帮助。例如，制作一个教程，演示一些非平凡的 dask-delayed 工作（即不仅仅是计算平均值），该工作按照最佳实践编写，并展示采用每项最佳实践后性能如何提高/解释每一步缓慢的原因。我认为还可以改进性能报告，指出代码中最慢的 5 个部分及其行号，以及可能的文档链接。
我非常喜欢这个主题。 我们现在有了一个由中高级 Dask 用户组成的强大社区，我们应该赋予他们更多能力。 我们通常编写面向广泛的初级用户的材料，但也需要重新考虑一下。 高级用户在性能和调试方面有很多很好的潜在材料可以发布。
文档网站有时导航起来很令人困惑，更好地分离 API 和示例会有帮助。或许这可以带来启发：https://documentation.divio.com/
实际上，我认为 Dask 的文档写得相当不错。但文档可能需要一些重新组织——通常很难找到相关的 API。而且启动一个典型工作流需要大量的 HPC 内部知识——目前这些知识大部分隐藏在 GitHub issue 中（这很好！但可以将其更多地推送到 FAQ 中，使其更易获取）。
更详细的文档和示例。提供端到端的示例，这些示例不假设我了解很多（关于 Dask、命令行工具、云技术、Kubernetes 等）。
我认为更易懂的 delayed/bags 介绍以及更多复杂用例的附加示例可能会有帮助。
我们拥有我称之为出色的 参考文档。 事实上，如果今天有人想构建一个动态分布式任务调度器，我会说 distributed.dask.org 可能是现存最全面的参考资料。
然而，我们缺乏良好的 叙述性文档，这也是大多数评论提出的担忧。这很难做到，因为 Dask 用于许多 不同的用户场景。 要同时围绕所有这些场景来组织 Dask 文档具有挑战性。
我赞赏第一条评论中直接引用了一个带有框架的网站。 总的来说，我很想与那些半专业地组织文档的人交流并学习更多。
这里混合了各种功能请求，其中有几个共同的主题
更好地支持 pandas（如多重索引），这将帮助我将现有代码迁移到 Dask。
我希望看到对 actor 有更好的支持。我认为拥有远程对象是一个常见的用例。
改进 DataFrames - 多重索引！！增加与 Pandas API 的功能对等性。
也许少关注一点机器学习，多关注一些“经典”的大数据应用（CDF、PDEs、粒子物理等）。并非所有东西都可以 map-reduce。
更好的数据库集成。在 SQL Alchemy 中重写 SQL 查询可能非常不切实际。如果能有更好的方法来确保进程不会因错误估计每个块所需的内存量而终止，那就太好了。
更好的诊断工具；哪些操作是任务图的瓶颈？支持多重索引。
我的工作经常需要按多列对 DataFrame 进行排序。Pandas 可以单核执行此操作；H2O 和 Spark 可以多核和分布式执行此操作。但是 dask 完全不能对多列进行 sort_values() 操作（例如 df.sort_values([ "col1", "col2" ,"col3" ], ascending=False)）。
类型提示（Type-hints）！在大型机器学习应用中使用 Dask，甚至没有进行静态类型检查的选项，这非常繁琐。
此外，令人非常沮丧的是，Dask 试图模仿 Pandas API，但 40% 的 API 无法使用（未实现），或者与 Pandas API 偏离太大，导致某些参数未实现。唯一了解这些的方法就是阅读文档。有了类型提示，在从 Pandas 切换到 Dask 时，可以大大减少这种试错过程。
很难追踪 Dask 周围的一切！！！ Actors 有点不受待见，但我发现它们超级有用
为所有方法添加类型注解，以更好地支持 IDE (VSCode)
我认为 Actor 模型可以多得到一些关注
有趣的趋势，许多并非我所预料
需要更好的物理数据独立性。手动数据分块、内存管理、查询优化都非常麻烦。应更多地自动化这些过程。
Dask 使得没有并行计算经验的用户也能快速扩展（比如我），但我们不知道如何判断自己的资源需求。如果 Dask 能有一些工具或教程帮助我判断问题的大小（例如内存使用量），那就太好了。这些工具或教程可能已经存在，但如何使用的例子可能很难找到。
稳定性是最重要的因素
我选择了不使用 Dask 的长期支持版本，但通常真正好的机会是那些按需出现的。问题在于，当这些修复版本发布时，它们没有得到很好的宣传，而且内部有些东西发生了变化。因此，最终会破坏其他东西，或者我之前对工作原理的特定知识不再正确。Dask 的维护者们形成了一个有点奇怪的小圈子，作为一个新手或学习者，你可能会觉得他们对你轻视或无暇顾及。他们没有时间帮助别人。所以他们应该通过博客或其他方式安排更多的维护者来回答一些更基础的问题，例如我们看到人们常犯的错误或遇到的困难。包括一些基础的、一些进阶的和一些高级的内容。如果底层的 Dask API 发生了变化，那么应该通过新的博文更新这些变化。展示通过困难方式解决问题的分解步骤。这样人们可以看到标准工作流程中每一步如何实现。然后对比 Dask 的方式，它需要更少的样板代码和/或能提高速度。如果有些地方速度没有提高，则展示它不起作用的地方与可能起作用的工作流程之间的区别。
我们长期部署 Dask 集群（数周到数月），注意到它们有时会进入异常状态。我们未能确定根本原因。发生异常时，重新部署很简单也很容易，但仍然有点令人烦恼。
我最大的痛点是调度器（scheduler），因为我倾向于花费时间编写基础设施来管理调度器，并拆分/重写任务图以最大程度地减少对调度器的影响。
正如我的回答所明确指出的（以及之前与 Matt、James 和 Genevieve 的交流），我最希望看到的改进是稳定版本。既包括运行时层面的稳定（即坚如磐石的 Dask distributed），也包括 API 层面的稳定（这样我就不必每隔几周就修改代码）。所以对 LTS（长期支持）版本大力支持。
更好的错误处理/错误描述，更好地支持（略微）不同版本之间的互操作性
如果出现问题（无论是在 Dask 中、批处理系统中，还是 Dask 与批处理系统的交互中），问题都非常不透明且难以诊断。Dask 需要大量的额外文档，并且可能需要额外的功能，以使调试更容易、更透明。
更好地获取 worker 内存使用日志的方法，特别是在 Dask 崩溃/失败后。将性能报告写入日志文件的方法，而不是写入 HTML 文件，因为如果 Dask 客户端进程失败，HTML 文件将不会写入。
对我来说，两大难题是当 Dask 失败时，难以确定哪里出了问题以及如何修复。
去年 12 月，稳定性确实有所下降。 不过我现在感觉不错。 未来几周内，将有很多优秀的成果被合并并发布，我认为这将显著改善许多常见的痛点。
然而，仍有许多重大改进尚待完成。 我尤其喜欢上面关于在出现问题时进行报告和日志记录的主题。 我们现在在这方面做得还可以，但仍有很大的提升空间。
上面的观点是否充分表达了您对 Dask 发展方向的看法，还是遗漏了什么？
请在以下地址分享您的观点： dask.org/survey。 整个过程应该不到五分钟。
Copyright © 2022 Dask 核心开发者。New-BSD 许可。
