Глава 1 «Введение в хранилища данных»

Аннотация

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

Ключевые слова

• данные
• хранилище данных
• большие данные
• системы поддержки принятия решений
• масштабируемость
• бизнес-аналитика

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

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

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

РИСУНОК 1.1 Иерархия информации

Данные, находящиеся внизу иерархии, представляют собой конкретные, объективные факты или наблюдения.

Примеры могут выражаться в виде утверждений, таких как «Рейс DL404 прибывает в 08:30 утра» или «LAX находится в Калифорнии, США». Такие факты сами по себе не несут внутреннего смысла, но могут быть легко зафиксированы, переданы и сохранены в электронном виде.

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

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

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

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

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

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

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

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

История хранилищ данных

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

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

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

Системы поддержки принятия решений

Для обеспечения быстрого доступа к информации, необходимой для процессов принятия решений, предприятия внедрили системы поддержки принятия решений (Decision Support Systems, DSS). Такие системы объединяют различные расширяемые и интерактивные ИТ-технологии и инструменты, которые помогают менеджерам в принятии решений путем обработки и анализа данных.

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

Для загрузки данных используются инструменты ETL (extract, transform, load — извлечение, преобразование, загрузка), предназначенные для извлечения, преобразования и загрузки данных из источников в целевые хранилища:

База данных аналитических моделей на Рисунке 1.2 наполняется процессом ETL данными из пяти источников. Затем данные агрегируются либо в процессе ETL (на этапе подготовки данных), либо при выполнении бизнес-пользователем запроса к базе данных. Бизнес-пользователи могут выполнять ad-hoc запросы и другие сложные аналитические запросы к базе данных аналитических моделей. В большинстве случаев данные уже подготовлены для их целей и содержат только релевантную информацию.

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

РИСУНОК 1.2 Система поддержки принятия решений

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

Системы хранилищ данных

Система хранилища данных (Data Warehouse, DWH) — это система поддержки принятия решений, основанная на данных. Она поддерживает процесс принятия решений на стратегическом уровне, а также операционные решения, например, аналитику в реальном времени для выявления мошенничества с кредитными картами или динамические рекомендации товаров и услуг.

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

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

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

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

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

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

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

Среда корпоративного хранилища данных

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

Следующие разделы представляют основные бизнес-требования к корпоративным хранилищам данных.

Доступ

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

Несколько предметных областей

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

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

Единая версия истины

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

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

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

Единая версия фактов

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

Ведущий автор этой книги был одним из первых специалистов в индустрии хранилищ данных, кто продвигал эту идею, особенно из-за требований к соответствию нормативным требованиям. В конечном итоге это привело к созданию концепции Data Vault, которая стала ключевым принципом в модели Data Vault 2.0 и реализуется в Raw Data Vault.

Единая версия фактов также важна с точки зрения аудита и соответствия нормативным требованиям, что будет рассмотрено в разделе 1.2.10. Позже в этой книге мы узнаем, что EDW, основанные на Data Vault, предоставляют обе версии: и единую версию истины, и единую версию фактов.

Критическая важность для бизнеса

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

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

Масштабируемость

Масштабируемость — это способность архитектуры хранилища данных адаптироваться к увеличению объемов данных и росту количества пользовательских запросов, которые необходимо обрабатывать. Архитектура должна быть построена таким образом, чтобы поддерживать добавление новых данных — не только увеличивающихся объемов, но и более сложных данных. Если объем данных превышает возможности оборудования, должна быть возможность распределять хранилище данных между несколькими машинами и полностью использовать возможности добавленного оборудования. Этот концепт называется массово-параллельной обработкой (MPP, Massively Parallel Processing). Если архитектура не является масштабируемой, добавление нового оборудования либо не оказывает никакого эффекта, либо дает лишь минимальное улучшение после достижения определенного уровня расширения.

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

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

Большие данные (Big Data)

