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

Рассвет и закат бизнес-аналитики

С ростом объемов данных стало очевидно, что построение сложных отчетов в системах класса ERP, CRM и других бизнес-приложениях, поддерживающих текущую работу компании, существенно замедляется, и это зачастую приводит к полной остановке ключевых бизнес-процессов. Одним из решений стала выгрузка данных из учетных систем в специальные хранилища для последующего анализа, и до определенного момента это помогало, однако архитектура традиционных систем поддержки принятия решений основана на запросах, в частности SQL, не позволяющих учитывать взаимосвязи между элементами данных.

В ответ на это для ускорения обработки сложных запросов стали применяться различные варианты реализации методов оперативной аналитической обработки (OLAP). Некоторые ROLAP (Relational Online Analytical Processing) позволяют извлекать данные в реальном времени по мере необходимости, но требуют больших вычислительных ресурсов. По такому принципу работают, например, IBM Informix MetaCube и MicroStrategy. А технологии MOLAP (Multidimensional Online Analytical Processing), например Essbase и Palo, хотя и отличаются высокой производительностью, требуют предварительной агрегации данных по нескольким измерениям (OLAP-кубы). Попытки компенсировать недостатки обоих подходов привели к созданию семейства неких гибридных технологий HOLAP (Hybrid Online Analytical Processing). Многие современные СУБД, такие как Oracle или Microsoft SQL Server, поддерживают различные варианты реализации OLAP и поэтому не могут быть отнесены к какому-то строгому классу. И тем не менее они не используют данные с учетом взаимосвязей между их отдельными элементами.

В начале нынешнего века произошло стечение малозаметных на первый взгляд, но важных для развития бизнес-аналитики обстоятельств — широкое распространение получила 64-разрядная архитектура и существенно подешевела оперативная память, что подстегнуло разработчиков к созданию систем, в которых вся обработка данных выполняется в оперативной памяти (in-memory). По этому пути пошли такие производители СУБД, как Oracle (TimesTen и Bercley), MicroStrategy, IBM (TM1), SAP (HANA) и QlikTech, которая, помимо обработки в памяти, предложила еще и ассоциативную модель данных.

Свою систему QlikView компания QlikTech относит к классу Business Discovery («бизнес-открытия» или «бизнес-исследования»), полагая, что эти системы должны прийти на смену популярным ныне продуктам для бизнес-анализа. Идея Business Discovery заключается в том, чтобы заменить или дополнить типовые предопределенные алгоритмы обработки данных гибкими методами ассоциативного поиска и анализа. Принципы работы таких систем максимально приближены к известным правилам функционирования человеческого мозга и построены на свободно формируемых ассоциативных связях.

В QlikView при загрузке данных в память таблицы связываются между собой по ключевым полям, имеющим одинаковые названия. Таким образом, когда пользователь выбирает значение поля в одной таблице, автоматически подключаются и все связанные (ассоциируемые) данные из остальных таблиц. При этом пользователь в процессе исследования данных может «скользить» по этим ассоциативным связям в любом направлении, выстраивая непредсказуемые логические цепочки, что иногда позволяет приходить к неожиданным выводам. Вместо жестко запрограммированных отчетов пользователь выполняет запросы «по требованию» (ad-hoc), руководствуясь исключительно собственным здравым смыслом. При этом сам пользователь может и не обладать специальными знаниями о структуре данных или языке запросов.

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

 

Практика QlikView

Торговый дом «Копейка» (X5 Retail Group) применяет QlikView для анализа данных из 80 источников, среди которых системы от SAP (около 15 Тбайт данных) и система Gestori (данные по кассовым чекам — за два месяца это 150 Гбайт информации и 3 млрд строк бухгалтерских проводок). Согласно проведенным замерам, с внедрением QlikView время выполнения запросов сократилось на 98,6% (раньше отчетность формировалась непосредственно в конкретных учетных системах). В системе QlikView производится кластерный анализ продаж, анализ товарооборота, эффективности маркетинговых акций, почасовой анализ продаж с детализацией до чеков, а также анализ продаж на множестве чеков, сгруппированных по интервалам сумм покупок, и др.

