Dask 开发日志
这项工作得到了 Continuum Analytics、XDATA 项目 以及来自 Moore 基金会的数据驱动发现倡议的支持。
由于采纳度的提高以及私营公司资助的功能开发，Dask 最近一直很活跃。这种日益增加的活动很棒，然而一个意想不到的副作用是，我花在撰写开发文章和与更广泛社区互动的时间变少了。为了解决这个问题，我希望每周写一篇关于一般开发的博文。这些文章不会特别精雕细琢，也不会宣布可供用户立即使用的功能，但它们应该会增加透明度，并有望更好地吸引开发者社区。
上周的主题
- 为工作进程嵌入 Bokeh 服务器
- 更智能的工作进程
- 经过改进的调度器，总体上略微简化（得益于更智能的工作进程），但具有更巧妙的任务窃取功能
- Fastparquet
在 Dask 工作进程中嵌入 Bokeh 服务器
分布式调度器的 Web 诊断页面 是 Dask 更引人注目的功能之一。它实时显示集群上每个计算的进展。这些诊断对于用户和核心开发人员理解性能都具有无价的价值。
我打算很快将重点放在工作进程的性能上，所以我决定为每个工作进程附加一个 Bokeh 服务器，以提供关于该工作进程的 Web 诊断。为了让这更容易，我还学习了如何将 Bokeh 服务器嵌入到其他 Tornado 应用程序中。这大大减少了创建新可视化和暴露实时信息的精力，我现在可以在大约 30 分钟内创建完整的实时可视化。现在，对我来说，构建一个新的诊断比通过日志搜索要快得多。这非常有用。
这里有一些截图。没有什么太花哨的，但这些信息对我来说非常有价值，因为我可以衡量带宽、代码各个部分的延迟、工作进程之间如何发送数据等等。
需要说明的是，这些诊断页面并没有经过任何打磨。还有很多缺失，这只是我一天之内能完成的工作。尽管如此，每个运行 Tornado 应用程序的人都应该运行一个嵌入式的 Bokeh 服务器。它们非常适合快速推出视觉丰富的诊断信息。
更智能的工作进程和更简单的调度器
以前，调度器知道一切，而工作进程相当简单。现在，我们已经将一些知识和责任转移给了工作进程。以前，调度器只会给工作进程分配足够的工作来保持它们忙碌。这使得调度器能够更好地决定整个集群的状态。通过将任务提交给工作进程延迟到最后一刻，我们确保了我们做出了正确的决定。然而，这也意味着工作进程有时会拥有空闲资源，特别是网络带宽，而此时它可以推测性地为未来的工作做准备。
现在，我们将所有准备运行的任务立即提交给一个工作进程，并且该工作进程可以根据情况自行对这些任务进行流水线处理。这在本地表现更好，但在全局上略差。为了平衡这一点，我们现在对任务窃取更加积极主动，并且由于工作进程拥有更多信息，它们可以自行管理一些任务窃取的管理成本。由于这不仅仅局限于在调度器上运行，我们可以使用比以前在调度器上处理所有事情时更昂贵的算法。
这次改变有几个动机
- Dataframe 的性能受限于工作进程硬件是否得到充分利用，而我们之前没有做到这一点。我预计这些改变最终将带来大约 30% 的速度提升。
- 传统作业调度器机器（SGE、SLURM、TORQUE）上的用户以及喜欢 GPU 的用户都希望能够使用特定的资源限制来标记任务，例如“此任务消耗一个 GPU”或“此任务运行时需要 5GB RAM”，并确保工作进程在运行任务时遵守这些约束。旧的工作进程不够复杂，无法理解这些约束。而对于新的工作进程，添加此功能是微不足道的。
- 通过将逻辑从调度器移到工作进程，我们实际上使两者都更容易理解。这应该会降低贡献者参与核心项目的门槛。
Dataframe 算法
近似 nunique 和多输出分区 groupbys 上周已合入主分支。出现这些需求是因为一些高级用户拥有非常大的 dataframe，遇到了可伸缩性限制。感谢 Mike Graham 提供的近似 nunique 算法。这也将 哈希更改 推送到了 Pandas 上游。
Fast Parquet
Martin Durant 一直在研究一个使用 Numba 为 Python 实现的 Parquet 读写器。它非常棒。他在 Continuum 内部项目中使用了一段时间，发现在性能和 Pythonic 体验方面都很好，而以前这个格式相当难以访问。
他计划在不久的将来撰写关于此的文章，所以我不抢他的风头。这里是文档链接：fastparquet.readthedocs.io
博客评论由 Disqus 提供