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

Международная организация "The Data Warehousing Institute" опубликовала ряд тезисов под общим названием "Десять главных ошибок, которых не следует допускать при разработке Хранилища данных" ("Top Ten Mistakes to Avoid When Building a Data Warehouse"). Согласно этому документу ошибка под номером 5 - откладывание внедрения тщательно продуманной инфраструктуры Хранилища. А ведь благодаря гибкому представлению различных бизнес-данных хорошо структурированное Хранилище берет на себя функции отчетности, разгружая учетную (OLTP) систему. Предназначение Хранилища данных - предоставление специально подобранной информации, необходимой для принятия решений (именно эта идея вкладывалась в популярный ныне термин Business Intelligence (BI)). Сегодня известно несколько различных архитектур корпоративной отчетности, начиная созданием отчетов напрямую из учетных систем и заканчивая комплексной средой Хранилища, где данные очищаются, затем приводятся к стандартному формату и загружаются в репозиторий. В данной статье описываются наиболее распространенные подходы к разработке отчетов, а также соотношение выгод и потерь, которые необходимо учитывать при выборе любого из них.

Отчетность в учетных системах

Многие небольшие фирмы, составляющие отчеты при помощи старых BI-средств, получают данные непосредственно из учетных систем. Для этого обычно применяется инструментарий, где предусмотрено собственное подсоединение к базе данных OLTP или используется общий протокол доступа к данным, например: ODBC, JDBC, OLE DB и т.п.

Рис. 1. Отчетность в учетной системе

Надписи на рисунке:
Sales -продажи;
Operations - операции;
Financial - финансы;
HR - человеческие ресурсы;
Business User - бизнес-пользователь

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

Данные, полученные из учетной системы - это необработанные сведения, введенные операторами. Их часто называют "неочищенными" (dirty), имея ввиду, что они недостаточно четко представляют необходимую информацию. Например, имена пользователей могут быть введены в различных вариантах написания (так, Bob O'Neill, Robert O'Neill и Bob O'Neal оказываются одним и тем же человеком - Бобом О'Нилом). Кроме того, эти имена могут вводиться из различных корпоративных источников. И если каждый отдел использует свою учетную систему, то для выяснения различных вопросов (например: "Кто же наши основные клиенты?") необходимо будет создавать и объединять множество отчетов.

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

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

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

Отчетность по дублированной базе учетной системы

Альтернатива описанному выше подходу - использование "автономной" (offline) базы данных (data store), которая представляет собой дубликат оперативной базы. Дублированная база обновляется по мере необходимости; в ней применяются те же средства отчетности. Запросы пользователей передаются в автономную базу данных, которая может быть реализована по разному, например в виде плоских файлов (flat files) или копий таблиц исходной базы.

Рис. 2. Отчетность в дублированной базе учетной системы

Надписи на рисунке:
Sales -продажи;
Operations - операции;
Financial - финансы;
HR - человеческие ресурсы;
Business User - бизнес-пользователь

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

Дублированные данные передаются из OLTP-системы в основном тремя способами: при помощи журналов транзакций (transaction logs), путем репликации базы или через пакетные файлы. Каждый способ имеет свои преимущества и недостатки, о чем будет сказано ниже.

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

Репликация позволяет быстро передать измененные данные в автономную базу данных. Пользователю достаточно подождать, пока очистится очередь репликации (replication queue): обычно это занимает 10-15 минут. Тем не менее, для корпоративной отчетности такой способ не удобен. Системные ресурсы оперативной базы данных расходуются на обработку репликационных запросов, следующих один за другим. Настройка и поддержка репликации занимает немало времени для многих учетных систем, которые используются для создания корпоративных отчетов.

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

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

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

С ее помощью разработчики представляют данные уже на языке бизнес-терминологии, а не в виде формальных OLTP-структур. Тогда любой средний пользователь, не являющийся специалистом по учетным системам, сможет без особой подготовки получить из витрины данных относительно сложную информацию. Такой метод анализа получил название оперативной аналитической обработки, или OLAP (OnLine Analytical Processing). Он является мощным инструментом просмотра любых параметров коммерческой деятельности компании. Эти параметры также известны как измерения, в них заносится информация о клиентах, поставщиках, типе продукции, времени и географии продаж и т.д. Таким образом, OLAP дает ответы на такие вопросы, как, например: "Сколько товаров и каким продавцом было продано по каждому из регионов в прошлом месяце?" или "Как эти значения изменились по сравнению с предыдущим месяцем и с тем же месяцем в прошлом году?".

