Архитектура Impala

Основным компонентом Impala является Impala Daemon. Он представлен процессом impalad. Демон Impala получает запрос от клиента, берёт на себя функции координатора, анализирует запрос, разделяет на подзадачи и распределяет подзадачи по другим нодам с процессами impalad. После того как каждый процесс рабочей ноды impalad получает подзапрос, он начинает выполнять локальный запрос (например, запрашивать HDFS DataNode или region-сервер HBase) и возвращает результаты запроса центральному координатору. Координатор собирает результаты запросов от других процессов impalad, объединяет их и отправляет результат клиенту.

Демон Impala состоит из трех модулей:

Демоны Impala могут быть развернуты одним из следующих способов:

Демоны Impala находятся в постоянном взаимодействии с Statestore, чтобы иметь информацию о том, какие демоны в рабочем состоянии и могут принимать новые запросы.

Они также получают широковещательные сообщения от сервиса Impala Catalog всякий раз, когда какой-либо демон Impala в кластере создает, изменяет или удаляет объекты любого типа, или когда Impala обрабатывает оператор INSERT или LOAD DATA.

Вы можете контролировать, какие ноды работают как координаторы запросов, а какие — как исполнители, чтобы улучшить масштабируемость высококонкурентных рабочих нагрузок в больших кластерах. Для получения дополнительной информации см. How to configure Impala with dedicated coordinators.

Компонент Impala Statestore собирает информацию о работоспособности всех демонов Impala и постоянно пересылает результаты всем нодам с процессом impalad. Statestore представлен демоном statestored. Кластеру нужен этот процесс только на одном хосте. Если демон Impala отключается из-за аппаратного сбоя, сетевой ошибки, проблемы с программным обеспечением или по другим причинам, Statestore информирует об этом все другие демоны Impala, и новые запросы не отправляются недоступному демону.

Поскольку Statestore играет важную роль только когда нормальная работа кластера Impala нарушена, а также транслирует метаданные координаторам, его функции не всегда являются критическими. Если Statestore становится недоступным, демоны Impala продолжают работать и распределять нагрузку между собой, как обычно при работе с данными, известными Impala. Кластер может стать менее надежным, если некоторые демоны Impala выйдут из строя. Метаданные также становятся менее согласованными, поскольку они изменяются, пока Statestore недоступен. Когда Statestore возвращается к работе, он восстанавливает связь с демонами Impala и возобновляет функции мониторинга и вещания.

Если вы выполните выражение DDL, когда Statestore недоступен, запросы, обращающиеся к новому объекту, созданному DDL, завершатся ошибкой.

Компонент Impala Catalog Service отправляет широковещательные сообщения всем демонам Impala при изменении метаданных, сделанных операторами SQL через Impala. Например, когда создаётся таблица, загружаются данные или выполняются другие операции по изменению таблиц или данных. Он представляет собой процесс catalogd.

Этот процесс нужен только на одном хосте в кластере. Поскольку изменения метаданных передаются через демон Statestore, имеет смысл устанавливать компоненты Impala Catalog Service и Impala Statestore на одном и том же хосте.

Вы можете использовать параметр load_catalog_in_background, чтобы определить, когда следует загружать метаданные таблицы. Флажок load_catalog_in_background расположен на вкладке CLUSTERS → Кластер ADH → Services → Impala → Components → Impala Catalog Service → Configuration.

Если установлено значение false, метаданные таблицы загружаются при первом обращении к ней. В этом случае первое выполнение запроса может быть медленнее последующих.

Если для параметра load_catalog_in_background установлено значение true, Catalog Service загружает метаданные для таблицы, даже если эти метаданные не требуются ни для одного запроса. Таким образом, метаданные могут быть уже загружены, когда будет выполнен первый запрос к этой таблице. Однако не рекомендуется устанавливать для этого параметра значение true. Фоновая загрузка может мешать загрузке метаданных для текущего запроса и приводить к случайным долго выполняемым запросам, которые трудно диагностировать. Impala также может загружать метаданные для таблиц, которые никогда не используются, увеличивая размер каталога и использование памяти как для Catalog Service, так и для демона Impala.