Big Data — это не просто «много данных» или «больше данных, чем я могу обработать». Мы определяем Big Data по трем характеристикам:

• Объем (Volume)
• Скорость (Velocity)
• Разнообразие (Variety)

Первая характеристика — это объем данных Volume. Часто под Big Data подразумевают значительно больший объем данных, чем тот, с которым пользователь привык работать. Однако это понятие субъективно: Big Data для одного человека или компании может означать 1 ГБ сырых данных, но это будет считаться малым объемом для того, кто загружает терабайты или даже петабайты данных.

Загрузка данных в режиме реального времени предъявляет особые требования, и, соответственно, определение Big Data в этом случае отличается от определения при загрузке данных ночными пакетами или в режиме, близком к реальному времени (near real-time, когда данные из операционных систем доступны в хранилище данных в течение, как правило, 15 минут).

Определение Big Data также зависит от доступного оборудования хранилища данных.

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

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

Третья характеристика — разнообразие Variety. Big Data часто не имеют единой структуры. Структура данных может изменяться со временем или вообще отсутствовать, как в случае неструктурированных данных (например, текстов, мультимедиа).

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

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

Поскольку объем доступных данных постоянно растет, архитектура хранилища данных должна не только масштабироваться (volume), но и эффективно обрабатывать скорость поступления данных (velocity) и их разнообразие (variety).

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

Это создает дополнительные проблемы для Big Data, поскольку данные постоянно поступают в сеть и выходят из нее. Чтобы их проанализировать, их необходимо собирать, объединять и агрегировать — в некоторых случаях в реальном времени.

Это повышает требования к архитектуре и планированию Big Data и подводит нас к вопросам производительности, которые рассматриваются в следующем разделе.

Проблемы производительности

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

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

Производительность систем хранилищ данных зависит от того, как система управления базами данных (СУБД) хранит данные на диске. Данные сохраняются в страницах фиксированного размера. Например, Microsoft SQL Server выделяет 8 КБ дискового пространства на каждую страницу. Каждая страница содержит несколько записей определенной таблицы. Чем шире таблица (чем больше у нее колонок), тем меньше строк может поместиться на одной странице.

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

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

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

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

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

Оба этих метода критически важны для Data Vault 2.0 и повлияли на изменения в моделировании Data Vault по сравнению с первой версией (Data Vault 1.0).

Сложность

Системы хранилищ данных часто сталкиваются с проблемами сложности из-за множества бизнес-требований. Технические сложности возникают в трех областях:

• Проблемы источников данных (sourcing issues).
• Проблемы трансформации данных (transformation issues).
• Проблемы загрузки в целевые системы (target issues).

Проблемы источников данных

Эти проблемы связаны с системами, из которых извлекаются данные. К типичным проблемам относятся:

• Ограниченная доступность систем-источников.
• Использование межсистемных объединений (joins), фильтрации или агрегации.
• Проблемы с индексами в исходных данных.
• Отсутствие ключей источника или даже полных наборов данных.
• Некачественные или вышедшие за допустимые пределы данные.
• Сложность структуры данных в системе-источнике.
• Нагрузка на CPU, RAM и диск в системе-источнике.
• Блокировки транзакционных записей.

Проблемы трансформации данных

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

• Очистка данных.
• Управление качеством данных и их согласование.
• Объединение (joins), консолидация, агрегация и фильтрация.
• Присвоение последовательностей, что часто препятствует параллельной обработке.
• Коррекция типов данных и обработка ошибок.
• Проблемы с сортировкой данных, такие как необходимость в больших кешах, частые переполнения диска и работа с большими ключами.
• Применение бизнес-правил непосредственно при трансформации данных.
• Множественные источники и целевые системы в одном потоке данных.
• Узкие места в трансформации (transformation bottlenecks).

Проблемы загрузки в целевые системы

Эти проблемы возникают при загрузке данных в хранилище и включают:

