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

История ClickHouse

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

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

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

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

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

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

  • Хранение данных для восстановления сессий из Yandex.Metrica.
  • Обработка промежуточных данных.
  • Создание глобальных отчетов с Analytics.
  • Выполнение запросов для отладки движка Yandex.Metrica.
  • Анализ логов из API и пользовательского интерфейса.

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

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

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

Однако агрегирование данных имеет множество ограничений:

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

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

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

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

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