Я новачок в Apache Spark, і я щойно дізнався, що Spark підтримує три типи кластера:
Оскільки я новачок у Spark, думаю, спочатку слід спробувати автономний . Але мені цікаво, який із них рекомендується. Скажімо, у майбутньому мені потрібно створити великий кластер (сотні екземплярів), до якого типу кластера мені піти?
Відповіді:
Я думаю, що найкраще відповісти на це тим, хто працює над Spark. Отже, від Learning Spark
Почніть з автономного кластера, якщо це нове розгортання. Автономний режим найпростіший у налаштуванні і надаватиме майже всі ті ж функції, що й інші менеджери кластерів, якщо ви використовуєте лише Spark.
Якщо ви хочете запустити Spark поряд з іншими програмами або скористатися розширеними можливостями планування ресурсів (наприклад, черги), ці функції пропонують як YARN, так і Mesos. З них YARN, швидше за все, буде попередньо встановлено у багатьох дистрибутивах Hadoop.
Однією з переваг Mesos перед YARN і автономним режимом є його дрібний параметр спільного доступу, який дозволяє інтерактивним програмам, таким як оболонка Spark, зменшувати розподіл ЦП між командами. Це робить його привабливим в середовищах, де кілька користувачів використовують інтерактивні оболонки.
У всіх випадках найкраще запускати Spark на тих самих вузлах, що і HDFS, для швидкого доступу до сховища. Ви можете встановити Mesos або автономний диспетчер кластерів на ті самі вузли вручну, або більшість дистрибутивів Hadoop вже встановлюють YARN та HDFS разом.
Spark Standalone Manager : Простий менеджер кластерів, що входить до складу Spark, що полегшує налаштування кластера. За замовчуванням кожна програма використовує всі доступні вузли в кластері.
Кілька переваг Пряжі перед автономними та Mesos:
YARN дозволяє динамічно спільно використовувати та централізовано конфігурувати один і той же пул ресурсів кластера між усіма фреймворками, які працюють на YARN .
Ви можете скористатися всіма можливостями планувальників YARN для категоризації, ізоляції та встановлення пріоритетів робочих навантажень.
Режим іскрового автономного вимагає , щоб кожне додатки для запуску виконавця на кожен вузлі в кластері; тоді як із YARN ви вибираєте кількість виконавців, які використовуватимуться
YARN безпосередньо обробляє стійку та місцезнаходження машини у ваших запитах, що зручно.
Модель запиту ресурсу, як не дивно, у Mesos є зворотною . У YARN ви (фреймворк) запитуєте контейнери із заданою специфікацією та надаєте переваги місцевості. У Mesos ви отримуєте "пропозиції" ресурсів і приймаєте або відхиляєте пропозиції на основі власної політики планування. Модель Месоса є, можливо, більш гнучкою, але, здавалося б, більшою роботою для людини, яка впроваджує фреймворк.
Якщо у вас є великий кластер Hadoop, YARN - кращий вибір.
Менеджер Standalone вимагає призначеного для користувача конфігурації кожного з вузлів із загальним секретом. Модуль автентифікації за замовчуванням Mesos , Cyrus SASL, можна замінити на спеціальний модуль. YARN має захист для автентифікації, авторизації рівня обслуговування, автентифікації веб-консолей та конфіденційності даних. Аутентифікація Hadoop використовує Kerberos для перевірки автентифікації кожного користувача та служби Kerberos.
Корисні посилання:
сторінка документації про іскру
стаття agildata
Автономний досить зрозумілий, як і інші згадані, його слід використовувати лише тоді, коли у вас є лише робоче навантаження.
Між пряжею та мезо, слід врахувати той факт, що на відміну від mapreduce, іскрові завдання захоплюють виконавців і утримують його протягом усього життя роботи. де в mapreduce робота може отримати та випустити картографувачі та редуктори протягом усього життя.
якщо у вас тривалий час працюють іскрові завдання, які протягом життя роботи не повністю використовують усі ресурси, отримані на початку, можливо, ви захочете поділитися цими ресурсами з іншою програмою, і це можна зробити лише за допомогою Mesos або Spark динамічного планування . https://spark.apache.org/docs/2.0.2/job-scheduling.html#scheduling-across-applications Отже, з пряжею єдиним способом динамічного розподілу іскри є використання динамічного розподілу за умови іскри. Пряжа не буде втручатися в це, поки Месос буде. Знову ж таки, весь цей момент важливий лише у тому випадку, якщо у вас є давно запущена програма іскр, і ви хочете динамічно масштабувати її вгору та вниз.
Mesos має більш складний дизайн планування, що дозволяє програмам, таким як Spark, домовлятися з ним. Сьогодні це більше підходить для різноманітності програм. Я знайшов цей сайт справді проникливим:
https://www.oreilly.com/ideas/a-tale-of-two-clusters-mesos-and-yarn
"... YARN оптимізовано для планування завдань Hadoop, які є історичними (і все ще зазвичай) пакетними завданнями з тривалим часом. Це означає, що YARN не був розроблений для довготривалих служб, а також для короткочасних інтерактивних запитів (наприклад, невеликих і швидкі завдання Spark), і хоча це можливо, щоб він планував інші види робочих навантажень, це не ідеальна модель. Вимоги до ресурсів, модель виконання та архітектурні вимоги MapReduce сильно відрізняються від вимог довготривалих служб, таких як як веб-сервери або додатки SOA, або робочі навантаження в режимі реального часу, такі як Spark або Storm ... "