Apache HAWQ: эволюция MPP

Архитектура Apache HDFS Spark

предисловие

Когда я недавно изучал Hive и Impala, я обнаружил, что их методы расчета различаются. Hive использует Map Reduce или Tez для выполнения задач, а Impala использует MPP. Раньше я знал о MPP в классе, но не очень хорошо, поэтому я проверил много информации в интернете. Наконец нашел этот английский блог лучшеApache HAWQ, сравнение этих двух также более подробное, и я переведу его здесь, чтобы углубить свое понимание.

текст

Apache HAWQ(incubating)Первая версия выиграла от организации ASF (основа программного обеспечения Apache), эффективно сочетая MPP (массивно-параллельную обработку) и пакетную систему (пакетную систему), было достигнуто значительное улучшение производительности и преодолены некоторые ключевые ограничения. Новый переработанный исполнительный механизм значительно улучшил общую производительность системы в следующих областях:

  • Проблемы с короткой платой, вызванные аппаратными ошибками (отставание)
  • Ограничение параллелизма
  • Необходимость хранения промежуточных данных
  • Расширяемость
  • скорость выполнения

Разработка Pivotal HAWQ основана наБаза данных GreenPlumФорк , пока (август 2016) более 3 лет. Основная цель — запустить операторы SQL в кластере Hadoop для запроса данных, хранящихся в HDFS. Многие улучшения HAWQ были представлены в первом общедоступном выпуске три года назад. Но для механизма выполнения запросов Pivotal HAWQ по-прежнему использует ту же архитектуру, что и GreenPlum — механизм выполнения MPP.

Базовый код HAWQ был внесен в проект ASF и остаетсяPiotal HDB(Мы предоставляем коммерческую поддержку собственного SQL Hadoop). На этой неделе Hortonworks только что анонсировала продукт с поддержкой HAWQ в партнерстве с Pivotal.

В этом посте я представлю основную идею новой архитектуры дизайна Apache HAWQ.

МПП-архитектура

Первоначальная идея решения MPP заключалась в том, чтобы исключить общие ресурсы. Каждый исполнитель имеет отдельные ресурсы ЦП, памяти и жесткого диска. Один исполнитель не может получить прямой доступ к ресурсам другого исполнителя, кроме как посредством контролируемого обмена данными по сети. Эта независимая от ресурсов концепция прекрасно решает проблему масштабируемости архитектуры MPP.

Второй важной концепцией MPP является параллелизм. Каждый исполнитель выполняет одну и ту же логику обработки данных, используя частные блоки данных в локальном хранилище. Есть некоторые точки синхронизации между разными фазами выполнения (Мое понимание: если вы понимаете механизм Java GC, вы можете сравнить stop-the-world в GC, В этой точке синхронизации все исполнители находятся в состоянии ожидания.), эти точки синхронизации обычно используются для обмена данными (например, фаза перемешивания в Spark и MapReduce). Вот пример классической временной шкалы запроса MPP: Каждая вертикальная пунктирная линия — это точка синхронизации. Например, на этапе синхронизации данные должны быть «перемешаны» в кластере для операций объединения и агрегирования, поэтому на этапе синхронизации могут выполняться некоторые операции агрегирования данных, объединения таблиц и сортировки данных, в то время как каждый исполнитель выполняет остальную часть вычислений. .

Недостатки конструкции МПП

Однако у такой конструкции есть главная проблема всех решений MPP — эффект короткой доски. Если узел всегда выполняется медленнее, чем другие узлы в кластере, производительность всего кластера будет ограничена скоростью выполнения неисправного узла (так называемый эффект бочки с короткой доской). находятся в кластере, улучшений не будет. Вот пример, показывающий, как отказавший узел (Executor 7 на изображении ниже) может замедлить выполнение кластера.

В большинстве случаев все исполнители, кроме Исполнителя 7, простаивают. Это потому, что все они ждут, пока Executor 7 завершит выполнение процесса синхронизации, что является корнем нашей проблемы. Например, когда производительность RAID узла в системе MPP очень низкая из-за проблем с диском или проблем с производительностью ЦП, вызванных аппаратными или системными проблемами, такие проблемы возникнут. Все системы MPP сталкиваются с этой проблемой.