ООО «Квиза-Трейд» (торговая марка «Велика Кишеня») – одна из крупнейших национальных сетей розничной торговли Украины (47 супермаркетов в 23 городах и собственное производство продуктов). Для управления товарными запасами компания использует два распределительных центра. Общий объем данных в учетных системах — 7 млрд строк, причем 1,5 млрд строк одновременно находятся и обрабатываются в оперативной памяти. Если до внедрения системы отчет типа Out of stock (отсутствие в торговой точке заявленного в наличии товара) рассчитывался за 4 часа, то теперь — за 5 минут.

Сеть декоративно-строительных гипермаркетов в формате «Сделай сам» (ЗАО «Новая линия») предлагает отечественные и импортные товары для строительства, ремонта и обустройства дома, причем 40% ассортимента составляет эксклюзивная продукция, изготовленная по индивидуальному дизайну мировыми производителями. Объемы данных — 12 млрд строк за всю историю продаж; 800 млн строк одновременно находятся в оперативной памяти и обрабатываются в QlikView. Показательным можно считать время (4 минуты) создания отчета «Оборачиваемость за год» по 105 тыс. активных товарных позиций.

 

Решать по частям

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

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

На самом деле пользователям редко бывают нужны всеобъемлющие отчеты, в которых одновременно собраны, например, все детальные данные о продажах за последние 10-15 лет, включая поставщика конкретной партии товара, номер кассы в магазине, а также пол, возраст и прочие характеристики покупателя. Каждый раз, сталкиваясь с определенной проблемой и решая очередной практический вопрос, пользователи обращаются лишь к той части данных, которая может быть им полезна в конкретном случае. Именно поэтому разработчики из QlikTech не ограничились использованием одной монолитной системы данных. В зависимости от их объема и потребностей пользователя QlikView позволяет как обрабатывать все данные в одном приложении, так и создавать набор независимых приложений, решающих узкий круг специализированных задач. Такие приложения относительно быстро разрабатываются, достаточно компактны и ими удобно обмениваться, например, через корпоративный портал QlikView Server. Они хранят лишь часть общего объема данных и ассоциативных связей между ними, что обеспечивает высокую скорость работы. И наконец, эти приложения интегрируются друг с другом, что позволяет пользователям исследовать данные по всем направлениям, выстраивая сложные логические цепочки. Обычно на платформе QikView можно реализовать проекты за три-пять недель, однако в некоторых отраслях (крупная розничная сеть, телеком, финансы) необходимо анализировать такие объемы данных, для обработки которых быстродействия QlikView может оказаться недостаточно. В этом случае имеется возможность создания квазихранилища данных на базе формата qvd — весь объем данных по некоторым базовым критериям делится на несколько порций, каждая из которых сохраняется на диске в отдельном файле qvd, в виде готового к работе приложения. По запросу пользователя нужное приложение загружается в оперативную память, и затем анализ продолжается в штатном режиме.

Результаты испытаний, проведенных компанией RBC Group, показали, что конечный пользователь может оперировать миллиардами строк данных, сохраняя при этом интерактивность аналитических приложений. Испытания проводились на сервере с 72 Гбайт оперативной памяти и двумя шестиядерными процессорами. Исходный массив данных состоял из 2 млрд строк по 27 полей и охватывал данные по 470 магазинам и 25 тыс. товарных позиций. Формирование  массива,  содержащего 427 млн строк данных о продажах с высоким коэффициентом сопоставлений и расчетов (включая расчет оборачиваемости и учет совместно продаваемых товаров), заняло 130 секунд, а отклик на любой запрос пользователя к полученному приложению в 95% случаев не превышал 1 секунды.

Андрей Ревуцкий (revutskiy@rbcgrp.com) — сотрудник компании RBC Group (Киев).