Консолидация данных — ключевые понятия

Задача консолидации

Введение

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

 

Обычно руководителям проектов по бизнес-аналитике с нуля приходится сталкиваться со следующей ситуацией. Во-первых, данные на предприятии расположены в различных источниках самых разнообразных форматов и типов — в отдельных файлах офисных документов (Excel, Word, обычных текстовых файлах), в учетных системах («1С:Предприятие», «Парус» и др.), в базах данных (Oracle, Access, dBase и др.). Во-вторых, данные могут быть избыточными или, наоборот, недостаточными. А в-третьих, данные являются «грязными», то есть содержат факторы, мешающие их правильной обработке и анализу (пропуски, аномальные значения, дубликаты и противоречия).

 

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

Определение

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

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

 

Основные критерии оптимальности с точки зрения консолидации данных:

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

Источники данных

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

 

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

Основные задачи консолидации данных

В процессе консолидации данных решаются следующие задачи:

  • выбор источников данных;
  • разработка стратегии консолидации;
  • оценка качества данных;
  • обогащение;
  • очистка;
  • перенос в хранилище данных.

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

 

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

 

Базы данных (БД) различных СУБД, таких как Oracle, SQL Server, Firebird, dBase, FoxPro, Access и т.д. Файлы БД лучше поддерживают целостность структуры данных, поскольку тип и свойства их полей жестко задаются при построении таблиц. Однако для создания и администрирования БД требуются специалисты с более высоким уровнем подготовки, чем для работы с популярными офисными приложениями.

 

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

 

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

 

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

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

Определение

Очистка данных — комплекс методов и процедур, направленных на устранение причин, мешающих корректной обработке: аномалий, пропусков, дубликатов, противоречий, шумов и т.д.

Еще одной операцией, которая может понадобиться при консолидации данных, является их обогащение.

Определение

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

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

Обобщенная схема процесса консолидации

Место консолидации в общем процессе анализа данных может быть представлено в виде структурной схемы (рис. 1).

Рис. 1. Процесс консолидации данных

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

Пример

Процесс сбора, хранения и оперативной обработки данных на типичном предприятии обычно содержит несколько уровней. На верхнем уровне располагаются реляционные SQL-ориентированные СУБД типа SQL Server, Oracle и т.д. На втором — файловые серверы с некоторой системой оперативной обработки или сетевые версии персональных СУБД типа R-Base, FoxPro, Access и т.д. И наконец, на самом нижнем уровне расположены локальные ПК отдельных пользователей с персональными источниками данных. Чаще всего информация на них собирается в виде файлов офисных приложений — Word, Excel, текстовых файлов и т.д.

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

 

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

2. Введение в хранилища данных

Введение

К середине 80-х гг. XX в. практически полностью завершился первый этап оснащения бизнеса и государственных структур средствами вычислительной техники и начался период бурного развития информационных систем для организации сбора и хранения больших массивов различного рода деловой и служебной информации. В основном это были корпоративные системы, предназначенные для оперативной обработки информации, которые обслуживали бухгалтерию, информационные архивы, телефонные сети, регистрацию документов, банковские операции и т.д. С появлением персональных компьютеров такие системы стали доступными для множества мелких и средних фирм, предприятий и организаций. Системы оперативной обработки информации получили название OLTP (On-Line Transaction Processing — оперативная, то есть в режиме реального времени, обработка транзакций).

Определение

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

Обобщенная структура системы OLTP представлена на рис. 2.

Рис. 2. OLTP-система

Пример

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

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

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

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

Рассмотрим характерные черты данного процесса, свойственные в той или иной мере всем OLTP-системам.

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

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

 

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

Предпосылки появления ХД

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

 

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

 

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

Рис. 3. Структура информационной СППР

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

 

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

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

В связи с этим можно выделить ряд принципиальных отличий СППР и OLTP-систем. Эти отличия представлены в табл. 1.

 

Таблица 1. Отличия СППР и OLTP-систем

Свойство OLTP-система СППР
Цели использования данных Быстрый поиск, простейшие алгоритмы обработки Аналитическая обработка с целью поиска скрытых закономерностей, построения прогнозов и моделей и т.д.
Уровень обобщения (детализации) данных Детализированные Как детализированные, так и обобщенные (агрегированные)
Требования к качеству данных Возможны некорректные данные (ошибки регистрации, ввода и т.д.) Ошибки в данных не допускаются, поскольку могут привести к некорректной работе аналитических алгоритмов
Формат хранения данных Данные могут храниться в различных форматах в зависимости от приложения, в котором они были созданы Данные хранятся и обрабатываются в едином формате
Время хранения данных Как правило, не более года (в пределах отчетного периода) Годы, десятилетия
Изменение данных Данные могут добавляться, изменяться и удаляться Допускается только пополнение; ранее добавленные данные изменяться не должны, что позволяет обеспечить их хронологию
Периодичность обновления Часто, но в небольших объемах Редко, но в больших объемах
Доступ к данным Должен быть обеспечен доступ ко всем текущим (оперативным) данным Должен быть обеспечен доступ к историческим (то есть накопленным за достаточно длительный период времени) данным с соблюдением их хронологии
Характер выполняемых запросов Стандартные, настроенные заранее Нерегламентированные, формируемые аналитиком «на лету» в зависимости от требуемого анализа
Время выполнения запроса Несколько секунд До нескольких минут

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

