Юрий Воинов

Технология Хранилищ Данных существует и развивается во всем мире уже достаточно долго. Исторически она восходит к Системам Поддержки Принятия Решений (DSS¹), которые в техническом плане представляют собой базу данных, работающую по принципу накопления свершившихся фактов, связанных с бизнес-процессами. В задачи DSS-системы входит предоставление данных по не предопределенным запросам (так называемым ad hoc запросам).

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

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

Миф 1. Первым и основным достоинством Корпоративного Хранилища Данных является возможность доступа к данным посредством инструментария Business Intelligence.

Существует большое количество решений, ориентированных именно на верхушку айсберга Хранилища Данных - конечного пользовательского интерфейса (потребитель хочет этого - потребитель получает это). Системы и компоненты подобного класса решений даже имеют собственное название - Business Intelligence. Что именно скрыто за фасадом таких решений - потребителю, как правило, неизвестно. "Я не знаю, что я хочу, но хочу, чтобы было хорошо" - как раз такой подход характерен для очень большого процента конечных пользователей информационных систем, причем не только нижнего уровня - но и многих руководителей. И, в принципе, данный подход зачастую справедлив, но при этом содержимое системы и ее функции полностью отдаются на откуп и ответственность поставщика решения.

Чем объясняется успех систем подобного рода на рынке? Потребитель получает якобы полностью готовое решение, которое имеет развитый пользовательский интерфейс, которое не требует собственных затрат на разработку, поскольку уже разработано, и его достаточно "распаковать и включить", чтобы все заработало.

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

Резюмируя вышесказанное, Хранилища Данных, в которых доминируют концепции Business Intelligence, зачастую вырождаются в так называемые Свалки Данных.

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

Что такое Свалка Данных? Свалка данных - это то, во что превращается Хранилище, ориентированное не на процессы и не на структуры данных, а на пользовательский интерфейс - продукт деятельности людей, считающих корпоративное Хранилище своего рода чуланом, куда сваливаются абсолютно все данные компании. Люди верят, что данные самоорганизуются и смогут быть легко извлечены или проанализированы в случае необходимости.

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

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

Попытки применить какую-либо продвинутую технологию (например, Data Mining - Добыча Данных) иногда работают, но какой ценой это достается и сколько времени может потребовать - определить невозможно. При этом результаты гарантировать, разумеется, нельзя.

Миф 3. Создать хранилище данных можно быстро, дешево и хорошо.

Заблуждение номер один - "Наша база имеет конечный объем и не будет расти" опровергается общемировой статистикой и практикой эксплуатации СУБД². Согласно статистике, каждые несколько месяцев объем баз данных, находящихся в эксплуатации, удваивается. Если же исходить из концепции Свалки Данных, то уже на самом начальном этапе эксплуатации в систему попадает очень большой объем данных, в том числе и явно избыточных. Если даже удается избежать этой ловушки, то данные, попадающие в такую базу, плохо структурированы и не приспособлены к легкому и быстрому извлечению, обновлению, сопровождению. Мировая практика показывает, что Свалки Данных исключительно быстро достигают терабайтных объемов, и продолжают расти (вплоть до полного коллапса, если не позаботиться об этом в процессе разработки и сопровождения). Сопровождение таких систем требует специальной подготовки и опыта.

Заблуждение номер два - "Вот готовое решение, которое можно установить (создать, разработать) всего за N дней" - опровергается правилами и практикой проектирования информационных систем. Для того чтобы построить не избыточное и эффективное структурированное Хранилище, необходимо, как минимум, провести глубокий аудит существующих источников и структур данных, определить, какие данные вообще должны быть в Хранилище, разработать гибкую, эффективную и масштабируемую структуру хранения, которая, к тому же, должна соответствовать ожиданиям и потребностям потребителей информации, и, к тому же, быть масштабируемой. Фактически необходим полный цикл проектных работ, который требует времени и ресурсов.

Заблуждение номер три - "Достаточно построить и наполнить Хранилище, после чего оно будет функционировать само собой". К сожалению, не существует еще ни одной информационной системы, способной просуществовать сколько-нибудь значительный период в повседневном рабочем режиме без присмотра администраторов, тем более в период выполнения серьезных технологических операций - загрузки, выгрузки, обновления, реструктуризации данных. Надо отметить, что без таких операций обойтись не удастся ни при каких обстоятельствах. Однако, заблуждение номер три, вместе с уже упомянутым первым заблуждением (и это иногда подогревается некоторыми поставщиками решений, дабы не пугать пользователя) приводит к тому, что на эксплуатацию выделяются мизерные ресурсы.

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

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

