Как построить хранилище данных

Инструменты для создания Хранилищ данных

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

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

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

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

Универсальные инструменты для разработки DWH

Хранилища данных строятся на одной из трех платформ, или их совокупности:

Реляционные СУБД (DB2, MS SQL, Oracle и т.д.),
Специальные платформы (Sybase IQ, RedBrick, Teradata и т.д.),
OLAP-серверы (Hyperion Essbase, IBM OLAP Server, MS Analysis Services, Oracle Express и т.д.).

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

CASE-системы, предназначенные для проектирования специфических реляционных схем DWH — «звезда» и «снежинка».
Системы для управления метаданными.
Системы для извлечения, очистки и загрузки данных.
Системы для выполнения запросов, визуализации данных и генерации отчетов.

Так продукт компании Sybase «Warehouse Studio» состоит из CASE-инструмента для проектирования реляционной или многомерной базы данных Хранилища WarehouseArchitect, системы управления метаданными Warehouse Control Center, системы импорта, очистки и загрузки данных PowerStage, системы визуализации данных и генерации отчетов InfoMaker. При этом для хранения метаданных предлагается СУБД Sybase Adaptive Server Enterprise/Anywhere, а для хранения данных — произвольная РСУБД или специальная СУБД для Хранилищ данных Sybase IQ, особенностью которой является одновременное компактное хранение как атомарных, так и агрегированных данных.

Рис. 1 Интерфейс проектирования структуры DWH системы Sybase Warehouse Architect

Платформа для создания Хранилищ данных Data Warehouse Framework от корпорации Microsoft включает в себя MS SQL Server для реляционной составляющей и хранения метаданных в специальном репозитории, MS Analysis Servises/MS OLAP Server для хранения агрегированных данных, MS Data Transformation Services для извлечения и загрузки данных, MS Pivot Table для визуализации данных.

Компания из Сантк-Петербурга Digital Design разработала свой набор инструментов Data Vision, интегрирующий платформу MS Data Warehouse Framework и предоставляющую единый интерфейс для проектирования, администрирования и эксплуатации гибридных Хранилищ данных.

Система Warehouse Builder корпорации Oracle представляет собой интегрированную среду для проектирования БД, хранения метаданных, маппинга источников и приемников данных, описания правил преобразования данных при загрузке. В сочетании с СУБД Oracle 8i, OLAP-клиентом Oracle Discoverer эта система позволяет построить законченное Хранилище данных на основе продуктов Oracle.

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

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

Специализированные Хранилища данных

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

Корпорация SAS предлагает свою систему CFO Vision, которая позиционируется как система финансовой консолидации данных и выпуска отчетов. Система основана на использовании технологий финансового хранилища данных и OLAP. В качестве платформы используется OLAP-сервер SAS, или СУБД третьих фирм. Как и в универсальных системах в состав CFO Vision входят инструменты сбора, очистки и загрузки данных, управления метаданными, многомерная БД. Отличие состоит в том, что в системе заранее реализованы стандартные для финансовых систем измерения такие как «Организация», «Валюта», «Счет», «Рынок», «Продукция», «Время». Кроме этого в интерфейсах, без программирования могут быть созданы дополнительные измерения. В систему встроены алгоритмы, реализующие основные финансовые законы и правила консолидации. Для внедрения финансового Хранилища данных требуется описать бизнес-модель предприятия, настроить процедуры импорта данных, правила консолидации и отчеты. Кроме сбора финансовых данных из подразделений и выпуска корпоративной отчетности система позволяет выполнять финансовое планирование, управление расходами и различные виды анализа: анализ продаж, анализ клиентской базы и т.д.

Sybase предлагает продукт Industry Warehouse Studio — интегрированный набор приложений, моделей данных и инструменты для быстрого создания Хранилища данных предприятия на основе модели подобного предприятия. Так же как и SAS, Sybase поставляет весь набор инструментов, необходимых для настройки и эксплуатации Хранилища данных. Особенностью является то, что в комплект входит библиотека готовых моделей данных, методологий и законченных приложений, построенных по технологии Хранилищ данных для различных отраслей. Комплект включает следующие приложения:

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

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

Российская компания Intersoft Lab (www.iso.ru) поставляет систему Контур Корпорация — студию для создания финансовых Хранилищ данных.

Контур Корпорация — специализированная студия для построения финансовых DWH

