Spark Application - Управление банками зависимостей - PullRequest
0 голосов
/ 16 октября 2019

Я новичок в поиске и ищу лучшие практики по управлению банками зависимостей

Есть несколько вариантов, которые я могу придумать

  1. Включить все (приложение и сторонние разработчики)jars) в толстом jar

Pros : Зависимости контролируются через файл maven pom, какие jar-зависимости зависимостей мы используем для компиляции, сборки и тестирования, переходят в разные среды (QA / Prod и т. Д.)

Минусы : поскольку это толстая банка, репозиторий maven заполняется, требуется время для сборки и переноса банки из машины сборки в машину развертывания и т. Д.

В банке находится только код приложения, а файлы сторонних производителей экспортируются как --conf spark.executor.extraClassPath =

Плюсы : файл приложениямаленький, его легко собрать и перенести из сборки в целевые среды

Минусы : может привести к несоответствию между списком зависимостей maven pom и списком имен jar, указанных в списке classpath, также необходимо сделатьверные версии не повреждены

Мы используем дистрибутив Cloudera и используем Spark 2.3.0

Также в обоих случаях нам не нужно включать spark, по умолчанию Jar-файлы, связанные с Hadoop, будутдоступно в spark executors, поэтому нет необходимости переносить его в executor каждый раз, когда мы запускаем spark-приложение, верно?

Откуда мы знаем, какие все jar-файлы зависимостей по умолчанию будут доступны в (Cloudera) spark executorчтобы мы не экспортировали и не включали его в толстую банкувместо того, чтобы хранить jars в клиентском / пограничном узле и экспортировать их оттуда?

Есть ли лучшие рекомендации или рекомендации? Любая ссылка приветствуется?

1 Ответ

0 голосов
/ 16 октября 2019

Здесь много вопросов, но я постараюсь их охватить.

Также в обоих случаях нам не нужно включать spark, jar-файлы, связанные с hadoop, по умолчанию будут доступны в искровых исполнителях, поэтому нетВам нужно передавать его исполнителю каждый раз, когда мы запускаем приложение spark, верно?

Все необходимые jar для hasdop и т. д. включены в репозитории Cloudera на каждом узле, поэтому вам не нужно их копироватьили включите их в свою искру представить. Единственное, что вам, возможно, придется сделать, это определить SPARK_HOME с правильным путем для вашего дистрибутива cloudera (в cloudera также есть различие между Spark 1.6 и 2.0+, поэтому убедитесь, что вы используете правильный SPARK_HOME).

Например, для CM 5.10 дом Spark для экспорта в Spark 2 выглядит следующим образом:

export SPARK_HOME="/cloudera/parcels/SPARK2/lib/spark2"

откуда мы знаем, какие все банки зависимостей по умолчанию будут доступны в (cloudera) искровом исполнителе, такчто мы не экспортируем и не включаем его в толстый jar

Вы можете перейти в каталог coresponding в cloudera, где хранятся jar-файлы. Вы можете проверить существующие jar с помощью:

ls /cloudera/parcels/SPARK2/lib/spark2/jars

Всегда есть простой способ запустить что-то, и если jar отсутствует, вы увидите это в ошибке выполнения.

хорошо хранить сторонние файлы jar в hdfs и экспортировать их в classpath, вместо того чтобы хранить файлы jar в клиентском / граничном узле и экспортировать их оттуда?

Добавление файлов в jar является почти плохой идеейclaspath по умолчанию, потому что classpath - это область с корневым доступом, поэтому вам придется попросить своих администраторов добавить туда файлы (что замедляет работу), и я не уверен, что произойдет в случае обновления до более поздней версии. Вы можете создать дополнительный репозиторий во всех узлах, где вы можете хранить все дополнительные файлы jar, которые нужны вашему приложению, и создать простой сценарий sftp для распределения всех файлов jar по этому пути на всех машинах.

Затем добавьте в свой conf /spark-defaults.conf

spark.driver.extraClassPath /my_extra_jars_path/* 
spark.executor.extraClassPath /my_extra_jars_path/*

или на вашей свече отправьте опцию add --jars с указанием полного пути всех разделенных запятыми банок.

Альтернатива для хранения дополнительных банок в Hdfs itбыло бы очень хорошо, но я не использовал его.

Между этими двумя вариантами я бы посоветовал не включать все зависимости в Jar и иметь медленное время сборки и распространения и иметь легкий jar только с соответствующим кодом иуправляйте зависимостями с помощью сценария распространения simle sftp для копирования jar-файлов во все узлы в выделенном каталоге (или в hdfs, если это возможно).

...