HBase является подходящим выбором, если у вас есть OLTP-тип запросов, то есть ваш шаблон запросов ограничен точечными или малыми диапазонами запросов.
Phoenix - это просто слой SQL поверх HBase, который предоставляетвозможность пользователя запрашивать данные в HBase с использованием конструкций SQL.
Когда вы отправляете любой запрос SQL, Phoenix проанализирует его и создаст план выполнения, который может разбить запрос при полном сканировании, сканировании диапазона или получении точки в зависимости от того, чтоВы запросили.
Для обработки результатов Phoenix использует Predicate Push down, поэтому HBase выполняет всю обработку (сканирование и получение необходимых строк со всех серверов регионов), Phoenix собирает / сортирует результирующие строки и возвращает их пользователю.
Теперь, чтобы ответить на ваш вопрос " Подходит ли Феникс для ETL и агрегации? " - NO не подходит, если вам необходимо выполнитьбольшое сканирование (полное или большое сканирование) с агрегацией и ожидание обработки результатов в считанные секунды oсубсекундыЭти запросы могут нормально работать, если размер таблицы невелик (несколько сотен ГБ), но, поскольку со временем размер таблицы будет увеличиваться, вы столкнетесь с серьезными проблемами с производительностью.Это сценарий OLAP, и вы должны искать другие альтернативы.
Я предполагаю, что когда вы говорите, используя Hive с HBase, вы планируете создать внешнюю таблицу Hive поверх таблицы HBase, которая может запрашивать HFiles напрямую, используяHiveHBaseTableInputFormat.Это будет использовать MapReduce для обработки запроса, и вы не сможете реально использовать оптимизацию производительности с помощью разбиения, сегментирования и т. Д.
Я бы посоветовал рассмотреть возможность использования опции HBase + Phoenix для получения точек и запросов малого диапазона, для большой агрегации / ETLЗапросы типов, рассмотренные с использованием Spark, будут лучше и намного быстрее, чем опция Hive.
Если ваши данные добавляются только, вы можете рассмотреть возможность использования альтернативных опций хранения, поддерживающих OLAP, таких как Driud, Clickhouse или Hive on Tez,Улей с опциями Impala или Presto вместо HBase.
Обновлено в соответствии с комментарием -
Spark будет быстрее, чем опция Hive (MapReduce);Используйте Spark только для запросов, использующих большой диапазон или полное сканирование с последующим агрегированием.
Несмотря на то, что Phoenix использует сопроцессоры и предикатный переход в регионы HBase, количество доступных ресурсов может стать ограничением, Phoenix распараллелит запросв чанках, которые определяются GUIDE_POSTS_WIDTH, для больших таблиц это может легко варьироваться от нескольких сотен до 1000 с и создавать конфликт для очередей RPC, также во время сканирования HFiles будут считываться и загружаться в кучу регион-сервера, вы можете столкнуться с проблемами GC или OOM, еслисканирование не может соответствовать результатам в выделенной куче.Сканеры могут быть ограничены временем ожидания rpc и доступной памятью, что приводит к тайм-аутам.
Вы можете настроить вышеперечисленные ситуации в определенной степени, но HBase / Phoenix не предназначены для OLAP.Используя Spark, вы можете напрямую читать HFiles и применять фильтры после этого, это устранит проблемы тайм-аута.Если один и тот же набор данных запрашивается снова и снова, вы можете попробовать внешнее кэширование rdd / dataframe в Ignite.
Я хотел бы добавить, что прежде чем искать альтернативу, вы должны проанализировать, как вы храните свои данные в HBase:выровнялся ли он по вашему шаблону запроса?Пересмотрите свой дизайн rowkey, если ваш план запроса создает полные сканы, попробуйте перепроектировать rowkey или запрос, чтобы избежать полных сканов?Проверьте, хорошо ли ваши данные распределены по всем регионам?Может ли ваша высокая скорость записи повлиять на производительность чтения?
Если у вас есть тип потока данных, который нужно проанализировать, проверьте Clickhouse, Яндекс разработал и открыл его для аналогичного варианта использования, но он работает хорошои для других случаев использования OLAP.
Надеюсь, это полезно.