Технология хранилищ данных

2 Распределенность

      Хранилища Данных уже по своей природе являются распределенным решением.

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

3 Защита данных  от несанкционированного  доступа;

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

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

      В таких системах часто оказывается  недостаточно защиты, обеспечиваемой в стандартных конфигурациях  коммерческих СУБД (обычно уровень защиты по классу "C2 Orange Book"). Региональный менеджер должен видеть только те данные, которые относятся к его региону, а менеджер подразделения не должен видеть данные, относящиеся ко всей фирме. Но для повышения эффективности доступа к данным, в целевой БД Хранилища Данных все эти данные, как правило, хранятся в виде единой фактологической таблицы. Следствием этого является то, что средства реализации должны поддерживать ограничения доступа не только на уровне отдельных таблиц и их колонок, но и отдельных строк в таблице (класс "B1 Orange Book").

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

4 Построение и ведение  многоуровневых справочников  метаданных

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

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

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

• разнородность компонентов;
• ориентированность на нерегламентированную работу с данными.

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

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

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

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

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

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

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

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

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

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

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

Таблица 4. Уровни метаданных в Хранилище Данных. 

5 Хранение и обработка  очень больших  объемов данных.

      Когда мы говорим о целевой БД Хранилища Данных, то подразумеваем, что это нечто очень большое (таблица 5). Но насколько большое? Согласно данным Meta Group, уже сегодня около половины организаций планируют Хранилища в 100 гигабайт и более. И уже известны реализации систем с терабайтами данных.

Таблица5. Классификация ХД в соответствии с объемом целевой БД.

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