ClickHouse в системах сбора статистики

 АЛЕКСАНДР КАЛЕНДАРЕВ, OTG, руководитель группы (ТимЛид), akalend@mail.ru

ClickHouse в системах сбора статистики

Еще не прошло и полгода, как компания Yandex открыла исходный код cвоей аналитической БД ClickHouse, а сегодня на GitHub она уже завоевала 1500+ лайков. Попытаемся разобраться, зачем нужна БД и как ей пользоваться, на примере системы сбора статистики

Возможности ClickHouse

ClickHouse [1] была разработана в рамках проекта Яндекс.Метрики, являющегося второй по величине в мире системой веб-аналитики. ClickHouse принадлежит семейству колоночных СУБД. Система хранения данных колоночных СУБД предполагает хранение данных не по записям (одна запись одна строка), как это реализовано у классических СУБД типа Oracle, MS SQL Server, MySQL, PostgreSQL и т.д., а по колонкам, т.е. у колоночных БД данные привязываются к значениям колонки, которая является первичным ключом.

Ниже представлен пример построчного хранения данных:

Эти же данные хранятся поколоночно в следующем порядке:

Примеры колоночных БД: Cassandra, Hbase, MonetDB, Vertica, Paraccel, Sybase IQ, Exasol, Infobright, InfiniDB, LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+ ит.п.

Разный порядок хранения данных лучше подходит для разных сценариев работы СУБД. Не существует серебряной пули, одинаково хорошо подходящей под существенно различные нужды пользователей. Чем больше нагрузка на систему, тем более важной становится специализация под данный сценарий работы. Специфика колоночных БД такова, что они очень быстры на запись, что очень важно для систем, разработанных под большие нагрузки.

Для онлайн-обработки аналитических запросов предполагается следующий сценарий работы:

• подавляющее большинство запросов на чтение;
• данные обновляются достаточно большими пакетами (> 1000 строк), а не по одной строке;
• данные могут не обновляются вообще;
• данные добавляются в БД, но не изменяются;
• при чтении вынимается достаточно большое количество строк из БД, но только небольшое подмножество столбцов;
• таблицы являются «широкими», т.е. содержат большое количество столбцов;
• запросы идут сравнительно редко (обычно не более сотни в секунду на сервер);
• при выполнении простых запросов допустимы небольшие задержки;
• значения в столбцах небольшие: числа и короткие строки (до 64 байт);
• требуется высокая пропускная способность при обработке одного запроса;
• транзакции отсутствуют;
• низкие требования к консистентности данных;
• в запросе одна большая таблица, все таблицы, кроме одной, маленькие;
• результат выполнения запроса существенно меньше исходных данных, т.е. данные фильтруются или агрегируются;
• результат выполнения помещается в оперативку на одном сервере.

Если в ваших проектах требуется система с вышеперечисленными критериями, то эта система для вас.

Если бы мне пришлось вновь заняться архитектурой разработки систем учета партнерских программ, то мой выбор остановился бы на ClickHouse. Кратко рассмотрим, что собой представляет «партнерка». Есть множество рекламодателей, которым необходимо продать свой товар. Есть большое множество владельцев веб-сайтов, которые размещают на своих сайтах JS-код партнерской программы. Есть множество пользователей, которые посещают эти сайты, кликают по баннерам, показывающимся JS-кодом «партнерки», и приобретают товары или услуги. Все эти клики, посещения или покупки учитываются партнерской системой и владельцы веб-сайтов получают свою комиссию.

Рассмотрим «партнерку» с технической точки зрения. При переходе с сайта партнера (владельца веб-сайта) на «партнерку» необходимо учесть клик, в котором содержится информация: с какого сайта (site_id) был осуществлен переход, номер баннера (banner_id), по которому кликнул пользователь, и учетный номер партнерской программы (partner_id), по которой идет учет и выплачиваются гонорары и комиссии.

Для сбора статистики необходимо учесть по кликам следующие данные:

• site_id – сайт, с которого осуществлен переход, передается в url;
• webmaster_id – ID владельца сайта, вычисляется из site_id;
• banner_id – номер баннера, с которого осуществлен переход, передается в url;
• partner_id – номер партнерской программы, передается в url;
• client_id – ID рекламодателя, вычисляется из partner_id.
• timestamp – время осуществления клика;
• ua – User Agent;
• ip – IP-адрес;
• latitude, lontitude – геокоординаты пользователя.

Как это работает: при переходе на «партнерку» по ссылке с баннера из быстрого key-value-хранилища в основном используют Redis, по ключу site_id:partner_id извлекается недостающая информация: webmaster_id, client_id, адрес перехода, учитывается клик, которому присваивается уникальный номер, формируется адрес перехода и осуществляется сам переход по url, в котором передается некая информация, включающая click_id. К сожалению, в рамках данного материала мы не рассматриваем алгоритмы показа баннера, учитывающие интересы пользователя.

Если пользователь приобрел товары или услуги, то партнер (рекламодатель) делает так называемый кэллбэк, в котором указывает номер заказа, сумму или величину комиссии (определяется типом партнерской программы). Эта информация также учитывается, но уже в таблице лидов.

Статью целиком читайте в журнале «Системный администратор», №1-2 за 2017 г. на страницах 56-59.

PDF-версию данного номера можно приобрести в нашем магазине.

1. https://clickhouse.yandex/reference_ru.html – официальная документация.
2. https://github.com/yandex/ClickHouse – открытый код проекта.
3. https://hub.docker.com/r/yandex/clickhouse-server – doc clicks_3shardsker-образ ClickHouse-сервера.
4. https://hub.docker.com/r/yandex/clickhouse-client – docker-образ ClickHouse-клиента.
5. http://www.cs.umb.edu/~poneil/lsmtree.pdf – слабо структурированное дерево LSM.
6. https://github.com/8bitov/clickhouse-php-client – PHP-клиент.
7. https://github.com/smi2/phpClickHouse – еще один PHP-клиент.
8. https://habrahabr.ru/company/yandex/blog/303282 – статья на «Хабре» в блоге компании Yandex про ClickHouse.

Комментарии могут оставлять только зарегистрированные пользователи