Обработка на местах, анализ в реальном времени и объединение данных - ключевые концепции ИТ-архитектур

Информация - это воздух для организации, а данные - ее память.

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

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

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

Скорость работы и емкость БД неумолимо растут. Результаты эталонного теста TPC-C, разработанного Советом по скорости обработки транзакций, показывают: любая из пяти ведущих СУБД для однопроцессорных машин способна сегодня обрабатывать свыше 400 тыс. транзакций в минуту.

Новый же эталонный тест корпорации Microsoft и фирмы NEC Solutions America дал еще более высокий результат: SQL Server на аппаратном сервере NEC обрабатывает 433 107 транзакций в минуту, а по пропускной способности эта комбинация превосходит любой другой 32-разрядный сервер независимо от того, какая на нем установлена база данных или операционная система.

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

Корпорация Oracle - многолетний лидер в этой области - постоянно обогащает свою основную транзакционную СУБД такими функциями хранилищ данных, как, например, растровые индексы. Этот производитель даже отказался от выпуска автономной СУБД оперативного анализа данных Express (которая традиционно использовалась для организации хранилищ данных) в пользу нового расширения онлайновой аналитической обработки для Oracle9i. Высокие результаты в этой области показывают также DB2 корпорации IBM и SQL Server корпорации Microsoft, позволяющие использовать предварительно рассчитанные запросы (материализованные виды) и такие функции SQL из области оперативного анализа данных, как rollup и cube.

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

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

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

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

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

Web-сервисы уже доказали свою способность связывать разрозненные системы данных в единую базу данных. Модель этих сервисов такова, что данные оказываются доступными в реальном времени, отображаются в общем формате (XML) и поддерживаются через стек из клиентского приложения, промежуточного звена и БД.

В ближайшие полтора года технологии XML должны коренным образом изменить мир баз данных. Производители основных СУБД уже переделывают свои продукты, встраивая в них поддержку типов данных по схеме XML, а в качестве языка запросов применяя XML Query. Грядущий пакет приложений Microsoft Office 2003, например, откроет перед создателями БД более эффективные пути генерации структурированных данных, как никогда ранее приспособленных для повторного использования.

Конечно, в СУБД и дальше будут применяться различные способы хранения данных, но на них обязательно скажутся тенденции, вызванные распространением XML. “Текучесть” данных, их преобразование на лету и возможность самоописания (включение в данные их структурного описания) должны коренным образом изменить характер обработки данных в организациях.

С техническим директором eWeek на Западном побережье США Тимоти Диком можно связаться по адресу: timothy_dyck@ziffdavis.com.

Создание современной архитектуры данных

Данные должны быть доступны

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

- Методы тиражирования данных позволят вам расширить сферу распространения информации и одновременно поддерживать правила относительно их качества.

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

Данные должны быть точными

- Постоянно ведите централизованный словарь данных.

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

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

Данные должны быть в контексте

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

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

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