Нефть и песок О стали Компрессор - подбор и ошибки Из истории стандартизации резьб Соперник ксерокса - гектограф Новые технологии производства стали Экспорт проволоки из России Прогрессивная технологическая оснастка Цитадель сварки с полувековой историей Упрочнение пружин Способы обогрева Назначение, структура, характеристики анализаторов Промышленные пылесосы Штампованные гайки из пружинной стали Консервация САУ Стандарты и качество Технология производства Водород Выбор материала для крепежных деталей Токарный резец в миниатюре Производство проволоки Адгезия резины к металлокорду Электролитическое фосфатирование проволоки Восстановление корпусных деталей двигателей Новая бескислотная технология производства проката Синие кристаллы Автоклав Нормирование шумов связи Газосварочный аппарат для тугоплавких припоев
Главная страница / Архитектура отрасли

Хранилища, витрины. Что дальше?

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

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

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

Накопленные данные здесь достаточно велики, и вычислительная техника зачастую просто не в состоянии обрабатывать в разумные сроки запросы, отнимающие много ресурсов. Во многих случаях БД биллинговой системы не может справиться с нагрузкой, поступающей от аналитиков и персонала, формирующего отчеты. Кроме того, в каждой биллинговой системе есть узкие места, в связи с чем ответ на простой с виду вопрос может занимать слишком много времени. Например, в ходе реализации проекта построения аналитической отчетной системы в компании Misrfone (GSM, Египет) было выявлено, что ответ на вопрос о том, когда определенный абонент совершил свой первый звонок, был получен только через 42 часа... Причем сеть компании к тому времени работала всего полгода...

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

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

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

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

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

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

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



Классическая схема хранилища данных



Хранилище, как было сказано, само по себе не предназначено, для того чтобы быть источником данных для пользователей. Для этого есть витрины. Между тем и в хранилище информация поступает не напрямую из источников данных, а из оперативного хранилища (ODS – Operational Data Source). Рассмотрим подробнее вопрос для чего нужна такая схема.

Чтобы информация в источниках данных аналитических систем обновлялась, необходимо периодически "закачивать" ее из БД продукционных систем, то есть через определенные промежутки времени должны выполняться процедуры извлечения данных, преобразования и обновления хранилища и витрин данных. Если источник один, то, как правило, агрегирование и трансформацию данных можно выполнить "на лету", и ODS не понадобится. Однако случается (особенно, если БД была ненормализованной) что данные необходимо предварительно "очистить". Допустим, есть расхождения в написании фамилии: где-то она была указана как "Иванов", а где-то – "иванов". Все это необходимо "причесать", чтобы система всцию. ODS также, как правило, используется при работе с несколькими источниками данных.

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

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



Элементы построения хранилищ и витрин данных



Оценив сложность структуры хранилища данных, следует решить, надо ли использовать какие-то специализированные инструменты разработки структур данных и процедур их выгрузки/трансформации/очистки. Стоимость подобного ПО достаточно высока, однако оно существенно упрощает создание хранилища и администрирование. Инструменты для этого предлагают практически все производители СУБД. Один из наиболее интересных – Informix DataStage, разработанный компанией Ardent. DataStage обеспечивает работу с БД различных производителей и функционально мощнее ближайших конкурентов.

Что касается сервера БД, то изначально для организации хранилищ и витрин использовались многомерные серверы. В последнее время возможности реляционных серверов значительно расширились, и настоящее большое хранилище, как утверждают специалисты, можно построить только с их помощью. Это справедливо не только для больших, но и для любых других источников данных для аналитических приложений. Практически все производители доработали свои реляционные серверы, чтобы они отвечали требованиям аналитических систем. Привлекает также возможность использования уже имеющихся в компании серверов, и самым важным фактором становится здесь наличие навыков работы с ними. Ведь не секрет, что, например, Oracle Express – не просто дорогой сервер. Для его обслуживания нужны специалисты, которые достаточно редки.

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

Витрины данных могут быть перенесены на рабочие столы пользователей. Один из способов сделать это – применение ПО доступа, OLAP и разработки отчетов. Примером может служить такойects.

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

При работе с базами данных OLTP (будущими источниками данных для

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

Главная страница / Архитектура отрасли