Компонент Impala Client — это impala-shell, который представляет собой интерфейс командной строки для запросов к демону Impala. Можно установить Impala Client на один или несколько хостов в сети. Он может удаленно подключаться к любому экземпляру демона Impala.

Там, где это целесообразно, Impala использует существующую инфраструктуру Apache Hive, которая уже есть у многих пользователей Hadoop, для выполнения длительных, пакетных SQL-запросов. Impala хранит определения таблиц в базе данных MySQL или PostgreSQL, известной как Metastore, в той же базе данных, где Hive хранит данные такого типа. Таким образом, Impala может получить доступ к таблицам, определенным или загруженным через Hive, если во всех столбцах используются поддерживаемые Impala типы данных, форматы файлов и кодеки сжатия.

Первоначальный фокус на функциях запросов и производительности означает, что Impala может считывать больше типов данных с помощью оператора SELECT, чем записывать с помощью оператора INSERT. Чтобы запросить данные с использованием форматов файлов Avro, RCFile или SequenceFile, вы должны загрузить данные с помощью Hive.

Оптимизатор запросов Impala также может использовать статистику по таблицам и столбцам. Первоначально в Hive эта информация собиралась с помощью оператора ANALYZE TABLE. Вместо этого в Impala можно использовать оператор COMPUTE STATS. COMPUTE STATS требует меньше настроек, более надежен и не требует переключения между impala-shell и оболочкой Hive.

Как описано выше, Impala хранит информацию об определениях таблиц в централизованной базе данных, называемой Metastore. Impala также отслеживает метаданные низкоуровневых характеристик файлов данных — физическое расположение блоков в HDFS.

Для таблиц с большим объемом данных и/или множеством партиций получение всех метаданных может быть длительным. Каждый узел Impala кеширует эти метаданные для повторного использования в будущих запросах к той же таблице.

Если определение таблицы или данные в таблице обновлены, все демоны Impala в кластере должны получить последние метаданные и заменить устаревшие кешированные метаданные, прежде чем выполнять запрос к этой таблице. Обновление метаданных автоматически координируется компонентом Impala Catalog Service для всех операторов DDL и DML, выполняемых через Impala. Для DDL и DML, запущенных через Hive, или изменений, внесенных вручную в файлы HDFS, необходимо использовать оператор REFRESH (когда новые файлы данных добавляются в существующие таблицы) или оператор INVALIDATE METADATA (для новых таблиц, после удаления таблицы, перебалансировки HDFS и удаления файлов данных). INVALIDATE METADATA извлекает метаданные для всех таблиц, отслеживаемых Metastore. Если вы знаете, какие таблицы были изменены за пределами Impala, можно запустить REFRESH <table_name> для каждой затронутой таблицы, чтобы получить последние метаданные для этих таблиц.

Impala использует HDFS в качестве основного хранилища данных. Impala полагается на избыточность, обеспечиваемую HDFS, для защиты от сбоев оборудования или сети на отдельных узлах. Данные таблиц Impala представлены в виде файлов данных в HDFS с использованием стандартных форматов файлов HDFS и кодеков сжатия. Когда файлы данных присутствуют в каталоге новой таблицы, Impala читает их все, независимо от имён файлов. Новые данные добавляются в файлы с именами, контролируемыми Impala.

HBase — это альтернатива HDFS в качестве хранилища данных Impala. Это система баз данных, построенная поверх HDFS, без встроенной поддержки SQL. Чтобы запросить содержимое таблиц HBase через Impala, определите таблицы в Impala и сопоставьте их с эквивалентными таблицами в HBase. Таким образом, вы можете выполнять даже JOIN-запросы, включающие как таблицы Impala, так и HBase.