Большинство крупных поставщиков решений прямо и недвусмысленно предупреждают - "Хранилище Данных - это большая инвестиция". Однако при этом не детализируют все, что подразумевается под этим определением. А подразумевается буквально следующее: Хранилище Данных - это серьезный и большой проект, требующий больших затрат всех ресурсов, в частности, денежных средств и квалифицированного труда. Он не может быть выполнен в кратчайшие сроки, тем более не может мгновенно окупиться.

Однако устоявшаяся в среде многих проектировщиков и разработчиков идеология быстрой разработки приложений (RAD³) подталкивает тех и других к решению задачи методом восходящего проектирования - то есть быстрым созданием пилотного проекта, в достаточной степени работоспособного, чтобы окупить хотя бы небольшую часть вложений. К сожалению, пилотные проекты очень часто перерастают в готовые решения по принципу - "Работает - и не надо ничего трогать". Сначала строят маленький киоск данных⁴, а потом делают из него большое хранилище. Считается, что разница только в размерах.⁵ Как результат, подобная система не может ни эффективно решать свои задачи, ни быть эффективно масштабируемой. Более того, она не может быть легко переделана или оптимизирована и таковой остается на длительный период времени, иногда навсегда.

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

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

Миф 5. После того, как Хранилище построено и отлажено, оно работает само по себе и не нуждается в нашем внимании.

Прежде всего, Хранилище требует регулярного выполнения процедур Извлечения, Преобразования и Переноса данных (ETT/ETL).⁶

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

Помимо этого, при работе с любой системой на основе СУБД необходимо регулярное выполнение задач резервирования и восстановления, оптимизации производительности, управления изменениями⁷ (связанными, в свою очередь, с изменениями бизнес-процессов и бизнес-функций). Данные задачи в большинстве случаев решаются администраторами, причем стратегии их выполнения не описываются в проектных документах, поскольку вообще не разрабатывались.

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

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

Существует еще одна задача, часто вообще не осознаваемая проектировщиками Хранилищ Данных. Это - извлечение устаревающих данных или архивация.

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

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

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

Миф 6. Только Хранилище Данных может решить все наши проблемы.

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

Считается, что чем больше отчетов и чем более они обширны и разнообразны, тем более эффективно может управлять предприятием руководитель. Как правило, практически все оперативные информационные системы содержат в своем составе средства формирования отчетов. Эти средства закладываются в систему на этапе проектирования и строго привязываются к вполне определенным процессам и функциям. Вполне разумно, что процессы и функции со временем меняются и вместе с ними меняются отчеты. Гибкость средств формирования отчетов является достоинством. Плодить большое количество ненужной или малополезной информации с точки зрения принципа Оккама⁸ не требуется для сохранения эффективности управления (данный подход является одним из основных принципов грамотного менеджмента).

Конечно, существует такая задача, как анализ, которая требует выполнения поиска знаний в информации, обобщения, поиска тенденций и тому подобного. В связи с данной задачей даже определена особая категория запросов, называемых ad hoc. Причем в традиционных системах регулярное получение простых сводных отчетов, необходимых для решения повседневных задач и управления на нижнем и среднем уровне, возлагается на оперативную систему, задачи же анализа традиционно решаются в рамках отдельной системы DSS (поддержка принятия решений на верхнем уровне). В некоторых случаях, когда объем аналитических задач становится чрезмерным, строятся отдельные аналитические системы как надстройки над оперативными или DSS-системами, и используются особые методологии, ориентированные, прежде всего на удобных представлениях данных для анализа (OLAP⁹-технологии). Следует отметить, что обычно OLAP не утруждает себя проблемами извлечения больших объемов данных и скоростью их обработки. Технологии OLAP ориентированы на удобный инструмент для аналитиков. Когда встала необходимость анализировать по-настоящему большие массивы информации, некоторые концепции OLAP были изменены.¹⁰

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

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

В большинстве предприятий действительно необходимыми является не более 10-50 стандартных отчетных форм. Только небольшой процент от этого количества охватывает большую часть данных системы, в их число входят статистические отчеты. Отчеты всегда являются дополнительной нагрузкой на систему, зачастую весьма серьезной. Однако использовать Хранилища для решения только лишь проблемы отчетности - решение чрезмерно дорогостоящее и малоэффективное (к тому же требующее длительного и тяжелого проектирования и внедрения). Отдавая себе в этом отчет, поставщики методик и решений Хранилищ Данных предлагают оптимальное решение проблемы - Stage.¹¹