Система позволяет построить Хранилище данных на платформе MS SQL Server в ROLAP- или HOLAP-архитектуре. Система предоставляет технологию быстрого создания корпоративного Хранилища данных и управленческих приложений, использующих эти данные. Она обеспечивает консолидацию финансовых и других деловых данных, вычисления производных финансовых показателей, предоставляет инструменты выпуска отчетов и «заготовки» для создания системы бюджетирования многофилиальной организации или банка.

Также как и в SAS CFO Vision в системе заранее реализованы основные бизнес-объекты, которые, как правило, создаются в финансовых Хранилищах данных, но их перечень и структура несколько отличаются. В системе существуют «банки данных», однотипные объекты, которые одновременно играют роль специализированных информационно-поисковых систем и измерений для фактов — счетов, финансовых и количественных показателей, документов. В рамках каждого банка данных можно настроить множество типов объектов и их реквизиты. Это Субъект (Клиент, Контрагент, Конкурент, Сотрудник и т.д.), Организационно-штатная структура (Филиал, Отдел, Должность и т.д.), Бизнес-Операция (Направление деятельности, Продукт, Операция), Финансовый инструмент (Валюта, Ценная бумага и т.д.), Форма документа. Для описания модели финансового учета может быть создано неограниченное количество Планов счетов, показателей, бюджетов.

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

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

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

Как и в системе SAS CFO Vision работа данными Хранилища во встроенных интерфейсах системы выполняется методом углубления (drill-down), что позволяет в процессе анализа спуститься от обобщенных финансовых показателей корпорации до аналитических счетов и проводок любого филиала.

Для выпуска отчетов и анализа данных Контур Корпорация оснащена встроенными специализированными интерфейсами, генераторами отчетов, интегрирована с приложениями MS Office и OLAP-клиентом Контур Стандарт, предоставляет API для других систем класса front-end и OLAP-сервер.

Система имеет объектную оболочку, которая реализована на языке Python. Каждому объекту Хранилища данных соответствует объект библиотеки, а каждому объекту библиотеки — XML-документ для обмена данными, метаданными и удаленного выполнения операций над данными. В сочетании с OLE DB и COM-интерфейсами это позволяет быстро создавать динамические страницы на корпоративном сайте с доступом к Хранилищу данных для поиска информации, выпуска отчетов и анализа.

Рис. 4 Работа с метаданными в системе Контур Корпорация

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

Также как и в Sybase Industry Warehouse Studio, для Контур Корпорации поставляются готовые приложения. Сегодня это два приложения для коммерческих банков: «Управление филиалами» и «Бюджет». Учитывая высокую степень готовности этих приложений к эксплуатации в банках, можно говорить о тиражном Хранилище данных. Опыт показывает, что внедрение системы в эксплуатацию со стандартными приложениями занимает от 1 до 6 месяцев в зависимости от количества индивидуальных настроек и доработок приложений.

Автор: В.Некрасов

Источник: «RM-Magazin», 2002, №1

Успешное Хранилище данных: архитектурные решения

Методика построения Хранилищ данных из простой теоретической дисциплины превратилась в сложную науку, полную вариаций и направлений. Если в теории классическое Хранилище данных предприятия (Enterprise Data Warehouse, EDW) рисуется в черно-белом цвете, то реальная реализация систем Хранилищ и витрин данных состоит из всевозможных оттенков серого. Если раньше мы знали только о EDW, то теперь нам предлагают постепенно развиваемую витрину данных (incremental Architected Data Mart, ADM), Распределенное Хранилище данных/ Распределенная витрина данных (Distributed Data Warehouse/ Distributed Data Mart, DDW/DDM), Объединенное Хранилище данных/ Объединенная витрина данных (Federated Data Warehouse/ Federated Data Mart, FDW\FDM). Выбрать оптимальную систему из этого богатейшего набора архитектурных решений, не запутавшись в аббревиатуре и хитроумных подходах, — не такая простая задача. В этой статье я попытаюсь кратко рассмотреть основные типы архитектур и осветить различные способы построения системы Хранилища данных, сделав акцент на двух главных подходах: «сверху вниз» (top down) и «снизу вверх» (bottom up).

Классическое Хранилище данных

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

Рис. 1. Система классического Хранилища данных

Достоинствами архитектуры классического Хранилища данных являются:

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

Недостатки такого архитектурного решения:

Реализация требует больших затрат.
Высокая ресурсоемкость.
Потребность в системах и ресурсах в масштабе всего предприятия.
Рискованный сценарий («все поставлено на карту»).

