Почему полное сканирование и агрегация HBase медленнее, чем паркет, несмотря на то, что они также являются столбчатой ​​базой данных?

Я пытался использовать "правильную" технологию для клиентского приложения на 360 градусов, оно требует:

  1. Таблица с широкими столбцами, каждый клиент - одна строка с большим количеством столбцов (говорит> 1000)
  2. Ежедневно выполняется около 20 заданий по пакетному обновлению. Каждое задание аналитики запрашивает и обновляет небольшой набор столбцов для всех строк. Он включает в себя агрегирование данных для составления отчетов и загрузку / сохранение данных для алгоритмов машинного обучения.
  3. Мы обновляем информацию о клиентах в нескольких столбцах с <= 1 миллион строк в день. Загрузка обновлений распределяется по рабочим часам. У нас более 200 миллионов строк.

Я попытался с помощью Hbase, точки 1 и 3 выполнены. Но я обнаружил, что аналитика (загрузка / сохранение / агрегирование) на HBase мучительно медленная, она может быть в 10 раз медленнее, чем в Parquet. Я не понимаю, почему и Parquet, и Hbase являются столбчатыми БД, и мы достаточно хорошо распределили рабочую нагрузку в кластере HBase (так говорит "количество запросов на регион").

Любые советы? Я использую не тот инструмент для работы?

Источник

1 ответ

Решение

и Паркет, и Hbase являются столбчатыми БД

Это предположение неверно:

  • Паркет не является базой данных.
  • HBase не является столбчатой ​​базой данных. Это часто рассматривается как единое целое, но это неправильно. HFile не ориентирован на столбцы (Паркет).

HBase мучительно медленный, он может быть в 10 раз медленнее, чем с паркетом

Полное сканирование HBase обычно намного медленнее, чем эквивалентное сканирование файлов в формате HDFS, поскольку HBase оптимизирован для шаблонов произвольного доступа. Вы не указали, как именно вы сканировали таблицу - TableSnapshotInputFileFormat намного быстрее чем наивный TableInputFormat, но все же медленнее, чем сканирование файлов в формате HDFS.

Источник
Другие вопросы по тегам