Основные особенности концепции ХД

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

Определение

 

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

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

 

Типичное ХД существенно отличается от обычных систем хранения данных. Главным отличием являются цели использования. Например, регистрация продаж и выписка соответствующих документов — задача уровня OLTP-систем, использующих обычные реляционные СУБД. Анализ динамики продаж и спроса за несколько лет, позволяющий выработать стратегию развития фирмы и спланировать работу с поставщиками и клиентами, удобнее всего выполнять при поддержке ХД.

 

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

Основные требования к ХД

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

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

Чтобы соблюсти все перечисленные требования, для построения и работы ХД, как правило, используется не одно приложение, а система, в которую входит несколько программных продуктов. Одни из них представляют собой собственно систему хранения данных, другие — средства их просмотра, извлечения, загрузки и т.д.

 

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

3. Основные концепции хранилищ данных

Основные положения концепции ХД

Принято считать, что у истоков концепции ХД стоял технический директор компании Prism Solutions Билл Инмон, который в начале 1990-х гг. опубликовал ряд работ, ставших основополагающими для последующих исследований в области аналитических систем.

 

В основе концепции ХД лежат следующие положения:

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

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

 

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

 

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

 

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

 

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

 

Использование концепции ХД в СППР и анализе данных способствует достижению таких целей, как:

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

Задачи, решаемые ХД

Процесс разработки ХД весьма трудоемок, некоторые организации затрачивают на него несколько месяцев и даже лет, а также вкладывают значительные финансовые средства. Основными задачами, которые требуется решить в процессе разработки ХД, являются:

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

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

Рис. 4. Концептуальная схема ХД

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

Детализированные и агрегированные данные

Данные в ХД хранятся как в детализированном, так и в агрегированном виде. Данные в детализированном виде поступают непосредственно из источников данных и соответствуют элементарным событиям, регистрируемым OLTP-системами. Такими данными могут быть ежедневные продажи, количество произведенных изделий и т.д. Это неделимые значения, попытка дополнительно детализировать которые лишает их логического смысла.

 

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

 

Поскольку один и тот же набор детализированных данных может породить несколько наборов агрегированных данных с различной степенью обобщения, объем ХД возрастает, иногда существенно. Например, набор, содержащий данные о продажах по дням в течение года, помимо своих 360 значений, порождает 52 значения с обобщением по неделям и 12 — по месяцам. Если при этом вычисляются все виды агрегации — сумма, среднее, максимальное и минимальное значения за соответствующий период, — то количество хранящихся агрегированных значений составит уже (52 + 12) • 4 = 256. Иногда это приводит к «взрывному», неконтролируемому росту ХД и вызывает серьезные технические проблемы: хранилище «распухает», из-за того что непрерывный поток входных данных автоматически агрегируется в соответствии с настройками ХД. Однако с этим приходится мириться: если бы агрегированные данные не содержались в ХД, а вычислялись в процессе выполнения запросов, время выполнения запроса увеличилось бы в несколько раз.

Метаданные

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

Пример

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

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

 

Если рассматривать понятие «метаданные» в контексте технологии ХД, то его можно определить следующим образом.

ОпределениеМетаданные — высокоуровневые средства отражения информационной модели и описания структуры данных, используемой в ХД. Метаданные должны содержать описание структуры данных хранилища и структуры данных импортируемых источников. Метаданные хранятся отдельно от данных в так называемом репозитарии метаданных.

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

 

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

 

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

 

Бизнес-метаданные описывают объекты предметной области, информация о которых содержится в ХД, — атрибуты объектов и их возможные значения, соответствующие поля в таблицах и т.д. Бизнес-метаданные образуют так называемый семантический слой. Пользователь оперирует близкими ему терминами предметной области: товар, клиент, продажи, покупки и т.д., а семантический слой транслирует бизнес-термины в низкоуровневые запросы к данным в хранилище.

Способы использования ХД

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

 

Спектр аналитических задач очень широк. Соответственно, и методики применения ХД для решения тех или иных задач весьма разнообразны. Тем не менее можно выделить три основных подхода к использованию ХД:

  • регулярные отчеты — подготовка отчетов стандартных форм, получаемых многократно с определенной периодичностью;
  • нерегламентированные запросы — возможность получать ответы на нестандартные, сформированные «по требованию» вопросы;
  • интеллектуальный анализ данных — поддержка процесса интеллектуального анализа больших массивов данных с целью выявления скрытых закономерностей, структур и объектов, построения моделей, прогнозов и т.д.

Краткий обзор архитектур ХД

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

 

Реляционные ХД используют классическую реляционную модель, характерную для оперативных регистрирующих OLTP-систем. Данные хранятся в реляционных таблицах, но образуют специальные структуры, эмулирующие многомерное представление данных. Такая технология обозначается аббревиатурой ROLAP — Relational OLAP.

 

Многомерные ХД реализуют многомерное представление данных на физическом уровне в виде многомерных кубов. Данная технология получила название MOLAP — Multidimensional OLAP.

 

Гибридные ХД сочетают в себе свойства как реляционной, так и многомерной модели данных. В гибридных ХД детализированные данные хранятся в реляционных таблицах, а агрегаты — в многомерных кубах. Такая технология построения ХД называется HOLAP — Hybrid OLAP.

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

 

