а почему вы сравниваете разные базы с точки зрения джойнов?

т.е. почему нельзя без джойнов сделать в вертике и почему нельзя сделать джойны в том же клике?

тут о том, что источники разные,  и хдфс, и кафка и прочее одновременно

все равно не понял, особенно момент, как клик и вертику в разные разряды разнесли

Если посмотрите я указал 2 реализации OLAP

Первая molap, препросчитаны кубы и ответы на срезы даёт достаточно быстро, поэтому часто высовывают их на интерактивные дашборды

Вторые rolap, в которых внутри обычно схема снежинка, для выборок обычно нужны джойны, что уже не быстро, чаще гоняют в аналитике и репорты, интерективные дашборды на них намного реже делают

Клика находится где-то посередине, частичная преагрегация и весёлый формат хранения, поэтому пускай и с ограниченной поддержкой sql, но можно делать интерактивные дашборды по большим объёмам данных

Но в клику нужно отдельно вставлять данные

Пинот и друид цепляется на кафку реалтайм нодой и делает данные доступными для показа с минимальной задержки (секунды после того как событие случилось, поэтому часто как дашборды для графиков и тайм серий используются)

То есть есть:
Molap
Rolap
Непонятная хрень

@dartov меня поправит где ошибся

сори, чёт я немножко потерял тему разговора

о чём сейчас пойнт?

Делать 1 широкую таблицу в вертике не принято

Делать много разных таблиц в клике не принято, там только недавно подвезли что-то похожее на джойн, до этого я бы сказал это был лукап по второй таблице после её бродкаста

Поэтому теоретически можнт сделать, но это относится к плохим практикам

Давайте по порядку:
1. OLAP кубы бывают трех видов: ROLAP, MOLAP, HOLAP, с точки зрения работы с СУБД они отличаются тем, что где-то идет генерация запроса sql под модель данных, а где-то суют уже готовую модель, конечный результат - это всегда плоская таблица
2. Модели данных вы можете выбирать какую угодно в любой СУБД. Вы можете без проблем подготовить конечную плоскую таблицу фактов и скормить её любому кубу и все это будет нормально работать.
3. Что касается КХ, то это тип колоночных СУБД с элементами таймсириес, заточенный в основном считать в рамках одной таблицы фактов с аналитическим окном (ибо КХ не умеет нормально в джойны). С таким же успехом и даже лучше, работают те же Vertica и Snowflake.

Из этого следуют следующие вопросы:
1. Непонятно, почему вы сравниваете OLAP кубы и СУБД?
2. Непонятно, почему под тип куба вы подставляете конкретные СУБД?

кто вам такое сказал?

Что имено?

что в вертике плохая практика широкие таблицы?

Всем привет!
Есть хайв табличка такого вида:

+-------------------+-------+-----+
|               DATE|SEGMENT|COUNT|
+-------------------+-------+-----+
|2021-01-11 00:00:00|    Int|    1|
|2021-01-11 00:00:00|    Mid|    1|

       
Из нее надо получить таблицу вида:
   

+-------------------+-------+-----+
|               DATE|SEGMENT|COUNT|
+-------------------+-------+-----+
|2021-01-11 00:00:00|    Int|    1|
|2021-01-11 00:00:00|    Mid|    1|
|2021-01-11 00:00:00|    FI |    0|
|2021-01-11 00:00:00|  Large|    0|

Т.е для сегментов (их всего четыре), которые не посчитаны за конекретную дату, проставить нули.
И соответственно добавить эти строки. Сделать надо именно хайв запросом.
Буду благодарен за помощь!

Между прочим, в КХ, из-за кривизны, есть справочники во внешних БД, которые именно джойнятся - это и нормальная практика

Широкие нет

Запихать всё в пару таблиц да
Так как денормализацию намного сложнее поддерживать

Тут зависит как это называть

кто вам такое сказал?

Вертику я не сравнивал с олап, а указал как одно из популярных решений, которое видел для этого дела (колумнар сторейдж)