Если вы посмотрите на GoogleОтчет о частоте ошибок диска, можно обнаружить, что при наблюдаемом AFR (годовая частота отказов, годовая частота отказов) в лучшем случае диск выйдет из строя на 20% в течение 3 месяцев после первого использования.

Если в кластере 1000 дисков, будет 20 сбоев в год или один сбой каждые две недели. С 2000 дисками у вас будут сбои каждую неделю, с 4000 у вас будут сбои два раза в неделю. После двух лет использования вы умножите это число на 4, что означает, что кластер из 1000 дисков будет выходить из строя два раза в неделю.

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

Более важным отличием MPP от пакетных решений, таких как MapReduce, является степень параллелизма. Параллелизм — это количество запросов, которые могут эффективно выполняться одновременно. MPP идеально симметричен: при выполнении запроса каждый узел в кластере одновременно выполняет одну и ту же задачу. Это означает, что параллелизм кластера MPP не имеет ничего общего с количеством узлов в кластере. Например, кластер из 4 узлов и кластер из 400 узлов будут поддерживать один и тот же уровень параллелизма, и они будут деградировать практически в один и тот же момент. Ниже приведен пример того, о чем я говорю.

Как видите, 10-18 параллельных сеансов запросов дают максимальную пропускную способность всего кластера. Если вы увеличите количество сеансов выше 20, пропускная способность будет медленно падать до 70% или даже ниже. Здесь указано, что пропускная способность — это количество однотипных задач запроса, выполняемых в течение фиксированного интервала времени (достаточно продолжительного для получения репрезентативного результата).Команда YahooАналогичный результат теста был получен при исследовании ограничений параллелизма Impala. Impala — это MPP-движок на базе Hadoop. Таким образом, более низкий параллелизм — это то, что должна нести схема MPP, чтобы обеспечить низкую задержку запросов и высокую скорость обработки данных.

пакетная архитектура

Для решения этой проблемы вместе сMaprecuce PaperПубликация и появление производных технологий родило новое решение. Этот принцип проектирования был применен кApache Hadoop MapReduce,Apache Sparkи другие инструменты. Основная идея состоит в том, чтобы разделить каждый отдельный этап выполнения («шаг») между двумя точками синхронизации на ряд независимых «задач», количество «задач» совершенно не связано с количеством пола «исполнителей». Например, в HDFS количество «задач» MapReduce равно количеству фрагментов входного файла, то есть равно количеству блоков HDFS (на одном узле), соответствующих входному файлу. Между точками синхронизации эти «задачи» случайным образом назначаются свободным «исполнителям». Напротив, каждая задача в MPP, которая обрабатывает данные, привязана к указанному исполнителю, содержащему срез данных. Точка синхронизации MapReduce выполняет запуск, перемешивание и остановку задания. для апача Для Spark точки синхронизации выполняют запуск задания, перемешивание, кэширование набора данных и остановку задания. На рисунке ниже показан пример работы Apache Spark.Каждая полоса разного цвета представляет собой отдельную задачу, и каждый исполнитель может выполнять 3 задачи параллельно.

Вы можете видеть, что Executor 3 является неисправным узлом — он выполняет задачи примерно в два раза медленнее, чем другие Executors. Но это не проблема, Executor 3 будет постепенно выделять меньше задач для выполнения. Если проблема более серьезная,Спекулятивное исполнениебудет работать, задачи на медленных узлах будут перевыполняться на других узлах (Один из механизмов MapReduce: если выполнение задачи занимает слишком много времени, она повторно запустит задачу на других узлах и возьмет результат задачи, которая завершится первой.).

Этот метод (спекулятивное выполнение) возможен из-за использования общего хранилища. Чтобы обработать часть данных, вам не нужно хранить эту часть данных на указанной вами машине. Вместо этого вы можете получить необходимые блоки данных с удаленного узла. Конечно, удаленная обработка всегда дороже локальной, потому что данные нужно перемещать, поэтому машинные узлы максимально обрабатывают данные локально. Но для предотвращения неисправных узлов и завершения пакетного процесса спекулятивное выполнение решит проблему неисправных узлов, совершенно неразрешимую в MPP.

Вот спекулятивное исполнение в облакеИсследование.

Эта диаграмма показывает производительность программы WordCount. Как видите, спекулятивное выполнение ускоряет выполнение в 2,5 раза в облачной среде, в то время как облачная средаЭффект короткой доскихорошо известен. Сочетание общего хранилища и более детального планирования (задач) делает пакетные системы более масштабируемыми, чем кластеры MPP, поддерживая тысячи узлов и десятки тысяч жестких дисков.

