МЕТОДЫ И АЛГОРИТМЫ ДЛЯ ХРАНЕНИЯ И ОБРАБОТКИ РЕТРОСПЕКТИВНОЙ ИНФОРМАЦИИ

Основой уровня хранения данных для аналитической системы является быстрая и отказоустойчивая СУБД. Стандартные решения, применяемые для работы корпоративной системы, не подходят для аналитики. Для быстрой работы аналитических запросов данные на диске должны хранится по колонкам, а не по строкам, в отличие от большинства СУБД.

Результатом работы многих приложений являются данные, накопленные за большой промежуток времени. Их представление и тип отличаются в зависимости прикладной области. Это могут быть покупки (ритейл), транзакции (финансы). Все эти данные хранятся долгое время и никакой пользы не приносят. Однако современные методы и алгоритмы работы с данными позволяют извлечь из них пользу. От статистики продаж по датам и регионам до прогнозирования спроса на продукцию с помощью моделей машинного обучения.

Прежде чем аналитик получит возможность работать со всеми данными предприятия необходимо провести преобразования и привести все данные к единому виду (рис. 1) в виде плоских таблиц (для машинного обучения) и совокупности таблиц в виде схемы звезда (для витрин данных).

Рисунок 1. Преобразование всех данных к единому виду

Весь массив преобразованных данных хранится в реляционной СУБД в виде строк на диске и пользователь, составляя SQL запросы к таблице фактически работает со строками. Для ускорения поиска (WHERE) в большинстве современных СУБД предусмотрены индексы, которые значительно ускоряют такие операции. Но для аналитика очень важно получить результат запроса быстро при этом производя группировку и агрегацию по полям.

SELECT SUM(total) from food_mart WHERE country = Russia;

Данные в реляционной СУБД хранятся построчно в следующем виде:

[A1, B1, C1], [A2, B2, C2], [A3, B3, C3]

Где A, B, C это поля, а 1, 2, 3 номер записи

Контроллер жесткого диска при выполнение ранее приведенного запроса считает все сроки таблицы, для которых условие фильтра верно, а уже само приложение (СУБД) будет обрабатывать поля, приведенные в операциях группировки и суммировании. Такой подход очень неэффективный. Учитывая объемы современных хранилищ аналитических данных и количество пользователей можно предположить, что аналитик будет получать результаты выполнения запроса очень долго.

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

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

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

Распараллеливание запроса на ядра процессора (рис. 2). После сохранения данных в таблицу происходит шардирование по перинному ключу с равномерным распределением. Можно гарантировать, что у каждого инстанса будет равное количество информации. Скорость выполнения запроса вырастает пропорционально количеству ядер (по одному инстансу на ядро).

Рисунок 2. Массово-параллельная архитектура.

Поколоночное хранение данных со сжатием.

Представим, что данные теперь имеют колоночное представление:

[A1, A2, A3], [B1, B2, B3], [C1, C2, C3]

Где A, B, C это поля, а 1, 2, 3 номер записи

Выполнение агрегирующего запроса:

SELECT SUM(total) from food_mart;

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

Для подтверждения теоретических выводов проведем эксперимент на тестовом стенде.

Тестовый стенд имеет следующую конфигурацию:

2 x Xeon E5-2609; 48 GB RAM; 4 x 300 GB SAS

Тестирование производилось на следующих СУБД с построением индексов:

• СУБД Greenplum (column storage)
• СУБД Greenplum (row storage)
• PosgreSQL 9.2 (без MPP)
• PosgreSQL 9.6 (с MPP)

Замерялось время тестирования для следующих операций, на открытых данных совокупным объемом 10 GB, которые можно скачать по ссылке [4].

• COPY (load) – загрузка данных
• GROUP BY a, SUM(x) – группировка и агрегирование по одному полю
• GROUP BY a, b, SUM(x), SUM(y)

По результатам тестирования получаются следующие результаты:

• Загрузка данных выполняется с одинаковой скоростью в пределах погрешности измерений
• По аналитическим запросам колоночный Greenplum (column storage) является безусловным лидером
• Greenplum (row storage) проигрывает почти в 6 раз column storage при одномерной группировке
• Результаты Greenplum (row storage) сравнимы с PosgreSQL 9.6, так как в обоих случаях ускорение получается за счет распараллеливания, но отставание увеличивается пропорционально количеству колонок в запросе.
• Ускорения за счет колоночного хранения получается больше чем в 2.5 раза

Полученные результаты измерений представлены на диаграмме (рис. 3).

Рисунок 3. Среднее сравнение скорости на небольших объемах данных

Для более справедливого эксперимента увеличим изначальный набор данных в 10 раз.

• 1 200 000 000 записей
• 100 GB

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

Таблица 1.

Сравнение скорости обработки запросов.

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

Список литературы:

1. Regina Obe, Leo Hsu. PostgreSQL: Up and Running. O'Reilly Media, 2017. С.13 -20.
2. Чернышев Г. А. Организация физического уровня колоночных СУБД // Труды СПИИРАН, 2013. С.80-83.
3. Колоночные СУБД — принцип действия, преимущества и область применения. 28.01.2011. URL: http://habr.com/post/95181/
4. Data expo 09 — Airline on-time performance. 01.02.2009. URL: http://stat-computing.org/dataexpo/2009