在 Spark 执行器节点上安装 Python 依赖项的最简单方法？

Question

我了解您可以将单个文件作为 Python Spark 程序的依赖项发送。但是成熟的库（例如 numpy）呢？

Spark 是否有办法使用提供的包管理器（例如 pip）来安装库依赖项？还是必须在 Spark 程序执行之前手动完成？

如果答案是手动，那么在大量分布式节点上同步库（安装路径、版本等）的“最佳实践”方法是什么？

Answer 1

实际上，在实际尝试过之后，我认为我作为评论发布的链接并不能完全满足您对依赖项的要求。您相当合理地要求的是一种让 Spark 在安装依赖项方面与 setuptools 和 pip 很好地配合的方法。令我震惊的是，Spark 并没有更好地支持这一点。第三方依赖问题在通用 Python 中很大程度上得到了解决，但在 Spark 下，似乎假设您将返回手动依赖管理或其他东西。

我一直在使用基于 virtualenv 的不完美但功能齐全的管道。基本思想是

1. 纯粹为您的 Spark 节点创建一个 virtualenv
2. 每次运行 Spark 作业时，请运行您自己的所有内部 Python 库的全新

   pip install

   。如果您使用

   setuptools

   设置了这些，这将安装它们的依赖项
3. 压缩 virtualenv 的 site-packages 目录。这将包括工作节点需要的库及其依赖项，但不包括他们已经拥有的标准 Python 库
4. 将包含您的库及其依赖项的单个

   .zip

   文件作为参数传递给

   --py-files

当然，您可能希望编写一些帮助程序脚本来管理此过程。这是一个根据我一直在使用的脚本改编的帮助程序脚本，无疑可以进行很大改进：

#!/usr/bin/env bash
# helper script to fulfil Spark's python packaging requirements.
# Installs everything in a designated virtualenv, then zips up the virtualenv for using as an the value of
# supplied to --py-files argument of `pyspark` or `spark-submit`
# First argument should be the top-level virtualenv
# Second argument is the zipfile which will be created, and
#   which you can subsequently supply as the --py-files argument to 
#   spark-submit
# Subsequent arguments are all the private packages you wish to install
# If these are set up with setuptools, their dependencies will be installed

VENV=$1; shift
ZIPFILE=$1; shift
PACKAGES=$*

. $VENV/bin/activate
for pkg in $PACKAGES; do
  pip install --upgrade $pkg
done
TMPZIP="$TMPDIR/$RANDOM.zip" # abs path. Use random number to avoid clashes with other processes
( cd "$VENV/lib/python2.7/site-packages" && zip -q -r $TMPZIP . )
mv $TMPZIP $ZIPFILE

我有一组其他简单的包装脚本，用于提交我的 Spark 作业。我只是首先调用此脚本作为该过程的一部分，并确保在运行

spark-submit

时将第二个参数（zip 文件的名称）作为 --py-files 参数传递（如注释中所述）。我总是运行这些脚本，所以我永远不会意外地运行旧代码。与 Spark 开销相比，对于我的小型项目来说，打包开销是最小的。

可以进行大量改进 - 例如，明智地选择何时创建新的 zip 文件，将其拆分为两个 zip 文件，一个包含经常更改的私有包，另一个包含很少更改的依赖项，这些依赖项不需要如此频繁地重建。在重建 zip 之前，您可以更聪明地检查文件更改。检查论点的有效性也是一个好主意。但目前这足以满足我的目的。

我提出的解决方案并不是专为像 NumPy 这样的大规模依赖项而设计的（尽管它可能适用于它们）。此外，如果您正在构建基于 C 的扩展，并且您的驱动程序节点与集群节点具有不同的体系结构，则它将无法工作。

我在其他地方看到过建议在所有节点上运行像Anaconda这样的Python发行版，因为它已经包含NumPy（和许多其他包），这可能是获取NumPy以及其他C的更好方法基于扩展进行。无论如何，我们不能总是期望 Anaconda 在正确的版本中拥有我们想要的 PyPI 包，此外你可能无法控制你的 Spark 环境能够将 Anaconda 放在上面，所以我认为这个基于 virtualenv 的方法还是有帮助的。