Кроме того, все ХД можно разделить на одноплатформенные и кросс-платформенные. Одноплатформенные ХД строятся на базе только одной СУБД, а кросс-платформенные могут строиться на базе нескольких СУБД.

4. Многомерные хранилища данных

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

Многомерная модель данных, лежащая в основе построения многомерных хранилищ данных, опирается на концепцию многомерных кубов, или гиперкубов. Они представляют собой упорядоченные многомерные массивы, которые также часто называют OLAP-кубами (аббревиатура OLAP расшифровывается как On-Line Analytical Processing — оперативная аналитическая обработка). Технология OLAP представляет собой методику оперативного извлечения нужной информации из больших массивов данных и формирования соответствующих отчетов.

Основы многомерного представления данных

Сущность многомерного представления данных состоит в следующем. Большинство реальных бизнес-процессов описывается множеством показателей, свойств, атрибутов и т.д. Например, для описания процесса продаж могут понадобиться сведения о наименованиях товаров или их групп, о поставщике и покупателе, о городе, где производились продажи, а также о ценах, количествах проданных товаров и общих суммах. Кроме того, для отслеживания процесса во времени должен быть введен в рассмотрение такой атрибут, как дата. Если собрать всю эту информацию в таблицу, то она окажется сложной для визуального анализа и осмысления. Более того, она может оказаться избыточной: если, например, один и тот же товар продавался в один и тот же день в различных городах, то придется несколько раз повторить одно и то же соответствие «город — товар» с указанием различных суммы и количества. Все это способно окончательно запутать и сбить с толку любого, кто попытается извлечь из такой таблицы полезную информацию с целью анализа текущего состояния продаж и поиска путей оптимизации процесса торговли. Указанные проблемы возникают по одной простой причине: в плоской таблице хранятся многомерные данные.

 

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

 

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

 

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

Замечание

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

Измерения и факты — базовые понятия многомерной модели данных

В основе многомерного представления данных лежит их разделение на две группы — измерения и факты.

 

Измерения — это категориальные атрибуты, наименования и свойства объектов, участвующих в некотором бизнес-процессе. Значениями измерений являются наименования товаров, названия фирм-поставщиков и покупателей, ФИО людей, названия городов и т.д. Измерения могут быть и числовыми, если какой-либо категории (например, наименованию товара) соответствует числовой код, но в любом случае это данные дискретные, то есть принимающие значения из ограниченного набора. Измерения качественно описывают исследуемый бизнес-процесс.

 

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

Структура многомерного куба

Многомерный куб можно рассматривать как систему координат, осями которой являются измерения, например Дата, Товар, Покупатель. По осям будут откладываться значения измерений — даты, наименования товаров, названия фирм-покупателей, ФИО физических лиц и т.д.

 

В такой системе каждому набору значений измерений (например, «дата — товар — покупатель») будет соответствовать ячейка, в которой можно разместить числовые показатели (то есть факты), связанные с данным набором. Таким образом, между объектами бизнес-процесса и их числовыми характеристиками будет установлена однозначная связь.

 

Принцип организации многомерного куба поясняется на рис. 5. В ячейке 1 будут располагаться факты, относящиеся к продаже цемента ООО «Спецстрой» 3 ноября, в ячейке 2 — к продаже плит ЗАО «Пирамида» 6 ноября, а в ячейке 3 — к продаже плит ООО «Спецстрой» 4 ноября.

Рис. 5. Принцип организации многомерного куба

Многомерный взгляд на измерения Дата, Товар и Покупатель представлен на рис. 6. Фактами в данном случае могут быть Цена, Количество, Сумма. Тогда выделенный сегмент будет содержать информацию о том, сколько плит, на какую сумму и по какой цене приобрела фирма ЗАО «Строитель» 3 ноября.

Рис. 6. Измерения и факты в многомерном кубе

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

 

  • Представление данных в виде многомерных кубов более наглядно, чем совокупность нормализованных таблиц реляционной модели, структуру которой представляет только администратор БД.
  • Возможности построения аналитических запросов к системе, использующей МХД, более широки.
  • В некоторых случаях использование многомерной модели позволяет значительно уменьшить продолжительность поиска в МХД, обеспечивая выполнение аналитических запросов практически в режиме реального времени. Это связано с тем, что агрегированные данные вычисляются предварительно и хранятся в многомерных кубах вместе с детализированными, поэтому тратить время на вычисление агрегатов при выполнении запроса уже не нужно.В принципе, OLAP-куб может быть реализован и с помощью обычной реляционной модели. В этом случае имеет место эмуляция многомерного представления совокупностью плоских таблиц. Такие системы получили название ROLAP — Relational OLAP.Использование многомерной модели данных сопряжено с определенными трудностями. Так, для ее реализации требуется больший объем памяти. Это связано с тем, что при реализации физической многомерности используется большое количество технической информации, поэтому объем данных, который может поддерживаться МХД, обычно не превышает нескольких десятков гигабайт. Кроме того, многомерная структура труднее поддается модификации; при необходимости встроить еще одно измерение требуется выполнить физическую перестройку всего многомерного куба. На основании этого можно сделать вывод, что применение систем хранения, в основе которых лежит многомерное представление данных, целесообразно только в тех случаях, когда объем используемых данных сравнительно невелик, а сама многомерная модель имеет стабильный набор измерений.

Работа с измерениями

