ClickHouse в системах сбора статистики::Журнал СА 3.2017
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1826
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1887
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1446
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1066
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1636
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

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

Архив номеров / 2017 / Выпуск №3 (172) / ClickHouse в системах сбора статистики

Рубрика: Базы данных /  Инструменты

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

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

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

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

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

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

host timestamp p1 p2
127.0.0.1 1488621674 2 a
127.0.0.2 1488621674 5 a
127.0.0.21 1488621675 1 f
127.0.0.27 1488621675 5 b

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

host
127.0.0.1
127.0.0.2
127.0.0.21
127.0.0.27
 
p1
2
5
1
5
 
timestamp
1488621674
1488621674
1488621675
1488621675

Примеры колоночных БД: 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.

Комментарии отсутствуют

Добавить комментарий

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

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru