Ян Шимек:
Ян Шимек: «Хранилище данных не должно быть игрушкой для ИТ-департамента и объектом затрат для бизнеса — оно должно давать конкретный экономический эффект, помогать зарабатывать деньги»

Ян Шимек, вице-президент компании Teradata по Восточной Европе, ответил на несколько вопросов, связанных с перспективами хранилищ данных и спецификой проектов, связанных с их созданием.

Что, с вашей точки зрения, в наибольшей степени повлияло на развитие отрасли хранилищ данных в последние пять лет?

Основным фактором был рост конкуренции и усложнение ее характера во всех сегментах рынка. В Западной Европе эти явления можно было наблюдать и раньше, а в Восточной Европе — в последние пять лет. Приведу пример из новейшей истории России. В вашей стране три крупнейших мобильных оператора. Пять лет назад у каждого из них было 25-25 млн зарегистрированных SIM-карт, а сегодня — 50-70 млн. Таким образом, мобильной связью от этих компаний обеспечен практически каждый житель страны, а ведь есть еще региональные операторы. Вот реальный уровень конкуренции: на рынке не осталось никого, кто не имел бы мобильного телефона. И теперь операторы не могут экстенсивно расти за счет продажи своих продуктов тем, у кого аналогичных продуктов еще нет. Им нужны клиенты, которые работают с конкурентами, и необходимо понять, как их получить. Надо разобраться в их поведении, в том, чего они хотят. Чтобы извлечь полезную информацию из доступных данных, необходимо поместить их в хранилище.

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

Следующий фактор — технологического характера. До некоторого времени производители приложений самостоятельно разрабатывали разные версии своих решений для разных серверных платформ или предлагали открытые решения. Важной для отрасли технологической тенденцией стало создание адаптируемых платформ для решения различных аналитических задач, которые включают аппаратную составляющую и СУБД. Мы начали предлагать такие решения еще 15 лет назад. И разговоры об открытости решений постепенно исчезают. Пользователей уже не волнует, кто сделал для их компьютера процессор или оперативную память, — они рассматривают хранилище данных как некую услугу. И это важнейший сдвиг в сознании.

Далее, архитектурный фактор. Мы всегда пропагандировали третью нормальную форму, одну версию правды, один репозиторий, принцип «сохранять однократно, а использовать многократно». Наш архитектурный подход предполагает наличие одного репозитория данных и слоя логических витрин поверх репозитория.

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

Каковы основные тенденции развития хранилищ данных с точки зрения бизнеса?

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

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

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

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

Что означает термин in-database analysis?

Предположим, вы работаете с сотнями источников данных. С помощью ETL-инструментов вы загружаете их в хранилище. Традиционный подход к анализу этих данных состоит в извлечении необходимых данных и перемещении их в витрину, откуда их будет брать аналитическое приложение, а в завершение результат будет возвращен в хранилище данных. Технология in-database analysis предполагает использование для аналитических вычислений компьютерных ресурсов, на которых реализованы сами хранилища данных, и передачу в приложение только конечного результата. Поскольку хранилища Teradata основаны на очень производительных параллельных компьютерных системах, при этом подходе исключается необходимость физического перемещения больших объемов данных, и они обрабатываются внутри СУБД. Правда, реализация такого подхода требует серьезной модификации приложений.

Каковы основные этапы проектов создания хранилищ данных?

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

Далее, необходимо обладать технологиями создания хранилищ данных. Если вы начали создавать хранилище и разрабатываете для него логическую модель, то у вас должен быть словарь, определяющий все основные понятия. Даже такие расхожие понятия, как «клиент» и "продукт", имеют сотни определений. Спросите финансового директора, как он определит понятие "клиент", и сравните его ответ с ответом директора по маркетингу. Скорее всего, они дадут совершенно разные определения. Необходимо собрать вместе ключевых сотрудников из разных подразделений и заставить их унифицировать понятия, сформировать единый словарь. Только получив представление о том, что означают те или иные термины в данной организации, можно определить источники необходимых данных, которые следует загрузить в хранилище.

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

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