Нажмите кнопку «Редактировать», чтобы изменить этот текст. Проснувшись однажды утром после беспокойного сна, Грегор Замза обнаружил, что он у себя в постели превратился в страшное насекомое.

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

  • сечение (срез);
  • транспонирование;
  • свертка;
  • детализация.

Сечение заключается в выделении подмножества ячеек гиперкуба при фиксировании значения одного или нескольких измерений. В результате сечения получается срез или несколько срезов, каждый из которых содержит информацию, связанную со значением измерения, по которому он был построен. Например, если выполнить сечение по значению ЗАО «Строитель» измерения Покупатель, то полученный в результате срез будет содержать информацию об истории продаж всех товаров данного предприятия, которую можно будет свести в плоскую таблицу. При необходимости ограничить информацию только одним товаром (например, керамзитом) потребуется выполнить еще одно сечение, но теперь уже по значению Керамзит измерения Товар. Результатом построения двух срезов будет информация о продажах одной фирме по одному товару. Манипулируя таким образом сечениями гиперкуба, пользователь всегда может получить информацию в нужном разрезе. Затем на основе построенных срезов может быть сформирована кросс-таблица и с ее помощью очень быстро получен необходимый отчет. Данная методика лежит в основе технологии OLAP-анализа.

 

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

Рис. 7. Сечения гиперкуба

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

 

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

 

Таблица 2. Исходная таблица

Группа Товар Сумма
Стройматериалы Кирпич 22 000
Цемент 12 000
Керамзит 4500
Доска 7400
Инструмент Отвертка 1200
Электропила 7600
Дрель Шпатель
Шпатель 780

Таблица 3. Результат свертки исходной таблицы по измерению «Товар»

Группа Сумма
Стройматериалы 45 900
Инструмент 12 030

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

5. Реляционные хранилища данных

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

Определение

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

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

 

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

Схемы построения РХД

На логическом уровне различают две схемы построения РХД — «звезда» и «снежинка».

 

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

Рис. 8. Схема построения РХД «звезда»

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

 

Для более эффективной работы с иерархическими измерениями была разработана модификация схемы «звезда», которая получила название «снежинка». Главной особенностью схемы «снежинка» является то, что информация об одном измерении может храниться в нескольких связанных таблицах. То есть если хотя бы одна из таблиц измерений имеет одну или несколько связанных с ней других таблиц измерений, в этом случае будет применяться схема «снежинка» (рис. 9).

cons 09 - Консолидация данных — ключевые понятия

Рис. 9. Схема построения РХД «снежинка»

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

 

Выбор схемы для построения РХД зависит от используемых механизмов сбора и обработки данных. Каждая из схем имеет свои преимущества и недостатки, которые, однако, могут проявляться в большей или меньшей степени в зависимости от особенностей функционирования ХД в целом. К преимуществам схемы «звезда» можно отнести:

  • простоту и логическую прозрачность модели;
  • более простую процедуру пополнения измерений, поскольку приходится работать только с одной таблицей.Недостатками схемы «звезда» являются:
  • медленная обработка измерений, поскольку одни и те же значения измерений могут встречаться несколько раз в одной и той же таблице;
  • высокая вероятность возникновения несоответствий в данных (в частности, противоречий), например, из-за ошибок ввода.

Преимуществами схемы «снежинка» являются следующие:

  • она ближе к представлению данных в многомерной модели;
  • процедура загрузки из РХД в многомерные структуры более эффективна и проста, поскольку загрузка производится из отдельных таблиц;
  • намного ниже вероятность появления ошибок, несоответствия данных;
  • большая, по сравнению со схемой «звезда», компактность представления данных, поскольку все значения измерений упоминаются только один раз. Недостатки схемы «снежинка»:
  • достаточно сложная для реализации и понимания структура данных;
  • усложненная процедура добавления значений измерений.

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

Преимущества и недостатки РХД

  • Основные преимущества РХД следующие:

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

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

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

     

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

6. Гибридные хранилища данных

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

 

Логично было бы использовать такую модель ХД, которая представляла бы собой комбинацию реляционной и многомерной моделей и позволяла бы сочетать высокую производительность, характерную для многомерной модели, и возможность хранить сколь угодно большие массивы данных, присущую реляционной модели. Такая модель, сочетающая в себе принципы реляционной и многомерной моделей, получила название гибридной, или HOLAP (Hybrid OLAP).

 

Хранилища данных, построенные на основе HOLAP, называются гибридными хранилищами данных (ГХД) (рис. 10).

 

Главным принципом построения ГХД является то, что детализированные данные хранятся в реляционной структуре (ROLAP), которая позволяет хранить большие объемы данных, а агрегированные — в многомерной (MOLAP), которая позволяет увеличить скорость выполнения запросов (поскольку при выполнении аналитических запросов уже не требуется вычислять агрегаты).

Рис. 10. Гибридное ХД

Пример

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

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

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

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

Витрины данных

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

 

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

Определение

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

На рис. 11 изображена система консолидации с использованием витрин данных.

Рис. 11. Консолидация с использованием витрин данных

Использование витрин данных имеет следующие преимущества, делающие их ближе и доступнее конечному пользователю:

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

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

 

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

 

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

cons 13 - Консолидация данных — ключевые понятия

Рис. 12. Централизованное ХД с витринами данных

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

