Основные характеристики современного Хранилища данных

2007-09-06

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

Наиболее характерные проблемы традиционных ХД следующие:

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

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

Можно сказать, что современное Хранилище существенно расширяет традиционное, включая в себя такие компоненты и процессы как:

расширенный уровень подготовки данных;
сервис-ориентированное взаимодействие между инструментами и процессами;
событийно управляемое (event-driven) взаимодействие между компонентами;
новые системы администрирования и управления метаданными (общие разделяемые метаданные, бинаправленные метаданные (bidirectional metadata), хранение версий, сложная модель управления);
специально оптимизированный уровень хранения данных.

Расширенный уровень подготовки данных

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

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

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

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

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

Сервисно-ориентированное взаимодействие между инструментами и процессами

Все компоненты представлены в виде сервисов. Сервис – это системный компонент, в котором функции декларируются с помощью языка общих определений (common definition language). Такой компонент размещается и запускается с помощью общего механизма обнаружения и запуска. Эта концепция заимствуется из общей парадигмы сервис-ориентированной архитектуры (SOA). Разница лишь в том факте, что в предлагаемом решении выделяются компоненты взаимодействия, которые представлены в виде сервисов (они, в свою очередь, могут быть веб-сервисами на основе UDDI).

Все компоненты (как ключевые бизнес-сущности, так и приложения) представлены в виде сервис-фасадов (service facades). Сервис-фасады обеспечивают бизнес-функции, требуемые для этих приложений и компонентов, в частности для участия в потоке операций. Координатор взаимодействия процессов взаимодействует и с функциями сервис-фасадов для выполнения этого потока. Сервис-фасад нельзя путать с пользовательским интерфейсом приложения (API). Программный интерфейс приложения необходим в сервис-фасадах для реализации бизнес-потоков. Административные и бизнес-функции отдельных приложений или систем по-прежнему представляются конечному пользователю в виде интерфейса конкретного приложения или системы.

Некоторые компании предлагают расширенную функциональность веб-сервисов, например концентраторы (web services hub), которые представляют собой шлюзы (gateway) для внешних клиентов. Преобразования выполняются с помощью архитектуры SOA. В шлюз поступают запросы от веб-сервис клиентов и передаются на серверы для обработки. Ответы передается через концентратор на веб-сервис клиента.

Концентраторы поддерживают следующие сервисы.

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

Управление метаданными

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

Интегрированные метаданные

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

Очень важно понять возможности и важность двунаправленного потока метаданных. Несмотря на то, что большинство репозиториев метаданных, используемых различными инструментами, подчиняются общей модели Хранилища (common warehouse model - CWM), они не могут совместно использовать физический репозиторий. Метаданные, разработанные одним инструментом, не будут видны в другом, и в результате возникнут несогласованности и снижение общей окупаемости.

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

хранение версий — чтобы расширять Хранилище дополнительными источниками с минимальными конфликтами данных, необходимо хранить версии метаданных;
отчетность по метаданным — отчетность по метаданным, обеспечиваемая ETL-инструментами, может использоваться для существенного расширения общего использования метаданных;
управление зависимостями (dependency management) — если Хранилище наполняется данными из множества источников и информация из него передается в ряд целевых приложений, то управление зависимостями становится критически важной задачей, способствующей внесению различных изменений в систему. Например, если в исходной системе изменяется одно из базовых определений таблицы, то, прежде чем переносить это изменение в Хранилище, необходимо зафиксировать весь перечень преобразований и отчетов, которые нужно будет модифицировать.

Надежная модель администрирования

Любой успешный проект, связанный с метаданными, подразумевает надежную модель администрирования. Администрирование – это структура для принятия решений и контроля их своевременного и согласованного выполнения. Важно определить:

кто отвечает за принятие решений;
как эти решения выполняются;
кто эти решения выполняет;
как они выполняются.

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

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

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

Уровень хранения, оптимизированный для ХД

Чтобы разработать оптимальное решение для хранения данных, необходимо учесть ряд факторов, в том числе:

общую архитектуру проекта;
внутреннюю архитектуру ETL-инструмента;
внутренние функции;
инструменты управления БД и отчетности.

Рассмотрим ETL-инструменты. Даже если создается впечатление, что функции ETL-продукта очень похожи, то инструменты могут использовать различную архитектуру. Например, симметричную многопроцессорную обработку (symmetric multiprocessing - SMP) или массово-параллельную обработку (massively parallel processing – MPP). Выбор ETL-инструмента оказывает серьезное и продолжительное влияние на Хранилище и архитектуру базы данных. Даже настройка СУБД требует интегрированного представления системы, а не только уровня хранения данных.

Публикации

«Основные характеристики современного Хранилища данных. Часть 1. Критика традиционных ХД» (Essential Characteristics of a Modern Data Warehouse, Part 1: Critical Issues with a Conventional Data Warehouse), Виджей Сэрадхи (Vijay Saradhi), Июнь 2007 г.
«Основные характеристики современного Хранилища данных. Часть 2. Фундаментальные возможности» (Essential Characteristics of a Modern Data Warehouse, Part 2: Foundation Features), Виджей Сэрадхи (Vijay Saradhi), Июнь 2007 г.