这项工作得到以下机构的支持：Anaconda Inc、NSFEarthCube 项目以及加州大学伯克利分校 BIDS
几周前，我们中的一些人搭建了pangeo.pydata.org，这是一个在 Google Container Engine (GKE) 上实验性部署 JupyterHub、Dask 和 XArray 的项目，旨在支持对大型数据集进行大气和海洋数据分析。这建立在最近将 Dask 和 XArray 部署到超级计算机上进行相同工作负载的研究之上。这个系统是一个概念验证，它让我们受益匪浅，指明了前进方向。这篇博文将简要描述问题、系统，然后介绍合作，最后讨论我们未来几个月将要应对的一些挑战。
问题
大气和海洋科学通过卫星收集并通过模拟生成大型数据集，他们希望使用分布式系统对其进行分析。如果科学家拥有自己的集群，Dask 和 XArray 等库已经可以在计算上解决这个问题，但我们希望通过部署在基于云的系统上来扩大访问范围。我们构建了一个系统，人们可以轻松登录、获取 Jupyter Notebook 并启动 Dask 集群。我们希望这能增加访问机会，并将更多科学家与更多基于云的数据集连接起来。
系统
我们整合了多个现有技术，构建了一个系统，人们可以登录、访问 Jupyter notebook、使用 Dask 启动分布式计算集群，并分析存储在云端的大型数据集。他们可以通过网站获得完整的用户环境，可以利用数千个核心进行计算，并使用与他们在笔记本电脑上工作方式相似的现有 API 和工作流程。
以下是视频演示
我们由以下多个组件和技术构建了该系统
- JupyterHub：提供启动单用户 notebook 服务器的能力，并为我们处理用户管理。特别是，我们使用了 KubeSpawner 和Zero to JupyterHub上的优秀文档，我们向所有对此领域感兴趣的人推荐这些文档。
- KubeSpawner：一个 JupyterHub spawner，可以在 Kubernetes 系统上轻松启动单用户 notebook 服务器
- JupyterLab：经典 notebook 的新版本，我们用它来提供更丰富的远程用户界面，包括终端、文件管理等。
- XArray：提供对 NetCDF 格式数据的计算。XArray 扩展了 NumPy 和 Pandas，使科学家能够以他们认为直观的方式在复杂数据集上表达复杂的计算。
- Dask：提供 XArray 背后的并行计算能力
- Daskernetes：可以在 Kubernetes 上轻松启动 Dask 集群
- Kubernetes：如果还不清楚，所有这一切都基于 Kubernetes，它负责在不同机器上管理程序的启动（如 Jupyter notebook 服务器或 Dask worker），同时处理负载均衡、权限等。
- Google Container Engine：谷歌的托管 Kubernetes 服务。现在每个主要云服务提供商（谷歌、AWS、Azure）都有这样的系统，这让我们很高兴不必过度依赖某个单一系统。
- GCSFS：一个 Python 库，提供对 Google Cloud Storage 的直观访问，可以通过 Python 文件接口或通过一个FUSE文件系统实现。
- Zarr：一种适合云端的块状数组存储格式
协作
我们在几周内构建、部署并使用该系统解决了真实的科学问题。我们认为这一结果本身具有重要意义，这在很大程度上归功于我们广泛的协作。这个项目需要跨越多个项目、机构和资金来源的多个人的专业知识。以下是一些关于来自哪些组织的谁做了什么工作的例子。我们列出机构和职位主要是为了展示所涉及的角色。
- Alistair Miles，牛津大学教授：帮助优化 GCS 上 XArray 的 Zarr。
- Jacob Tomlinson，英国气象局信息学实验室员工：开发了最初的 JADE 部署和早期的 Dask-Kubernetes 工作。
- Joe Hamman，国家大气研究中心博士后：提供了科学用例、数据和工作流程。调整了 XArray 和 Zarr 以实现高效的数据存储和保存。
- Martin Durant，Anaconda Inc. 软件开发者：为多访问负载调整了 GCSFS。还提供了用于 NetCDF 支持的 FUSE 系统。
- Matt Pryor，环境数据分析中心员工：扩展了最初的 JADE 部署和早期的 Dask-Kubernetes 工作。
- Matthew Rocklin，Anaconda Inc. 软件开发者：集成。还进行了性能测试。
- Ryan Abernathey，哥伦比亚大学助理教授：XArray + Zarr 支持、科学用例、协调。
- Stephan Hoyer，谷歌软件工程师：XArray 支持。
- Yuvi Panda，加州大学伯克利分校 BIDS 和数据科学教育项目员工：提供了使用 KubeSpawner 配置 JupyterHub 的帮助。还原型开发了 Daskernetes Dask + Kubernetes 工具。
请注意学术机构和营利性机构的混合参与。另请注意科学家、员工和专业软件开发者的组合。我们相信这种组合有助于确保高效构建有用的解决方案。
经验教训
这次实验教会了我们一些希望进一步探索的东西
- 用户可以从 Kubernetes pods 启动 Kubernetes 部署，例如从他们的 JupyterHub 单用户 notebooks 中启动 Dask 集群。
- 要做好这一点，我们需要开始在 JupyterHub 中更明确地定义用户角色。我们需要在集群上给用户一个安全的、隔离的空间，让他们使用而不影响其他人。
-
- 云存储上的 HDF5 和 NetCDF 是一个悬而未决的问题
- 用于此类数据的文件格式非常普遍，但在云存储上并不特别方便或高效。特别是用于读取这些格式的库会进行许多小规模读取，每次操作在云对象存储上都是昂贵的。
-
- 我看到几种选择
-
- 使用 FUSE 文件系统，但通过预读和缓存等技巧进行调整，以弥补 HDF 的访问模式。
- 使用 HDF 工作组提出的 HSDS 服务，该服务有望解决这些问题。
-
- 采用更适合云的新文件格式。Zarr 就是一个这样的例子，目前表现出色，但肯定没有 HDF 和 NetCDF 赢得的长期信任历史。
-
-
- 环境定制既重要又棘手，尤其是在添加分布式计算时。
- 向科学团队展示这个系统后，他们立刻就想用自己的软件环境进行尝试。他们可以在他们的 notebook 会话中，使用 pip 或 conda 等工具轻松实现这一点，但将相同的更改应用到他们的 dask workers 上则有点更具挑战性，尤其是在这些 workers 动态创建和销毁时。
-
- 我们对此有一些解决方案。他们可以构建和发布 docker 镜像。他们可以添加环境变量来指定额外的 pip 或 conda 包。他们可以为自己的团队部署自己的 pangeo 实例。
-
- 然而，到目前为止，做好这些工作都花费了一些努力。我们希望结合类似 Binder 的发布方式和环境变量等小修改技巧能够解决这个问题。
-
- 我们的 docker 镜像非常大。这意味着用户有时需要等待一分钟或更长时间来启动他们的会话或他们的 dask workers（预热后时间会短一些）。
- 令人惊讶的是，其中很大一部分来自 conda 和 node 包。我们希望通过改进我们的 Docker 管理以及与打包社区合作来审计包大小来解决这个问题。
-
- 探索其他云平台
- 我们最初选择谷歌只是因为他们的 Kubernetes 支持出现得最早，但现在所有主要云服务提供商（谷歌、AWS、Azure）都提供一定程度的托管 Kubernetes 支持。我们所做的一切都与云供应商无关，并且一些已将数据存储在其他云平台上的团队已经联系我们，并开始在这些系统上进行部署。
-
- 与其他团队协同努力
- 事实上，我们并不是第一个做这项工作的团队。英国气象局信息学实验室在几个月前悄悄地构建了一个类似的原型，JADE（Jupyter 和 Dask 环境）。我们现在正在合作整合双方的努力。
-
- 值得一提的是，他们还原型开发了 Daskernetes 的第一个版本。
-
- 触及其他社区
- 虽然我们最初是与大气和海洋科学家合作，但同样的解决方案也适用于许多其他学科。我们应该调查其他领域，并与这些社区开展合作。
-
- 改进 Dask + XArray 算法
- 当我们在新环境中尝试新问题时，我们经常会发现改进 Dask 内部调度算法的新机会。这次也不例外 :)
-
许多即将开展的工作正在上游项目中进行，因此本次实验既对正在进行的科学研究具有具体价值，也对这些项目所服务的开源社区具有更广泛的用途。
社区采纳
在过去一周，我们在几个会议上展示了这项工作。
我们发现这个项目与许多政府机构当前在云存储（主要是 S3）上发布大型数据集的努力非常契合。许多此类数据发布工作都在寻求一个计算系统，以便科学界能够访问数据。我们的项目似乎在无需大量协调的情况下补充了这些需求。
免责声明
我们鼓励大家试用pangeo.pydata.org，但同时也提醒您，这个系统尚不成熟。具体而言，它存在以下问题
- 它不安全，请勿托管敏感数据
- 它不稳定，随时可能停止运行
- 它规模小，任何时候只部署了少量核心，主要用于实验目的
然而，它也是开源的，部署您自己的实例的说明在这里。
加入我们
我们是一个由技术专家、科学家和开源项目组成的不断壮大的团队。这里有很多工作可以做，有很多事情可以讨论。请通过以下方式联系我们：github.com/pangeo-data/pangeo/issues/new