7. Виртуальные хранилища данных

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

 

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

 

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

 

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

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

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

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

При работе с ВХД пользователь, можно сказать, имеет дело с «иллюзией» хранилища данных (рис. 13). Виртуальность предполагает, что ВХД существует только до тех пор, пока работает соответствующее приложение. Как только оно завершает работу, виртуальное хранилище прекращает существование.

cons 14 - Консолидация данных — ключевые понятия

Рис. 13. Виртуальное ХД

Концепция ВХД имеет ряд недостатков по сравнению с ХД, где информация консолидируется физически.

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

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

 

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

 

Даже когда одна и та же фирма выступает и в роли поставщика, и в роли покупателя, не происходит дублирования или противоречия. В одном случае запрос связывает фирму с данными из таблицы «Поставки», а в другом — с данными из таблицы «Отгрузки». Таким образом, виртуальное хранилище, формируя запрос «на лету», позволяет минимизировать избыточность и более эффективно использует дисковое пространство.

Рис. 14. Вариант организации ВХД

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

Узнайте о других решениях

8. Нечеткие срезы

Хороший пример обогащения одной технологии (хранилища данных) другой (нечеткая логика) демонстрируют нечеткие срезы (fuzzy slices). Под ними понимаются фильтры по измерениям, в которых фигурируют нечеткие величины, например «все молодые заемщики с небольшим доходом». В реляционных базах данных эту роль выполняют нечеткие запросы (fuzzy queries, flexible queries), которые впервые предложены в начале 80-х гг. в работах Д. Дюбуа и Г. Прада.

 

Так как информация в ХД присутствует в четком виде, для использования в фильтрах нечетких понятий нужно предварительно формализовать их, что делается при помощи нечетких множеств, описание которых приводится ниже.

Нечеткие множества

Математическая теория нечетких множеств (fuzzy sets) и нечеткая логика (fuzzy logic) являются обобщениями классической теории множеств и классической формальной логики. Данные понятия были впервые предложены американским ученым Лотфи Заде (Lotfi Zadeh) в 1965 г. Основной причиной появления новой теории стало наличие нечетких и приближенных рассуждений при описании человеком процессов, систем, объектов.

 

Характеристикой нечеткого множества выступает функция принадлежности (membership function). Обозначим через μ(x) степень принадлежности элемента x к нечеткому множеству, представляющую собой обобщение понятия характеристической функции обычного множества. Тогда нечетким множеством С называется множество упорядоченных пар вида C = {μ(x)/x}, при этом μ(x) может принимать любые значения в интервале [0, 1], x ∈ X. Значение μ(x) = 0 означает отсутствие принадлежности к множеству, 1 — полную принадлежность.

 

Проиллюстрируем это на простом примере. Формализуем неточное определение «неблагонадежный заемщик». В качестве X (область рассуждений) будет выступать количество случаев просроченной задолженности по кредиту за последние 6 месяцев. Пусть оно изменяется от 0 до 6. Нечеткое множество, определенное экспертом, может выглядеть следующим образом:

 

C = {0/0; 0,4/1; 0,7/2; 0,9/3; 1/4; 1/5; 1/6}.

 

Так, заемщик, совершивший две просрочки, принадлежит к множеству «неблагонадежный» со степенью принадлежности 0,7. Для одного банка такое число просрочек может быть крайне существенным, для другого — просто тревожным сигналом. Именно в этом и проявляется нечеткость задания соответствующего множества.

 

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

Рис. 15. Типовые функции принадлежности

Треугольная функция принадлежности определяется тройкой чисел (a, b, c), и ее значение в точке x вычисляется согласно выражению:

Аналогично для задания трапецеидальной функции принадлежности необходима четверка чисел (a, b, c, d):

  • Для нечетких множеств, как и для обычных, определены основные логические операции. Самыми необходимыми для расчетов являются пересечение, объединение и отрицание.

  • Пересечение двух нечетких множеств A ∩ B (нечеткое «И»):μ(x) = min(μA(x), μB(x)).
  • Объединение двух нечетких множеств A ∪ B (нечеткое «ИЛИ»):μ(x) = max(μA(x), μB(x)).
  • Отрицание нечеткого множества ¬А:μ(x) = 1 − μA(x),где μ(x) — результат операции;
    μA(x) — степень принадлежности элемента x к множеству А;
    μB(x) — степень принадлежности элемента x к множеству B.
    Совокупность нечетких множеств, относящихся к одному объекту, образует лингвистическую переменную. Например, лингвистическая переменная Возраст может принимать значения Молодой, Средний, Пожилой (их еще называют базовым терм-множеством, или термами). Зададим область рассуждений в виде X = {x | 0 < x < 90} (годы). Теперь осталось построить функции принадлежности для каждого терма (рис. 16).

    Каждая функция принадлежности описывается четверкой чисел: Молодой = {0; 0; 12; 40}, Средний = {20; 30; 50; 70}, Преклонный = {50; 60; 90; 90}.

Рис. 16. Графическое изображение лингвистической переменной «Возраст»

Принцип формирования нечетких срезов

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

cons 20 - Консолидация данных — ключевые понятия

Рис. 17. Вариант организации хранилища данных с поддержкой нечетких срезов

