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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение

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

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

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

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

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

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

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

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

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

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

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

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

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

  Недостатками схемы «звезда» являются:

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

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

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

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

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

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

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

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

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

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

Значителен объем хранимых данных (многомерные ХД становятся неэффективными).

Иерархия измерений несложная (другими словами, немного агрегированных данных).

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

Определение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение

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

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

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

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

Рис. 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):

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

μ(x) = min(μ_A(x), μ_B(x)).

μ(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).

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

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

Рис. 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).

Рис. 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%). Нужно добавить данные о новых клиентах и одновременно модифицировать информацию о существующих.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• текстовые файлы с разделителями (TXT, CSV);
• файлы электронных таблиц Excel;
• файлы плоских таблиц БД, например dBase, FoxPro и т.д. (DBF-файлы);
• реляционные СУБД настольного уровня, например Access и т.д.;
• корпоративные базы данных и учетные системы (Oracle, Informix, Sybase, DB2 и т.д.).

Текстовые файлы с разделителями (TXT, CSV). Файлы в TXT-формате хорошо известны большинству пользователей (даже непрофессиональных) еще со времен MS-DOS. Для создания таких файлов достаточно использовать простейший текстовый редактор, например Блокнот из набора стандартных программ Windows. Однако эти файлы имеют произвольную структуру данных, поэтому они наиболее уязвимы с точки зрения нарушения структуры, использования некорректных форматов и представлений данных. Так что загрузка и очистка TXT-файлов могут вызвать самые серьезные проблемы, несмотря на то что эти файлы очень просты в создании.

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

1. В первой строке файла нужно указать заголовки столбцов в произвольной форме, при этом используются кириллица и пробелы. При загрузке в аналитическую систему заголовки столбцов будут преобразованы в метки полей, что позволит аналитику быстрее разобраться с содержимым источника. Поскольку в TXT-файлах имена полей (в том виде, как они представлены в таблицах файлов БД) отсутствуют, при загрузке в аналитическую систему они будут установлены автоматически в соответствии с правилами, принятыми в данной системе. Например, им по умолчанию могут быть присвоены метки COL1, COL2 или FIELD1, FIELD2 и т.д. Если в первой строке текстового файла над каждым столбцом указано его название, то система при загрузке сможет преобразовать эти названия в имена полей, если каким-либо образом указать, что первая строка содержит заголовки. Однако это возможно только при условии, что названия столбцов не противоречат правилам назначения имен полей в данной аналитической системе, то есть не содержат недопустимых символов, не превышают заданную длину и т.д. Это следует учитывать при создании текстовых файлов с разделителями, которые планируется использовать в качестве источников данных для аналитических систем.

2. Необходимо соблюдать регулярность структуры данных, то есть каждые строка и столбец должны содержать одинаковое число элементов. Если некоторые значения были утеряны, то их можно заменить средними значениями по столбцу для числовых атрибутов. Для строковых атрибутов можно указать наиболее вероятное значение или значение по умолчанию, которое впоследствии может быть соответствующим образом обработано (например, NONAME). Оставлять пустые или фиктивные значения нежелательно: пропущенное значение может заблокировать работу аналитических алгоритмов, а фиктивное (например, $999,999) может быть обработано как истинное.

3. Столбцы должны быть типизированы, то есть содержать данные только одного типа (например, только строковые или только числовые). Кроме того, внутри каждого столбца формат представления чисел или дат должен быть одинаковым. Например, использование в одном столбце краткого (12.07.06) и полного (12 июля 2006 г.) форматов даты способно вызвать серьезные проблемы при загрузке данных. Также нежелательно использовать в одном поле числа в экспоненциальном формате (1,2E + 3) и в обычном (12 000), поскольку это может вызвать проблемы при загрузке значений из данного поля.

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

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

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

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

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

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

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

