Хранилище данных

Уильям Х. Инмон (англ. William H. Inmon), первым ввёдший этот термин, определяет хранилище данных как «интегрированную, ориентированную на предметную область, изменяющуюся во времени и невосприимчивую к изменениям» коллекцию данных, поддерживающую процессы принятия решений.

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

По Инмону, коллекция данных обладает следующими характеристиками:

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

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

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

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

Основные компоненты архитектуры хранилища данных:

• Данные из транзакционных систем: это массивы, формируемые внутренними корпоративными транзакционными системами, отдельными базами данных или даже поступающие извне. Часто архитектура хранилища предусматривает интеграцию внутренних и внешних данных, что расширяет информационный потенциал.
• Перемещение данных (data movement): отвечает за извлечение данных из транзакционных источников, интеграцию внутренней и внешней информации, предварительную обработку (pre-processing), проверку согласованности, конвертацию структур и обновление словарей-определителей.
• Собственно хранилище данных: здесь агрегированные из исходных архивов данные сохраняются в DW, доступ к которым возможен только для чтения. Данные историзированы, связаны с бизнес-объектами и могут храниться как в центральном архиве, так и в отдельном тематическом датамарте (например, для анализа маркетинга — отдельный блок для анализа клиентской базы). В DW может существовать несколько датамартов, каждая из которых фокусируется на своей бизнес-области.
• Метаданные: справочная информация о данных (иногда их называют «данные о данных», англ. data about data), описывающая происхождение, назначение, характеристики, функцию и семантику объектов DW. Для этого создаются специальные каталоги метаданных (information catalog), позволяющие конечным пользователям понимать содержание и структуру данных.
• Конечный пользователь: потребители информации из DW используют разнообразные средства для анализа и получения информации — генераторы запросов и отчетов, графические интерфейсы, сложные системы анализа данных.

Хранилище данных организовано на четырёх архитектурных уровнях:

1. Преобразование данных: получение и валидация исходных данных.
2. Подготовка и хранение: предоставление информации конечным пользователям и аналитическим приложениям.
3. Интерпретация и анализ: преобразование данных в стратегически ценную информацию.
4. Представление информации: вывод и визуализация результатов конечным пользователям.

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

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

Извлечение данных чаще всего реализуется средствами и языками самих платформ-источников. Это, как правило, параметризованные ad hoc-запросы, выполняемые периодически в периоды наименьшей активности системы.

Наиболее значимый по добавленной стоимости этап — преобразование (transformation): на этом этапе применяются бизнес-правила по интеграции, нормализации, стандартизации и очистке данных (cleansing). Здесь во многом формируется качество и доверие к данным DW среди конечных пользователей, поскольку извлечённая из исходных систем информация часто бывает неполной и недостаточно пригодной для аналитики.

Иногда операции преобразования порождают отклонения части потока данных — «reject» (отказ загрузки) из-за «загрязнённости» или несоответствия исходных данных.

Причины отказов включают:

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

После прохождения слоя преобразования данные сохраняются для:

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

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

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

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

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

Можно также строить одни или несколько датамартов (data mart), содержащих только агрегаты, однако это ограничивает глубину и мощность аналитики, так как расширение детализации невозможно.

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

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

Это снижает затраты и время на запуск новых отчётов и делает DW настоящей фабрикой «доставки информации» (information delivery).

Функции анализа позволяют проводить исследования агрегатов. Обычно для анализа в DW применяются технологии OLAP (On-Line Analytical Processing).

OLAP — это подход, ориентированный на многомерный анализ данных для поддержки управленческих решений. Ключевые характеристики OLAP:

• Ориентирован на потребителя бизнеса: большинство пользовательских размышлений строится не вокруг реляционных таблиц, а вокруг бизнес-измерений (например, «регион», «продукт», «месяц»). После освоения базовых понятий «измерение» и «иерархия» любой специалист способен анализировать данные при помощи OLAP-инструментов.
• Решение неструктурированных задач: в отличие от фиксированных отчётов, OLAP-системы позволяют свободную навигацию, постановку новых неочевидных вопросов и поиски причинно-следственных связей между факторами.
• Фокус на информации: OLAP-ядро не предназначено для визуализации, а реализует оптимизированное хранение и навигацию по многомерным данным. Пользователь видит только нужную ему информацию, организованную по ключевым аналитическим измерениям.
• Эффективность: за счёт перехода от общего к частному и эффективной поддержки логических сценариев анализа, OLAP-системы значительно ускоряют поиск нужной информации.

Этот уровень содержит инструменты визуализации и интерпретации информации для пользователей.

Выделяют три крупные группы решений:

• Специализированные инструменты бизнес-аналитики: включает конструкторы запросов и отчётов, браузеры OLAP-структур (OLAP viewer), а также web-браузеры — как единый интерфейс для работы с DW.
• Офисные приложения: часто вендоры BI-систем предлагают использовать привычные для пользователя текстовые и табличные редакторы как front-end для работы с DW. Это может быть удобно на начальном этапе, но архитектурные и функциональные возможности подобных инструментов ограничены для интенсивной аналитики.
• Инструменты графики и публикации: позволяют формировать графики, диаграммы и таблицы непосредственно из аналитических отчётов. Такая интеграция устраняет необходимость ручной визуализации результатов.

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

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

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

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

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

Основные подходы к построению DW:

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

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

• область извлечения и преобразования данных;
• база DW;
• средства анализа и работы с DW.

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

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

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

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

Большие объёмы нерелевантных данных могут сделать аналитику неэффективной — решением является сегментирование по бизнес-областям внутри DW.

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

Важнейшими условиями работы хранилища данных являются:

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

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

• DSS (Decision Support System — система поддержки принятия решений);
• EIS (Executive/Enterprise Information System — исполнительские/корпоративные информационные системы).

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

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

Фазы развития DW-стратегии в компании определяются двумя измерениями:

• Использование существующего DW: зрелость пользователей и поддерживающих функций по работе с имеющимся DW.
• Будущее использование DW: готовность применять DW как полноценную платформу поддержки решений.

Типичная стадийность:

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

Выделяют ряд прикладных направлений использования DW, в частности в финансах:

Базовая сфера применения — отчётность и расчёт рентабельности. Использование DW ради одного только контроллинга оправдано лишь как первая стадия стратегии предприятия в области хранения данных.

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

DW полезен при необходимости хранения и ведения больших массивов данных о клиентах, продуктах, кампаниях — как фундамент для индивидуального маркетинга («one-to-one» маркетинг), таргетированных предложений, развёрнутой поддержки клиентов.

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

Реализация на основе DW оправдана, если задачи требуют постоянной обработки неструктурированных запросов и анализа исторических данных — структура пользователей здесь сложнее, чем в классическом call-центре.

Использование DW целесообразно при необходимости агрегировать структурированные, преимущественно числовые данные; для неструктурированной информации предпочтительнее groupware-решения. Важно отличать DW от мультимедийных БД: наличие в реляционной БД мультимедийных функций ещё не делает её хранилищем данных — нужны специфические архитектурные и модельные решения.

На практике корпоративное знание («интеллект бизнеса») всё чаще признаётся ценным активом независимо от структуры — это преимущество DW как среды управления знаниями.

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

Распространение цифровых каналов особенно в финансах предъявляет новые требования к скорости адаптации — DW позволяет детектировать динамику онлайн-транзакций в реальном времени, анализировать их как объект и как механизм оказания услуг.

DW интегрируется с онлайновыми торговыми платформами («трейдинг»), поддерживая архитектуру данных и предоставляя аналитическое сопровождение.