自己写了个算法，算法所需的运行环境用conda打了个zip包，扔到了hadoop上。在spark上运行用如下命令。
这里为什么是个zip包呢？ 这样每次运行还得解压，不是浪费时间吗？
不能提前把conda环境在hadoop上解压，每次直接运行吗？

命令：
spark-submit --master yarn \
    --deploy-mode cluster   \
    --num-executors=8  \
    --executor-memory=10g  \
    --executor-cores=2  \
    --driver-memory=4g  \
    --conf spark.pyspark.python=./scoenv/scoenv/bin/python3.6   \
    --archives hdfs:/user/xx/xx//scoenv.zip#scoenv  \
    --py-files demo.zip spark_driver.py xxx
--
FROM 223.104.40.*

是的， 所以我才来问问，都有哪些原因非要这么做。而这些原因，是不是我能接受的

像你说的这些因素，我觉得可以接受。因为我们的运行环境确定后，基本不会变。使用者只会在固定的运行环境下运行成百上千使用固定算法的模型。

【 在 JulyClyde 的大作中提到: 】
: 有这种思想说明你缺乏运维思维
: 试想几种场景：
: 1 你的运行包将来要升级
: ...................
--
FROM 223.104.40.*

不是算法包的解压，算法包那一点还没有什么问题，是算法运行环境每次解压。一个conda环境，快10G了。

【 在 dyingsun 的大作中提到: 】
: 没用过pyspark，以前用过scala的，留下一点印象。
: 我的理解：
: 第一，分布式计算框架，是把分布式和单次计算两部分分开，这样有利于部署和运维。
: ...................
--
FROM 223.104.40.*

conda运行环境快10个G了
确实每个模型的运行时长不太长，短的1分钟，长的不到20分钟，确实感觉可以不上hadoop。不过遗留架构，不敢随便改

【 在 YYW 的大作中提到: 】
: 我的hadoop知识比较老旧，如果有讲错的请不吝赐教：
: 1. 如果把算法环境部署到每一个data node上，其实破坏了节点环境的独立性，它应该普遍适用于业务的计算要求，不被某个计算任务影响。集群的使用者也不应该有权限去影响节点的部署。破坏了这个规则，多用户、多任务就不可控。
: 2. 如果把算法包解压缩放到hdfs... hdfs的文件存储是分块的，块的大小可以设置，比如128M。一个大文件会拆分为若干128M的块，存储在各data node上，分块的信息、存储在哪里，类似的信息保持在name node。如果将类似py venv的小文件包不压缩放在hdfs上，会浪费
: ...................
--
FROM 223.104.40.*