Наверх

Тенденции в области Хранилищ данных на 2007 год

Время чтения: 10 минут
0
Тенденции в области Хранилищ данных на 2007 год

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

Подготовлено по материалам зарубежных сайтов.

 

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

Развитие в области Хранилищ данных (ХД) охватит архитектуру BI-систем (Business Intelligence – прим. ред.) в целом, с учетом нововведений на всех ее уровнях — интерфейсном (front end), промежуточном (middle) и исполнительном (back end). Технология Хранилищ выйдет за рамки интеграции данных (в некоторой степени, так и не решив эту задачу) в область интеграции бизнеса и технологии. Требование к руководителям и сотрудникам IT-подразделений по устранению разрыва между бизнесом и IT станет чрезвычайно актуальным.

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

Что касается front-end уровня системы ХД, то по-прежнему особую роль здесь играет пользовательский интерфейс. Вне зависимости от потока интегрируемых данных (который будет расти главным образом по сложности и по объему), пользователь, получая ответ на свой вопрос, в первую очередь оценивает качество предоставления информации, даже если сама ее обработка проводилась где-то в ином месте. Нововведения в области структурированного поиска и реляционного OLAP-анализа принесут больше пользы, чем многомерные базы собственной разработки. Опытные пользователи порадуются возможностям анализа «что, если?», а аналитики смогут без затруднений формулировать и задавать внешне простые, но по сути сложные бизнес-вопросы. Впрочем, при более взвешенном подходе выяснится, что самообслуживание клиентов подходит вовсе не для всех.

Поэтому быстрая разработка приложений (RAD — Rapid application development), прототипирование, порталы, оценочные и инструментальные панели — это как раз то, что необходимо многим классам пользователей, таким как: исполнительное руководство, администраторы, руководители подразделений, которые точно знают, что им нужно выяснить. И никто (или мало кто) будет заниматься построением front-end приложений вручную, отдавая предпочтение инструментам «быстрого старта» или «быстрой разработки приложений».

В области front-end-инструментов нас ждет еще один сюрприз. Предполагаемая тенденция к «массовости» BI покажет, что «массы» — это вовсе не то, о чем думалось. Т.е. речь идет не о количестве пользователей, а о множестве различных типов — с разными требованиями и задачами. Становится очевидным, что для преобразования простых данных в корпоративную информацию необходимо иметь несколько инструментов или технологий. Просто купить у известного поставщика пакет инструментов — недостаточно для решения проблемы интеграции данных (хотя в случае проблем с продуктом или услугами с одним поставщиком разобраться будет проще). Однако различные классы пользователей нуждаются в нескольких видах инструментов для удовлетворения своих требований. Руководителям нужны оценочные и инструментальные панели, опытным пользователям — кубы и OLAP, экспертам — передовая прогнозная аналитика, клеркам — стандартные предопределенные отчеты. И всем пользователям необходимы своевременные предупреждения и уведомления.

На промежуточном (middle) уровне архитектуры предполагаются модернизации в области метаданных, управления сообщениями и семантического анализа, которые должны повысить производительность, эффективность и интеграцию систем. Технология ETL, брокеры сообщений (message brokers) и интеграция информации требуют перехода к динамическим Хранилищам (работающим в реальном времени). Эта тенденция становится все более стабильной и постоянно нарастает.

Без брокера сообщений ни одно предприятие не сможет проводить постоянное обновление в реальном времени, которое необходимо для сокращения интервала ожидания в системе. Возможность выполнять преобразования в памяти (memory-to-memory) за счет расположения брокера сообщений на одном из узлов не участвующего в распределении ресурсов процессора, который формирует концентратор данных Хранилища, — это зарекомендовавшая себя тактика выполнения динамических быстрых обновлений. Кроме того, параллельное выполнение операций ETL, управление метаданными и динамическая интеграция информации дают хорошее дополнение к традиционным возможностям ХД. В любом случае, ETL — это идеальный способ связать стадию преобразования данных с лежащей в ее основе технологией.

