В чем разница между sparksession.config () и spark.conf.set ()

Question

Я пытался использовать оба способа для установки spark.dynamicAllocation.minExecutors, но похоже, что работает только первый способ

spark2 = SparkSession \
  .builder \
  .appName("test") \
  .config("spark.dynamicAllocation.minExecutors", 15) \
  .getOrCreate()

против

spark2.conf.set("spark.dynamicAllocation.minExecutors", 15)

Answer 1

Речь идет не столько о разнице между методами, сколько о разнице в контексте, в которой они выполняются. Опции

• pyspark.sql.session.SparkSession.Builder могут быть выполнены до того, как приложение Sparkбыло начато.Это означает, что, если нет активного SparkSession для извлечения, некоторые специфические для кластера параметры все еще могут быть установлены.

  Если сеанс уже был инициализирован, установка новых параметров конфигурации может не работать.См., Например, Spark 2.0: переопределение параметров SparkSession с помощью GetOrCreate и НЕ видение изменений в WebUI

• pyspark.sql.conf.RuntimeConfig может быть получено только из завершающегося сеанса, поэтому его set метод вызывается после запуска кластера.На данный момент большинство параметров кластера заморожены и не могут быть изменены.

В общем случае RuntimeConfig.set используется для изменения параметров конфигурации spark.sql.*, которые обычно могут быть изменены во время выполнения.

Обратите внимание, что в зависимости от режима развертывания некоторые параметры (прежде всего spark.*.extraJavaOptions) не могут быть установлены с помощью любого из этих методов и могут быть изменены только с помощью spark-submit аргументов или с помощью файлов конфигурации.

Answer 2

Я думаю, вы бы предпочли спросить, почему некоторые конфигурации (например, spark.dynamicAllocation.minExecutors) нельзя установить с помощью spark2.conf.set против SparkSession.config?

spark.dynamicAllocation.minExecutors, чтобы контролировать, как выполнять задания Spark.Самое главное, чтобы контролировать количество исполнителей и, как таковой, не должны быть установлены в приложении Spark.Я даже удивлен, узнав, что это сработало.На самом деле это не должно быть ИМХО.

Причина, по которой эту и некоторые другие конфигурации не следует устанавливать в приложении Spark, заключается в том, что они управляют средой выполнения для базовой среды выполнения Spark (которая работала за кулисами Spark SQL).и как таковое должно быть изменено с помощью spark-submit, что больше для разработчиков приложений или администраторов, чем для самих разработчиков.Независимо от того, используется динамическое распределение (исполнителей) или нет, это не влияет на деловое использование Spark и является решением, которое необходимо принять после разработки приложения.

С учетом сказанного позвольте мне ответить на ваш вопрос напрямую,некоторые конфигурации необходимо настроить до создания экземпляра SparkSession, поскольку они управляют тем, как будет создаваться этот экземпляр.После того, как вы создали экземпляр, при вызове spark2.conf экземпляр уже настроен, и некоторые конфигурации невозможно изменить никогда.Кажется, что spark.dynamicAllocation.minExecutors входит в число конфигураций, которые нельзя изменить после создания экземпляра SparkSession.И учитывая то, что я сказал ранее, я рад слышать, что это так (но, к сожалению, не во всех случаях).

Answer 3

Некоторые свойства конфигурации должны быть установлены до начала SparkSession, чтобы они работали.Sparksession использует их во время инициализации.Если вы установили spark.dynamicAllocation.minExecutors после создания sparksession, все равно произойдет изменение значения этого свойства в объекте sparConf, и вы можете проверить это, напечатав свойство, но это не повлияет на сеанс sparksession, так как оно приняло значениеприсутствует во время инициализации.