Системы объединенных Хранилищ данных/ витрин данных

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

Система объединенных Хранилищ данных/ объединенных витрин данных характеризуется совместным использованием общих информационных точек, устраняя, таким образом, избыточность и гарантируя достоверность информации по всей организации (см. рисунок 2).

Рис. 2. Системы объединенных Хранилищ данных/ витрин данных

Достоинства системы объединенных Хранилищ данных/ объединенных витрин данных:

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

Недостатки такого архитектурного решения:

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

Непроектируемые витрины данных

Появление непроектируемых витрин данных (Non-Architected Data Marts) объясняется, прежде всего, сложностями, связанными с реализацией систем EDW и FDW. Грязные и быстро получаемые наборы данных не подвергаются очистке и, следовательно, не могут использоваться для дальнейшей интеграции с любыми другими источниками данных систем Хранилищ данных. Очень быстро они превращаются в устаревшие системы, отдельно стоящие информационные «дымоходы», которые только добавляют проблемы, а не решают их. Для этих систем характерны многочисленные процессы извлечения, множество бизнес-правил, недостоверность информации (см. рисунок 3).

Рис. 3. Система непроектируемых витрин данных (LegaMart)

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

Быстрота.
Низкая стоимость.

Недостоверная информация.
Многочисленные процессы извлечения.
Многочисленные бизнес-правила.
Множественная семантика.
Повышенная сложность при интеграции.

Система постепенно развиваемых витрин данных

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

Рис. 4. Система постепенно развиваемых витрин данных

Достоинства постепенно развиваемых витрин данных:

Общая семантика и бизнес-правила.
Единый набор процессов извлечения.
Выполнимый масштаб.
Пошаговая природа.

Наиболее эффективны при использовании инструментального средства класса предприятия.
Необходимость в Архитектуре витрин данных предприятия (Enterprise Data Mart Architecture, EDMA).
Требуется согласованность с EDMA по всем IT-группам.

Методы построения успешного Хранилища данных предприятия

Существует два основных способа построения Хранилища данных предприятия: «сверху вниз» (top down) и «снизу вверх» (bottom up). При подходе «сверху вниз» Хранилище данных разрабатывается, проектируется и строится итерационным способом. При методе «снизу вверх» создается ряд постепенно развиваемых витрин данных, которые формируют основу результирующей системы Хранилища данных предприятия.

Подход «сверху вниз»

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

Рис. 5. Поэтапная разработка Хранилища данных предприятия

Рис. 6. Разработка Хранилища данных предприятия по методу «сверху вниз», фазы 1 и 2

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

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

Основная проблема заключается во «все пересекающей» природе системы EDW. Из самого названия, Хранилище данных «предприятия», следует, что IT-специалисты должны задействовать все политические, функциональные, ведомственные, юридические, организационные и прочие аспекты в рамках всей организации. Успешное продвижение по этому «минному» полю требует недюжинной «политической» прозорливости, которое не так часто присутствует в группе разработки EDW. Прибавьте сюда требование к исключительной гибкости этой команды: ориентированность на пользователя на все 100%, способность к постоянным изменениям и умение бесконечно и беспрерывно перепродавать и заново продвигать систему Хранилища данных, и вам станет понятно, что все эти испытания под силу далеко не всем IT-группам.

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

Достоинства подхода «сверху вниз»:

Скоординированная среда.
Единственная точка управления и развития.

«Все пересекающая» природа проекта предприятия.
Аналитический паралич.
Управление масштабом.
Время до появления на рынке.
Риск и подверженность внешнему воздействию.

Подход «снизу вверх»

Этот подход предназначен для реализации огромного потенциала, присущего Хранилищу данных, с одновременным устранением недостатков, свойственных подходу «сверху вниз». При данном подходе разрабатывается Архитектура витрин данных предприятия (Enterprise Data Mart Architecture, EDMA) для обеспечения контекста работ по развитию. Несмотря на то, что в этом случае рассматривается масштаб всей системы на высоком уровне, подход «снизу вверх» не так детален, как архитектура системы Хранилища данных предприятия, что позволяет избежать «аналитического паралича». По завершении EDMA, выбирается начальная область бизнес проблем для первой постепенно развиваемой витрины данных. Архитектура витрин данных предприятия расширяется на эту область, чтобы включить полный диапазон деталей, необходимый для проектирования и разработки этого ADM. На последующих этапах происходит заполнение архитектуры витрин данных предприятия, пока отделы и организация не готовы построить Хранилище данных предприятия (см. рисунок 7).

