Задача консолидации.Консолидация Данных

Задача консолидации Консолидация Данных Введение Ценность и достоверность знаний, полученных в результате интеллектуального анализа данных, зависит не только от эффективности используемых аналитических методов и алгоритмов, но и от того, насколько правильно подобраны и подготовлены исходные данные для анализа. Обычно руководителям проектов по бизнес-аналитике с нуля приходится сталкиваться со следующими ситуациями: • Данные на предприятии расположены в различных источниках самых разнообразных форматов и типов в отдельных файлах офисных документов (Ехсеl, Word, обычных текстовых файлах), в учетных системах (1С, Парус и др.), в базах данных (Oracle, Access, dBase и др.) • Данные могут быть избыточными или, наоборот, недостаточными • Данные являются связными – содержат факторы, мешающие их правильной обработке и анализу (пропуски, аномальные значения, дубликаты и противоречия) Поэтому, прежде чем приступить к анализу данных, необходимо : • Доведение данных до приемлемого уровня качества и информативности • Организовать их интегрирование в структурах, обеспечивающих их целостность, непротиворечивость, высокую скорость и гибкость выполняемых аналитических запросов. Консолидация —- комплекс методов, направленных на извлечение данных из различных источников, обеспечение необходимого уровня их информативности и качества, преобразование в единый формат, в котором они могут быть загружены хранилище данных – аналитическую систему. Основные критерии оптимальности с точки зрения консолидации данных: • Обеспечение высокой скорости доступа к данным • Компактность хранения • Автоматическая поддержка целостности структуры данных; • Контроль непротиворечивости данных. Источники данных Ключевым понятием консолидации является источник данных — объект, содержащий структурированные данные и используемая аналитическая платформа могла осуществлять доступ к данным из этого объекта непосредственно либо после их преобразования в другой формат. Основные задачи консолидации данных: • выбор источников данных; • разработка стратегии консолидации; • оценка качества данных; • обогащение; • очистка; • перенос в хранилище данных. Выбор источников данных - можно выделить три основных подхода к организации хранения данных. • Данные, хранящиеся в отдельных (локальных) файлах, например, в текстовых файлах с разделителями, документах Word, Ехсеl данные в котором организованы в виде столбцов и записей. Преимущество данные создаваться и редактироваться с помощью простых офисных приложений. К недостаткам не всегда оптимальны, компактности представления данных и поддержки их структурной целостности. • Базы данных (БД) различных СУБД, таких как Огас1е, SQL Server, Firebird, dBase, FохРго, Ассезз и т. д. Файлы БД лучше поддерживают целостность структуры данных, поскольку тип и свойства их полей жестко задаются при построении таблиц. Однако требуются специалисты с более высоким уровнем подготовки. • Специализированные хранилища данных (ХД) являются наиболее предпочтительным решением, поскольку их структура и функционирование специально оптимизируются для работы с аналитической платформой. Главное преимущество ХД перед остальными типами источников данных — наличие семантического слоя, который дает пользователю возможность оперировать терминами предметной области для формирования аналитических запросов к хранилищу. Очистка данных – комплекс методов и процедур, направленных на устранение причин, мешающих корректной обработке: аномалий, пропусков, дубликатов, противоречий, шумов и т.д. Обогащение - процесс дополнения данных некоторой информацией, позволяющей повысить эффективность решения аналитических задач. Его необходимо применять в тех случаях, когда данные содержат недостаточно информации для удовлетворительного решения определенной задачи анализа. Обобщенная схема процесса консолидации Место консолидации в общем процессе анализа данных может быть представлено в виде структурной схемы (рис 2.1) Рис. 2.1. Процесс консолидации данных В основе процедуры консолидации лежит процесс ЕТL (ехtraction, transformation, loading), Процесс ЕТL решает задачи извлечения данных из разнотипных источников, их преобразования к виду, пригодному для хранения в определенной структуре, а также загрузки в соответствующую базу или хранилище данных Процесс сбора, хранения и оперативной обработки данных на типичном предприятии обычно содержит несколько уровней. На верхнем уровне располагаются реляционные SQL-ориентированные СУБД типа SQL-Server, Оrас1е и т. д. На втором серверы с некоторой системой оперативной обработки данных OLТР. И наконец, на самом нижнем уровне расположены локальные ПК отдельных пользователей с персональными источниками данных. Из источников данных всех перечисленных уровней информация в соответствии с некоторым регламентом должна перемещаться в ХД. Для этого необходимо обеспечить выгрузку данных из источников, провести их преобразование к виду, соответствующему структуре ХД, а при необходимости выполнить их обогащение и очистку. Таким образом, консолидация данных является сложной многоступенчатой процедурой и важнейшей составляющей аналитического процесса, обеспечивающей высокий уровень аналитических решений. Введение в хранилища данных Введение С появлением персональных компьютеров корпоративные системы, предназначенные для оперативной обработки информации, стали доступными для множества мелких и средних фирм, предприятий. Системы оперативной обработки информации получили название ОLТР (On-line Transaction Processing — оперативная, то есть в режиме реального времени, обработка транзакций). Транзакция — некоторый набор операций над базой данных, который рассматривается как единое завершенное, сточки зрения пользователя, действие над некоторой информацией, обычно связанное с обращением к базе данных. Обобщенная структура системы ОLТР представлена на рис. 2.2. Типичным примером применения OLTP-систем является массовое обслуживание клиентов, например, бронирование авиабилетов или оплата услуг телефонных компаний. Обе эти ситуации имеют два общих свойства: очень большое число клиентов и непрерывное поступление информации. В данной задаче транзакция включает в себя набор таких действий, как: • запрос оператора о наличии свободных мест на тот или иной рейс; • отклик ВЦ с предоставлением соответствующей информации; • ввод оператором информации о клиенте, номере заказанного места и оплаченной сумме (возможно, будет присутствовать еще какая-либо служебная вспомогательная информация); • передача новой информации в базу данных и внесение в нее соответствующих изменений; • передача оператору подтверждения о том, что операция выполнена успешно. Такие транзакции выполняются тысячи раз в день в сотнях пунктов продаж. Очевидно, что основным приоритетом в данном случае является обеспечение минимального времени отклика при максимальной загрузке системы. Рассмотрим характерные черты данного процесса, свойственные в той или иной мере всем OLTP-системам. • Запросы и отчеты полностью регламентированы. Оператор не может сформировать собственный запрос, чтобы уточнить или проанализировать какую-либо информацию. • Как только перелет завершился, информация об обслуживании данного клиента теряет смысл, становится неактуальной и подлежит удалению по прошествии определенного времени (то есть исторические данные не поддерживаются). • Операции производятся над данными с максимальным уровнем детализации, то есть по каждому клиенту в отдельности. Анализ пассажиропотоков с целью их оптимизации, в случаи нехватки или низкого уровни спроса билетов на определенные маршруты позволяет сделать предположение о целесообразности увеличении или сокращении рейсов. Для проведения таких исследований необходимы как минимум три вещи: * необходима дополнительная информация о би знес- среде: о конкурентах, рыночных тенденциях, ценах на топливо н пр. Очевидно, что типичная 01ЛТ-система не может обеспечить ничего из перечисленного. Следовательно, необходимо использовать более развитые систем хранения данных, ориентированных на анализ. Предпосылки появления ХД Появление потребности в информационных системах, которые позволяли бы проводить глубокую аналитическую обработку, поиск скрытых структур и закономерностей в массивах данных, стратегическое и оперативное планирование, формирование нерегламентированных запросов, принятие решений и прогнозирование. Понимание преимуществ, которые способен дать интеллектуальный анализ, привело к появлению нового класса систем — информационных систем поддержки принятия решений (СППР), ориентированных на аналитическую обработку данных с целью получения знаний, Обобщенная структурная схема информационной СППР представлена на рис. 2.3. • Для выполнения сложных аналитических запросов необходима обработка больших массивов данных из разнообразных источников. • Для выполнения запросов, связанных с анализом тенденций, прогнозированием протяженных во времени процессов, необходимы исторические данные, накопленные за достаточно длительный период, что не обеспечивается обычными ОЬТР- системами. • При аналитической обработке предпочтение отдается не детальным данным, а обобщенным (агрегированным). Очевидно, что для анализа продаж крупного супермаркета интерес представляет не информация об отдельных покупках, а о продажах за период день, неделя, месяц, год. В связи с этим можно выделить ряд принципиальных отличии СПИР и ОЬТР- систем. Эти отличия представлены в табл. 2.1. Таблица 2.1. Отличия СППР и ОЬТР-систем Свойство ОЫР-система СППР Цели использования данных Быстрый поиск, простей­шие алгоритмы обработки Аналитическая обработка с целью поиска скрытых закономерностей, Уровень обобщения (детализации) данных Детализированные Как детализированные, так и обобщенные Требования к каче­ству данных Возможны некорректные данные (ошибки регистра­ции, ввода и т. д.) Ошибки в данных не допускаются, поскольку могут привести к не- Формат хранения данных Данные могут храниться в различных форматах в зависимости от при- Данные хранятся и обрабатываются в едином формате Время хранения данных Как правило, не более года (в пределах отчетного Г оды, десятилетия Изменение данных Данные могут добавляться, изменяться и удаляться Допускается только пополнение; ранее Периодичность Часто, но в небольших Редко, но в больших Должен бы 11.» обеспечен [Должен бы/ь ЫнМШЧИН доступ ко всем текущим 1/ннлун к не/орич#сяим По (опоратинным) данным рсть н'шмм&шшм ш Стандартные, настроенные I кре! тши I ирошиняе* заранее [формируемые ЬИШШ / ИМ0М Несколько секунд [До нескольких мину/ Как видно из табл. 2.1, требования к СГП1Р и ОМ Р системам существенно отличаются. Поэтому в СГП 1Р используются специализированные базы данных, которые называются хрннилишлми данных (ХД). Основные особенности концепции ХД Хранилище данных разновидность систем хранения, ориентированная на поддержку процесса анализа данных, обеспечивающая целостность, непротиворечивост ь и хронолог ию данных, а также высокую скорость выполнения аналитических запросов. Важнейшим элементом ХД является семант ический слой механизм, позволяющий аналитику оперировать данными посредст вом бизнес - терминов предметной области. Семантический слой дает пользователю возможность сосредоточиться на анализе и не задумываться о механизмах получения данных. Базы данных в ОЬ ГР-системах характеризуются очень высокой динамикой изменения записей из-за повседневной работы большого числа пользователей (откуда, кстати, велика вероятность появления противоречий, ошибок, нарушения целостности Ночных иШ ()•)> Что касается ХД, то данные из него не удаляются, а пополнение происходит в соответствии с определенным регламентом (раз о час, день, неделю, в определенное время). Основные требования к ХД • высокая скорость получения данных из хранилища; • автоматическая поддержка внутренней непротиворечивости данных; • возможность получения и сравнения срезов данных; • наличие удобных средств для просмотра данных в хранилище; 2.2. Основные концепции хранилищ данных Основные положения концепции ХД В основе концепции ХД лежат следующие положения: • интеграция и согласование данных из различных источников, таких как обычные системы оперативной обработки, базы данных, учетные системы, офисные документы, электронные архивы, расположенные как внутри предприятия, так и во внешнем окружении; • разделение наборов данных, используемых системами выполнения транзакций и СППР. Свойства ХД: предметно-ориентированный, интегрированный, неизменяемый и поддерживающий хронологию набор данных, предназна­ченный для обеспечения принятия управленческих решений. Ориентированность -ХД должно разрабатываться с учетом специфики конкретной предметной области, а не аналитических приложений, с которыми его предполагается использовать. Структура ХД должна отражать представления аналитика об информации, с которой ему приходится работать. Интегрированность означает, что должна быть обеспечена возможность за­грузки в ХД информации из источников, поддерживающих различные форматы данных и созданных в различных приложениях — учетных системах, базах данных, электронных таблицах и других офисных приложениях, поддерживающих структурированность данных (например, текстовые файлы с разделителями). Принцип не изменчивости предполагает, что, в отличие от обычных систем оперативной обработки данных, в ХД данные после загрузки не должны подвергаться каким-либо изменениям, за исключением добавления новых данных. Поддержка хронологии означает соблюдение порядка следования записей, для этого в структуру ХД вводятся ключевые атрибуты Дата и Время. Физически упорядочить записи в хронологическом порядке возрастания атрибута Дата, можно уменьшить время выполнения аналитических запросов. Использование концепции ХД в СППР и анализе данных способствует достижению таких целей, как: • своевременное обеспечение аналитиков и руководителей всей информацией, необходимой для выработки обоснованных и качественных управленческих решений; • создание единой модели представления данных в организации; • создание интегрированного источника данных, предоставляющего удобный доступ к разнородной информации и гарантирующего получение одинаковых ответов на одинаковые запросы из различных аналитических приложений. Задачи, решаемые ХД Основными задачами, которые требуется решить в процессе разработки ХД, являются: | выбор структуры хранения данных, обеспечивающей высокую скорость выполнения запросов и минимизацию объема оперативной памяти; | первоначальное заполнение и последующее пополнение хранилища; | обеспечение единой методики работы с разнородными данными и создание удобного интерфейса пользователя. Обобщенная концептуальная схема ХД представлена на рис. 2.4. Ь I . "~г~ Пользователь Рис. 2.4. Концептуальная схема ХД Согласно схеме данные извлекаются из различных источников и загружаются в ХД, которое содержит как собственно данные, представленные в соответствии с некоторой моделью, так и метаданные. Дггалширо ванные и агрег ированные данные Данные в ХД хранятся как в детализированном, так и в агрегированном виде, Данные в легализированном виде поступают непосредственно из источников данных и соответствуют элементарным событиям, регистрируемым 01Л Р- сислсмами. I акими данными могут быть ежедневные продажи, количество ВШКМДО/дошых изделий и т. д. Это неделимые значения, попытка дополнительно детализировать которые лишает их логического смысла. Многие задачи анализа (например, прогнозирование) требуют использования данных определенной степени обобщения. Например, суммы продаж, взятые подиям, могут /гать очень неравномерный ряд данных, что затруднит выявление характерных периодов, закономерностей или тенденций. Однако, если обобщить гги данные в пределах недели или месяца и взять сумму, среднее, максимальное и минимальное значения за соответствующий период, то полученный ряд может оказаться более информативным. Процесс обобщения детализированных данных называется агрегированием, а сами обобщенные данные — агрегированными (иногда — агрегатами). Обычно агрегированию подвергаются числовые данные (факты), они вычисляются и содержатся в ХД вместе с детализированными данными. 11осколмсу один и тот же набор детализированных данных может породить несколько наборов агрегированных данных с различной степенью обобщения^ объем ХД возрастает, иногда существенно. Например, набор, содержащий данные о продажах по дням в течение года, помимо своих 360 значений, порождает 52 значения с обобщением по неделям и 12 — по месяцам. Если при этом вычисляются все виды агрегации — сумма, среднее, максимальное и минимальное значения за соответствующий период, — то количество хранящихся агрегированных значений составит уже (52 + 12) • 4 в 256. Иногда это приводит к «взрывному», неконтролируемому росту ХД и вызывает серьезные технические проблемы: хранилище «распухает», из-за того что непрерывный поток входных данных автоматически агрегируется в соответствии с настройками ХД. Однако с этим приходится мириться: если бы аг регированные данные не содержались в ХД, а вычислялись в процессе пыполпспия запросов, время выполнения запроса увеличилось бы в несколько раз. Метаданные