Импала против Spark производительность для специальных запросов

Question

Меня интересуют только причины производительности запросов и связанные с ними архитектурные различия. Все ответы, которые я видел ранее, были устаревшими или не предоставили мне достаточного контекста, почему Impala лучше подходит для специальных запросов.

Из 3 соображений, приведенных ниже, только во 2-м пункте объясняется, почему Impala быстрее в больших наборах данных. , Не могли бы вы внести свой вклад в следующие утверждения?

1. Impala не упускает время для предварительной инициализации запроса, что означает, что демоны Impalad всегда работают и готовы. С другой стороны, Сервер заданий Spark обеспечивает постоянный контекст для тех же целей.

2. Импала находится в оперативной памяти и может выливать данные на диск с потерей производительности, когдаУ данных недостаточно оперативной памяти. То же самое относится и к Spark. Основным отличием является то, что Spark написан на Scala и имеет ограничения JVM, поэтому не рекомендуется использовать работники размером более 32 ГБ (из-за GC). В свою очередь, [неправильно, см. UPD] Impala реализована на C ++ и имеет высокие требования к оборудованию : 128-256 + ГБОЗУ рекомендуется. Это очень важно, но может принести пользу Impala только для наборов данных, которым требуется 32-64 + ГБ ОЗУ.

3. Impala интегрирована с инфраструктурой Hadoop. AFAIK главная причина использования Impala поверх других DWH в памяти - это возможность работать с форматами данных Hadoop без экспорта данных из Hadoop. Означает, что Impala обычно использует то же хранилище / данные / разбиение / сегментирование, которое может использовать Spark, и не дает никаких дополнительных преимуществ от структуры данных по сравнению со Spark. Я прав?

PS Импала быстрее, чем Спарк в 2019 году? Вы видели какие-либо тесты производительности?

UPD:

Обновление вопросов:

I. Почему Impala рекомендует 128 ГБ ОЗУ? Что является языком реализации каждого компонента Impala? * В документах сказано, что «демоны Impala запускаются на каждом узле кластера, и каждый демон способен выступать в качестве планировщика запросов, координатора запросов и механизма выполнения запросов». ,Если impalad - это Java, то какие части написаны на C ++? Есть ли что-то между импаладом и столбчатыми данными? Требуется ли 256 ГБ ОЗУ для Impalad или какого-либо другого компонента?

II. Impala теряет все преимущества производительности в памяти, когда дело доходит до кластерных перемешиваний (JOIN), верно? Есть ли у Impala какие-либо механизмы для повышения производительности JOIN по сравнению со Spark?

III. Импала использует многоуровневое сервисное дерево (что-то вроде Dremel Engine, см. «Модель исполнения» здесь ) против ориентированного ациклического графа Spark. Что на самом деле означает MLST против DAG с точки зрения производительности специальных запросов? Или это лучше подходит для многопользовательской среды?

Answer 1

Во-первых, я не думаю, что сравнение среды распределенных вычислений общего назначения и распределенной СУБД (движок SQL) имеет большое значение. Но если мы все же хотим сравнить выполнение одного запроса в режиме однопользовательский (?!), То самым большим отличием IMO будет то, что вы уже упомянули - у координаторов запросов Impala есть все (таблицаметаданные из Hive MetaStore + местоположения блоков из NameNode) кэшируются в памяти, в то время как Spark потребуется время для извлечения этих данных, чтобы выполнить планирование запросов.

Второй важной персоной, вероятно, будет реализация в произвольном порядке, когда Spark записывает временные файлы на диск на границах стадии, а Impala пытается сохранить все в памяти. Это приводит к радикальной разнице в устойчивости - хотя Spark может восстановиться после потери исполнителя и продолжить работу путем повторного вычисления отсутствующих блоков, Impala не выполнит весь запрос после одного сбоя демона impalad .

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

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