Роль аналитических систем в бизнесе современных компаний трудно переоценить. Именно они позволяют сотрудникам действовать не на основе интуиции или «на глазок», а принимать обоснованные решения. Для этого требуется не только удачно встроить аналитику в бизнес-процессы компании, но и обеспечить ее востребованность пользователями, и ключевую роль в этом играет управление данными.

Анатолий Семин
Анатолий Семин, директор департамента бизнес-приложений компании RedSys

Ключевым показателем с этой точки зрения является время доступа конечных пользователей к аналитической информации. Если оно составляет несколько секунд – это хороший показатель. Если же результат может быть получен лишь через несколько минут, часов или даже дней, то такая аналитика не может использоваться в повседневной работе. Невозможность оперативно обеспечить себя информацией для принятия решения, разобраться в причинах негативной динамики или проверить возникшую идею ведет к полному выключению аналитики из повседневных бизнес-процессов.

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

Роль централизации

Пожалуй, самая большая ошибка в области управления данными – недооценка возможностей централизации этого процесса и, более того, нарочитая его децентрализация. Например, в распределенной компании эти задачи нельзя отдавать на откуп филиалам: действительно, на первых этапах задача может быть решена гораздо дешевле и быстрее, но в дальнейшем это порождает стратегические проблемы, что типично как для коммерческих, так и для государственных структур.

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

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

Управление данными в контексте аналитических систем – вопрос серьезный и острый. Именно на этом этапе закладываются многие потребительские свойства приложений, включая их время отклика. Здесь можно выделить несколько категорий применяемых подходов и решений.

Трехслойное хранилище

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

Нижний – область временного хранения данных, или так называемый стейджинговый слой, куда загружаются данные из источников в исходном виде. Даже если источник изначально не поддерживает историчность данных, стейджинговый слой помогает ее обеспечить, накапливая данные.

Далее следует слой детальных данных, где данные подвергаются очистке и преобразованиям. В его рамках содержится аналитическая, объектная модель данных в той или иной предметной области. Именно она позволяет обеспечить возможность детализации аналитических отчетов до самого низшего уровня и возможность расчета любых аналитических показателей.

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

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

Интеллектуальная загрузка

Следующий компонент управления данными – инструменты ETL (Extraction, Transformation, Loading). Сегодня эти решения уже являются типовыми, и системные продукты такого класса существуют у всех ведущих производителей. Эта составляющая аналитического решения производит извлечение данных из источников и их необходимое преобразование под слои данных в хранилище с целью наполнения аналитических моделей и витрин.

Среди появившихся относительно недавно методик можно выделить подход Change Data Capture – пока не слишком распространенную технологию работы с источниками. Она позволяет извлекать данные из источника, практически не загружая его, ведя работу только с произошедшими изменениями в базе данных, на основе сформированных логов. Она особенно продуктивна при работе с распределенными источниками.

После проведения процедур ETL возникает одна из важнейших задач – управление качеством данных. Как показывает практика, качество данных во всех системах никогда не является идеальным, хотя во многих из них есть соответствующие средства контроля. Всегда есть некорректные данные, ошибки ввода, логические несуразности, дублирующиеся записи в НСИ. Возможны два подхода: использование специализированных пакетов для решения этой задачи и самостоятельная разработка скриптов для проверки данных.

Параллельная обработка

Еще одно интересное и перспективное направление, переводящее работу с аналитикой в новое качество, — использование массивно-параллельной архитектуры (MPP-системы). Она предполагает параллельную обработку данных несколькими процессорами и очень эффективна при больших объемах информации.

У одного из федеральных государственных заказчиков RedSys внедрена платформа IBM Netezza. Это комплекс машин, состоящий из одного главного сервера и нескольких подчиненных ему. Загружая данные, управляющий сервер «размазывает» данные согласно специальным стратегиям, разработанным архитекторами, по всем подчиненным серверам. При появлении аналитического запроса вычисления проводятся параллельно, а управляющий сервер «склеивает» ответы и отправляет результат пользователю. В результате обработка запросов происходит в несколько раз, иногда на порядок быстрее.

Например, обработка сложных запросов, охватывающих данные за длительный период, может длиться до полугода – абсолютно неприемлемое время. В 10 раз быстрее – это «всего» две недели: время, которое заказчик в ряде случаев уже готов ожидать.

Анализ без тормозов

