Обработка экстремально больших объемов данных требует использования специализированных инструментов. Однако в подавляющем большинстве случаев анализируются выборки до 100 млн. записей, с которыми можно комфортно работать, используя привычные продукты и несложные лайфхаки.
Анализ больших объемов данных (Big Data) требует знания специализированных инструментов и методологий. Их применение — нетривиальная задача. Оно оправдано и даже необходимо, когда речь идет об экстремально больших объемах в миллиарды записей и более, которые по другому невозможно обработать.
При этом, подавляющее большинство аналитиков не оперируют массивами в сотни терабайт, поэтому инструмент, позволяющий комфортно анализировать выборки объемом до 100 млн. записей покроет 99% задач. Такие объемы характерны для бизнесов, связанных с розничной торговлей, телекоммуникациями, банками, интернетом. Чаще всего это транзакционные данные: чеки, платежи, звонки, логи и т.п.
Если данных больше, то обычно аналитик выгружает некоторый сэмпл в десятки или сотню миллионов записей, используемых им для поиска закономерностей. Такие выборки позволяют с одной стороны построить качественные модели, а с другой, — не потребляют огромных вычислительных ресурсов. Кроме того, подобные объемы комфортно анализируются при помощи инструментов, не требующих специальных знаний, например, low-code платформ.
Не существует универсальных способов оптимизации производительности, пригодных для всех задач и любых объемов данных. Поэтому оптимизация должна производиться на различных уровнях:
Конечно, можно увеличить скорость обработки за счет мощного оборудования. Однако, полагаться только на «грубую силу», т.е. более производительные сервера, нерационально. Есть множество простых методов, при помощи которых можно комфортно обрабатывать большие данные без необходимости обновления «железа».
Аналитика данных предполагает выполнение множества простых операций над наборами: выборка, группировка, агрегация, сортировка и т.п. Классические реляционные базы отлично справляются с подобными операциями, т.к. проектировались именно под них.
В СУБД реализовано множество механизмов, позволяющих значительно увеличить скорость обработки:
Это небольшая часть возможностей, которые предоставляют современные СУБД. Повысить скорость можно и десятком других способов:
Причем многие из этих механизмов поддерживаются не только «тяжелыми» СУБД, но и бесплатными базами данных.
Возможности повышения скорости не сводятся только к оптимизации работы СУБД, многое можно сделать при помощи комбинирования различных моделей. Известно, что скорость обработки существенно связана со сложностью используемого математического аппарата. Чем проще алгоритмы анализа, тем быстрее расчеты.
Возможно построение сценария обработки таким образом, чтобы данные «прогонялись» через сито моделей. Применяется простая идея: не тратить время на обработку того, что можно не анализировать.
Вначале используются наиболее простые алгоритмы. Часть данных, которые можно обсчитать при помощи таких моделей, и которые бессмысленно обрабатывать с использованием более сложных методов, анализируется и исключается из дальнейшей обработки.
Оставшиеся данные передаются на следующий этап обработки, где используются более сложные алгоритмы, и так далее по цепочке. На последнем узле сценария обработки применяются самые сложные алгоритмы, но объем анализируемых данных во много раз меньше первоначальной выборки. В результате общее время, необходимое для обработки всех данных, уменьшается на порядки.
Комбинирование моделей, прогон данных через сито моделей
Приведем практический пример использования этого подхода. При решении задачи прогнозирования спроса первоначально рекомендуется провести XYZ-анализ, который позволяет определить, насколько стабилен спрос на различные товары.
Товары группы X продаются достаточно стабильно, поэтому применение к ним алгоритмов прогнозирования позволяет получить качественный прогноз. Товары группы Y продаются менее стабильно, возможно для них стоит строить модели не для каждого артикула, а для группы. Это позволяет сгладить временной ряд и обеспечить работу алгоритма прогнозирования. Товары группы Z продаются хаотично, поэтому для них не стоит строить прогностические модели. Потребность в этих товарах нужно рассчитывать на основе простых формул, например, среднемесячных продаж.
По статистике около 70% ассортимента составляют товары группы Z. Еще около 25% — товары группы Y и только примерно 5% — товары группы X. Таким образом, построение и применение сложных моделей актуально максимум для 30% товаров. Поэтому применение описанного выше подхода позволит сократить время на анализ и прогнозирование в 5 и более раз.
Еще одной эффективной стратегией обработки больших наборов является разбиение данных на сегменты и построение моделей для каждого сегмента по отдельности, с дальнейшим объединением результатов. Чаще всего в больших объемах данных можно выделить несколько отличающихся друг от друга подмножеств. Это могут быть, например, группы клиентов, товаров, которые ведут себя схожим образом и для которых целесообразно строить одну модель.
В этом случае вместо обучения одной сложной модели для всех можно строить несколько простых для каждого сегмента. Подобный подход повышает скорость анализа и снижает требования к памяти благодаря обработке меньших объемов данных в один проход. Кроме того, в этом случае аналитическую обработку можно распараллелить, что тоже положительно сказывается на затраченном времени. К тому же модели для каждого сегмента могут строить различные аналитики.
Разбиение данных на сегменты и построение моделей для каждого сегмента по отдельности, с дальнейшим объединением результатов
Помимо повышения скорости этот подход имеет и еще одно важное преимущество — несколько относительно простых моделей по отдельности легче создавать и поддерживать, чем одну большую. Можно запускать модели поэтапно, получая таким образом первые результаты в максимально сжатые сроки.
Один из популярных подходов к обработке больших данных — модель распределенных вычислений MapReduce. Ее классическая реализация предполагает работу кластера серверов с использованием большого количества компьютеров (называемых «нодами»). Однако сама идея применима для обработки данных в рамках одного сервера.
На Map-шаге данные разбиваются на фрагменты и производится предварительная обработка. Это особенно эффективно при наличии у сервера большого количества ядер. На Reduce-шаге происходит свёртка предварительно обработанных данных и рассчитывается итоговый результат.
MapReduce - модель распределенных вычислений
Например, чтобы подсчитать продажи по каждому городу, нужно сначала агрегировать данные в небольших пачках, а затем просуммировать ранее агрегированные данные. Достоинством подхода является то, что благодаря обсчету фрагментами можно обработать практически любой объем данных, используя ограниченный размер оперативной памяти.
При наличии больших объемов данных можно использовать для построения модели не всю информацию, а некоторое подмножество — репрезентативную выборку. Корректным образом подготовленная репрезентативная выборка содержит в себе информацию, необходимую для построения качественной модели.
Процесс аналитической обработки делится на 2 части: построение модели и применение построенной модели к новым данным. Построение сложной модели — ресурсоемкий процесс. В зависимости от применяемого алгоритма данные кэшируются, сканируются тысячи раз, рассчитывается множество вспомогательных параметров и т.п. Применение же уже построенной модели к новым данным требует ресурсов в сотни раз меньше. Очень часто это сводится к вычислению нескольких простых функций.
Таким образом, если модель строится на относительно небольших множествах и применяется в дальнейшем ко всему набору данных, то время получения результата сократится на порядок по сравнению с попыткой обучения модели на всем имеющемся объеме данных.
Сэмплинг
Для получения репрезентативных выборок существуют специальные методы, например, сэмплинг. Их применение позволяет повышать скорость аналитической обработки, не жертвуя качеством анализа.
Описанные подходы — это только небольшая часть методов, которые позволяют анализировать огромные объемы данных. Существуют и другие способы, например, применение масштабируемых алгоритмов, иерархических моделей, обучение окнами и прочее.
Анализ огромных баз данных — это нетривиальная проблема, которая в большинстве случаев не решается «в лоб», однако современные СУБД и аналитические платформы предлагают множество методов решения этой задачи. При разумном их применении системы способны перерабатывать сотни миллионов и даже миллиарды записей с приемлемой скоростью.
Другие материалы по теме:
Быстрый ETL от Loginom для PostgreSQL
