Impala и Kafka немного в стороне, остальные части облачные сервисы покрывают, можете их взять

хочется он премис, чтоб данные мигрировать туда-сюда... да и бюджета корпоративного нет, чтоб облака покупать

Это не оно?
https://www.cloudera.com/downloads/hortonworks-sandbox/hdp.html

похоже, спасибо!

Или тут можете попробовать
https://store.arenadata.io/#products/arenadata_hadoop

В плане сортировки, можете на данных посмотреть, что получится, если первым в сортировку поставить уникальный id, а потом делать сортировку по остальным полям.
К примеру таблица 5 млрд строк. Сортировка по уникальному id разобьет на 5 млрд подгрупп длиной по 1 строке.  И упорядочивание по последующим колонкам станет бессмысленным, бинарный алгоритм работать по ним не сможет.
Сортировка вначале по статусу из 2х уник значений разобьет на 2 подгруппы к примеру 1 и 4 млрд строк .
Далее сортировка по столбцу с 12 уник. зн. разобьет каждую подгруппу на 12 подгрупп.
То есть при таком подходе каждый шаг оставит диапазон строк для последующей сортировки.

Какие подгруппы, вам надо сегментировать по нодам, если вы не возьмете сегменты по уникальности, у вас будет перекос данных на нодах и перегрузка нод на запросах

Сегментацию проекции делают обычно такую же, как и список order by. Или исключая из них часть колонок.
В таком случае перекос между нодами возможен только при фильтрации для выгрузки в витрину или при ограничении в джоине.
С перекосом, который сильно мешает жить почти не сталкивался, обычно или его не видно или в пределах 10%.
Один раз заметили перекос, но разбираться не стали.
А вот зависы при селектах к витринам, или при сборке  данных приходится чинить часто.
По моему сегментация по унику или его хэшу даст идеальный баланс между нодами, но и максимальную нагрузку при записи туда данных. Это предположение, теоретически, на реальных данных это не тестил. Если вы эту тему испытывали, плз опыт в студию.

Принес опыт в студию, 5 летний, свежий

Добрый день! Подскажите, необходимо написать сервис по переносу данных из реляционной бд в Hadoop (hive), насколько актуально сейчас использовать sqoop? На официальном сайте написано что проект вышел из эксплуатации, есть ли аналоги ?

spark.read.jdbc

Наверняка ещё понадобится потом и обработать данные в хайве)

Спасибо, поизучаю

Я продолжаю использовать sqoop, потому-что там автоматическая логика разбиения на сплиты. В spark тебе нужно руками вбивать max(Id), min(id) lowerbound upperbound

тоже смотрю в сторону sqoop, но то что проект мертвый меня останавливает

Дело такое, смотреть в его сторону можно, но его в стеке уже редко можно встретить, а в дальнейшем ещё реже будет, очевидно, если его кто-нибудь не реанимирует. Потому завязываться на него - такое себе, в итоге следующие за Вами поколения инженеров будут все переписывать.

Наверное)

Ты амбассадор спарка 😏

Евангелист!

Пиар-менеджер😎