Dask 库的稳定性
作者：Matthew Rocklin
Dask 近期发展迅速。有时我们会因此引入破坏性变更。
从历史上看，这并非问题，根据我们去年的调查，大多数用户对 Dask 的稳定性相当满意。
然而，去年该项目经历了许多演变，这反过来导致了代码的大量变动。这可能会给下游用户带来一些阻碍，但同时也意味着未来会有非增量式的改进。我们稍微优化了长期增长，而不是短期稳定性。
变更的动机
有两项结构性因素推动了这些变更
- 计算规模的增加
- 组织规模的增加
计算规模
如今的 Dask 应用于更广泛的问题、更多样的硬件，并且比以往更常规地在更大规模下使用。
为了应对跨多个维度的规模增长，我们以多种方式重新设计了 Dask 的内部基础设施。
- 我们改变了 Dask 图的表示方式及其与调度器通信的方式
- 我们提取了 Dask 的内部状态机，并使其更加规范化
- 我们用 Cython 重写了调度器的很大一部分代码
- 我们彻底改进了所有 Dask 服务器之间消息的序列化方式
- 我们现在以比以前更精细的粒度跟踪内存
- ... 等等
我们在进行所有这些内部变更时，对众多下游用户社区（Xarray、Prefect、RAPIDS、XGBoost 等）的影响微乎其微。这很大程度上归功于这些下游开发者社区，他们帮助识别、隔离和解决我们在进行这些底层变动时表面出现的细微震荡。
组织规模
从历史上看，Dask 的核心由相对少数人维护，主要在 Anaconda。有数十名开发者在各种 dask-foo 项目上工作，但只有一小部分人关注序列化、状态机等方面。特别是，我个人跟踪每一个问题，了解整个项目。每当潜在冲突出现时，我通常都能及早发现。
这一切都发生了巨大变化。
首先，现在有几个跨公司团队在 Dask 内部的不同部分工作。
其次，我们还花了一些时间重新设计了 Dask 内部的一些部分，使其更易于维护。Dask 调度就像一个精密时钟。历史上，时钟的某些部分是由个人以工匠般的方法构建和设计的。现在我们正在以一种更具团队协作的方式重新设计。这带来了更易维护的设计，但同时也意味着我们正在拆开时钟并重新组装。找到所有缺失的零件需要一些时间 :)
这如何影响您今天的使用
这一切始于我们去年底切换到日历版本控制（Dask 版本 2.30.1 在去年 12 月过渡到 2020.12.0）。您可能已经注意到
- 对版本不匹配更加敏感（随着我们改变 Dask 协议，不同版本的 Dask 之间无法良好通信）
- 稳定性问题（2020.12 版本尤其不稳定）
- 发布期间 dask 和 distributed 版本之间更严格的依赖锁定
这将如何影响您
我们已经合并了一个PR，改变了将 Dask Dataframes 的高级图转移到调度器时的默认行为。这将大大减少提交大型计算时的延迟，并且几乎消除了优化延迟。这还为我们开辟了一条通道，可以将有关您的计算的大量语义信息发送给调度器，从而在未来实现新的可视化和更智能的调度。
这也可能会破坏一些东西。
需要说明的是，所有测试在 Dask、distributed、xarray、prefect、rapids 以及其他下游项目之间都通过了。我们已经做了充分的准备，但几乎肯定遗漏了一些东西。
这只是未来几个月内发生的几项较大变更之一。在进行这些重大转变时，我们感谢您的耐心和参与。无论好坏，最终用户都是最终的测试套件 :)
博客评论由 Disqus 提供支持