Недавно я начал изучать запросы больших наборов данных CSV, лежащих на HDFS, используя Hive и Impala. Как я и ожидал, я получил лучшее время отклика с Impala по сравнению с Hive для запросов, которые я использовал до сих пор.
Мне интересно, есть ли какие-то типы запросов/вариантов использования, которым по-прежнему нужен Hive, и где Impala не подходит.
Как Impala обеспечивает более быструю реакцию запроса по сравнению с Hive для тех же данных на HDFS?
Вы должны увидеть Impala как "SQL на HDFS", а Hive - больше "SQL на Hadoop".
Другими словами, Impala даже не использует Hadoop. У него просто есть демоны, запущенные на всех ваших узлах, которые кэшируют некоторые данные, находящиеся в HDFS, так что эти демоны могут быстро возвращать данные, не выполняя всю работу Map/Reduce.
Причиной этого является то, что при выполнении задания Map/Reduce есть определенные накладные расходы, поэтому при коротком замыкании Map/Reduce в целом вы можете получить довольно большой выигрыш во время выполнения.
При этом Impala не заменяет Hive, это хорошо для очень разных вариантов использования. Impala не обеспечивает отказоустойчивость по сравнению с Hive, поэтому, если во время запроса возникла проблема, она исчезла. Определенно, для типов ETL, где неудача одной работы была бы дорогостоящей, я бы рекомендовал Hive, но Impala может быть прекрасным для небольших специальных запросов, например для ученых-данных или бизнес-аналитиков, которые просто хотят взглянуть и проанализировать некоторые данные без создания надежных рабочих мест. Также из моего личного опыта Impala все еще не очень зрелая, и иногда я видел некоторые сбои, когда объем данных больше, чем доступная память.
IMHO, SQL на HDFS и SQL на Hadoop - то же самое. Ведь Hadoop HDFS (а также MapReduce). Поэтому, когда мы говорим о SQL на HDFS, понимается, что это SQL на Hadoop (может быть с MapReduce или без него).
Возвращаясь к актуальному вопросу, Impala обеспечивает более быструю реакцию, поскольку использует MPP (массивно-параллельную обработку), в отличие от Hive, который использует MapReduce под капотом, что связано с некоторыми первоначальными накладными расходами (как указал Чарльз сэр). Массовая параллельная обработка - это тип вычислений, который использует множество отдельных процессоров, работающих параллельно, для выполнения одной программы, где каждый процессор имеет собственную выделенную память. Сам факт, что Impala, основанный на MPP, не включает в себя накладные расходы рабочих мест MapReduce, а именно: настройка и создание задания, назначение слотов, создание раскола, создание карт и т.д., делает его невероятно быстрым.
Но это не означает, что Impala - это решение всех ваших проблем. Будучи интенсивно использующим память (MPP), он не подходит для задач, требующих больших операций с данными, таких как объединения и т.д., Поскольку вы просто не можете вместить все в память. Здесь Хейв лучше подходит.
Итак, если вам нужно в реальном времени, специальные запросы по подмножеству ваших данных поступают на Impala. И если у вас есть пакетная обработка, то нужно, чтобы ваши большие данные отправлялись в Hive.
НТН
В impala есть некоторые ключевые особенности, которые делают его быстрым.
Он не использует карту/сокращение, которые очень дороги для разветвления в отдельных jvms. Он запускает отдельный Impala Daemon, который разбивает запрос и запускает их параллельно и объединяет результирующий набор в конце.
Он выполняет большую часть своей работы в памяти.
Он использует hdfs для хранения, что быстро для больших файлов. Он кэширует как можно больше запросов от результатов к данным.
Он поддерживает новый формат файла, такой как паркет, который является форматом столбчатого файла. Поэтому, если вы используете этот формат, он будет быстрее для запросов, в которых вы чаще всего посещаете только несколько столбцов.
Impala не заменяет MapReduce и не использует MapReduce в качестве обработчика. Сначала необходимо понять ключевое отличие Impala от Hive.
Теперь, почему Impala быстрее, чем Hive в обработке запросов? Ниже приведены некоторые ключевые моменты.
При обработке SQL-подобных запросов Impala не записывает промежуточные результаты на диск(как в Hive MapReduce); вместо полная обработка SQL выполняется в памяти, что ускоряет его.
С Impala запрос начинает выполняться мгновенно по сравнению с MapReduce, что может занять значительное время. время для начала обработки больших запросов SQL, и это увеличивает время обработки.
Impala Query Planner использует интеллектуальные алгоритмы для выполнения запросов в несколько этапов в параллельных узлах, чтобы предоставлять результаты быстрее, избегая шагов сортировки и перемешивания, которые могут быть ненужными в большинстве случаев.
Impala имеет информацию о каждом блоке данных в HDFS, поэтому при обработке запроса она использует эти знания для более равномерного распределения запросов во всех узлах данных.
Существует демон Impala, который работает на каждом узле данных. Они отвечают за обработку запросов. При отправке запроса impalad (Impala daemon) считывает и записывает данные в файл данных и распараллеливает запрос, распределяя работу по всем другим узлам Impala в кластере Impala.
Другой ключевой причиной высокой производительности является то, что Impala сначала генерирует код уровня сборки для каждого запроса. ассемблерный код выполняется быстрее, чем любая другая структура кода, потому что пока выполняются запросы Impala изначально в памяти, наличие фреймворка добавит дополнительную задержку выполнения из-за фреймворка накладные расходы.
Impala обрабатывает все запросы в памяти, поэтому ограничение памяти на узлах, безусловно, является фактором. У вас должно быть достаточно памяти для поддержки результирующего набора данных, который может многократно увеличиваться во время сложного соединения операции.
Если запрос начинает обрабатывать данные и результирующий набор данных не может поместиться в доступную память, запрос завершится неудачей.