Тупик, коли одночасно заплановано багато іскрових завдань


17

Використання іскри 2.4.4, що працює в режимі кластера YARN з планувальником іскри FIFO.

Я надсилаю кілька операцій з фреймом даних іскри (тобто записування даних у S3) за допомогою виконавця пулу потоків зі змінною кількістю потоків. Це добре працює, якщо у мене є ~ 10 потоків, але якщо я використовую сотні ниток, виявляється, що виникає глухий кут, і ніякі завдання не плануються відповідно до інтерфейсу Spark.

Які фактори контролюють, скільки робочих місць можна запланувати одночасно? Ресурси драйвера (наприклад, пам'ять / ядра)? Деякі інші настройки конфігурації іскри?

Редагувати:

Ось короткий конспект мого коду

ExecutorService pool = Executors.newFixedThreadPool(nThreads);
ExecutorCompletionService<Void> ecs = new ExecutorCompletionService<>(pool);

Dataset<Row> aHugeDf = spark.read.json(hundredsOfPaths);

List<Future<Void>> futures = listOfSeveralHundredThings
  .stream()
  .map(aThing -> ecs.submit(() -> {
    df
      .filter(col("some_column").equalTo(aThing))
      .write()
      .format("org.apache.hudi")
      .options(writeOptions)
      .save(outputPathFor(aThing));
    return null;
  }))
  .collect(Collectors.toList());

IntStream.range(0, futures.size()).forEach(i -> ecs.poll(30, TimeUnit.MINUTES));
exec.shutdownNow();

У якийсь момент, у міру nThreadsзбільшення, іскра вже не здається, що вона планує будь-які робочі місця, про що свідчить:

  • ecs.poll(...) час закінчується
  • На вкладці Завдання Іскрового інтерфейсу не відображаються активні завдання
  • Вкладка "Іскрові користувачі інтерфейсу" не показує жодних активних завдань жодному виконавцю
  • Вкладка Spark UI SQL, що показує nThreadsзапущені запити без ідентифікаторів виконуваного завдання

Моє середовище виконання

  • AWS EMR 5.28.1
  • Іскра 2.4.4
  • Головний вузол = m5.4xlarge
  • Основні вузли = 3x rd5.24xlarge
  • spark.driver.cores=24
  • spark.driver.memory=32g
  • spark.executor.memory=21g
  • spark.scheduler.mode=FIFO


Чи є конкретний розділ, який обговорює це? Я прочитав ці документи кілька разів за останні кілька днів і не знайшов відповіді, яку шукаю.
Скотт

2
Чи можете ви, будь-ласка, показати код, який ви використовуєте для подання завдань Spark через виконавця пулу потоків? Здається, тупик відбувається до подання завдання Spark.
Салим

1
Чи можете ви опублікувати свій код? Вкажіть, будь ласка, детальну інформацію про ваше оточення: процесор, оперативна пам’ять; також як ви створюєте нитки: одночасно або в невеликих групах по 10?
Сахед

Вибачте, як ви маєте на увазі, що завдання не заплановані? Вони не відображаються у інтерфейсі Spark або вони відображаються у списку завдань, але завдання не виконуються? У будь-якому випадку, якщо ви підозрюєте про тупик, будь ласка, запустіть, jstack -lщоб отримати дамп потоку з інформацією про блокування.
Даніель Дарабос

Відповіді:


0

Якщо можливо, напишіть вихідні завдання в AWS Elastic MapReduce hdfs (щоб скористатися майже миттєвими перейменами та кращим файлом IO локальних hdfs) та додайте крок dstcp для переміщення файлів у S3, щоб заощадити всі проблеми з керуванням Внутрішні об'єкти магазину намагаються бути файловою системою. Крім того, запис на локальний hdfs дозволить вам дозволити спекуляціям контролювати утікаючі завдання, не потрапляючи в тупикові пастки, пов'язані з DirectOutputCommiter.

Якщо ви повинні використовувати S3 в якості вихідного каталогу, переконайтеся, що встановлені наступні конфігурації Spark

spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version 2
spark.speculation false

Примітка: DirectParquetOutputCommitter видаляється з Spark 2.0 через ймовірність втрати даних. На жаль, поки ми не покращили узгодженість з S3a, нам доведеться працювати з обхідними шляхами. З Hadoop 2.8 все покращується

Уникайте ключових слів у лексикографічному порядку. Можна обійтися хешшю / випадковими префіксами або зворотним часом-датою, щоб обійти їх. Трюк полягає в тому, щоб назвати свої ключі ієрархічно, поставивши найпоширеніші речі, за якими ви фільтруєте, ліворуч від вашої клавіші. І ніколи не слід підкреслювати назви відра через проблеми з DNS.

Включення fs.s3a.fast.upload uploadчастин одного файлу в Amazon S3 паралельно

Перегляньте ці статті для більш детальної інформації -

Встановлення spark.speculation в Spark 2.1.0 під час запису на s3

https://medium.com/@subhojit20_27731/apache-spark-and-amazon-s3-gotchas-and-best-practices-a767242f3d98


AWS має свій власний програму docs.aws.amazon.com/emr/latest/ReleaseGuide/…
mazaneicha

0

IMO, ви, ймовірно, підходите до цієї проблеми неправильно. Якщо ви не зможете гарантувати, що кількість завдань на одну роботу є дуже низькою, ви, швидше за все, не отримаєте значного поліпшення продуктивності, паралелізуючи одразу 100 робіт. Ваш кластер може підтримувати лише 300 завдань одночасно, припускаючи, що ви використовуєте паралелізм за замовчуванням у 200, що становить лише 1,5 завдання. Я б запропонував переписати ваш код, щоб обмежити максимум одночасних запитів на 10. Я дуже підозрюю, що у вас є 300 запитів із виконанням лише однієї задачі з декількох сотень. Більшість OLTP-систем обробки даних навмисно мають досить низький рівень одночасних запитів порівняно з більш традиційними системами RDS з цієї причини.

також

  1. Apache Hudi має паралелізм за замовчуванням у декілька сотень FYI.
  2. Чому ви просто не розділите на базі фільтру?
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.