Нет, кх повторно дернет кафку, но есть потенциальная возможность дубликатов, да

если у вас 5 MV и вставка прошла только в четырех и на последнем MV упало, то оффсет не закоммитится
потом будет ретрай и в четырех MV будут дубликатики

Я не знаю, тестировали ли MaterializeMySQL с MariaDB.

Я хотел  с  mariadb  в  clickhouse  некоторые  таблицы реплицировать  это возможно ?

Это не работает,  я использовал  просто Engine= Mysql движок это работает подключилось

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

Но принцип работу хочу узнать по точнее , этот движок как забирает ?

Он читает лог репликации MySQL.

Как это понял   binlog

ок, благодарю! можно будет попробовать сократить количество kafka-таблиц. с background_schedule_pool_size тоже потестирую.

?

Ну исправлять сеттинг это немного костьльное решение, плюс его емнип нужно будет указать в профайле дефолтного пользователя и оно требует перезагрузку кх

Считает с  binlog-а ?

Коллеги, всем привет!

Есть желание анализировать кликстрим по компании. Общий продукт комплексный, состоит из множества микросервисов, кучи поддоменов, над каждым работает отдельная команда. В рамках каждого события существует довольно обширный контекст (к примеру, если клиентом А был куплен продукт X, то для итоговой аналитики важно знать и все параметры клиента А, и все параметры продукта X, чтобы строить метрики в самых разных разрезах)

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

Соответственно, возникают вопросы:
1) стоит ли весь кликстрим по всем сервисам писать в одну таблицу и пытаться как-то разруливать (путем контроля) проблемы с «похожестью» названий атрибутов?
2) если пишем в одну таблицу, насколько правильно, что для одного сервиса будут использоваться первая половина атрибутов, а вторая будет «пустой», а для другого сервиса первая будет «пустой», а вторая заполнена?
3) стоит ли плодить множество таблиц в кликхаусе (для каждого сервиса - своя, со своим набором атрибутов контекста)?
4) стоит ли вообще писать контекст (обогощать сам факт события) в таблицу с событиями или лучше для аналитики обогащать уже после записи, например, в отдельной базе через ETL процессы?
5) если хранить в разных таблицах (каждый сервис в своей), то насколько удобно/правильно потом будет проводить какую-то сквозную аналитику между сервисами?

Примерное кол-во сервисов (доменов) - 70
Среднее кол-во атрибутов в контексте - 100

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

Да.

так а почему костыль ? вместо того что бы иметь 10 кафка таблиц для одного топика, можешь сделать 1 и к ней привязать одну таблицу. А потом к этой таблице сколько угодно MV

таким образом будет 1 консьюмер, если что-то отломается, то оффсет в принципе не комминется. А дальше уже данные(которые либо есть либо нет) по табличкам  разлетаются

Я про изменение сеттинга костыль,

а так если у них на 1 топик больше одной кафка таблицы то это неправильно конечно

Всем привет. Есть словарь с составным ключом на внешнюю вьюху fk_1, fk_2, fk_3. Есть ли возможность допустим указав только fk_1 и fk_2, вытащить список строк, в к-х эти 2 ключа совпали. Подскажите, пожалуйста.

Спасибо  большое , можете рекомендовать какой из них использовать по движкам MaterializeMysql  или Mysql?

MaterializeMySQL имеет экспериментальный статус, то есть, не предназначен для продакшена.

Движок MySQL подходит для продакшена. Он читает данные из MySQL напрямую. Скорость работы ограничена MySQL. Может быть необходимо создать таблицу в ClickHouse и сделать INSERT SELECT в неё для более эффективных запросов.