oбзор

Обзор: Рынок BI в России 2013

Инвестиции в хранилища данных вернутся в долгосрочной перспективе

Инвестиции в хранилища данных вернутся в долгосрочной перспективе

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


Концепция хранилища данных была предложена в начале 90-х годов прошлого века как основа методологии организации данных в системах поддержки и принятия решений. Определение термина "хранилище данных" первым ввел в обиход Билл Инмон (William H. Inmon). По его словам, хранилище данных есть предметно-ориентированная, интегрированная, неизменяемая и поддерживающая хронологию совокупность данных, предназначенная для поддержки процесса принятия управленческих решений.



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



Рост рынка


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



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

И если сейчас сегмент корпоративного программного обеспечения растет, в том числе и из-за активного интереса к управлению системами хранения данных, то с 2014 г., по мнению аналитиков Gartner, драйверами развития ИТ-рынка станут большие данные (Big Data) и другие сферы, относящиеся к управлению информацией: инструменты для интеграции данных и обеспечения их качества.



По прогнозам Gartner, в 2013 г. мировой объем рынка программного обеспечения для бизнес-аналитики составит $13,8 млрд. Однако по сравнению с прошлым годом рост составит лишь 7%, а темпы роста этого рынка в ближайшие годы не превысят 10% из-за макроэкономических условий и замедления циклов продаж крупных контрактов.



При этом в исследовании, опубликованном в 2012 г., аналитики Pierre Audoin Consultants (PAC) прогнозируют, что мировой рынок решений для обработки больших данных вырастет почти в 7 раз — с 3 млрд евро в 2010 г. до 20 млрд евро в 2016 г. По их мнению, большие данные могут улучшить работу потребительски-ориентированных компаний в телекоммуникациях, банках и рознице, где будут собираться и обрабатывать данные из социальных сетей и иных источников.



Важность выбора архитектуры


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



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



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



В своей книге "DW 2.0: The Architecture for the Next Generation of Data Warehousing" Билл Инмон пишет о подходе следующего поколения к построению хранилищ данных, который гарантирует, что команда, ответственная за качество данных, "выезжает" вперед прежде, чем "обоз" хранилища данных вступит на новые территории. Эта команда должна сделать профилирование исходных данных в интегративном режиме как можно раньше, чтобы обнаружить проблемы и аномалии данных и заранее оповестить команду разработчиков. При этом команда должна состоять из профессионалов и в области бизнеса, и в области информационных технологий.



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



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



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



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



При этом инвестиции в создание хранилищ данных, по результатам трехлетнего исследования, проведенного компанией IDC, эффективны с экономической точки зрения, например среднее суммарное значение возврата инвестиций за 3 года, вложенных в создание хранилищ данных, составляет 400%.



Аналитика и транзакции


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



Именно из разности этих задач и возникло разделение хранилищ данных на 2 основополагающих класса: OLTP (Online Transaction Processing) и OLAP (Online Analytical Processing). Транзакционные системы (OLTP) настроены на выполнение однотипных массовых операций с данными, тогда как аналитические (OLAP) проектируются под всевозможные аналитические запросы, где скорость выполнения не столь критична.



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



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



Одним из наиболее известных способов проектирования архитектуры хранилищ является корпоративная информационная фабрика (Corporate Information Factory, CIF) – это логическая архитектура программно-аппаратного решения по производству, складированию, управлению и доставке данных для поддержки принятия решений в масштабе организации. Концепция CIF, предложенная все тем же Биллом Инмоном, подразумевает системно организованное взаимодействие хранилищ оперативных данных (Operational Data Store), центрального хранилища данных, витрин данных и системы интеллектуального анализа данных (Data Mining) за счет создания технологических цепочек переработки и доставки данных.



Типовые архитектурные элементы логической структуры CIF


Унаследованные системы (Legacy Systems) – поддерживают бизнес-функции, которые были автоматизированы в организации ранее. Системы обеспечивают формирование отчетов, ввод и передачу данных, и реализуются в рамках единого модуля, что затрудняет решение задач по интеграции и преобразованию данных.


Приложения оперативного управления (OLTP)
– обеспечивают быструю обработку данных в рамках направлений бизнеса и, как правило, приобретаются у компании-разработчика.

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

Компоненты преобразования данных (ETL – tools) – служат для перегрузки данных из одних программных компонентов в другие с промежуточной очисткой и согласованием данных, получаемых из различных источников.


Корпоративное хранилище данных (Enterprise Data Warehouse)
– накапливает детальную информацию для выполнения анализа. Данные перегружаются в корпоративное хранилище из систем, содержащих оперативные данные.


Витрины данных (Data Marts)
– предназначены для хранения аналитической информации уровня подразделения или направления бизнеса.


Приложения поддержки принятия решений (DSS) и приложения анализа данных (DM)
– обеспечивают поддержку принятия решений и статистический анализ.


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



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

Андрей Коптелов

Вернуться на главную страницу обзора