Всем доброго утра. Только собираемся тестировать ClickHouse в качестве аналитического

хранилища. Почитал доки. Но особо толком BestPractice не нашел. Пишу сюда - может есть кто подскажет. Итак вопросы:
1) Есть ли смысл организовывать схему типа звезда? Или стоит все измерения включать внутрь таблицы?
2) Существует ли промышленная ETL система с подключением к ClickHouse? Если да, то какая? Теоретически нам надо передать данные из одной БД в другую.
3) JOIN для распределенных таблиц. Из прочитанного, есть мысль раскидать таблицы измерения на все Шарды, а вот таблицы Фактов сделать распределенными. В этом случае, теоретически, все джойны и агрегаты будут выполняться локально, на шардах, а не гонять туда-сюда данные по сети. Кто-нибудь так делал?
4) View. Насколько эффективны обычные View? Кто-нибудь ими толком пользуется? Грубо говоря - насколько эффективны View, смотрящие на другие View?

P.S. Сейчас пришлось урезать основные витрины до полугода и со сжатием они диске они занимают порядка 6Тб. При том что используется схема звезда. Теоретически нужны данные за 2 года. Для примера одна простая таблица имеет порядка 30 млрд записей.

> 1) Есть ли смысл организовывать схему типа звезда? Или стоит все измерения включать внутрь таблицы? clickhouse отлично работает со схемой звезда делаете максимально широкую таблицу фактов в которой PRIMARY KEY наиболее часто используемые столбцы измерений по возрастанию монотонности и кардинальности (то есть время -> низко кардинальные измерения -> средне кардинальные) а таблицы измерений закидываете в словари либо напрямую, либо импортируете slow changed dimensions в clickhouse и дальше используете range словари и при выборке используете dictGet вместо JOIN > 2) Существует ли промышленная ETL система с подключением к ClickHouse? Если да, то какая? Теоретически нам надо передать данные из одной БД в другую. ну есть коннекторов куча, вообще clichouse может через табличные функции напрямую из источников читать, тут сильно зависит от того что вам нужно, возможно именно промышленная ETL система вам не нужна. потому что слишком много посредников и медленно получается в качестве ELT решения сейчас многие используют dbt https://github.com/dbt-labs/dbt-core/ > 3) JOIN для распределенных таблиц. Из прочитанного, есть мысль раскидать таблицы измерения на все Шарды, а вот таблицы Фактов сделать распределенными. В этом случае, теоретически, все джойны и агрегаты будут выполняться локально, на шардах, а не гонять туда-сюда данные по сети. Кто-нибудь так делал? да в основном так и делают. но надо понимать что JOIN в clickhouse пока умеет только x=y + AND + OR ну еще ASOF JOIN есть, но его не везде можно воткнуть... таблицы измерений лучше всего подтягивать через dictGet вместо Join существенно быстрее получается почитайте про словари https://clickhouse.com/docs/en/sql-reference/dictionaries/external-dictionaries/external-dicts > 4) View. Насколько эффективны обычные View? Кто-нибудь ими толком пользуется? Грубо говоря - насколько эффективны View, смотрящие на другие View? чтобы ответить на этот вопрос правильно надо понимать. различаете ли вы разницу между CREATE VIEW и CREATE MATERIALIZED VIEW и какой именно тип имеете в виду в вашем вопросе?

1) по-поводу измерений. у меня некоторые измерения по 100тыс значений с кучей атрибутов. Не уверен что в словари стоит такое загонять. 4) имелись ввиду View как обычные селекты, не материализованные. Материализованные - суть та же таблица

легко миллионы загоняются... у вас сколько RAM ? там есть всякие возможности чтобы меньше памяти жрать почитайте про LAYOUT https://clickhouse.com/docs/en/sql-reference/dictionaries/external-dictionaries/external-dicts-dict-layout#complex-key-sparse-hashed и https://clickhouse.com/docs/en/sql-reference/dictionaries/external-dictionaries/external-dicts-dict-layout#complex-key-ssd-cache

> 4) имелись ввиду View как обычные селекты, не материализованные. Материализованные - суть та же таблица обычные VIEW тупо переписываются в рантайме на SELECT, там ничего экстра кардинального внутри алиасы ... ну может баги какие есть, но вроде починили уже все... MATERIALIZED VIEW на select это таблица на запись это AFTER INSERT TRIGGER из source(FROM) таблицы который пишет в destination (TO) таблицу

за ссылки спасибо. Буду курить их. что касается VIEW. Получается что SELECT из JOIN двум VIEW работает как два SELECT выгруженных параллельно в память и последующий JOIN этих DataSet без использования индексов? По сути считаем обычное VIEW некоей "макроподстановкой", аналог CTE, в MSSQL?

Join-ы не используют индексы. И нет, не получается

т.е. бежим от JOIN как от огня? Ок. Еще один вопрос. про JOIN. Будет ли выгоднее тогда использовать конструкцию UNION вместо JOIN в этом случае?

ну, вам написали про external dictionaries. думаю стоит все же проверить что это такое.

естественно я проверю. но очевидно, КХ сильно отличается от остальных БД по внутренностям и оптимизации производительности. Соответственно меняется и подход к организации хранилища. Сейчас я делаю JOIN для нескольких таблиц по 70млрд записей (на самом деле меньше, в силу партицирования, но идея не меняется) и получаю то, что нужно. но идея с dictionary данная ситуация не подходит, очевидно, под такое кол-во записей. грубо говоря я джойню несколько таблиц фактов, чтобы получить нужную мне витрину. я хочу понять как мне организовать хранилище, под подобные требования. К сожалению, нигде я описания подобных кейсов не нашел (что странно). Есть видео про внутренности КХ. Есть различные описания движков и т.д. Но с точки зрения пользователя КХ, нигде тех самых BestPractices нет.

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

Я бы подумал в сторону отказа от JOIN и попробовал бы сделать 1 широкую таблицу.

Вот это самый главный ответ. Спасибо. Но у меня не совсем DWH. А аналитическая DWH. Соответственно я могу делать предагрегации ;-) А про UNION, можете ответить? Он также выгружает все в память и все обьединяет в памяти? Грубо говоря вот такой запрос как будет отрабатываться? SELECT a, SUM(x1), SUM(x2) FROM (SELECT a, x1, NULL AS x2 FROM tab_1 UNION ALL SELECT a, NULL, x2 FROM tab_2) GROUP BY a

такое будет работать, у меня в одном приложении все джойны так (там робот пишет SQL-ли и джойнит таким образом)

гхм... вам надо почитать какие индексы есть в к clickhouse и попробовать разобраться как они работают ну и как JOIN работает в clickhouse что такое merge join в общем не обязательно там все в памяти будет, может на диске будут временные файлы

именно так. вот по индексам отличный видос выше, про адаптивную гранулярность. Про JOIN надо искать дальше видимо