В нашей системе аналитики события проходят путь от шины данных через сервис сбора событий, попадают в 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 для приема 100 млрд событий в сутки
Доклад будет интересен всем, кто работает с ClickHouse под высокой нагрузкой, собирает real-time-данные, использует Kafka и хочет понять, где тонко и как не порвать.