Рис. 7. Итерационная разработка Хранилища данных предприятия по методу «снизу вверх»

Благодаря этому подходу отделы могут разрабатывать методы и технологии, необходимые для организации Хранилища данных в условиях меньшего риска и меньшей подверженности внешнему воздействию, чем в случае проекта полномасштабного Хранилища данных предприятия. Кроме того, ADM разрабатывается быстрее по сравнению с системами EDW. Как правило, первая постепенно развиваемая витрина данных создается за 6-9 месяцев, а на реализацию первой стадии системы Хранилища данных предприятия может уйти год-полтора. Эта скорость выхода на рынок особенно важна, когда нужно показать возврат инвестиций и истинную ценность Хранилище данных для организации.

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

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

Достоинства этого подхода:

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

Возможное «проклятие успеха» (полный успех подавляет ресурсы).
Необходимость в координировании многочисленных групп.
Необходимость в Архитектуре витрин данных предприятия для интеграции постепенно развиваемы[ витрин данных.

Выбор приемлемого метода

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

Начните с определения типа своей организации: «Думай глобально, действуй глобально» (Think Globally, Act Globally), «Думай глобально, действуй локально» (Think Globally, Act Locally), «Думай локально, действуй локально» (Think Locally, Act Locally) (см. рисунок 8). Ранние реализации Хранилищ данных находились в области «Думай глобально, действуй глобально». Такие организации стремятся к получению преимуществ в конкурентной борьбе и повышению производительности за счет колоссальных инвестиций в технологии, сопряженные со значительным риском. Эта группа организаций приняла идеи теоретиков, авторитетных лиц в этой области и некоторых поставщиков программных средств, которые полагали, что рынок Хранилищ данных будет думать и поступать как эти клиента. Однако, с развитием рынка выяснилось, что огромное большинство его игроков находится в лагере «Думай глобально, действуй локально». Так, появление корпорации Microsoft с ее крайне низкими ценовыми показателями и пакетами решений должно значительно расширить этот сегмент рынка. Несмотря на то, что компонент «Думай глобально, действуй глобально» никогда не покинет рынка — с учетом астрономической стоимости бюджета, за которые борются поставщики программного обеспечения, средний слой рынка неизбежно станет доминирующим в сфере Хранилищ данных.

Рис. 8. Выбор приемлемого метода.

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

Рис. 9 Определение факторов оценки принятия решения

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

Заключение

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

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

Автор: Дуглас Хэкни (Douglas Hackney)

Как построить идеальное хранилище данных

Может показаться, что в последние годы многое изменилось в сфере сбора и хранения данных. Такие вещи, как NoSQL, «Big Data», различные графические и потоковые технологии изменили “ландшафт”, но “фундамент” остался прежним.

На моей текущей работе мы используем Amazon Redshift в качестве хранилища данных. Однако, если бы мы построили традиционное хранилище данных, используя Oracle или построили “озеро данных”, используя Hadoop — суть осталась бы прежней.

Вся суть сводится к этапу предварительной обработки и трем отдельным уровням(схемам, если используете Amazon Redshift): Staging, Master и Reporting. В этой статье я подробно о них расскажу.

Предварительная обработка

К сожалению, не все данные создаются в одинаковых условиях, но, тем не менее, это данные, и поэтому они несут в себе ценность.

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

Обработка включает, но не ограничивается этим:

Конвертирование Excel-таблиц в формат CSV
Парсинг JSON данных (Мы обрабатываем каждый объект одной строки одного столбца, и позволяем Redshift парсить его. Но ничего не мешает вам самим парсить объекты, если вам это нравится.)
Очистка поврежденных или ошибочных файлов данных

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

Например, можно поместить все файлы в Amazon S3. Он универсальный, дешевый и совместим со многими технологиями. Amazon S3 отлично совместим с Amazon Redshift.

Staging

“Staging” уровень— это основа для любого хранилища данных.

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

“Staging” уровень— это место, куда вы отправляете файлы из разных источников, например с Amazon S3, и временно храните, пока они не будут обработаны дальше.

Как погрузочная площадка на настоящем складе (хранилище). Место, где выгружают грузы, не является их конечным пунктом назначения. Это просто промежуточная зона.

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

Я считаю, что данные, находящиеся на “Staging” уровне, практически не должны обрабатываться (на стадии предварительной обработки вы можете внести некоторые изменения, но, в целом, данные должны остаться нетронутыми). Можете оставить нетронутыми исходные имена столбцов и таблиц. Это облегчит отслеживание проблем в источнике при поступлении сообщений об ошибке.

Staging уровень нужно рассматривать как промежуточный.

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

Это последний уровень, на котором данные должны оставаться практически необработанными. Далее, данные должны соответствовать стандартам хранилищ данных.

Master

Уровень “Master” — это место, где входящие данные обретают реальную форму.

Schema master должна содержать правильно смоделированные таблицы с соответствующими им названиями. Названия столбцов должны быть скорректированы в соответствии с их типами данных.

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

При перемещении данных из уровня “Staging” в “Master”, следует выполнить такие вещи, как:

Стандартизировать все форматы дат и часовых поясов в один формат (если необходимо)
Округлить десятичные дроби
Подправить строки, возможно где-то нужно исправить употребление заглавных букв или удалить начальные и конечные пробелы
Стандартизировать адреса в один формат
Разделить данные на несколько столбцов или извлечь их из JSON

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

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

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

Для инженера данных это является конечной целью.

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

Reporting

Основная работа выполнена. Мы подготовили, загрузили, смоделировали и очистили данные. Теперь мы хотим показать всему миру наши новенькие блестящие данные. Тут на сцену выходит уровень “Reporting”.

На этом этапе, если вы используете хранилище данных типа “row-based” как в Oracle — можете дополнительно создать таблицу фактов и витрину данных. Это вполне разумный сценарий использования для уровня “Reporting”, так как вы можете прикрепить любой достойный инструмент отчетности и в итоге будете готовы ко всему.

Тем не менее, некоторые из этих традиционных методов хранения данных имеют эффективность только с учетом хранения “row-based” хранилищ в Oracle. Эти системы эффективны при объединении данных, но при строках с множеством столбцов они неэффективны, главным образом из-за “row-based” подхода, при котором мы имеем дело со всей строкой, даже если для запроса требуется всего несколько столбцов.

Если вы используете хранилище данных типа “columnar-based”, как Amazon Redshift — ваш подход должен быть иным. Redshift предпочитает широкие таблицы и денормализацию — композицию нескольких таблиц в одну.

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

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

Например, вы хотите составить отчет о своих клиентах. У вас есть таблица клиентов, таблица заказов, маркетинговая таблица и некоторые данные веб-аналитики на уровне “Master”.

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

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

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

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

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

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

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

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

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

Итог

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

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

Business DWH (DataWareHouse): аналитическое хранилище данных

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

Хранилище может содержать:

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

Чтобы спроектировать хранилище данных (DWH, DataWareHouse),

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

оно строится для BI системы;
для сотрудников для формирования своих отчетов;
общее решение для двух вариантов.

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

Далее отталкиваться от этого и проектировать систему. Делать сразу для всех не получится: отчеты будут работать правильно и приемлемо (по времени), если хранилище заточено на работу с ними. В случае с BI, в некоторых системах мы можем переложить часть ETL (процесс Extract-Transform-Loading) на сторону BI, но это зависит от выбранной системы, например, у Qlik свой мощный ETL, а Tableau не умеет делать сложных преобразований.

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

В случае, если это для отчетов пользователей – то нужно понимать, какие запросы будут чаще всего делаться к хранилищу и затачивать его на эти конкретные запросы (80% всех запросов должны отрабатываться оптимально, 20% — нет, но они должны быть редкими)

В случае, если для обоих вариантов – все рассчитывается на уровне хранилища. BI – это просто инструмент визуализации (но вопрос зачем двойная отчетность).

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

Например: количество чеков может быть аддитивным и неаддитивным; остатки – нужны движения или предрассчитанные остатки, какой период нужен, частота обновления и т.д.

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

Построение хранилища данных:

Разработка Устава Проекта;
Создание на корпоративном web-портале (или иной web-системе) узла Проекта и формирование структуры web-узла:
- библиотека бизнес-требований и методик;
- раздел Протоколов рабочих совещаний, текущих задач;
- подраздел обсуждений рабочих вопросов (возможно, в виде форума, трекинга);
- разделы документации по хранилищу данных, витринам, OLAP-кубам;
- система знаний (wiki);
- библиотека регламентов;
- раздел обучения, web-касты;
- и другие разделы».
Сбор фрагментарных знаний о бизнес-процессах (БП) компании и метриках посредством проведения серий интервью с ключевыми бизнес-сотрудниками, экспертами. Формализация БП в виде укрупненных графических схем (например, BPMN-нотация);
Получение доступов к учетным системам (желательно к копиям; доступ как на чтение данных на уровне СУБД, так и просмотру данных через графический интерфейс пользователя);
Сбор и обсуждение методик, реализованных в существующих регламентных/управленческих отчетах;
Формулирование требований/ обсуждение методологий для новых/желаемых регламентных/управленческих отчетов;
Систематизация бизнес-требований (по результатам п.п 3, 5, 6) к составу атрибутов данных, которые должны быть отражены в хранилище данных;
Построение/актуализация и описание логических моделей учетных систем — источников данных для DWH. (возможно, модели уже имеются, хотя чаще нет);
Описание/актуализация физических моделей (построение ER-диаграмм) учетных систем — источников данных для DWH. (возможно, модели уже имеются, хотя чаще нет);
Анализ и формализация бизнес-требований к составу атрибутов данных (по п.п. 7, 8, 9), которые должны быть отражены в хранилище данных;
Подготовка технологической площадки для BI: сервер разработки, тестирования, производственного; установка серверного и прикладного программного обеспечения;
Разработка (возможно реинжиниринг существующих) процедур по извлечению необходимых данных (п. 10) из учетных систем в буферные таблицы (stage area); наполнение буферных таблиц;
Профилирование данных (по п.12), извлекаемых из учетных систем; систематизация статистики по метаданным и данным учетных систем;
Разработка логической модели хранилища данных;
Разработка структуры физической модели хранилища данных;
Разработка концептуальной схемы, подходов ETL-процессов по загрузке данных из учетных систем в хранилище данных;
Разработка карты мэппингов (поля source —> поля target);
Технологическая реализация (программная разработка) ETL/ELT -процессов по перегрузке данных справочников из учетных систем в таблицы измерений (dimensions) хранилища. (Выполняется поэтапно по предметным областям бизнеса);
Разработка процедур первичной/критической очистки/дедубликации данных справочников (совместно с п.18) [Проект НСИ (MDM) выполняется отдельным проектом/ подпроектом];
Технологическая реализация (программная разработка) ETL/ELT -процессов по перегрузке данных из учетных систем в таблицы фактов (fact table, factless table) хранилища. (Выполняется поэтапно по предметным областям бизнеса);
Тестирование:
- контроль сходимости итогов по данным в учетной системе с итогами по данным таблиц хранилища;
- скорости исполнения полного ETL-цикла»;
Доработка п.п. 18, 19, 20 по выявленным ошибкам, замечаниям по результатам работ п. 21;
Разработка структур витрин данных (агрегатных денормализованных таблиц/представлений). Выполняется поэтапно по предметным областям бизнеса;
Разработка ETL/ELT-процедур по обновлению витрин данных, расчету производных показателей (обогащение витрин данными);
Тестирование:
- контроль сходимости итогов по данным витрин с итогами по данным учетных систем и итогами по данным таблиц хранилища;
- скорости исполнения цикла обновления витрин данных»;
Разработка документации по хранилищу данных;
Разработка документации по витринам данных;
Выработка и согласование требований к аналитическим OLAP кубам (перечень измерений, метрик, доп. действий, разграничение прав доступа);
Разработка структур аналитических OLAP кубов, процедур обновления данных в кубах. Выполняется поэтапно по предметным областям бизнеса;
Тестирование аналитических кубов;
Подготовка, развёртывание инфраструктуры для публикации отчётов (репортинг, ad-hoc отчеты, OLAP) на web-портале (например, MS Sharepoint 2010 EE 64x + MS Reporting Services, возможно Gognos 10.х);
Разработка документации по аналитическим кубам, публикация документации на web-портале в системе знаний;
Разработка регламентных/управленческих отчётов (по п.п. 5, 6);
Публикация и систематизация регламентных/управленческих отчётов на корпоративном web-портале;
Обучение бизнес-пользователей интерактивному пользованию OLAP-кубами; выявление/формирование проактивных пользователей (power users);
Бизнес-пользователи (по возможности) самостоятельно формируют отчеты (по результатам п. 35); приемка и публикация отчетов осуществляется по согласованию с IT-аналитическим подразделением (возможно на первых порах).