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

Question

我知道您可以使用Python Spark程序将各个文件作为依赖项发送.但是完全成熟的图书馆(例如numpy)呢？

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

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

Answer 1

实际上实际上已经尝试过,我认为我发布的评论链接并不能完全满足您对依赖项的要求.你非常合理地要求的是一种方法,让Spark可以很好地使用setuptools和pip来安装依赖项.我觉得Spark不能更好地支持这一点.第三方依赖问题在很大程度上是通用Python解决的,但在Spark下,似乎假设您将回到手动依赖管理或其他什么.

我一直在使用基于virtualenv的不完善但功能强大的管道.基本的想法是

1. 纯粹为您的Spark节点创建virtualenv
2. 每次运行Spark作业时,pip install都要运行所有自己的内部Python库.如果你已经设置了这些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作业.我先简单把这个脚本作为这一进程的一部分,并确保第二个参数(zip文件的名称),然后当我运行--py-文件参数传递spark-submit(如在注释中记录).我总是运行这些脚本,所以我永远不会意外地运行旧代码.与Spark开销相比,我的小规模项目的包装开销很小.

可以进行大量改进 - 例如,知道何时创建新的zip文件,将其拆分为两个zip文件,一个包含经常更改的私有包,一个包含很少更改的依赖项,这些都不需要经常重建.在重建zip之前,您可以更聪明地检查文件更改.检查参数的有效性也是一个好主意.但是现在这足以满足我的目的.

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

我已经在其他地方看到了在所有节点上运行像Anaconda这样的Python发行版的建议,因为它已经包含NumPy(以及许多其他包),这可能是获得NumPy以及其他基于C的扩展的更好方法.无论如何,我们不能总是期望Anaconda在正确的版本中拥有我们想要的PyPI包,此外你可能无法控制你的Spark环境以便能够将Anaconda放在它上面,所以我认为这是基于virtualenv的方法仍然有用.