• Отсутствие оптимизации базы данных.
• Обновление индексов, что может приводить к взаимоблокировкам (deadlocks).
• Одновременное выполнение INSERT, UPDATE и DELETE в одном потоке данных, что замедляет обработку из-за необходимости соблюдать определенный порядок выполнения.
• Загрузка нескольких целевых систем одновременно.
• Широкие таблицы, как обсуждалось в разделе 1.2.8.
• Отсутствие контроля над разбиением данных (partitioning) в целевой системе.

Основная причина проблем

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

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

Аудит и соответствие требованиям

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

• Разработчики хранилища данных стремятся выявлять возможные ошибки и понимать поток данных в системе.
• Ценность данных зависит от их источника или возраста. Эта информация может использоваться в бизнес-правилах.
• Соответствие нормативным требованиям (compliance) требует отслеживания потока данных и процессов, если информация используется как основа для бизнес-решений. Должно быть четко видно, откуда поступили данные и когда они были загружены в хранилище.

Однако Inmon приводит аргументы против добавления аудита в хранилище данных:

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

С нашей точки зрения, аудит должен ограничиваться ответами на такие вопросы, как:

• Откуда был извлечен этот конкретный набор данных?
• Когда данные были извлечены?
• Какой процесс отвечал за извлечение данных?
• Где эти данные использовались?

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

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

Чтобы упростить аудит, процессы хранилища данных должны быть простыми и понятными.

Затраты

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

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

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

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

Основные факторы затрат

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

Основные затраты включают:

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

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

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

Снижение затрат за счет гибкости

Бизнес-требования не должны быть встроены в процесс загрузки хранилища данных, их следует переносить на уровень загрузки витрин данных (data marts) — ближе к конечным пользователям.

Это позволяет:

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

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

Другие бизнес-требования

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

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

В таких подходах обычно выделяют четыре фазы:

1. Определение требований к хранилищу данных.
2. Архитектурное планирование и проектирование хранилища данных.
3. Разработка хранилища данных.
4. Тестирование хранилища данных.

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

Изменения в существующих структурах не должны делать недействительными уже хранящиеся данные или используемые приложения. Одним из главных преимуществ гибких методов является способность быстро реагировать на изменения в бизнесе. Более подробно этот вопрос рассматривается в главе 3 — Методология Data Vault 2.0.

Инструменты для работы с данными

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

• Системы отчетности,
• Анализаторы запросов,
• OLAP-браузеры (онлайн-аналитическая обработка),
• Инструменты для анализа данных (data mining) и другие.

Примером является Microsoft SQL Server 2014, который содержит эти инструменты «из коробки».

Сохранение знаний в команде

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

Решения для этого включают:

• Хорошо документированную систему хранилища данных,
• Легко понятный дизайн,
• Использование BI-решений (бизнес-аналитики) от крупных вендоров.

Например, решения Microsoft широко известны в отрасли и поддерживаются другими вендорами и консалтинговыми компаниями.

Роль Data Vault 2.0

Все вышеперечисленное является основными компонентами Data Vault 2.0 и его инноваций.

DV2.0 охватывает Big Data, NoSQL, производительность, гибкость команд, сложность и множество других вопросов. Он определяет стандарты и передовые практики для моделирования, реализации, методологии и архитектуры хранилищ данных.

Введение в Data Vault 2.0

Data Vault представляет собой систему бизнес-аналитики. Полное название системы Data Vault — Common Foundational Warehouse Architecture. Эта система включает в себя различные аспекты, связанные с проектированием, реализацией и управлением хранилищем данных.

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

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

Эти компоненты:

• Data Vault 2.0 Modeling – Изменения модели для повышения производительности и масштабируемости.
• Data Vault 2.0 Methodology – Использование лучших практик Scrum и Agile.
• Data Vault 2.0 Architecture – Интеграция с NoSQL и Big Data-системами.
• Data Vault 2.0 Implementation – Автоматизация на основе шаблонов, генерация на уровне CMMI 5.

