1) Потому что затаскивали нормально его долго. Вот жира таска сборная, в рамках которой это делали:
https://issues.apache.org/jira/browse/HIVE-7292
и делали это много лет, и как я понимаю, все ещё до конца не доделали.
2) Часто видел инфу о том, что hive on spark - это очень не стабильно.
3) Мой личный опыт - были попытка перейти с tez движка на spark движок на свежих версиях hive. В итоге на спарк движке некоторые запросы вылетали с OOM.
4) Обновления спарка в этот движок затаскивались с большим лагом, т.е. там реально долго был спарк 1.6, когда уже вовсю на 2.х жили люди.

Ну это лишь в одном из направлений.
Вообще ещё athena(и аналоги в azure и google cloud), presto, а кто - то на гринпламе.
Кто - то на редшифте. По - разному, короче.

hive все же бд, у нее есть буферный кэш (в новых версиях), есть общая история всех запросов (может появятся какието инструменты для управления планами). До spark 3, в hive уже были join predicate pushdown,
Число контейнеров для reduce определяется автоматом, файлы на выходе мержатся, если их много, бакетирование на уровне метастора для таблиц, который можно перееиспользовать, автовыделение ресурсов под запрос

буферный кеш - это вы про llap?

кмк подход как у Feast или Tecton, когда всех кто наполняют feature store пытаются забрить в какой-то фиксированный фреймворк для запихивания пайплайнов - это утопия

кстати, а кто-нибудь сейчас пользуется импалой?

какие у нее сценарии использования?

мы используем что бы аналитики смотрели на data lake и как jdbc интерфейс тому кто данные выкачивает. получается не очень, постоянно что-то падает с нехваткой памяти

кмк подход как у Feast или Tecton, когда всех кто наполняют feature store пытаются забрить в какой-то фиксированный фреймворк для запихивания пайплайнов - это утопия

А что есть фича стор? Можете кто-то нубу ссылку на медиум хорошую дать?

а как иначе ? если каждый будет тащить так как ему показалось правильно, то и на выходе же будет шлак, который кому-то когда-то показалось правильным но уже многие годы тащит мусор

я думаю что возможность поставлять данные из разных мест не значит что надо обязательно шлак поставлять; с другой стороны попытка сделать god framework для всех во-первых, создает узкое место (эти самые разработчики фреймворка), и во-вторых толкает людей которых разработчики фреймворка обидели в сторону shadow IT

"в сторону shadow IT" - под этим вы имеете виду обходные пути, которые нарушают как бы политики компании, но позволяют получить требуемый результат?)
Типа как теневая экономика, только теневая разработка? :)

я думаю что возможность поставлять данные из разных мест не значит что надо обязательно шлак поставлять; с другой стороны попытка сделать god framework для всех во-первых, создает узкое место (эти самые разработчики фреймворка), и во-вторых толкает людей которых разработчики фреймворка обидели в сторону shadow IT

просто если у сатаниста будет возможность самому решать какие поставлять данные в feature store то начнется полная анархия. первый сатанист решает конкретную проблему, конкретной страны, соответственно засунет так как ему удобно. второй, из соседней страны, это переиспользовать не сможет, а будет изобретать свой велосипед заточенный на свою страну. если им позволено тащить как им нравится, никакого резона какое-то общее решение воротить нет.

Коллеги, а кто как пишет из кафки на, например, S3 или (вдруг до сих пор!) на hdfs?
Флюм и кафку коннект не предлагать🙂

NiFi, или самим написать приложеньку

Коллеги, а кто как пишет из кафки на, например, S3 или (вдруг до сих пор!) на hdfs?
Флюм и кафку коннект не предлагать🙂