Текстовые файлы в формате CSV менее известны пользователям, поскольку используются реже, чем обычные TXT-файлы. CSV (от англ. ramma separated values — «значения, разделенные запятыми») — это специальный текстовый формат, предназначенный для представления табличных данных. Каждая строка в таком файле соответствует одной строке таблицы. Значения отдельных столбцов разделяются специальным символом — запятой или точкой с запятой. Используемый символ-разделитель зависит от настроек региональных стандартов. В США это запятая, а в России — точка с запятой, поскольку у нас запятая используется для разделения целой и дробной частей чисел (в отличие от США, где для этого служит точка). Файлы такого типа могут быть получены путем конвертации из любого табличного процессора.

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

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

Файлы «плоских» таблиц СУБД семейства dBase, FoxBase, FoxPro и т.д. имеют расширение DBF (database file). Как и файлы любых СУБД, DBF-файлы имеют жестко заданную структуру. В них строго определены имена и типы полей, структура полей и записей, используемые форматы представления данных. Следовательно, проблем с загрузкой данных из таких источников намного меньше по сравнению с текстовыми файлами, поскольку все возможные проблемы контролируются в процессе создания файла. СУБД не позволит присвоить полю некорректное имя, ввести в поле данные, не соответствующие его типу или использующие неправильный разделитель групп разрядов в числе, и т.д., поэтому ожидаемое качество данных, загружаемых из DBF-файлов, является более высоким, чем для текстовых.

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

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

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

Обогащение данных

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

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

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

Данные и информация

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

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

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

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

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

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

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

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

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

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

Необходимость обогащения данных

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

Рис. 31. Обогащение данных

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

Определение

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

Можно выделить два основных метода обогащения данных — внешнее обогащение и внутреннее.

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

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

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

Внешними источниками могут быть:

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

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

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

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

Пример

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

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

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

Пример

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

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

Персоналии

Билл Инмон (Bill Inmon) — автор концепции хранилищ данных, обнародованной в 1989 г., крупнейший в мире специалист в этой области. Его идея вызвала настоящий переворот в методах использования при управлении бизнесом гигантских массивов данных, накопленных компаниями. Тем самым был дан мощный толчок дальнейшему развитию технологий Business Intelligence, прежде всего построению информационных витрин. Билл Инмон — соавтор концепций корпоративной информационной фабрики (Corporate Information Factory) и ее аналога для государственных структур (Government Information Factory). В его модели атомарные данные организованы в реляционные базы и находятся в нормализованном хранилище данных.

Из-под пера Инмона вышло более 600 статей, а также 46 книг, переведенных на девять языков мира. Среди них — бестселлер Building the Data Warehouse, суммарный тираж которого уже превысил полмиллиона экземпляров.

Билл Инмон является основателем Prism Solutions — первой в мире компании, которая занялась разработкой инструментария ETL — средств извлечения, преобразования и загрузки данных.

Ральф Кимболл (Ralph Kimball) — широко известный специалист в области хранилищ данных и бизнес-аналитики. Он предложил использовать пространственную организацию баз данных (dimensional data bases) с так называемой архитектурой «звезда».

Кимболл известен как автор бестселлера «Инструменты для хранилища данных: полное руководство пространственного моделирования» (The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling) и др.

Карьера Кимболла складывалась следующим образом. В 1972 г., после окончания постдока Стэндфордского университета в области электротехники (специализация — человеко-машинное взаимодействие), он попал в исследовательский центр Xerox Palo Alto, где принял участие в разработке коммерческого программного продукта Xerox Star WorkStation. Затем Кимболл становится вице-президентом компании Metaphor Computer Systems, занимающейся разработкой систем принятия решений и консалтингом. В 1986 г. он основывает компанию Red Brick Systems и занимает пост ее генерального директора до 1992 г. Red Brick System, сейчас принадлежащая IBM, известна своими разработками в области производительной реляционной СУБД, оптимизированной под хранилища данных.

В 1992 г. зарегистрирована ассоциация Ральфа Кимболла, оказывающая услуги консалтинга и обучения в области хранилищ данных. Сайт ассоциации: http://ralphkimball.com/.