Dask 开发日志
这项工作得到了 Continuum Analytics、XDATA Program 以及来自 摩尔基金会 (Moore Foundation) 的数据驱动发现倡议 (Data Driven Discovery Initiative) 的支持。
为了提高透明度，我每周都会撰写博客，介绍 Dask 及相关项目在前一周完成的工作。本日志涵盖 2016 年 12 月 11 日至 2016 年 12 月 18 日期间的工作。这里的所有内容都尚未投入生产。这篇博文是匆忙写成的，因此请勿期待精炼的润色。
上周的主题
- 在大型系统上对新的调度器和工作节点进行基准测试
- Kubernetes 和 Google Container Engine
- S3 上的 Fastparquet
重写负载均衡
在过去的两个星期里，我们重写了工作节点和调度器的很大一部分。这使得未来的发展成为可能，但也导致我们丢失了负载均衡和工作窃取算法（旧算法在新系统中不再适用）。细致的动态负载均衡对于运行非典型工作负载至关重要（这在 Dask 用户中出乎意料地常见），因此本周对我个人而言，重建这项工作占据了全部精力。
简单来说，Dask 最初会将任务分配给工作节点，同时考虑任务的预期运行时间、任务所需数据的大小和位置、每个工作节点上其他任务的持续时间，以及每块数据在所有工作节点上的位置。由于任务数量可能达到数百万，而工作节点数量可能达到数千，Dask 需要在接近恒定时间内找到接近最优的任务分配，这很困难。此外，系统运行一段时间后，我们估计中的不确定性会累积，我们需要相对频繁地将工作从饱和的工作节点重新均衡到空闲的工作节点。智能且响应迅速的负载均衡对于提供令人满意的用户体验至关重要。
我们针对这些行为有一套相当强大的测试套件，但要全面衡量基于性能的指标是困难的，因此也针对真实系统进行了大量的基准测试，以识别新的故障模式。我们正在尽力为我们找到的每种故障模式创建独立的测试，以便未来的重写能够保持良好的行为。
总的来说，在 Dask 分布式调度器上的工作让我认识到单元测试的脆弱性。由于我们反复重写内部实现，同时保持相同的外部 API，我们的测试策略已经从细粒度的单元测试显著转向行为集成测试和非常严格的运行时验证系统相结合的方式。
对我个人而言，重建负载均衡算法一直是重中之重，因为这些性能问题阻碍了当前的高级用户在他们的问题上有效地使用开发版本，不如使用最新发布版本。我期待着看到负载均衡再次运转良好，这样用户就可以回到 git-master 分支，我也能回去处理更广泛的问题。（对过去几周我忽略的所有人表示抱歉）。
在 Google Container Engine 上进行测试部署
我个人已开始将我的开发集群从亚马逊的 EC2 切换到谷歌的 Container Engine。以下是我个人视角下的一些优缺点。其中许多可能更多地与我使用特定工具的方式有关，而非服务本身的固有局限性。
对 Google 有利之处
- 对 Kubernetes 和 Docker 的原生且即时支持，两者的结合使我能更快速、更动态地创建和扩展用于不同实验的集群。
- 从单个节点动态扩展到一百个节点，然后在十分钟后缩回，这使我能更容易地运行更大范围规模的测试。
- 我喜欢按分钟计费而不是按小时计费，尤其考虑到可以动态扩展的能力
- 身份验证和计费感觉更简单
对亚马逊有利之处
- 我已经有在 EC2 上启动 Dask 的工具
- 我的所有数据都在亚马逊的 S3 上
- 我有基于 boto3 的很好的 S3 数据获取工具，s3fs。谷歌似乎没有一个很好的 Python 3 库来访问 Google Cloud Storage :(
我正在使用 Olivier Grisel 的仓库 docker-distributed 进行工作，尽管我正在更新到更新的版本并尽量减少对原始部署的修改。我当前的开发分支在这里：here。我希望下周能有一个更稳定的版本。
S3 上的 Fastparquet
周五，我们在一些分布在 S3 上的数据上尝试了 fastparquet 和 Dask.dataframe。令我惊讶的是，一切似乎都能直接使用。Martin Durant，他构建了 fastparquet 和 s3fs，做了很好的工作来确保所有组件都能良好协作。我们在从 S3 本身拉取字节时遇到了一些性能问题。我预计在接下来的几周内会有一些调整。
博客评论由 Disqus 提供支持