1 Введение
В последнее время аналитические системы являются очень востребован ными и используются повсеместно. Чаще всего самой важной частью таких систем является аналитическая база данных, в которую записываются все собы тия самых разных видов, происходящих в системе. Аналитическая база данных позволяет интерактивно выполнять запросы на этих данных, то есть выдавать результат, содержащий информацию о всех поступивших на текущий момент данных. Такой подход к аналитическим задачам называется интерактивной ана литической обработкой [1], и часто подразумевает, что записанные данные не модифицируются. В этой работе рассматривается агрегация данных, которая является важной частью аналитической обработки.
1.1 Актуальность
Распространенный паттерн использования аналитической системы заключается в агрегировании всех данных для подсчета статистики, группируя дан ные по стране, городу, или одному IPадресу. Для этого обычно выполняется GROUP BY запрос на языке SQL, доступный в большинстве реляционных баз данных. Он позволяет группировать строки согласно некоторому выражению, и считать любые поддерживаемые статистики на этих данных.
Для такой агрегации обычно нужно итерироваться по всем сохраненным данным, что неприемлемо для больших систем, которые записывают новые со бытия в базу со скоростью десятков тысяч событий в секунду. Если агрегация данных для больших таблиц это частая операция, которая должна учитывать все данные, включая самые последние, то инкрементальная агрегация это хо роший способ выполнять эту агрегацию быстрее и эффективнее.
Хороший пример, в котором требуется частая агрегация на свежих данных это системы антифрода и борьбы с мошенничеством. Такие системы агреги руют все поступающие события чтобы построить разные статистики, и с помощью этих статистик ищут активности, которые являются мошенническими с большой вероятностью [2]. Примером такой статистики является число уни кальных IPадресов для одного пользователя. Если один пользователь соверша ет много запросов с разных адресов, это говорит о том, что это скорее всего не настоящий пользователь, а робот, который генерирует мошенническую актив ность.
Можно придумать много разных запросов и статистик для обнаружения та кой активности, но считать все эти статистики на твердотельных устройствах хранения данных непрактично для высоконагруженных систем с большим чис лом событий в секунду. Для таких высоконагруженных систем логичным ва риантом является использование основной памяти с быстрым произвольным доступом, которая гораздо быстрее, и способна выдерживать более высокие на грузки. Использование этой памяти для агрегации данных и есть основная тема данной работы, инкрементальной агрегации данных в памяти.
1.2 Краткое описание работы
В этой работе описаны подходы, которые могут быть использованы для реализации возможности инкрементальной агрегации в памяти в ClickHouse,аналитической системе управления базами данных с открытым исходным ко дом. Несмотря на то, что в ClickHouse уже есть возможность инкременталь ной агрегации, в данной работе реализуется альтернативный подход, который будет быстрее работать и позволит выдерживать более высокие нагрузки из за замены дисковых операций более быстрыми операциями в памяти, а так же предоставит альтернативный интерфейс, который позволит эффективно ис пользовать результаты агрегации как часть других запросов.
1.3 Цели и задачи
Целью работы является добавление поддержки в ClickHouse возможности инкрементальной агрегации в памяти.
Перед нами были поставлены следующие задачи:
• Исследовать существующие подходы к агрегации в ClickHouse и других системах
• Реализовать новый табличный движок, реализующий инкрементальную агрегацию данных в памяти
• Реализовать поддержку использования этого движка вместе с материали зованными представлениями
• Протестировать новый функционал в разных сценариях использования
• Добавить в движок поддержку быстрого чтения по ключу
• Оценить производительность нового решения, измерив время обработки запросов и используемые ресурсы
• Сравнить производительность нового и существующих подходов для ре шения задачи определения подозрительной активности
• Подготовить пользовательскую документацию
1.4 Полученные результаты
В рамках данной работы мы добавили в ClickHouse новый табличный дви жок для инкрементальной агрегации в памяти, который является более произво дительным, по сравнению с существующими решениями для инкрементальной агрегации.
Также были получены следующие результаты:
• Реализована поддержка использования материализованных представле ний вместе с новым движком
• Написаны работающие тесты функциональности инкрементальной агре гации
• Проведены тесты производительности, показывающие эффективность но вого способа агрегации по сравнению с существующими
• Подготовлен и выложен на GitHub исходный код, реализующий все опи санные результаты
1.5 Структура работы
В главе 2 описываются важные используемые в ClickHouse термины и по нятия.
В главе 3 проводится обзор релевантных работ, в том числе существующих возможностей ClickHouse и других баз данных.
В главе 4 производится подробный разбор существующих механизмов для агрегации в ClickHouse.
В главе 5 описывается работа, проделанная для создания нового табличного движка.
В главе 6 описывается методика тестирования новой функциональности.
В главе 7 описываются эксперименты для оценки производительности но
вых и существующих решений.
В главе 8 описывается процесс разработки и пользовательская документа
ция.
В заключительной главе 9 подводятся выводы и описываются направления возможной дальнейшей работы.
2 Описание предметной области
2.1 Про ClickHouse
ClickHouse [3] это популярная система управления базами данных для ин терактивной аналитической обработки. Это проект с открытым исходным ко дом, который изначально разрабатывался внутри компании Яндекс более 10 лет назад. Весь код написан на С++ современного стандарта, а разработка ведется в публичном GitHub репозитории [4]. ClickHouse это колоночная SQL база дан ных, которая проектировалась чтобы выполнять запросы максимально быстро.
В ClickHouse проделано много работы для того, чтобы вся обработка дан ных выполнялась очень эффективно, и работала быстрее чем в аналогичных продуктах. Существуют тесты производительности, активно поддерживаемые разработчиками ClickHouse. По результатам этих тестов можно сделать вывод, что ClickHouse может быть быстрее других баз данных в десятки и сотни раз.
2.2 Используемые термины
• Колонки (англ. «Columns») — контейнеры, в которых непосредственно хранятся данные. Могут иметь разные типы, и обычно представляют из себя непрерывные участки в памяти.
• Поле (англ. «Field») — одно значение в колонке. Операции над одиночны ми полями обычно неэффективны, и заменяются операциями над целыми колонками.
• Блок (англ. «Block») — контейнер, который представляет подмножество из строк в таблице. Содержит в себе информацию про колонки, их типы, имена и позиции.
• Потоки блоков (англ. «Block Streams») — специальные интерфейсы, ко торые позволяют читать и записывать блоки, а также проводить с ними преобразования.
• Таблица (англ. «Table») — специальная структура, которая отвечает за за пись, чтение, хранение данных в базе данных.
• Движок (англ. «Storage») — реализация таблицы или класса таблиц. Ре ализация интерфейса движка IStorage обычно содержит функции read, write и другие, которые непосредственно обрабатывают операции с таб лицей на этом движке.
• Интерпретатор (англ. «Interpreter») — специальная структура, которая от вечает за построение плана и конвейера для выполнения запросов.
• Обычная функция (англ. «Function») — простая операция над данными, похожая на математическую, которая по одному значению сопоставляет другое.
• Агрегатная функция (англ. «Aggregate Function») — функция с состояни ем. Накапливает переданные значения в некотором внутреннем состоя нии, и возвращает результат, полученный из этого состояния.
• Агрегатор (англ. «Aggregator») — специальная структура, которая исполь зуется для агрегации данных в ClickHouse.
• Абстрактное синтаксическое дерево (англ. «AST») — специальная струк тура, в которой хранится запрос, прочитанный из строки. Состоит из кор невого и дочерних узлов, образуя таким образом дерево. ASTPtr это ука затель на узел дерева.
• Пайплайн (англ. «Pipeline») — конвейер для обработки данных.
• Чанк (англ. «Chunk») — контейнер, который хранит колонки с данными и количество строк, одинаковое для всех колонок.
• Одноуровневая агрегация (англ. «singlelevel aggregation») — агрегация с использованием одной хештаблицы.
• Двухуровневая агрегация (англ. «twolevel aggregation») — агрегация с использованием нескольких хештаблиц. Ключи между этими хештаблицами разделены на бакеты, и каждому бакету соответствует своя хештаблица.
• Воркер (англ. «Worker») — исполнитель кода. Как правило используется в задачах с несколькими параллельными воркерами.