Каждый из этих компонентов играет ключевую роль в общем успехе проекта корпоративного хранилища данных. Они сочетаются с известными в отрасли и проверенными временем методами, включая CMMI (Capability Maturity Model Integration), Six Sigma, TQM (Total Quality Management) и PMP (Project Management Professional).

Основные особенности Data Vault 2.0

• Data Vault 2.0 Modeling теперь включает изменения, позволяющие моделям беспрепятственно работать с NoSQL и Big Data-системами.
• Data Vault 2.0 Methodology ориентирована на 2-3-недельные спринты с адаптациями и оптимизациями для повторяющихся задач хранилища данных.
• Data Vault 2.0 Architecture включает NoSQL, потоковую обработку данных в реальном времени и Big Data-системы, работающие с неструктурированными данными.
• Data Vault 2.0 Implementation делает акцент на автоматизацию и шаблонные методы для экономии времени, сокращения ошибок и повышения производительности команды, работающей с хранилищем данных.

Архитектура хранилища данных

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

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

Две типичные архитектуры таких хранилищ будут описаны в следующих разделах.

Типичная двухслойная архитектура

Кимбалл представил широко используемую двухслойную архитектуру.

В этой архитектуре, представленной на Рисунке 1.3, есть только два уровня, которые являются частью самой системы хранилища данных.

Этап загрузки данных

Сырые данные из источников загружаются в промежуточную (stage) область.
Цель этого этапа — создать точную копию всех данных, которые должны быть загружены в хранилище данных.

Основное назначение промежуточной области:

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

Промежуточная область необходима в случаях, когда:

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

Этап загрузки в хранилище данных

После загрузки в stage, Кимбалл предлагает перемещение данных в хранилище.
Это хранилище данных построено на основе размерной модели и состоит из витрин данных (data marts), представляющих бизнес-процессы.

Эти витрины объединяются с помощью конформных измерений (conformed dimensions).
Такой подход был впервые предложен Кимбаллом в 1996 году.

Размерная модель Dimensional Modeling

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

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

Мы обсудим размерное моделирование в главе 7 – Dimensional Modeling.

Приложения для доступа к данным используют размерную модель, чтобы:

• Предоставлять пользователям информацию.
• Позволять проводить гибкий (ad-hoc) анализ.

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

✅ Преимущество: Проще построить размерное хранилище на основе исходных данных по сравнению с другими архитектурами.

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

Невозможно повторно использовать существующие ETL-пакеты.

Типичная трехслойная архитектура

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

Рисунок 1.4 Хранилище данных Инмона

Эта архитектура была представлена Инмоном и включает атомарное хранилище данных,
которое часто реализуется в виде нормализованного операционного хранилища данных (ODS).
ODS располагается между промежуточной областью (staging area) и размерной моделью.

Описание слоев трехслойной архитектуры

Промежуточная область (Stage Area)

• Работает так же, как в двухслойной архитектуре.
• Служит для извлечения данных из источников перед загрузкой в хранилище.

Хранилище данных (Data Warehouse / ODS)

• Содержит сырые данные.
• Моделируется в третьей нормальной форме (3NF).
• Интегрирует все данные предприятия, но при этом сохраняет физические таблицы исходных систем.
• Функционирует аналогично большой операционной базе данных.

Размерная модель (Dimensional Model / Data Marts)

• Основана на нормализованных бизнес-данных.
• Бизнес-пользователи могут анализировать данные через предметно-ориентированные витрины данных (data marts).
• Похожая схема использовалась в двухслойной архитектуре.

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

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

Недостатки трехслойной архитектуры

• Усложнение построения хранилища данных. Требуется больше ресурсов и времени на обработку данных.
• Проблемы с изменением модели данных. Если многие витрины данных зависят от операционного хранилища (ODS), изменение модели данных может создать дополнительные сложности.

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