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

Question

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

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

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

Answer 1

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

我一直在使用基于 virtualenv 的不完善但功能齐全的管道.基本思路是

1. 为您的 Spark 节点创建一个虚拟环境
2. 每次运行 Spark 作业时，对您自己的所有内部 Python 库运行全新的 pip install。如果您已使用 setuptools 设置它们，这将安装它们的依赖项
3. 压缩 virtualenv 的站点包目录。这将包括工作节点需要的库及其依赖项，但不包括它们已经拥有的标准 Python 库
4. 将包含您的库及其依赖项的单个 .zip 文件作为参数传递给 --py-files

当然，您会希望编写一些帮助程序脚本来管理此过程。这是一个改编 self 一直在使用的帮助脚本，毫无疑问，它可以改进很多:

#!/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 文件，一个包含经常变化的私有(private)包，另一个包含很少变化的依赖项，它们不不需要经常重建。在重建 zip 之前，您可以更聪明地检查文件更改。检查参数的有效性也是一个好主意。但是现在这足以满足我的目的。

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

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