Перейти к основному содержимому
Перейти к основному содержимому

История ClickHouse

ClickHouse был изначально разработан для работы с Yandex.Metrica, второй по величине платформой веб-аналитики в мире, и продолжает быть ее основным компонентом. С более чем 13 триллионами записей в базе данных и более чем 20 миллиардами событий ежедневно, ClickHouse позволяет создавать на лету пользовательские отчеты непосредственно из неагрегированных данных. В этой статье кратко рассматриваются цели ClickHouse на ранних этапах его разработки.

Yandex.Metrica создает индивидуализированные отчеты на лету на основе посещений и сеансов, с произвольными сегментами, определяемыми пользователем. Для этого часто требуется формирование сложных агрегатов, таких как количество уникальных пользователей, так как новые данные для построения отчетов поступают в реальном времени.

На апрель 2014 года Yandex.Metrica отслеживала около 12 миллиардов событий (просмотры страниц и клики) ежедневно. Все эти события нужно было хранить, чтобы построить пользовательские отчеты. Один запрос мог требовать сканирования миллионов строк за считанные миллисекунды или сотен миллионов строк всего за несколько секунд.

Использование в Yandex.Metrica и других сервисах Яндекса​

ClickHouse выполняет несколько задач в Yandex.Metrica. Его основная задача — строить отчеты в режиме онлайн, используя неагрегированные данные. Он использует кластер из 374 серверов, которые хранят более 20.3 триллионов строк в базе данных. Объем сжатых данных составляет около 2 ПБ, не включая дубликаты и реплики. Объем несжатых данных (в формате TSV) составил бы примерно 17 ПБ.

ClickHouse также играет ключевую роль в следующих процессах:

  • Хранение данных для Session Replay из Yandex.Metrica.
  • Обработка промежуточных данных.
  • Построение глобальных отчетов с помощью аналитики.
  • Запуск запросов для отладки движка Yandex.Metrica.
  • Анализ логов из API и пользовательского интерфейса.

В настоящее время существует несколько десятков инсталляций ClickHouse в других сервисах и подразделениях Яндекса: вертикали поиска, электронная коммерция, реклама, бизнес-аналитика, мобильная разработка, персональные сервисы и другие.

Агрегированные и неагрегированные данные​

Существует распространенное мнение, что для эффективного подсчета статистики необходимо агрегировать данные, так как это уменьшает объем данных.

Однако агрегация данных имеет много ограничений:

  • Необходимо иметь заранее определенный список нужных отчетов.
  • Пользователь не может создавать пользовательские отчеты.
  • При агрегации по большому количеству различных ключей объем данных почти не уменьшается, и агрегация становится бессмысленной.
  • Для большого количества отчетов существует слишком много вариантов агрегации (комбинаторный взрыв).
  • При агрегации ключей с высокой кардинальностью (таких как URL) объем данных не уменьшается значительно (менее чем в два раза).
  • По этой причине объем данных с агрегацией может расти, а не уменьшаться.
  • Пользователи не просматривают все отчеты, которые мы генерируем для них. Большая часть этих расчетов оказывается ненужной.
  • Логическая целостность данных может быть нарушена для различных агрегатов.

Если мы не агрегируем ничего и работаем с неагрегированными данными, это может сократить объем расчетов.

Тем не менее, при агрегации значительная часть работы выполняется оффлайн и завершается относительно спокойно. В отличие от этого, онлайн-вычисления требуют максимально быстрой обработки, так как пользователю необходимо получить результат.

Yandex.Metrica имеет специализированную систему для агрегации данных, называемую Metrage, которая использовалась для большинства отчетов. Начиная с 2009 года, Yandex.Metrica также использовала специализированную OLAP базу данных для неагрегированных данных под названием OLAPServer, которая ранее использовалась для строителя отчетов. OLAPServer хорошо справлялась с неагрегированными данными, но имела множество ограничений, которые не позволяли использовать ее для всех отчетов по желанию. К ним относились отсутствие поддержки типов данных (только числа) и невозможность инкрементального обновления данных в реальном времени (это могло быть сделано только путем переписывания данных ежедневно). OLAPServer не является СУБД, а специализированной БД.

Первоначальной целью ClickHouse было устранение ограничений OLAPServer и решение проблемы работы с неагрегированными данными для всех отчетов, но с течением времени он стал универсальной системой управления базами данных, подходящей для широкого спектра аналитических задач.