Раньше кстати пользовались clickhouse-driver, но он не поддерживает шаблонизацию и чет мы немного помучались с передачей в него настроек. Также, насколько я помню, он по дефолту оставляет подключения открытыми.
Мы используем вот этот плагин, для наших целей отлично подходит. Там помимо ClickHouseOperator, есть еще сразу ClickHouseSensor и ClickHouseHook.
Мы еще в него добавили дефолтные параметры типа названия подключения, настроек, query_id. Также из плюсов он поддерживает шаблонизацию Airflow, то есть туда прямо в SQL код можно добавлять всякие параметры типа {{ ds }}, {{ next_ds }} и пр. Ну и еще удобно что можно передавать сразу несколько SQL файлов.
В итоге большинство наших DAG'ов - это набор из следующих операторов/сенсоров:
Вы правы, под капотом любая операция delete/update инсертнет обновленные данные. И это достаточно затратно по ресурсам. Зато подобная архитектура позволяет кликхаусу быть очень быстрой OLAP СУБД (при правильных настройках).
Для обновления данных в реплицированной таблице необязательно подключаться к каждому хосту, достаточно выполнить например replace partition on cluster <cluster> - так он сам отправит запросы на все ноды и дождется успешного выполнения. Либо можно дропать партицию и делать инсерт новой.
Разумеется, у каждого инструмента есть свои ограничения, поэтому крупные компании часто используют кликхаус в связке например с Greenplum / Vertica / HDFS / etc. В кликхаусе хранится кликстрим, а транзакционные данные - в других хранилищах.
Да, вы более чем правы, с дефолтным постгресом работать в определенной мере проще и точно привычнее. Но когда данных становится очень много, уже особо нет выбора и приходится переходить к менее привычным инструментам для работы с большими данными (колоночные распределенные СУБД, HDFS и тд).
Также, несмотря на то что порог входа в ClickHouse ненулевой, он в грамотных руках дает гораздо больший буст производительности и удобства работы (те самые фишки выше из статьи и не только🙂). Это примерно как впервые купить SmartTV для просмотра федеральных каналов - пока не разобрался и так сойдет, но потом оказывается что можно и много всего друго крутого делать: и отдельные приложения ставить, и музыку слушать, и в игры играть.
На мой взгляд, особенно на первых этапах работы с ClickHouse, задача дата инженеров и заключается в том, чтобы обеспечить плавный переход для аналитиков с привычных им СУБД - сделать простые понятные таблицы, рассказать про правильную фильтрацию и основные проблемы с которыми можно столкнуться. А уже потом постепенно рассказывать про нетривиальные, но удобные штуки, чтобы раскрыть этот инструмент по максимуму.
Раньше кстати пользовались clickhouse-driver, но он не поддерживает шаблонизацию и чет мы немного помучались с передачей в него настроек. Также, насколько я помню, он по дефолту оставляет подключения открытыми.
Мы используем вот этот плагин, для наших целей отлично подходит. Там помимо ClickHouseOperator, есть еще сразу ClickHouseSensor и ClickHouseHook.
Мы еще в него добавили дефолтные параметры типа названия подключения, настроек, query_id. Также из плюсов он поддерживает шаблонизацию Airflow, то есть туда прямо в SQL код можно добавлять всякие параметры типа
{{ ds }},{{ next_ds }}и пр. Ну и еще удобно что можно передавать сразу несколько SQL файлов.В итоге большинство наших DAG'ов - это набор из следующих операторов/сенсоров:
Также из удобств он всегда закрывает за собой подключения, а также по дефолту пишет в логи финальный текст SQL запроса.
Вы правы, под капотом любая операция delete/update инсертнет обновленные данные. И это достаточно затратно по ресурсам. Зато подобная архитектура позволяет кликхаусу быть очень быстрой OLAP СУБД (при правильных настройках).
Для обновления данных в реплицированной таблице необязательно подключаться к каждому хосту, достаточно выполнить например
replace partition on cluster <cluster>- так он сам отправит запросы на все ноды и дождется успешного выполнения. Либо можно дропать партицию и делать инсерт новой.Разумеется, у каждого инструмента есть свои ограничения, поэтому крупные компании часто используют кликхаус в связке например с Greenplum / Vertica / HDFS / etc. В кликхаусе хранится кликстрим, а транзакционные данные - в других хранилищах.
спасибо) заберу к списку аргументов для обновления
Спасибо за комментарий! С обычным (Replicated)MergeTree же все ок?
И можете плиз поделиться ссылкой на описание проблемы с консистентностью? Беглым поиском не смог найти, а проекции мы используем)
Да, вы более чем правы, с дефолтным постгресом работать в определенной мере проще и точно привычнее. Но когда данных становится очень много, уже особо нет выбора и приходится переходить к менее привычным инструментам для работы с большими данными (колоночные распределенные СУБД, HDFS и тд).
Также, несмотря на то что порог входа в ClickHouse ненулевой, он в грамотных руках дает гораздо больший буст производительности и удобства работы (те самые фишки выше из статьи и не только🙂). Это примерно как впервые купить SmartTV для просмотра федеральных каналов - пока не разобрался и так сойдет, но потом оказывается что можно и много всего друго крутого делать: и отдельные приложения ставить, и музыку слушать, и в игры играть.
На мой взгляд, особенно на первых этапах работы с ClickHouse, задача дата инженеров и заключается в том, чтобы обеспечить плавный переход для аналитиков с привычных им СУБД - сделать простые понятные таблицы, рассказать про правильную фильтрацию и основные проблемы с которыми можно столкнуться. А уже потом постепенно рассказывать про нетривиальные, но удобные штуки, чтобы раскрыть этот инструмент по максимуму.
Занятная фишка конечно)
А что будет если
optimize table finalсделать?И если это воспроизводится, мб issue закинуть?
У нас тоже все RMT таблицы реплицированы, но таких проблем не наблюдаем 🤷♂️