Проблемы с пакетной архитектурой

Однако за все приходится платить.В MPP вам не нужно записывать промежуточные данные на жесткий диск, потому что один Executor обрабатывает только одну задачу, поэтому вы можете просто передавать данные непосредственно на следующий этап выполнения. Это называется "конвейерной обработкой" и обеспечивает значительный прирост производительности.

Как упоминалось в обсуждении в блоге Даниэля, для реализации операции объединения двух больших таблиц Spark запишет на жесткий диск 3 раза (1. Таблица 1 перемешивается в соответствии с ключом соединения 2. Таблица 2 перемешивается в соответствии с ключом соединения 3. Хэш запись таблицы на жесткий диск), в то время как MPP требуется только одна запись (запись хеш-таблицы). Это связано с тем, что MPP запускает маппер и редюсер одновременно, а MapReduce делит их на зависимые задачи (DAG), эти задачи выполняются асинхронно, поэтому зависимости данных должны разрешаться путем записи промежуточных данных в разделяемую память.

Когда у вас есть несколько несвязанных задач, и они могут выполняться последовательно на одном исполнителе, например, при пакетной обработке, вы исключаетеХранить промежуточные данные на локальном диске, У вас нет выбора. Следующий этап выполнения будет считывать промежуточные данные с локального диска и обрабатывать их. Это также то, что делает систему медленнее.

Из того, что я знаю из опыта, при сравнении производительности современной MPP-системы и Spark на идентичном аппаратном кластере Spark обычно в 3-5 раз медленнее. Кластер MPP из 50 машин обеспечит примерно ту же вычислительную мощность, что и Spark с 250 узлами, но Spark может масштабироваться за пределы 250 узлов, что невозможно с MPP.

Объединение MPP и пакетной обработки

Теперь мы можем увидеть сильные и слабые стороны обеих архитектур. MPP быстрее, но у него есть две ключевые болевые точки — эффекты короткой доски и ограничения параллелизма. Для пакетных систем, таких как MapReduce, нам нужно тратить время на хранение промежуточных данных на диске, но в то же время мы получаем более высокую степень масштабируемости и, следовательно, гораздо больший размер кластера, чем MPP. Как мы можем объединить эти два подхода, чтобы получить MPP с малой задержкой и высокой скоростью обработки, а также использовать пакетную структуру, чтобы уменьшить эффекты короткой доски и проблемы с параллелизмом? Я думаю, вы не удивитесь, если я скажу, что ответ — новая архитектура Apache HAWQ.

Опять же, вопрос в том, как выполняется запрос MPP? Один и тот же код запускается определенным количеством параллельных процессов выполнения, количество процессов точно совпадает с количеством узлов в кластере, и на каждом узле обрабатываются локальные данные. Однако, когда мы ввели HDFS, вы не привязывали данные к локальному Исполнителю, а значит, можете избавиться от ограничения на количество Исполнителей, и вам не нужно обрабатывать локально существующие данные на фиксированной ноде (В традиционном MPP нельзя обрабатывать данные с удаленных узлов.) Почему? Поскольку HDFS по умолчанию хранит 3 резервных копии для одного и того же блока, а это означает, что в кластере есть как минимум 3 узла, вы можете создать Executor и обрабатывать локальные данные. Более того, HDFS поддерживает удаленное считывание данных, а это означает, что как минимум две стойки могут обрабатывать данные на локальной стойке, так что данные можно получить удаленно через наименьшее количество топологий.

Вот почему Apache HAWQ предлагает концепцию «виртуальных сегментов» — «сегмент» в GreenPlum — это отдельный экземпляр в улучшенной версии базы данных PostgreSQL, который существует на каждом узле и генерируется в каждом процессе «исполнителя» запроса. Если у вас небольшой запрос, его могут выполнять 4 исполнителя или даже один. Если у вас есть большой запрос, вы можете выполнить его с сотнями или даже тысячами исполнителей. Каждый запрос по-прежнему обрабатывает локальные данные в стиле MPP и не требует записи промежуточных данных на жесткий диск, а требует «виртуального «сегменты» позволяют исполнителю работать где угодно. Ниже приведен рабочий пример (разные цвета обозначают разные запросы, пунктирные линии обозначают операции перемешивания в запросе)