По своей сути, Stage является не чем иным, как классической системой DSS, как правило, имеющей такую же структуру, что и оперативная система-источник. Содержащиеся в ней данные обычно отстают по степени актуальности от оперативной системы, однако этого вполне достаточно для отчетности. Проблемы отчетности (кроме верхнего уровня) построением Хранилища не могут быть решены, это прерогатива оперативных систем, в лучшем случае Stage-систем.¹²

Автору довелось однажды участвовать в предварительном предпроектном обследовании крупного промышленного предприятия (четыре территориально распределенных площадки, работающих под управлением ERP-системы Baan), собиравшегося внедрять Хранилище Данных. Тщательный анализ показал, что единственной проблемой предприятия является неэффективная оперативная отчетность, которую предполагалось переложить на Хранилище. Дальнейшая проработка проекта привела к осознанию необходимости создания Stage-системы с целью переложить на нее централизованное формирование конечного числа унифицированных отчетных форм.

Преимущество подобного решения заключается в том, что Stage не обязан накапливать в себе все данные предприятия. Его обслуживание производится по открытому циклу, с хранением лишь относительно небольшого количества данных за некоторый промежуток времени с полной перезагрузкой, когда надобность в этих данных отпала (дублирование процессов резервирования оперативных систем также не имеет никакого смысла). Отчеты могут быть почти в полном объеме выполнены этой системой, при этом нет необходимости дублирования отчетности у источников данных (оперативных систем). Более того, если впоследствии, по мере роста предприятия, все-таки потребуется создание Хранилища Данных, то фундамент для него уже заложен.¹³

Заключение

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

Доверяйте профессионалам. Любитель - даже самый лучший - всегда остается любителем. Особенно, не имеющий специальной подготовки. Проектная команда, работающая по стандартным методикам - лучшее решение. Пренебрежение методиками обходится чрезвычайно дорого. Стандартная методика в данной сфере - OWM¹⁴, базирующаяся на другой стандартной методологии, CDM.¹⁵ Обратите внимание, что методологии быстрой разработки не применимы в технологии Хранилищ Данных.

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

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

1. DSS-Design Support Systems.
2. Системы Управления Базами Данных.
3. RAD-Rapid Application Development.
4. Data mart - киоск данных.
5. Хранилище Данных - это оптимизированный под решение бизнес задач управления и анализа набор большей части данных предприятия. Киоск же является предварительно обработанным подмножеством данных хранилища, организованным по принципу структурных подразделений, предметных областей или отдельных задач и должен в идеале являться надстройкой над Хранилищем Данных, а не его фундаментом и, тем более, не должен полностью или частично дублировать функции Хранилища.
6. ETT - аббревиатура, означающая Extraction Transformation Transition. ETL - Extraction Transformation Loading. Обе аббревиатуры означают одно и то же у различных поставщиков - основополагающий технологический процесс в Хранилищах Данных - Извлечение, Преобразование и Перенос данных.
7. Change Management - управление изменениями.
8. Принцип Оккама гласит - "Не умножай сущего сверх необходимого".
9. OLAP-On Line Analytical Processing.
10. Так, MOLAP - Multidimensional Online Analytical Processing был вытеснен ROLAP - Relational Online Analytical processing, после того, как многомерные системы анализа проиграли борьбу с постоянно растущими объемами анализируемых данных.
11. Stage в технологиях Хранилищ Данных называется промежуточный массив информации, извлеченной из оперативных систем и других источников информации для обработки и преобразования перед загрузкой в Хранилище в рамках процедур ETL. Согласно методологии Хранилищ Данных может использоваться для формирования отчетов и снятия нагрузки отчетности с оперативных систем и может функционировать автономно, без создания Хранилища Данных. Stage в том или ином виде является ключевой компонентой большинства методологий Хранилищ Данных.
12. Функции Хранилища Данных заключаются в выполнении анализа, выполнении ad hoc запросов, предоставлении отчетности верхнего уровня, поддержке процессов Data Mining и поиска закономерностей, предоставлении разнообразных наборов и подмножеств данных и их представлений для сотрудников предприятия и его клиентов (для чего используются киоски данных).
13. Даже наличие Stage/DSS не всегда является необходимостью. Существуют значительно более простые решения. Например, оптимизация производительности оперативных систем. Однако, с точки зрения дизайна, физическое разделение оперативной активности и отчетности на различные системы все-таки имеет больше смысла. Другой вопрос, целесообразно ли для этого использовать именно Хранилища Данных.
14. OWM - Oracle Warehouse Method.
15. CDM - Custom Development Method.

Оригинал статьи: http://www.softdeco.com