Насколько понятен процесс создания и функционирования Хранилищ данных?

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

Термин Хранилище данных появился 20 лет назад. С тех пор процесс создания Хранилищ стал господствующей тенденцией для ведущих компаний, входящих в рейтинг журнала Fortune: многие из них осуществили один или несколько подобных проектов за последнее десятилетие. Но даже после 20 лет создания Хранилищ очевидно, что этот процесс для многих остается не до конца ясным. Рик Шерман (Rick Sherman), эксперт в области Business Intelligence и Хранилищ данных, обладающий 18-летним опытом работы в этой сфере, пытается проанализировать причины такого парадокса.

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

Цель создания Хранилищ данных - получение однозначной и единой картины о состоянии дел (one version of the truth). Но в результате многие компании лишь множат свои изолированные структуры. Вот несколько примеров:

• в рамках идеи о создании Хранилища компании устанавливают множество баз данных; при этом многие из них оказываются несовместимыми или не связанными друг с другом. Согласно исследованию The Data Warehousing Institute, проведенном в 2004 года, в среднем организации имеют два Хранилища, шесть независимых витрин данных, 4.5 операционных склада данных и 28.5 табличных витрин;
• многие проекты, связанные с внедрением Business Intelligence (BI) и подготовкой отчетности с помощью систем планирования ресурсов предприятия (Enterprise Resource Planning, сокр. ERP), по-прежнему основываются на изолированных структурах, как организационно, так и технически. И это несмотря на то, что поставщики ERP признали ценность Хранилищ данных и встраивают модули для их создания в свои продукты. К сожалению, эти модули часто используются отдельно от корпоративных Хранилищ данных, уже существующих в компаниях;
• технология управления эффективностью корпорации (Corporate Performance Management, сокр. CPM) дает хороший стимул для осуществления проекта по созданию всеобъемлющего, согласованного и интегрированного Хранилища данных в корпорации. Но часто в рамках проекта CPM производится внедрение готового решения от поставщика BI, которое, как и вышеупомянутое решение ERP, оказывается оторванным от корпоративного Хранилища данных компании. Такой подход дает лишь краткосрочные и быстро преходящие выгоды. В первое время этот подход кажется продуктивным, но в итоге он лишь плодит изолированные структуры и увеличивает несогласованность данных в компании.

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

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

Люди часто путают понятия Хранилище данных (data warehouse) и процесс его создания и функционирования (data warehousing). Создание и функционирование Хранилищ данных - это не просто работа с одним Хранилищем; этот процесс включает построение законченной архитектуры и ее поддержание в работоспособном состоянии. Это превращение данных в информацию, что позволяет бизнесу оценивать свою деятельность и эффективность. Такой процесс требует переноса данных из источников и их трансформации, что дает бизнесу возможность получить доступ к информации и осуществлять ее анализ. Способы хранения данных могут быть либо постоянными (на дисках), либо кратковременными (на дисках или в памяти компьютера). Помимо этого, документооборот обычно требует различных способов хранения данных для поддержания их организации и преобразования в информацию. Такими способами хранения могут являться операционные склады данных, Хранилища, витрины данных, OLAP-кубы, файлы, в частности, плоские файлы (например, выборка данных, разделенных запятыми), данные в формате XML и даже электронные таблицы.

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

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

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

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