Следующая важнейшая технология – многомерный анализ данных, OLAP. Она хороша тем, что универсальна и позволяет «отвязать» пользователя от разработчика. Имея готовую модель, пользователь может сам проводить необходимые действия, иногда даже весьма глубокий анализ. Так же быстро и эффективно с помощью OLAP-движка можно строить и управленческую отчетность.

Относительно недавно появилось полностью отечественная OLAP-платформа «Полиматика». В ее архитектуре реализована не только обработка данных в оперативной памяти (in-memory OLAP), но и технологии ускорения вычислений с использованием графических процессоров. Основные операции OLAP так или иначе связаны с сортировкой, и графические процессоры очень эффективно решают эти задачи. Как следствие, в системе исчезают ограничения, связанные с объемами данных, количеством и емкостью измерений.

Специалисты Redsys имеют большой опыт использования классических OLAP-инструментов Oracle Hyperion и IBM Cognos TM1. Эти решения хороши, но эффективно справляются с задачами лишь до определенного объема данных 300-400 Гбайт. Выше этого объема любой движок начинает «тормозить». Актуальны там и проблемы с большими размерностями данных. Например, номенклатура крупной торговой сети – 15-20 тыс. позиций в сезон. Умножив на четыре сезона в году, получаем объем, на котором производительность системы уже проседает.

Проводя первые разработки и тесты на «Полиматике», специалисты RedSys построили OLAP-куб с измерением, в котором 150 млн позиций – число людей, проживающих в Российской Федерации. При этом любые действия происходили за считанные секунды.

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

Дешевое хранение

Важная область управления данными, находящая все большее применение, – технологии Big Data. По сути, это набор подходов для обработки больших массивов разнородных данных, в том числе неструктурированных, из различных источников. Мы используем их как отдельное направление для дешевого хранения данных. В системах MPP используется похожий подход, однако они весьма дороги, и поэтому не слишком подходят для хранения «холодных», нечасто востребованных данных.

Например, телекоммуникационным компаниям требуется хранить записи о вызовах (Call Detail Record, CDR), представляющие собой текстовые файлы, объем которых составляет десятки терабайтов. Они нужны для аналитики, но не очень часто, и хранить их в высокопроизводительных системах класса Hi-End не имеет смысла. Другим примером могут служить данные, порождаемые системами мониторинга информационной безопасности, фиксирующими различные инциденты. Хранить их в MPP или «боевом» хранилище слишком дорого. В этом случае гораздо эффективнее использовать технологии Hadoop и проводить анализ средствами NoSQL.

Аналитическое самообслуживание

Наконец, на вершине аналитической пирамиды находится слой средств BI. Он позволяет дополнить все потребности в аналитике, не реализованные в предыдущих слоях. Современные средства достаточно удобны и гибки для этого.

BI – это интерфейс между хранилищем данных и пользователем. Он включает в себя два уровня: бизнес-сущности, понятные пользователям, например «клиенты», «выручка», «прибыль», и физические сущности хранилища данных – таблицы, поля и т. п. Это реализация предметной области на какой-либо платформе.

Среди последних тенденций можно отметить потребность в мобильном BI: пользователи переходят с компьютеров на мобильные устройства. Аналитика должна поддерживать эти потребности, и мы развиваем такие решения, быстро реализуя подобные задачи, поскольку имеем наработки в виде библиотек мобильных объектов. Это позволяет достаточно быстро выполнять подобные проекты.

Данные становятся активом

Объем данных, которыми оперируют компании, резко вырос, и наблюдается переход их количества в качество. Компании начинают осознавать ценность данных, понимают, что с их помощью можно добиться гораздо большего, начинают их воспринимать как бизнес-актив. Это предопределяет выход задач управления данными на более высокий уровень: не случайно в наиболее продвинутых компаниях начинают появляться должности директора по данным (Chief Data Officer).

Разумеется, для реализации новых возможностей нужна определенная зрелость компании – и с точки зрения подходов к управлению, и с точки зрения ее процессов, и прежде всего ИТ-процессов. Кроме того, бизнес должен доверять данным и аналитике на их основе, ведь зачастую одной из фундаментальных проблем российских компаний становится элементарное недоверие бизнеса к данным. Но если данные начинают показывать бизнесу не только результаты деятельности, но и перспективные направления его развития, они действительно становятся полноценным активом компании.

Анатолий Семин, директор департамента бизнес-приложений компании RedSys