В дополнении к статье — наткнулся на небольшую схемку, которую я составлял на первых этапах. Это может помочь в понимании важности каждого из кусочков мониторинга.
Если задача простая, например просто сгруппировать данные в таблице за последний день, то используем готовый плагин https://github.com/bryzgaloff/airflow-clickhouse-plugin , а именно ClickhouseOperator. Простой в использовании, работает стабильно.
В нашем случае проблемы несогласованности метрик между дашбордами были по причине огромного количество различных условий для фильтрации в графиках. Мы решили проблему тем, что создали горячую таблицу, в которую попадают уже отфильтрованные для мониторинга данные.
Мы стараемся не использовать матвью именно для агрегирования. В наших задачах большинство метрик измеряется в квантилях, на больших данных использовать стейты для финальной агрегации квантилей оказывается не очень производительно. Имею ввиду построение графиков.
С задачей агрегирования у нас справляется Airflow. Этого нам пока более чем достаточно. Если короткий ответ, то пока просто не возникало самой потребности в dbt)
Именно самого железа не скажу точные характеристики, но касательно конфигурации Clickhouse нашей команды: мы поделили все данные на несколько кластеров (Кстати о разделении ответственности), у каждого разное железо и свой конфиг. Основной кластер состоит из 6 шардов с реплика-фактор 2. Каждая нода кластера это примерно 7-8Тб SSD и 20-30Тб HDD, получается где-то 1/3 соотношение.
Можно накинуть роль редактора только редакторам, а остальным роль viewer. Или я не очень вопрос понял
К слову Grafana-as-code я пробовал, но вообще в другом направлении) Решал задачку автоматизации работы с Grafana, типо копирования строк целиком, перенос переменных из другой борды и всякое такое.
OLAP в Grafana помогает нам не меняя источника вести как привычный timeseries мониторинг, так и погружаться в событийную аналитику. Где-то видел нагрузочное сравнение ts-хранилищ и Clickhouse, выглядело достойно)
Действительно, использовать все подряд в индексе не стоит. Это лишь к тому, что использование колонок из индекса оптимизирует запрос. Довольно простая идея, которую мне показалось уместно выделить
С партициями и вправду я ошибся, стоит использовать toYYYYMM()
Да, это очень хорошее замечание, что такое решение не всегда подходит. Бывают случаи когда перед тем как рассчитать метрику, приходится агрегировать значения по какому-нибудь user_id или какому-то другому полю с высокой кардинальностью. В таком случае динамическое семплирование по случайному числу вовсе приведет к неверным результатам.
Но в обычных ситуациях, при достаточно большом количестве данных мы считаем что данные «размажутся» равномерно и не думаем о распределении
Объем именно передаваемых данных скорее никак не поменяется, все агрегации и фильтрации происходят непосредственно в Clickhouse - Результатом запроса почти всегда будет уже готовый временной ряд.
Динамическое семплирование помогает ограничить количество прочитанных данных при выполнении запросов за большой промежуток времени.
Да, насколько я в курсе, ограничить выбор датасорса не получится и все равно кто-то будет строить графики с неправильным. Но можно намекнуть в названии датасорса, что он нужен только для супер важных графиков, по типу [Clickhouse] CRITICAL
В дополнении к статье — наткнулся на небольшую схемку, которую я составлял на первых этапах. Это может помочь в понимании важности каждого из кусочков мониторинга.
Если задача простая, например просто сгруппировать данные в таблице за последний день, то используем готовый плагин https://github.com/bryzgaloff/airflow-clickhouse-plugin , а именно ClickhouseOperator. Простой в использовании, работает стабильно.
Если что-то посложнее, например что-то чем-то дообогатить нужно, дополнить данными из других кластеров/источников, то используем PythonOperator и там уже крутим данные используя clickhouse_driver https://clickhouse-driver.readthedocs.io/en/latest/api.html#clickhouse_driver.Client.query_dataframe
Мы просто пока не столкнулись с проблемами, но возможно в будущем и придем в чему-то типо dbt :)
Я думаю, что единым источником данных для всего)
В нашем случае проблемы несогласованности метрик между дашбордами были по причине огромного количество различных условий для фильтрации в графиках. Мы решили проблему тем, что создали горячую таблицу, в которую попадают уже отфильтрованные для мониторинга данные.
Мы стараемся не использовать матвью именно для агрегирования. В наших задачах большинство метрик измеряется в квантилях, на больших данных использовать стейты для финальной агрегации квантилей оказывается не очень производительно. Имею ввиду построение графиков.
С задачей агрегирования у нас справляется Airflow. Этого нам пока более чем достаточно. Если короткий ответ, то пока просто не возникало самой потребности в dbt)
Именно самого железа не скажу точные характеристики, но касательно конфигурации Clickhouse нашей команды: мы поделили все данные на несколько кластеров (Кстати о разделении ответственности), у каждого разное железо и свой конфиг. Основной кластер состоит из 6 шардов с реплика-фактор 2. Каждая нода кластера это примерно 7-8Тб SSD и 20-30Тб HDD, получается где-то 1/3 соотношение.
А там ведь уже есть ролевая модель https://grafana.com/docs/grafana/latest/administration/roles-and-permissions/
Можно накинуть роль редактора только редакторам, а остальным роль viewer. Или я не очень вопрос понял
К слову Grafana-as-code я пробовал, но вообще в другом направлении) Решал задачку автоматизации работы с Grafana, типо копирования строк целиком, перенос переменных из другой борды и всякое такое.
Спасибо за такой подробный комментарий!
OLAP в Grafana помогает нам не меняя источника вести как привычный timeseries мониторинг, так и погружаться в событийную аналитику. Где-то видел нагрузочное сравнение ts-хранилищ и Clickhouse, выглядело достойно)
Действительно, использовать все подряд в индексе не стоит. Это лишь к тому, что использование колонок из индекса оптимизирует запрос. Довольно простая идея, которую мне показалось уместно выделить
С партициями и вправду я ошибся, стоит использовать toYYYYMM()
Да, это очень хорошее замечание, что такое решение не всегда подходит. Бывают случаи когда перед тем как рассчитать метрику, приходится агрегировать значения по какому-нибудь user_id или какому-то другому полю с высокой кардинальностью. В таком случае динамическое семплирование по случайному числу вовсе приведет к неверным результатам.
Но в обычных ситуациях, при достаточно большом количестве данных мы считаем что данные «размажутся» равномерно и не думаем о распределении
Объем именно передаваемых данных скорее никак не поменяется, все агрегации и фильтрации происходят непосредственно в Clickhouse - Результатом запроса почти всегда будет уже готовый временной ряд.
Динамическое семплирование помогает ограничить количество прочитанных данных при выполнении запросов за большой промежуток времени.
Спасибо!
Да, насколько я в курсе, ограничить выбор датасорса не получится и все равно кто-то будет строить графики с неправильным. Но можно намекнуть в названии датасорса, что он нужен только для супер важных графиков, по типу [Clickhouse] CRITICAL