运维开发网

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

运维开发网 https://www.qedev.com 2020-05-18 14:51 出处:网络
我知道您可以使用 Python Spark程序将各个文件作为依赖项发送.但是完全成熟的图书馆(例如numpy)呢? Spark是否有办法使用提供的包管理器(例如pip)来安装库依赖项?或者这是否必须在执行Spark程序之前手动完成? 如果答案是手动的,那么在大量分布式节点上同步库(安装路径,版本等)的“最佳实践”方法是什么? 实际上已经尝试过了,我认为我发布的评论链接并没有完全符合你想要的依赖关系
我知道您可以使用 Python Spark程序将各个文件作为依赖项发送.但是完全成熟的图书馆(例如numpy)呢?

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

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

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

我一直在使用基于Virtualenv的不完善但功能强大的管道.基本思路是

>仅为Spark节点创建Virtualenv

>每次运行Spark作业时,都要运行所有内部Python库的新pip安装.如果您使用setuptools设置了这些,则会安装它们的依赖项

>压缩Virtualenv的网站包dir.这将包括您的库及其依赖项,工作节点将需要它们,但不包括它们已有的标准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作业.我只是首先调用此脚本作为该过程的一部分,并确保在我运行spark-submit时将第二个参数(zip文件的名称)作为–py-files参数传递(如注释中所述).我总是运行这些脚本,所以我永远不会意外地运行旧代码.与Spark开销相比,我的小规模项目的包装开销很小.

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

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

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

0

精彩评论

暂无评论...
验证码 换一张
取 消