Результатом выполнения нечеткого среза, помимо самого подмножества ячеек гиперкуба, удовлетворяющих заданным условиям, является индекс соответствия срезу CI ∈ [0, 1]. Он представляет собой итоговую степень принадлежности к нечетким множествам измерений и фактов, участвующих в сечении куба, и рассчитывается для каждой записи набора данных. Чтобы ускорить выполнение запросов к ХД, часто задают верхнюю границу индекса соответствия CI > а. Это позволяет уже на уровне SQL-запроса отсеять записи, которые заведомо не будут удовлетворять минимальному порогу индекса соответствия (рис. 18). На рисунке видно, что элементы нечеткого множества со значениями в интервале [xf, x2] обеспечат степень принадлежности не ниже а.

Рис. 18. Нечеткое множество

Рис. 19. Алгоритм получения нечеткого среза

Алгоритм формирования нечеткого среза иллюстрирует схема (рис. 19). На шаге 1 используется семантический слой хранилища данных. На шаге 3 в результирующий SQL-запрос попадают границы с учетом минимального индекса соответствия а. Шаг 5 предполагает применение нечетких логических операций.

 

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

 

Очевидно, что Код анкеты — это служебное поле. Для возраста будем использовать лингвистическую переменную, определенную на рис. 16, а для поля Стаж работы — переменную, определенную на рис. 20. Каждая функция принадлежности описывается числами: Малый = {0; 0; 6}, Продолжительный = {3; 6; 10; 20}, Большой = {15; 25; 40; 40}.

 

Таблица 4. Срез по измерениям «Возраст» и «Стаж работы»

Код анкеты Возраст Стаж работы
1 23 4
2 34 11
3 31 10
4 54 36
5 46 26
6 38 15
7 21 1
8 23 2
9 30 8
10 30 12

Рис. 20. Графическое изображение лингвистической переменной «Стаж работы»

Сделаем нечеткий срез «Возраст = Средний и Стаж работы = Продолжительный». Например, для анкеты 4 получим:

Аналогично рассчитаем степени принадлежности к итоговому нечеткому множеству для каждого претендента, зададим минимальный индекс соответствия, равный 0,3, и получим результат, показанный в табл. 5.

 

Таблица 5. Результат нечеткого среза

Код анкеты Возраст Стаж работы Индекс соответствия
3 31 10 1
9 30 8 1
6 38 15 1
2 34 11 0,9
10 30 12 0,8
8 23 2 0,3
1 23 4 0,3

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

Введение в ETL

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

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

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

Определение

ETL — комплекс методов, реализующих процесс переноса исходных данных из различных источников в аналитическое приложение или поддерживающее его хранилище данных.

Основные цели и задачи процесса ETL

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

 

Независимо от особенностей построения и функционирования ETL-система должна обеспечивать выполнение трех основных этапов процесса переноса данных (ETL-процесса).

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

Перемещение данных в процессе ETL можно разбить на последовательность процедур, представленных следующей функциональной схемой (рис. 21).

Рис. 21. Обобщенная структура процесса ETL

1. Извлечение. Данные извлекаются из источников и загружаются в промежуточную область.

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

3. Преобразование. Данные группируются и преобразуются к виду, соответствующему структуре ХД.

4. Распределение. Данные распределяются на несколько потоков в соответствии с особенностями организации процесса их загрузки в ХД.

5. Вставка. Данные загружаются в хранилище-получатель.

С точки зрения процесса ETL архитектуру ХД можно представить в виде трех компонентов (рис. 22), таких как:

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

Рис. 22. Потоки данных в ETL

Перемещение данных от источника к получателю называется потоком данных. Требования к организации потоков данных описываются аналитиком.

 

ETL часто рассматривают как просто подсистему переноса данных из различных источников в централизованное хранилище. Что касается самих хранилищ данных, то они, строго говоря, не связаны с решением какой-либо конкретной аналитической задачи. Задача хранилища — обеспечивать надежный и быстрый доступ к данным, поддерживать их хронологию, целостность и непротиворечивость. Поэтому на первый взгляд ETL оказывается отделенным от собственно анализа данных. Однако такой взгляд на ETL не позволит добиться преимуществ, которые можно получить, если рассматривать его как неотъемлемую часть аналитического процесса.

 

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

 

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

 

Таким образом, ETL следует рассматривать не только как процесс переноса данных из одного приложения в другое, но и как инструмент их подготовки к анализу.

Извлечение данных в ETL

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

 

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

 

Если выгрузку данных производить более часто, то, с одной стороны, количество «окон загрузки» увеличивается, но поскольку за меньший период в OLTP-системе накапливается меньше изменений, то «окна загрузки» становятся короче и нагрузка на систему — ниже.

 

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

 

1. Извлечение данных с помощью специализированных программных средств (рис. 23).

Рис. 23. Первый способ извлечения данных в ETL

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

 

2. Извлечение данных средствами той системы, в которой они хранятся (рис. 24).

Рис. 24. Второй способ извлечения данных в ETL

 

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

 

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

 

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

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

Рис. 25. Схема организации ETL

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

Выбор используемых источников данных

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

 

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

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

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

Особенности организации процесса извлечения данных

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

 

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

