Поводом для написания данного материала послужила статья "Хранилища данных: шаги от идеи до внедрения", опубликованная CNews 17 августа этого года. Спор экспертов об основах и практических моментах создания и внедрения хранилищ данных продолжается.

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

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

Но компания должна развиваться дальше - задерживаться в развитии из-за беспорядка в собственных данных нельзя. Вот здесь на помощь и приходит технология использования хранилищ данных.

Вид на бизнес с высоты

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

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

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

Стандартная схема хранилища данных

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

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

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

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

Иногда используют промежуточную область хранения данных (см. рис. 2), называемую ODS (Operational Data Storage, оперативное хранилище данных). ODS используется для прямого копирования данных из исходных систем в ту же среду, где располагается настоящее хранилище. При этом подходе в ODS находятся точные копии данных исходных систем для облегчения последующей доставки в хранилище данных с использованием однотипных средств выгрузки/загрузки. Обычно ODS используется при усложненном доступе к исходным данным по времени или расположению.

Схема хранилища данных с использованием ODS

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

Макет хранилища

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

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

Рекомендуется использовать подход по построению хранилищ данных с применением промышленных средств

Важнейшей технологией для наполнения хранилища данных является ETL (Extract, Transform, Load). ETL-средства используются, как и следует из названия технологии, для извлечения, преобразования и последующей загрузки данных в хранилище. Сейчас существует довольно много разнообразных ETL-средств, но есть стандартные требования к ним, которые должны максимально выполняться. К таким требованиям относятся высокая производительность при выгрузке, обработке и загрузке данных, работа с большими объемами данных, возможность параллельного выполнения процессов загрузки способность подключения к многочисленным типам источников данных без использования промежуточных средств хранения, трансформация данных любой сложности, простота и скорость разработки процессов, внесения изменений и администрирования, а также прозрачность - возможность полного аудита решения.

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

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

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

Системы отчетности и анализа данных (BI, OLAP, Data Mining) используют данные из хранилища, не затрагивая при этом ETL-часть решения. Это и есть визуальная часть проекта. Именно эти системы показывают результат работы огромного механизма, не видимого пользователю. Поэтому очень важно понимать, что сами по себе средства отчетности или анализа могут обрабатывать большие объемы данных, но построение даже самого простого агрегированного отчета в этом случае может занимать часы. Однако при использовании хранилища данных правильно построенный отчет обычно формируется за секунды.

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

Что нам стоит дом построить

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

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

При создании хранилища данных очень важна хорошая команда

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

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

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

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

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

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

Конечно, очень важным фактором является наличие квалифицированной, опытной рабочей команды. В идеале она должна состоять как из представителей заказчика, так и координатора для обеспечения слаженной работы по всем направлениям проекта.

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

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