Оптимальный подход к проекту внедрения хранилищ данных

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

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

Согласно недавнему отчету «Магический квадрант СУБД для хранилищ данных» компании Gartner, сегодня наблюдается рост спроса на консалтинговые услуги, связанные с внедрением технологий хранилищ данных. Исследование Gartner показало, что существующие пользователи хранилищ данных склоняются к использованию новых архитектур с расширенными возможностями управления данными. Однако, в то же время, многие пользователи впервые входят на этот рынок.

«В 2012 году Gartner зафиксировал значительное увеличение запросов от организаций, впервые желающих внедрить хранилища данных и источники аналитические информации, - отмечают аналитики. - Это может показаться невероятным спустя 25 лет с момента наступления эры хранилищ данных, но общение с клиентами подтверждает, что они рассматривают перспективы применения хранилищ данных действительно с нуля».

Эксперты Gartner предупреждают, что организациям-«новичкам» следует тщательно выбирать поставщика хранилища данных, настороженно относиться к производителям программного обеспечения, если те попытаются переоценить инфраструктуру. «История показывает периодическое возрождение дискредитированных практик исполнителей с сомнительной репутацией, которые провалили внедрение хранилища данных в организации, - утверждают в Gartner. - Поэтому, клиенты должны быть осторожны, им следует провести пилотный проект (proof-of-concept), отражающий их предполагаемую специфику использования хранилища в течение трёх-пяти лет. Новые пользователи этой технологии должны тщательно оценить, насколько изменится их рабочая нагрузка и как она может управляться решениями при разных архитектурах».

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

С урезанием бюджетов, увеличением числа нормативных требований и геометрическим ростом расходов на обслуживание таких систем (наряду с ростом количества временных решений), многие организации отметили движение маятника в противоположном направлении: избегать централизации данных и полагаться вместо этого на прямые межсистемные сообщения. В статье в Wall Street & Technology известные специалисты в области систем управления информацией утверждают, что «компании больше не тратят деньги на гигантские хранилища данных и согласование единой модели данных, размещающих всю информацию в одном месте. Вместо этого они выбирают ориентированное на сообщения управление данными, где ссылки и инфраструктура лежат в системах записи, а затем эта информация передается для последующих систем».

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

Например, создание довольно примитивной отчётности по кредитным рискам вылилась бы для крупного регионального банка в необходимость извлечения информации более чем из 30 систем-источников, данные которых хранятся в «проприетарных» форматах, в различных версиях реляционных таблиц и баз данных Lotus Notes, в сотнях электронных таблиц, в текстовых файлах и других «репозиториях». Информация о клиентах находилась бы не менее чем в девяти CRM-системах.

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

• Разработать начальную, общую, структурно гибкую и простую модель, которую можно легко приспособить к новым требованиям.
• Наполнить хранилище - как подразумевает термин «сторона потребления» - только теми данными, которые необходимы для конкретного бизнес-пользования - вместо старого подхода «на всякий случай».
• Убедиться, что даже с добавлением специфических бизнес-требований структура хранилища остаётся «основополагающей», то есть содержит только данные и бизнес-логику всей организации, которая может быть доступна лишь с помощью надлежащим образом разработанных средств.
• Построить вторичный слой специализированных витрин данных, где дополнительная информация и логика, относящаяся к одному или нескольким «потребителям» (которыми могут быть структурные подразделения или конкретные типы отчётов), может обогатить или преобразовать данные в соответствии с определёнными потребностями.
• Создать систему ответственного управления, в которой расходы на разработку, хотя бы частично, несёт «потребитель» данных, обеспечивая, таким образом, тщательную оценку любых новых требований.

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

Публикации

1. Марк Брунелли (Mark Brunelli) «Магический квадрат Gartner обнаружил растущий спрос на хранилища данных» (Gartner Magic Quadrant finds rising demand for data warehouse services), 27 марта 2013 г.
2. Виктор Зискин (Victor Ziskin) «Подход к хранилищу данных с точки зрения потребителя: разработка необходимого, а не возможного» (Demand-side-driven data warehousing: Building what you need, not what you could), 27 февраля 2013 г.

Автор: По материалам зарубежных сайтов