ПримерЛегко представить, что посетитель супермаркета зашел туда случайно: не для покупки товара, а чтобы переждать дождь, встретиться с кем-то, помочь донести сумки и т.д. При этом он приобретает коробку спичек, авторучку или другую мелочь, которую мог купить и на обычном уличном лотке. Однако даже для спичечного коробка пробивается чек и создается соответствующая запись в регистрирующей системе. И запись о покупке спичечного коробка за 50 коп. требует места на диске или в памяти не меньше, чем о продаже бутылки коньяка за 1000 руб. В результате после агрегирования данных о продажах за день по отделу выясняется, что зарегистрировано 100 продаж, которые дали в сумме 300 руб., и 10 продаж на общую сумму 15 000 руб. Возникает вопрос: нужно ли тратить время на обработку и хранение огромного количества записей, вклад которых в результат анализа будет ничтожен. Более того, включение в анализ информации о мелких покупках, сделанных случайными клиентами, может только помешать, например, построению модели поведения постоянных клиентов. Поэтому аналитик может задать условие, что извлекаться должны лишь те записи, в которых значение поля «Сумма» не менее 20 руб.

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

 

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

 

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

 

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

 

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

Особенности извлечения данных из различных типов источников

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

 

Базы данных (SQL Server, Oracle, Firebird, Access и т.д.). В большинстве случаев извлечение данных из баз данных не вызывает проблем, поскольку структура данных в них жестко задана, соответствует определенным стандартам и общепринятым требованиям. Кроме того, во многих СУБД предусмотрен автоматический контроль за целостностью и непротиворечивостью данных.

 

Структурированные файлы различных форматов. Такие файлы очень широко распространены, поскольку средства их создания (в большинстве случаев это типовые офисные приложения) общедоступны и не требуют высокой квалификации персонала и высокой производительности систем. К таким источникам относятся текстовые файлы с разделителями, файлы электронных таблиц (например, Excel, CSV-файлы, HTML-документы и т.д.). Здесь проблем больше, поскольку пользователь может допускать ошибки, пропуски, вводить противоречивые данные, терять фрагменты данных и т.д. Пользователи офисных приложений часто понятия не имеют о том, что такое тип данных, и уж тем более не связывают вводимые ими данные с задачами будущего анализа. Очевидно, что в этой ситуации при извлечении данных можно столкнуться с чем угодно. Единственным плюсом является то, что для доступа к типовым структурированным данным можно применять такие стандартные средства, как ODBC и ADO.

 

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

 

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

Очистка данных в ETL. Два уровня очистки данных

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

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

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

Критерии оценки качества данных

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

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

Основные виды проблем в данных, из-за которых они нуждаются в очистке

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

  • корректность форматов и представлений данных;
  • уникальность первичных ключей в таблицах БД;
  • полнота и целостность данных;
  • полнота связей;
  • соответствие некоторым аналитическим ограничениям и т.д.

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

 

Таблица 6. Типичные ошибки, соответствующие структурным единицам БД

На уровне отдельной ячейки таблицы наиболее характерны следующие ошибки.

 

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

 

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

 

Фиктивные значения — данные, не имеющие смысла, никак не связанные с описываемым ими бизнес-процессом. Подобная ситуация возможна, если оператор системы OLTP, не располагая необходимой информацией, ввел в ячейку произвольную последовательность символов. Оператор бывает вынужден это сделать, когда система не позволяет продолжать работу, пока соответствующая ячейка не будет заполнена. Так, если клиент забыл указать в анкете возраст, то оператор может ввести значение 0 или 999. При этом лучше, если значение явно «не лезет ни в какие ворота», поскольку в таком случае вероятность того, что оно будет принято за реальное, уменьшается. Вообще, обнаружить и отфильтровать фиктивные значения довольно трудно, поскольку понятие «смысл» является субъективным и не поддается формализации. Поэтому на этапе очистки данных средствами ETL можно выработать только общие формальные методы обнаружения фиктивных значений и борьбы с ними. Например, можно установить правило: «Если возраст клиента больше 150, то заменить его на значение 0». Когда при последующем анализе аналитик встретит такое значение, он поймет, что значение фиктивное, и примет меры к его замене на более правдоподобное (например, среднее по выборке). Существует и другой способ борьбы с фиктивными значениями. Можно проинструктировать операторов OLTP-систем или персонал, который занимается сводками данных в офисных приложениях, что при отсутствии реальных данных должен вводиться специальный код, который при обработке в процессе ETL распознавался бы как фиктивное значение. Затем к таким данным можно применить обработку, предписанную аналитиком. Наконец, если фиктивные значения являются аномальными (что чаще всего и имеет место), то они могут быть обнаружены и скорректированы средствами аналитической системы.

 

Логические несоответствия возникают, если значение в ячейке не соответствует логическому смыслу поля таблицы. Например, вместо наименования фирмы указан ее банковский счет.

 

Закодированные значения — сокращения, аббревиатуры, замена наименований числовыми кодами.

 

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

 

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

 

На уровне таблицы основными проблемами являются дублирующие и противоречивые записи.

 

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

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

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

 

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

 

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

 

На уровне множества БД возникают проблемы, связанные с отличиями структуры данных в различных базах:

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

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

 

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

Преобразование данных в ETL

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

 

В процессе преобразования данных в рамках ETL чаще всего выполняются следующие операции (рис. 26):

  • преобразование структуры данных;
  • агрегирование данных;
  • перевод значений;
  • создание новых данных;
  • очистка данных.

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

Преобразование структуры данных

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

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

 

