Сколько нам нужно хранилищ данных для управления ими?

Автор: Colin White
Дата публикации оригинала: 2006-09-18
Источник: Сайт BeyeNETWORK

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

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

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

В этой статье я буду использовать следующие термины:

  • Частные данные – данные, принадлежащие частному лицу, этими данными не делятся с другими и управление ими не осуществляется.
  • Коллективные данные – управляемые данные рабочей группы и корпоративные данные, которыми делятся с большим количеством лиц, групп и компаний.
  • Внутренняя деловая информация – частные или коллективные данные, которые создаются и управляются сотрудниками компании и внутренними приложениями.
  • Внешняя деловая информация – данные, которые могут предоставляться и/или изменяться людьми, которые находятся за пределами организации.
  • Структурированные данные – набор одной или более записей данных со структурой поля фиксированной длины, которые определяются внешней моделью данных.
  • Слабоструктурированные данные – набор одной или более записей данных со структурой поля переменной длины, которые могут определяться внешней моделью данных.
  • Неструктурированные данные – набор одной или более записей данных, которые не имеют внешней определенной структуры поля.
  • Текущие данные – последняя версия записи данных.
  • Исторические данные – более ранняя версия записи данных.
  • Старые данные – текущие данные, которые более не требуются для операционных процессов.
  • Хранилище данных (data store) – логический набор общих данных.
  • База данных – группа файлов физических данных, содержащие данные из одного или нескольких хранилищ данных.
  • Сервер баз данных – система программного или аппаратного обеспечения, используемая для управления одной или несколькими базами данных.
  • Система управления базами данных (СУБД) – программный компонент управления данными сервера баз данных.

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

Рисунок 1: Типы бизнес-процессов

Совместные процессы (Collaborative Processes)

Совместные процессы включают в себя ориентируемую на людей деятельность и задачи, которые создают и управляют неструктурированными и слабоструктурированными данными. Эти данные могут включать в себя информацию рабочих групп, такую как документы, электронные таблицы, презентации, отчёты BI, изображения, видео, электронную почту и операционную информацию предприятия, такую как электронные формы, цифровые изображения заказов, факсов и web-страничек. Значительный процент совместных данных, особенно на уровне рабочей группы, составляют частные данные. Целью компаний является интеграция этих частных данных в общие хранилища данных контента (CDS) с использованием программного обеспечения для управления контентом. CDS используются для хранения текущих и исторических данных. Зачастую для идентификации исторических данных используется версионный контроль.

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

Перед компаниями возникает вопрос, как справиться с увеличивающимся объемом частных (и, таким образом, неуправляемых) данных, которые генерируются новыми web-технологиями, такими как блоги и вики.

Процессы бизнес-планирования (Business Planning Processes)

Процессы планирования используются для стратегического, тактического и оперативного планирования, бюджетирования и прогнозирования. Управление слабоструктурированными и структурированными данными, создаваемыми в результате данных процессов, может осуществляться в хранилище частных данных, таком как электронная таблица или в общем хранилище данных, которое управляется независимым приложением для планирования или системой планирования бизнес-ресурсов (ERP). Целью компаний является интеграциях частных плановых данных в общее хранилище плановых данных (PDS), управляемое независимыми приложениями планирования. PDS используется для управления текущими и историческими данными. Зачастую для управления историческими данными в PDS используется версионный контроль.

В более крупных организациях плановые данные остаются разделенными между ERP и независимыми приложениями планирования. Плановые данные ERP управляются подобным образом как рабочие (оперативные данные), которые будут рассмотрены далее в данной статье. Многие независимые приложения для планирования поставляются различными BI-поставщиками, а данные PDS в этих случаях управляются той же системой управления базами данных (СУБД), которая использовалась для поддержки BI-процессов.

Процессы оперативных транзакций (Business Transaction Processes)

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

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

Процессы бизнес-аналитики (Business Intelligence Processes)

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

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

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

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

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

Некоторые люди спорят с тем, что данные ODS могут храниться в одном разделе табличной области, а данные EDW в других разделах. С помощью этого способа текущие данные переходят из раздела ODS в разделы EDW в случае их изменения и старения. Этот способ работает если:

  • СУБД и сервер баз данных могут управлять нагрузкой
  • Модели данных ODS и EDW являются одними и теми же
  • Можно разделить данные по дате и времени
  • Первичный ключ может содержать дату и время, а приложения и запросы могут ориентироваться на время

Некоторые конструкции приложений работают таким способом, в то время как другие не работают. Например, модели данных ODS и EDW могут не всегда быть одними и теми же. Как я говорил в начале этой статьи – одно и то же не подходит для всех.

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

Процессы основных данных (Master Data Processes)

Процессы основных данных отвечают за управление данными, относящимися к основным хозяйственным субъектам, таким как клиенты, сотрудники, поставщики, части, бухгалтерские книги и местонахождения. Традиционно основные данные управляются процессами бизнес-транзакций и сохраняются в хранилищах данных бизнес-транзакций. Эти основные данные затем обычно передаются в ODS и EDW. Основные данные фактически используются в среде бизнес-аналитики (BI) для предоставления возможности, с помощью которой данные могут предоставляться бизнес-пользователям, которые, к примеру, хотят просмотреть информацию по клиентам, регионам или номеру изделия.

Целью в этом случае является отделение основных данных от данных бизнес-транзакций и управление ими с использованием отдельных процессов основных данных. Данная тенденция будет оказывать сильное влияние на то, как хранятся и управляются основные данные не только в операционной среде, но и в среде BI. Эта тема будет рассмотрена в части 2 данной статьи.

Часть 2


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

Читайте также: