Dask 2021 用户调查：早期反馈
作者：Matthew Rocklin
年度 Dask 用户调查正在进行中，目前正在 dask.org/survey 接收回复。
本文提供了早期结果的预览，重点关注了用户反馈。
动机
Dask 用户调查帮助开发者集中精力并确定我们更大工作的优先级。 它也是一个引人入胜且有价值的数据集，其中包含人们目前如何使用 Dask 的案例反馈。 感谢所有迄今为止参与调查的人，你们的参与意义重大。
调查仍在开放，我鼓励大家畅所欲言分享他们的经验。 这篇博文旨在通过让您了解它如何影响开发以及分享调查中提供的用户故事来鼓励参与。
本文跳过了我们收集的所有定量数据，重点关注最终评论中列出的直接反馈。 有关更详细的定量分析，请参阅 Tom 前几年发布的博文：2020 Dask 用户调查结果 和 2019 Dask 用户调查结果。
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 issues 中（这很棒！但可以更多地推送到常见问题解答中，使其更容易访问）。
需要更详细的文档和示例。从头到尾的示例，不假设我了解很多东西（关于 Dask、命令行工具、云技术、Kubernetes 等）。
我认为更容易的 delayed/bags 介绍以及更复杂用例的额外示例可能会有所帮助。
回应
我们的文档有时会受到赞扬，有时会受到嘲讽。 我们拥有我称之为优秀的 参考文档。 事实上，如果今天有人想构建一个动态分布式任务调度器，我会说 distributed.dask.org 可能是最全面的参考资料。
然而，我们缺乏优秀的 叙述性文档，这也是大多数评论中提出的担忧。这很难做到，因为 Dask 被用于许多 不同的用户场景。 同时围绕所有这些场景来组织 Dask 文档具有挑战性。
我很欣赏第一条评论中直接引用了一个包含框架的网站。 总的来说，我希望与那些半专业地进行文档排版的人交流并学习更多。
功能性
这里汇集了各种功能请求，其中有一些共同的主题
更好地支持 pandas（例如多级索引），这有助于我将现有代码迁移到 Dask。
我希望看到对 actors 的更好支持。我认为拥有远程对象是一种常见的用例。
改进 Dataframes - 多级索引！！与 Pandas API 实现更多功能对等。
也许可以减少一点机器学习相关内容，多一些“经典”大数据应用（CDF、PDE、粒子物理等）。并非所有东西都是可进行 map-reduce 的。
更好的数据库集成。在 SQL Alchemy 中重写 SQL 查询可能非常不切实际。如果能有更好的方法确保进程不会因误判每个块所需的内存而终止，那也将非常棒。
更好的诊断工具；哪些操作是任务图的瓶颈？支持多级索引。
我的工作经常需要按多列对 DataFrame 进行排序。Pandas 可以在单核上完成；H2O 和 Spark 可以在多核和分布式环境下完成。但 dask 完全无法对多列进行 sort_values()（例如
df.sort_values([ "col1", "col2" ,"col3" ], ascending=False)）。类型提示！在大型机器学习应用中使用 Dask 而没有进行静态类型检查的选项，这非常繁琐。
此外，令人非常沮丧的是，Dask 试图模仿 Pandas API，但 40% 的 API 无法工作（未实现），或者与 Pandas API 偏差太大，导致某些参数未实现。唯一了解这一点的方法是阅读文档。有了类型提示，可以在从 Pandas 切换到 Dask 时减轻很多这种试错过程。
很难跟踪 Dask 周围的所有东西！！！Actors 有点不受待见，但我发现它们非常有用
所有方法都需要类型注解，以获得更好的 IDE (VSCode) 支持
我认为 Actor 模型需要得到一些关注
回应
有趣的趋势，许多是我没有预料到的
- 多级索引（好吧，这是意料之中的）
- Actors
- 用于 IDE 支持的类型提示
- SQL 访问
高级优化
需要更好的物理数据独立性。手动数据分块、内存管理、查询优化都很麻烦。需要更多自动化这些方面。
Dask 使没有并行计算经验的用户（比如我）能够快速扩展，但我们不清楚如何判断资源需求。如果 Dask 能有一些工具或教程帮助我判断问题的大小（例如内存使用），那将非常棒。这些可能已经存在，但如何操作的示例可能很难找到。
运行时稳定性和高级故障排除
稳定性是最重要的因素
我回答了不需要 Dask 的长期支持版本，但通常真正重要的机会是那些按需出现的。问题在于，当这些修复发布时，它们并没有得到很好的宣传，并且内部发生了一些变化。因此，最终会导致其他东西损坏，或者我对我之前了解的工作原理不再正确。Dask 的维护者们似乎有点像一个奇怪的小圈子，作为一个新手或学习者，你可能会感觉自己被轻视，或者实际上，他们没有时间帮助别人。因此，他们可能应该有更多的维护者通过博客或其他方式回答一些更常见的问题，例如我们看到人们常犯的错误或遇到的困难。可以提供一些基础、一些中级和一些高级的内容。如果底层的 Dask API 发生了变化，那么应该通过新的博文来更新这些变化。展示困难方法的分解步骤。这样人们就可以一步一步地看到标准工作流程是如何工作的。然后对比 Dask，使用更少的样板代码和/或速度提升。如果有些地方速度没有提升，则展示它不起作用的地方与可能起作用的工作流程的区别。
我们长期部署 Dask 集群（几周到几个月），并注意到它们有时会进入不稳定状态。我们一直无法确定根本原因。虽然重新部署发生时简单容易，但仍然有点烦人。
我最大的痛点是调度器，因为我倾向于花时间编写基础设施来管理调度器，并分解/重写任务图以最大程度地减少对调度器的影响。
正如我的回答所表明的（以及之前与 Matt、James 和 Genevieve 的对话），我最希望看到的改进是稳定版本。无论是从运行时角度（即坚如磐石的 Dask distributed）还是从 API 角度（这样我就不必每隔几周就修改代码），都希望能稳定。因此，强烈支持 LTS 版本。
更好的错误处理/错误描述，（略微）不同版本之间的更好互操作性
如果出现问题（在 Dask、批处理系统或 Dask 与批处理系统交互中），问题非常不透明且难以诊断。Dask 需要大量额外的文档，可能还需要额外的功能，以使调试更容易、更透明。
更好地获取 worker 内存使用日志的方法，尤其是在 Dask 崩溃/失败后。将性能报告写入日志文件而不是 HTML 文件的方法，因为如果 Dask 客户端进程失败，HTML 文件将不会被写入。
对我来说，两个大问题是 Dask 失败时，难以确定哪里出错了以及如何修复。
回应
稳定性在去年 12 月确实有所下降。 不过我现在感觉不错。 未来几周将合并并发布许多优秀的工作，我认为这将显著改善许多常见痛点。
然而，仍有许多重要的改进尚待完成。 我特别喜欢上面提到的关于在出现问题时报告和日志记录的主题。 我们目前在这方面做得还行，但仍有很大的提升空间。
下一步是什么？
上面的观点是否完全表达了您对 Dask 发展方向的看法，或者遗漏了什么？
请在 dask.org/survey 分享您的看法。 整个过程应该不到五分钟。
博客评论由 Disqus 提供