Так, если в источнике, полученном из одного филиала, информация о покупателях хранится в поле Customer_Id, а в источнике, полученном из другого филиала, — в поле Clients_Name, то для создания одного измерения Покупатель придется решать задачу их объединения.

 

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

Агрегирование данных

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

 

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

 

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

 

В результате агрегирования большое количество записей о каждом событии в бизнес-процессе заменяется относительно небольшим количеством записей, содержащих агрегированные значения. Например, вместо информации о каждой из 365 ежедневных продаж в году в результате агрегирования будут храниться 52 записи с обобщением по неделям, 12 — по месяцам или 1 — за год. Если цель анализа — разработка прогноза продаж, то для краткосрочного оперативного прогноза достаточно использовать данные по неделям, а для долгосрочного стратегического прогноза — по месяцам или даже по годам.

 

Фактически при агрегировании производится объединение нескольких записей в одну с вычислением агрегированного значения на основе значений каждой записи. При вычислении агрегатов может быть использовано несколько способов. □ Среднее — для данных, расположенных в пределах интервала, в котором они обобщаются, вычисляется среднее значение. Затем все записи из данного интервала заменяются одной, содержащей их среднее значение (рис. 27).

cons 31 - Консолидация данных — ключевые понятия

Рис. 27. Пример агрегирования

  • Сумма — агрегируемые записи заменяются одной, в которой указывается сумма агрегируемых значений.
  • Максимум — в результирующей записи остается максимальное значение из всех объединяемых.
  • Минимум — в результирующей записи остается минимальное значение из всех объединяемых.
  • Количество уникальных значений — результатом агрегирования будет число уникальных значений, появляющихся в ячейках одного и того же поля. Так, для поля, содержащего информацию о профессии клиента, данный способ агрегирования покажет, сколько раз та или иная профессия появлялась в списке. Например, если в 25 записях в поле профессия имело место значение Системный аналитик, а в 50 — Менеджер, то в результате агрегирования мы получим число 2.
  • Количество — результатом агрегирования будет число записей, содержащихся в поле. В приведенном выше примере с профессиями клиентов при этом варианте агрегирования получим 75.
  • Медиана — вычисляется медиана агрегируемых значений. Медиана представляет собой порядковую статистику, рассчитываемую следующим образом. Набор агрегируемых значений, например продажи по дням недели, сортируется в порядке возрастания. Тогда медианой будет центральный элемент упорядоченного набора, если этот набор содержит нечетное количество значений, или среднее двух центральных элементов, если число элементов четное. Например, пусть каждый день в течение недели продажи составляли {100, 120, 115, 119, 107, 131, 102}. Тогда для определения медианы нужно выстроить эти значения по возрастанию: {100, 102, 107, 115, 119, 120, 131}. Значение центрального элемента полученной последовательности, то есть 115, и будет медианой. Если продажи осуществлялись только 6 дней в неделю (воскресенье — выходной), то будет получена последовательность из четного числа значений {100, 107, 115, 119, 120, 131}. В этом случае медиана будет равна: (115 + 119) / 2 = 117.

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

 

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

 

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

 

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

Перевод значений

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

 

Например, согласно заведенному в организации порядку идентификационный номер операции может быть закодирован в виде 06–04–12–62, где 06–04 — число и месяц, 12 — код товара, 62 — код региона. Такое представление позволяет хранить данные очень компактно. Однако для заполнения соответствующих измерений в многомерной модели запись необходимо декодировать.

 

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

Создание новых данных

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

 

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

 

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

Очистка данных

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

 

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

 

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

Выбор места для выполнения преобразований данных

В принципе, преобразование данных может быть выполнено на любом этапе ETL-процесса. Но иногда требуется выбрать оптимальное место для осуществления преобразования. Некоторые виды преобразований удобнее выполнять «на лету», в процессе извлечения данных из источника, другие — в промежуточной области, третьи — в процессе загрузки данных в ХД. Рассмотрим преимущества и недостатки этих вариантов.

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

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

Загрузка данных в хранилище

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

Организация процесса загрузки

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Неполная загрузка данных

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

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

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

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

Рис. 28. Последовательность действий при наличии отклоненных записей в процедуре загрузки в ХД

 

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

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

Многопоточная организация процесса загрузки данных

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

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

Для обеспечения этих функций загружаемые данные распределяются по двум параллельным потокам (data flow) — потоку добавления и потоку обновления (рис. 29).

cons 33 - Консолидация данных — ключевые понятия

Рис. 29. Поток добавления и поток обновления

 

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

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

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

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

 

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

Постзагрузочные операции

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

 

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

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

Кроме того, может оказаться полезным сравнивать данные не только в различных разрезах после их загрузки в ХД, но и с источниками данных. Так, если значения какого-либо показателя в источнике и хранилище равны, то все нормально, в противном случае данные, возможно, некорректны.

 

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

Загрузка данных из локальных источников

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

 

Таким образом, часть данных поступает в аналитическую систему через ХД с соответствующей очисткой и подготовкой, а другая часть — непосредственно из источников (рис. 30).

Рис. 30. Загрузка данных из локальных источников

 

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

Преимущества и недостатки отказа от хранилищ данных

Главным преимуществом, которое дает использование хранилищ данных в аналитических технологиях, является повышение эффективности и достоверности анализа данных, особенно для поддержки принятия стратегических решений. Это достигается за счет оп&#