实际上，在实际尝试过之后，我认为我作为评论发布的链接并不能完全满足您对依赖项的要求。您相当合理地要求的是一种让 Spark 在安装依赖项方面与 setuptools 和 pip 很好地配合的方法。令我震惊的是，Spark 并没有更好地支持这一点。第三方依赖问题在通用 Python 中很大程度上得到了解决，但在 Spark 下，似乎假设您将回到手动依赖管理或其他方式。
我一直在使用一个不完美但功能齐全的管道虚拟环境 https://pypi.python.org/pypi/virtualenv。基本思想是
- 纯粹为您的 Spark 节点创建 virtualenv
- 每次运行 Spark 作业时，运行一个新的
pip install您自己的所有内部 Python 库。如果您已设置这些setuptools，这将安装它们的依赖项
- 压缩 virtualenv 的 site-packages 目录。这将包括工作节点需要的库及其依赖项，但不包括它们已经拥有的标准 Python 库
- 通过单
.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 作业。我只是首先调用此脚本作为该过程的一部分，并确保在运行时将第二个参数（zip 文件的名称）作为 --py-files 参数传递spark-submit（如评论中所述）。我总是运行这些脚本，所以我永远不会意外地运行旧代码。与 Spark 开销相比，对于我的小型项目来说，打包开销是最小的。
可以进行大量改进 - 例如，明智地选择何时创建新的 zip 文件，将其分成两个 zip 文件，一个包含经常更改的私有包，另一个包含很少更改的依赖项，这些依赖项不需要经常被重建。在重建 zip 之前，您可以更聪明地检查文件更改。检查论点的有效性也是一个好主意。但目前这足以满足我的目的。
我提出的解决方案并不是专为像 NumPy 这样的大规模依赖项而设计的（尽管它可能适用于它们）。此外，如果您正在构建基于 C 的扩展，并且您的驱动程序节点与集群节点具有不同的体系结构，则它将无法工作。
我在其他地方看到过建议只运行 Python 发行版，例如Anaconda https://www.continuum.io/why-anaconda在所有节点上，因为它已经包含 NumPy （并且许多其他包 http://docs.continuum.io/anaconda/pkg-docs），这可能是让 NumPy 以及其他基于 C 的扩展运行的更好方法。无论如何，我们不能总是期望 Anaconda 在正确的版本中拥有我们想要的 PyPI 包，此外你可能无法控制你的 Spark 环境能够将 Anaconda 放在上面，所以我认为这个基于 virtualenv 的方法还是有帮助的。