Методом проб и ошибок компании придут к тому, что расходы на интеграцию станут напрямую связанными с количеством интерфейсов между восходящими/нисходящими транзакционными и BI-системами. Чем больше системных интерфейсов, тем выше расходы. При отсутствии концентратора данных, который позволил бы рационализировать перенос данных в ETL-инструмент, количество связей будет расти линейно, в то время как интерфейсы «многие — ко многим» будут распространяться в геометрической прогрессии, что приводит к повышению затрат и снижению окупаемости проектов. Если правила взаимодействия систем, а также смысловое содержимое элементов системных данных перенести в динамический репозиторий метаданных, то повышения производительности можно достичь за счет анализа влияний (impact analysis), основанного на метаданных. Те же соображения относятся и к интеграции корпоративных приложений, основанных на брокерах сообщений и оперативной интеграции информации.

Термин «динамические» относится к метаданным, которые используются для генерирования компонентов системы. Наиболее частым примером здесь является ситуация, когда логическая модель данных может генерировать структуры языка определения данных (DDL) для любой стандартной реляционной базы (IBM DB2, Oracle, Microsoft SQL Server и т.п.). Дизайн, основанный на метаданных, позволит тщательнее контролировать все типы компонентов системы, интегрировать процессы и проводить анализ влияния, расширяющий возможности поставщика и сокращающий расходы на координацию проекта. Для любой из технологий — ETL, EAI (интеграции корпоративных приложений — Enterprise Applications Integration), EII (интеграции корпоративной информации — Enterprise Information Integration) — развитие в области метаданных приведет к налаживанию инфраструктуры и обнаружению ответов на бизнес-вопросы (например, касающихся приобретения клиентами конкретных продуктов и услуг).

Что касается back-end (исполнительного) звена архитектуры, то здесь виртуализация и автономное управление расширят гибкость и сократят необходимость управления конфигурациями систем и ресурсов вручную. Следовательно устранятся некоторые препятствия для повышения операционной эффективности. Поэтапные модернизации (например, усовершенствование алгоритмов сжатия) помогут сократить чрезмерное разрастание Хранилищ, несмотря на то, что объемы данных по-прежнему будут расти огромными темпами. Разработка и внедрение собственного типа данных XML в реляционных базах позволит получать и организовывать содержимое, ранее представленное в неструктурированной форме, для того, чтобы его можно было обрабатывать в Хранилище. Такая возможность ликвидирует разрыв между бизнесом и IT в части представления информации в удобном формате.

Целевые, предопределенные, не участвующая в распределении ресурсов базы данных, на сегодняшний день получившие название «устройств» для ХД (DW appliance) будут и дальше развиваться на рынке (см. материал «Что такое устройства для Хранилищ данных»). При этом цена на такую продукцию будет со временем падать. По сути речь идет о распространении отдельных витрин данных, разработанных для решения тактических бизнес-проблемы, устранения «технологической бреши», либо для демонстрации крупному поставщику, что в «игре» участвует не только он один. Всё это, конечно, очень хорошо, однако растущая конкуренция приведет к развитию устройств ХД от известных поставщиков (многие из них этим вплотную занимаются), которые (за счет меньшего риска, отличной поддержки и умеренной наценки за все эти качества) впоследствии просто-напросто поглотят тех, кто эту технологию предложил.

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

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

Таким образом, компаниям удастся объединить два полюса — бизнес и технологию, при этом в области пересечения окажется Хранилище данных. Отдельные инициативы — управление бизнес-процессами, сервисно-ориентированная архитектура, управление нормативно-справочной информацией — поднимут (каждая по-своему) планку и поставят новые задачи для развития Хранилищ. BPM использует ХД в качестве источника ключевых показателей эффективности; сервисно-ориентированная архитектура позволит в виде сервиса передавать информацию из ХД и дистанционно стимулировать необходимые действия; MDM обеспечит четкое согласованное представление клиентов, продуктов и других бизнес-сущностей для поддержки передовых методов BI.

Со стороны бизнеса можно сказать, что отделам продаж и маркетинга удастся связать информацию воедино и получить ответы на вопрос «какие клиенты уходят и почему?». Финансовый отдел выяснит для себя, «какие клиенты, продукты и категории товаров дают максимальную прибыль, а какие — убыток?». Все это возможно при наличии в Хранилище согласованной нормативно-справочной информации о клиентах и продуктах. Операционный отдел разрешит проблемы, связанные с эффективностью поставщиков и закупок, с устареванием складов, рисков капитала и резервов, с динамическим ценообразованием и агрегированием транзакционных данных в Хранилище.

Перевод: Intersoft Lab

Источник: Intersoft Lab

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 0

Чтобы прокомментировать, или зарегистрируйтесь