Это дает вам следующие свойства:

  1. Сокращение короткой доски для систем MPP: потому что мы можем динамически добавлять узлы и удалять узлы. Поэтому серьезные отказы дисков не повлияют на производительность всего кластера, а система может иметь больший уровень кластеров, чем традиционные MPP. Теперь мы можем временно удалить неисправную ноду из кластера, тогда на ней запустится больше Исполнителей. Также нет простоев при удалении узла.
  2. Запрос теперь выполняется динамическим числом исполнителей, что приводит к более высокой степени параллелизма, снимает ограничения системы MPP и добавляет гибкости пакетной системе. Представьте себе кластер из 50 узлов, каждый узел может запускать до 200 параллельных процессов. Это означает, что у вас есть в общей сложности «50 * 200 = 10 000» «слотов выполнения». Вы можете запустить 20 запросов с 500 исполнителями, вы можете запустить 200 запросов с 50 исполнителями или даже 1 запрос с 10 000 исполнителей. Здесь он полностью гибкий и управляемый. У вас также может быть большой запрос, который использует 4000 сегментов, и 600 небольших запросов, для каждого из которых требуется 10 исполнителей, что тоже нормально.
  3. Идеальное приложение для конвейеров данных: передача данных от одного исполнителя к другому в режиме реального времени. На этапе выполнения отдельные запросы по-прежнему являются MPP, а не пакетами. Следовательно, нет необходимости хранить промежуточные данные на локальном диске (операции позволяют использовать конвейеры данных, когда это возможно). Это означает, что мы на шаг ближе к скорости MPP.
  4. Как и MPP, мы по-прежнему максимально используем локальные данные для выполнения запросов, что можно сделать с помощью быстрого чтения HDFS (когда клиент и данные находятся на одном узле, DataNode можно обойти, напрямую прочитав локальный файл, см.HDFS Short-Circuit Local Reads)реализовать. Каждый исполнитель будет создан и выполнен на узле с наибольшим количеством блоков в файле, что также максимизирует эффективность выполнения.

понять больше

Apache HAWQ предлагает новый дизайн, который представляет собой комбинацию MPP и пакетной обработки, объединяющую преимущества обоих и компенсирующую основные недостатки каждого из них. Конечно, идеального решения для обработки данных не существует — MPP по-прежнему быстрее, а пакетная обработка по-прежнему обладает более высокой параллелизмом и масштабируемостью. Вот почему выбор конкретного решения для конкретного сценария является ключевым, и у нас есть много экспертов для поддержки. Для более глубокого понимания вы можете прочитатьВведение в архитектуру Apache HAWQ, также смздесьа такжездесь.

впечатление

У MPP и Batch есть свои преимущества и недостатки. Как сказано в исходном тексте, идеального решения не существует. Ключ в том, чтобы выбрать подходящую архитектуру для вашей собственной сцены. Если есть более высокие требования к производительности в реальном времени и размер кластера не очень большой, вы можете выбрать использование структуры MPP, которая обеспечит более высокую скорость запросов, если размер кластера большой, он имеет более высокую масштабируемость. вы можете выбрать архитектуру пакетного типа (например, Spark). Можно сказать, что HAWQ нейтрализует преимущества и недостатки этих двух и обеспечивает решение со сбалансированной производительностью.Я лично думаю, что он более склонен к стилю дизайна MPP, но для того, чтобы решить его дефекты масштабируемости и эффекты короткой платы, дизайн вводится идея Batch, которая частично улучшает масштабируемость и больше не ограничивается выполнением запросов фиксированным числом исполнителей. В разделе комментариев 3-го блога справки Дэниэлс также провел бурную дискуссию по Spark и MPP, по их словам, каждая технология постоянно развивается, не будучи «упакованной в коробку», разница между MPP и Batch будет больше не будет столь очевидным, и Spark также работает в направлении MPP, чтобы обеспечить более высокую скорость запросов. Считается, что будущее технологическое развитие постепенно сократит разрыв между ними и обеспечит более совершенное решение.

использованная литература

  1. hadoop vs MPP
  2. Знать почти ответил: Какая связь между Hadoop и MPP
  3. Apache Spark Future(Сосредоточьтесь на процессе обсуждения Даниэля)
Категории