Рис. 3. Отчетность в дублированной базе учетной системы

Надписи на рисунке:
Sales -продажи;
Operations - операции;
Financial - финансы;
HR - человеческие ресурсы;
Sales Data Mart - витрина данных продаж;
Operations Data Mart - витрина данных операций;
Financial Data Mart - витрина данных финансов;
HR Data Mart - витрина данных человеческих ресурсов;
Business User - бизнес-пользователь

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

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

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

Отчетность по Хранилищу данных предприятия

Хранилище данных предприятия (Enterprise Data Warehouse - EDW) предназначено для объединения данных из различных учетных систем, обеспечивает консолидированные и очищенные данные для ряда витрин данных. Ключевым моментом этой технологии является применение бизнес-правил к исходным данных. Бизнес-правила определяют методы консолидации, стандартизацию кодов, очистку данных и отслеживание транзакций за прошедшие периоды. Таким образом, каждая из систем (учетная, Хранилище и витрина данных) будет выполнять те цели, для которых она была разработана.

Рис. 4. Отчетность по хранилищу данных предприятия

Надписи на рисунке:
Sales -продажи;
Operations - операции;
Financial - финансы;
HR - человеческие ресурсы;
Enterprise Data Warehouse - Хранилище данных предприятия;
Sales Data Mart - витрина данных продаж;
Operations Data Mart - витрина данных операций;
Financial Data Mart - витрина данных финансов;
HR Data Mart - витрина данных человеческих ресурсов;
Business User - бизнес-пользователь

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

После консолидации к данным применяются правила стандартизации и очистки. Таким образом, у пользователей появляется согласованный доступ к данным, не зависящий от источника. Записи, которые не отвечают требованиям, предъявляемым к качеству данных, получают статус "ожидания" ("on hold"), пока не будет выполнено некоторое действие, которое устранит создавшуюся неопределенность. В соответствии с бизнес-правилами, таким данным можно присвоить также значение "по умолчанию" (default value).

После очистки и консолидации данные хранятся в реляционной СУБД. Часто используется та же технология, что и в учетных системах (например, продукт фирмы Oracle, IBM, SQL Server и т.п.). Данные хранятся в реляционном формате, позволяя эффективно использовать историю транзакций и время от времени менять дизайн. Помимо истории транзакций Хранилище данных также содержит изменения, вносимые в структуру бизнес подразделений. Так, продавцы часто переходят в другие отделы, а заведующие отделов прикрепляются к другим подразделениям. Но запись о конкретной продаже не подгоняется под изменившуюся структуру организации, так как каждая транзакция должна отражать ту реальную ситуацию, которая складывалась на момент ее выполнения. Таким образом, в Хранилище поддерживаются так называемые "медленно изменяющиеся измерения" (slowly changing dimensions).

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

Поскольку изменения происходят как в учетной системе, так и в витринах данных, Хранилище служит своего рода буфером, минимизирующим исправления в данных и инфраструктуре отчетности. EDW подходит для компаний, которые планируют переход к ERP-системам (Enterprise Resource Planning - планирование ресурсов предприятия). Хранилище предназначено для работы со стандартными транзакционными форматами. Манипулированию каждой из исходных систем придается меньше значения, основное внимание уделяется тому, как привести данные в соответствие стандартному формату. По выполнении этой задачи, данные можно обрабатывать обычным способом для всех источников.

Это в равной мере относится как к крупным компаниям, поглощающим мелкие, так и к мелким, ориентированным на слияние с крупными. Данные из EDW-системы передаются в многомерную витрину. Для хранения данных, отображаемых с помощью интерфейсных средств, в этих витринах используются стандартные структуры данных, а также схемы "звезда" (star) и "снежинка" (snowfalke). На сегодняшний день, большинство поставщиков BI-инструментов обеспечивают поддержку стандартных форматов и позволяют пользователям осуществлять доступ и просматривать бизнес-данные. При покупке нового инструмента проблем с созданием отчетов по соответствующим витринам данных не возникает. Такая устойчивость и совместимость обеспечиваются EDW-архитектурой.

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

Резюме

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

Рис. 5. Характеристики различных архитектур отчетности

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