Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Журнал ВРМ World

«Болезни роста» современных хранилищ данных

Недавно Иен Николсон (Ian Nicholson), эксперт компании BIReady Australia, поставщика BI-решений, задался вопросом, почему довольно часто проекты внедрения хранилищ данных заканчиваются неудачей. Особый интерес, по его мнению, вызывает тот факт, что это происходит сегодня – с наличием современных навыков, методов и инструментов, позволяющих обеспечить их быстрое и успешное развёртывание. Фактически, упоминание хранилищ данных вызывает у опытного IT-менеджера мысли о крупном, рискованном и дорогом проекте, который имеет незначительные шансы на успех.

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

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

Востребованность

Ключевой маркер успешности каждого BI-проекта. Если внедрённое решение не востребовано пользователями - он провален.

Пользователи не знают, что они не знают

Совершенно бессмысленно платить бизнес-аналитику за недели расспросов пользователей об их ожиданиях относительно BI-проекта. Пользователи этого не знают и никогда не узнают, до тех пор, пока не увидят. Это означает, что каскадная или SDLC-методика (оперирующая жизненным циклом разработки систем) неприменимы для разработки BI-решения. Использование диаграмм Ганта для управления BI-проектом – это верный признак движения на пути к провалу. Более подходящими методологиями являются Scrum, методология управления проектами, делающая акцент на качественном контроле процесса разработки, или Agile, подход ориентированный на использование итеративной разработки. Таким образом, инкрементальные, итерационные шаги – это правильный подход.

Все BI-решения потребуют изменений

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

Всем нравится Кимболл

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

В опросе, проведённом в Linkedin некоторое время назад, экспертам по бизнес-аналитике был задан вопрос о том, какая часть BI-проекта уходит на то, чтобы просто правильно доставить данные. Ответ был 75-80%, то есть три четверти трудозатрат в каждом BI-проекте тратится на приведение данных в порядок. Таким образом, внесение изменений потребует больших усилий.

Все игнорируют Инмона и Линштедта

Билл Инмон (Bill Inmon), «отец хранилищ данных», является автором многочисленных книг на эту тему. Его концепция «корпоративной информационной фабрики» – сбор данных изо всех источников и приведение их к третьей нормальной форме в корпоративном хранилище данных - имеет огромное значение. Это делает данные более «общими» на низком уровне детализации. Данные в этом состоянии являются прекрасным источником для схемы «звезда» Кимболла.

Ден Линштедт (Dan Linstedt) расширил модель третьей нормальной формы с помощью архитектуры Data Vault, которая позволяет хранить историческую информацию о данных и их источнике. Уникальной особенностью Data Vault является возможность проследить состояние хранилища в любой момент времени. Вероятно, подходы Инмона и Линштедта игнорируются из-за того, что их сложно реализовать с помощью традиционных инструментов ETL.

Хранилища данных не строятся с помощью ETL-инструментов

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

«Убийцы» производительности

Проект внедрения хранилища данных - это довольно сложная инициатива. Мало того, что проект в целом может закончиться неудачей, но также следует принимать во внимание и возможные проблемы с производительностью. Хорошо спроектированное продуманное хранилище данных может помочь повысить прибыль компании, - например, благодаря тому, что данные BI-приложений поставляются бизнес-пользователям на своевременной основе. Однако, если не соблюдать осторожность, «производительность хранилища данных может проседать во множестве разных мест», считает Виллиам МакНайт (William McKnight), президент McKnight Consulting Group. Например, МакНайт указывает на недостатки моделирования данных и системной архитектуры, как потенциальные помехи для производительности.

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

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

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

Публикации

  1. Йен Николсон (Ian Nicholson). «Хранилища данных: невыученные уроки» (Data Warehousing: Lessons We Have Failed to Learn), 27 мая 2013 г.
  2. Крэг Стедман (Craig Stedman). «Убийцы» производительности хранилищ данных и как их избежать (Data warehouse performance killers -- and how to avoid them), май 2013 г.