В нашей системе аналитики события проходят путь от шины данных через сервис сбора событий, попадают в Kafka, а затем — в ClickHouse с помощью Kafka-Engine. В архитектуре — три кластера ClickHouse (main, replica, sandbox) с настроенной репликацией, каждый из которых обслуживает свою зону ответственности: сбор, BI, пользовательские запросы.
Мы провели серию нагрузочных и отказоустойчивых тестов, чтобы убедиться, что система выдерживает реальные и экстремальные сценарии. В докладе расскажем:
* Как устроен наш стриминговый пайплайн: от шины данных до ClickHouse.
* Как сервис сбора событий справляется с миллиардами событий.
* Какие тесты проводили:
* 9 млрд событий в сутки;
* 15 млрд событий в сутки;
* 24 млрд событий в сутки — предел, к которому стремились;
* внезапный скачок нагрузки х2;
* сбой кластера ClickHouse и как он проявился;
* сбой Kafka и поведение пайплайна;
* запись всех событий в один проект вместо 50+ — и к чему это привело;
* Kafka-Engine vs Kafka-Connect — замеры, сравнение, выбор.
* Как организовали мониторинг и метрики, на что смотрели в Grafana и ClickHouse.
* Какие баги, затыки и инсайты мы получили и как это повлияло на прод.
Доклад будет интересен всем, кто работает с ClickHouse под высокой нагрузкой, собирает real-time-данные, использует Kafka и хочет понять, где тонко и как не порвать.