Comments 26
О, этот дивный ClickHouse
select version() -- 23.12.1.1368
В общем есть в нём одна незадокументированная фишка, а именно - ReplicatedReplacingMergeTree не работает, точнее работает, но не как задумано.
В чём выражается - данные должны дедпуплицироваться по PK/SK, это происходит, но только частично, у нас сейчас в продовой БД есть дубли которым 2+ года (процесс дедубликации не моментальный, но не 2 года же), при этом данные находятся на одном шарде.
Решается только если грузить методом REPLACE PARTITION.
Занятная фишка конечно)
А что будет если optimize table final сделать?
И если это воспроизводится, мб issue закинуть?
У нас тоже все RMT таблицы реплицированы, но таких проблем не наблюдаем 🤷♂️
к сожалению я не могу этого сделать вручную (не являюсь админом клика), только загружаю в него
optimize дёргается кроном\аирфлоу по расписанию, но это не помогает
в общем советую проверить данные на дубли)
В общем есть в нём одна незадокументированная фишка
(процесс дедубликации не моментальный, но не 2 года же)
Именно это и задокументировано прямым текстом: "в неизвестный момент времени, на который вы не можете ориентироваться". Не надо додумывать и считать, что документация вам врёт, потому что вам кажется, что в этой фразе почему-то подразумевается "но не 2 года же".
(справедливости ради, документация иногда действительно врёт, но не в данном случае)
А вам стоит разобраться, почему у вас не происходит дедубликация (если вам это, конечно, нужно):
действительно ли данные на одном шарде
не лежат ли данные в разных партициях (так тоже не будет дедубликации)
настройки типа insert_deduplicate=0 + optimize_skip_merged_partitions=1 могут привести к неудалению дублей даже в одной партиции
насколько большие парты с дублями (есть лимиты на слияние слишком больших)
как именно вызываете optimize (с final или нет) и каких таблиц и партиций, на всех ли шардах...
не падает ли мердж
Может еще что-то забыл и проблема в чем-то еще. Но у нас почти всё на ReplicatedReplacingMergeTree, так что на 99% уверен, что проблема не в КХ (даже не смотря на не самую удачную версию у вас - 1% на это оставляю).
PS. В современных версиях есть настройки, задающие максимальное время до мерджа, что потенциально может избавить от optimize по cron/airflow, но мы до этого еще не обновились, так что не могу сказать, насколько оно норм и какие там грабли.
Создалось впечатление, что это рай для разработчиков, с сотнями настроек, от движков до использования памяти, но должно быть ад для аналитиков, которым на более user friendly базах со стандартным SQL думать обо всем этом не надо, и можно сосредоточится на бизнес логике. Ошибочное, или есть в этом доля истины?
Да, вы более чем правы, с дефолтным постгресом работать в определенной мере проще и точно привычнее. Но когда данных становится очень много, уже особо нет выбора и приходится переходить к менее привычным инструментам для работы с большими данными (колоночные распределенные СУБД, HDFS и тд).
Также, несмотря на то что порог входа в ClickHouse ненулевой, он в грамотных руках дает гораздо больший буст производительности и удобства работы (те самые фишки выше из статьи и не только🙂). Это примерно как впервые купить SmartTV для просмотра федеральных каналов - пока не разобрался и так сойдет, но потом оказывается что можно и много всего друго крутого делать: и отдельные приложения ставить, и музыку слушать, и в игры играть.
На мой взгляд, особенно на первых этапах работы с ClickHouse, задача дата инженеров и заключается в том, чтобы обеспечить плавный переход для аналитиков с привычных им СУБД - сделать простые понятные таблицы, рассказать про правильную фильтрацию и основные проблемы с которыми можно столкнуться. А уже потом постепенно рассказывать про нетривиальные, но удобные штуки, чтобы раскрыть этот инструмент по максимуму.
Понятно. Я бы возможно чуть поспорил вот в каком плане. Вы перешли с Постгресса на Кликхаус, получили производительность при работе с большими данными, но и одновременно сложность, которая кажется неизбежной. А для меня это два независимых свойства, работа с большими данными и миллионы настроек. Та же BigQuery позволяет анализировать огромные данные, используя стандартный SQL, почти никогда не задумываясь что внутри. Из настроек производительности доступны в основном PARTITION BY и CLUSTER BY таблицы, и создание materialized view. Наверняка Кликхаус в каких-то случаях позволяет достичь лучшей производительности, настроив именно то что вам надо, но в принципе эта сложность не является необходимым условием работы с большими данными.
Это рай только для тех разработчиков, которым в кайф в этом разбираться. У нас кликхаус заменили на BigQuery просто потому что никто не хотел вникать, как там у кликхауса все устроено. Если есть команда увлеченных дата инженеров, тогда проще.
Думаю просто недостаточно данных.
Каков порядок данных/запросов, что BQ устраивает?
Я бы спрашивал какие требования к самым быстрым запросам. BigQuery такая же массивно-параллельная аналитическая база данных, масштабируется точно не меньше ClickHouse, таблицы петабайты это норма. Но такой тонкой ручной настройки индексов и движков как в ClickHouse нет, поэтому для "точечных" запросов наверняка можно добиться лучшего результата, хотя поработать придется.
Зато в BigQuery обо всех этих настройках не надо (да не и дают) особенно думать, само справляется обычно. Настроил PARTITION BY, создал materialized view если нужно для частых запросов, и работает.
А хз, может и мало, небольшая компания же. Смотрю статистику, 80TB daily и 2.5mln requests daily. Для операторов связи или маркетплейсов - фигня. Сырые ивенты и вовсе в BT, чтоб не спамить в BQ.
Самое удобное - интеграция с любой сторонней тулзой, простая миграция данных со всех платформ. Низкий порог вхожения. Надо понимать про партишены для своих таблиц и как считается биллинг запросов. С внедрением dbt построением моделей могут заниматься сами дата аналитики под присмотром 1 дата инженера из числа опытных аналитиков, который больше думает о качестве данных, чем о том как эти данные уложить, чтоб ничего не сломалось и было консистентно.
C кликхаусом нужен был контроль девопса и хотя бы 1 data engineer (2, если он хочет в отпуск), который шарит в особенностях движков, знает, что в какой версии поменялось, и делает модели. Просто дать разрабу или аналитику задачу не получалось, слишком большой порог вхождения, а мотивации обучаться ноль, потому что знание кликхауса на американском рынке не продашь. В итоге, если сложить зарплаты инженеров и биллинг за сервера, получалось дороже, чем гугловые решения.
У гугла одна беда - биллинг и система квот такая, что без бутылки не разберешься.
CH cloud существует и активно создают коннекторы...лишают так сказать возможности копаться в настройках. Поэтому не совсем корректно сравненивать локальную и облако.
Но 2.5mln - это запросы пользователей, а не аналитиков? Здесь уже кроется разница - СН больше про аналитические запросы. 80tb(это довольно много...без сжатия же? Или это объем чтения в BQ? ). Но главное - пара запросов по неиндексированным колонкам - может скушать весь бюджет BQ или нет? Мы за раз прочитаем 1TB и заплатим 6$? (Ну может я что-то не понимаю)
Для примера, json событие внутри которого массив(динамический из строк) и вложенный словарь: массив можно просто в колонку вставить, словарь разложить на индексы и значения в 2 колонки... и даже при сотнях миллионов записей поиск по массиву(который очевидно не проиндексирован) - секунды/десятки секунд. Как с таким будет BQ работать?
Склоняюсь к тому, что вам он и не нужен был. Тоже имеет место быть.
А мотивация - простая, если запрос выполнялся 50 минут, а стал 2 минуты. Это очень мотивирует)
Как с таким будет BQ работать?
Офигенно будет. У меня прям похожая etl есть с расчетами по данным из больших структур внутри одного поля, которая реализована сначала была на кликхаусе, а потом на BQ. Это тоже колоночная субд, только индексация и ключи - все скрыто от пользователя. Пользователю даются разве что настройка партиций, и то лимитировано.
80tb(это довольно много...без сжатия же? Или это объем чтения в BQ? )
чтение в день. Сколько, чего и где лежит в BQ - неизвестно, облако ж.
Но 2.5mln - это запросы пользователей, а не аналитиков?
думаю, что 99% - это перекидывание данных в рамках etl, юзеры ну 50к день наверное. Кликхаус кстати подходит для показа данных большому числу пользователей, ЯМетрика на нем же была (или и есть).
Но главное - пара запросов по неиндексированным колонкам - может скушать весь бюджет BQ или нет? Мы за раз прочитаем 1TB и заплатим 6$?
индексации, доступной юзеру, нет. А без партиционирования и без ограничений - даже петабайт можно получить на 1 запросе, который не предусматривает группировку. Это прям главная боль таких решений. Будет очень быстро и потом очень дорого. Поэтому и dbt используется, которая строит агрегированные модели и проверяет данные на консистентность тестами, чтобы аналитики или юзеры брали данные уже из небольших таблиц.
А мотивация - простая, если запрос выполнялся 50 минут, а стал 2 минуты. Это очень мотивирует)
так у вас постгря была, еще бы =) Добро пожаловать в мир колоночных субд. group by - это больше не больно)
Офигенно будет. У меня прям похожая etl есть с расчетами по данным из больших структур внутри одного поля
пример: вектор словарей вида [ {'произвольное_название_1': скор 0.8 } ... ]
Выражаю свои сомнения, что на BQ это будет быстрее\удобнее клика. Особенно для объединения\пересечения ключей.
постгря
sql server (хотя пример 50 к 2 минутам - это про многомерность выше...)
юзеры ну 50к день наверное
в совокупности звучит, как прод с витринами.
А без партиционирования и без ограничений - даже петабайт можно получить на 1 запросе, который не предусматривает группировку.
Обсуждение было про много ли данных. Если все в витринах\вьюшках. Какая разница сколько данных в хвосте 100гб или 100тб? они фактически в холодном хранилище.
В целом, у меня нет цели продать клик, за это не платят( Выше была просто многомерная боль. И OLAP на клике - отличная идея... Вместо куба с ограничениями - получаем многомерные срезы. Чтений данных будет много - мы же не ограничиваем себя агрегациями какими-то.
Только задумайтесь, зачем 5 аналитиков, если есть олап и можно оставить одного аналитика? П-рофит.
У меня был кликхаус 2 года, но так как в нем никто больше не хотел разбираться, а у меня других обязанностей хватало, ушли на BQ.
пример: вектор словарей вида [ {'произвольное_название_1': скор 0.8 } ... ]
Выражаю свои сомнения, что на BQ это будет быстрее\удобнее клика. Особенно для объединения\пересечения ключей.
Надо же, один в один. Если вы из стриминговых сервисов, у нас с вами могут быть похожие задачи. Согласна, что удобнее такие опереции делать в кликхаусе. В кликхаусе это делалось чуть ли не одной строчкой в запросе "объединить словари, отсортировать по значению определенного ключа, убрать дубли, получить разницу между определенными элементами соседних словарей, сложить эти разницы".
Но в BQ дешевле, и даже аналитик может понять, что происходит. А значит, где-то радуется один программист и идет кодить, а не быть дата-инженером на полставке :)
Только задумайтесь, зачем 5 аналитиков, если есть олап и можно оставить одного аналитика? П-рофит.
а сколько дата-инженеров? ;)
это ад для разработчика, delete Отключен по умолчанию, данные можно только добавлять (но не удалять)
если есть косяк в данных то это только срубать всю таблицу целиком либо пытаться сделать через replace partition (подключаясь напрямую к каждому шарду поочерёдно)
Вы правы, под капотом любая операция delete/update инсертнет обновленные данные. И это достаточно затратно по ресурсам. Зато подобная архитектура позволяет кликхаусу быть очень быстрой OLAP СУБД (при правильных настройках).
Для обновления данных в реплицированной таблице необязательно подключаться к каждому хосту, достаточно выполнить например replace partition on cluster <cluster> - так он сам отправит запросы на все ноды и дождется успешного выполнения. Либо можно дропать партицию и делать инсерт новой.
Разумеется, у каждого инструмента есть свои ограничения, поэтому крупные компании часто используют кликхаус в связке например с Greenplum / Vertica / HDFS / etc. В кликхаусе хранится кликстрим, а транзакционные данные - в других хранилищах.
Если вы аналитик который не любит кофе пить (попить кофе пока ждёте запрос) - клик пушка.
Про "ад" - не очень понятно, если вы про приведённые ошибки с max_* - это скорее к админам, чем к аналитикам. У "дефолтного" sql- неоптимизированный запрос - сожрет cpu, не выполнится(за разумное время) в итоге, а разгребать это админам. А здесь обычный оом...впрочем, таких проблем практически не было...
sql почти дефолтный...тут скорее вопрос какие у вас данные. CH не любит джойны..
Спасибо за статью! У проекций есть проблема с консистентностью при использовании Replacing/Collapsing/AggregatingMergeTree. В 24.8 пофиксили… ну так себе фикс, можно поставить на автоматический ребилд парта.
Спасибо за комментарий! С обычным (Replicated)MergeTree же все ок?
И можете плиз поделиться ссылкой на описание проблемы с консистентностью? Беглым поиском не смог найти, а проекции мы используем)
Я об этом сам случайно узнал от Миловидова в последнем Release Call 24.8. В документации или других источниках до данного момента не попадалось. Попробовал провести простой тест агрегирующей проекции в ReplacingMergeTree и всё печально... агрегат продолжает агрегировать полностью игнорируя факт replace'а))
Известно, что для Airflow нет официального провайдера для ClickHouse. Вы что использовали на стороне Airflow для взаимодействия с кликом - BashOperator, драйвер от ClickHouse, неофициальный PlugIn, связку с JDBC или еще что-то и были ли при этом какие-то проблемы?
Мы используем вот этот плагин, для наших целей отлично подходит. Там помимо ClickHouseOperator, есть еще сразу ClickHouseSensor и ClickHouseHook.
Мы еще в него добавили дефолтные параметры типа названия подключения, настроек, query_id. Также из плюсов он поддерживает шаблонизацию Airflow, то есть туда прямо в SQL код можно добавлять всякие параметры типа {{ ds }}, {{ next_ds }} и пр. Ну и еще удобно что можно передавать сразу несколько SQL файлов.
В итоге большинство наших DAG'ов - это набор из следующих операторов/сенсоров:
ch_task = DefaultClickhouseOperator(
task_id="ch_task",
sql=["#1_drop_partition.sql", "#2_insert_increment.sql"],
params={**TABLES},
)Также из удобств он всегда закрывает за собой подключения, а также по дефолту пишет в логи финальный текст SQL запроса.
Раньше кстати пользовались clickhouse-driver, но он не поддерживает шаблонизацию и чет мы немного помучались с передачей в него настроек. Также, насколько я помню, он по дефолту оставляет подключения открытыми.
Как небольшой команде переехать на ClickHouse: на какие грабли мы наступили и о каких фишках не знали