Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбалл (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
КХД (EDW) расшифровывается как корпоративное хранилище данных,
но, более того, это название подхода проектирования. Подход КХД
отличается материально от подхода Архитектуры Шины Хранилища Данных
(Data Warehouse Bus Architecture). КХД заключает в себе ряд связанных
тем, каждую из которых нужно индивидуально противопоставить подходу
Шины ХД. Возможно, будет полезно на момент отделить логические вопросы
от физических.
Логически оба подхода пропагандируют согласованный набор определений,
рационализирующих различные источники данных, разбросанные по организации.
В случае Шины ХД, согласованный набор определений принимает специфическую
форму согласованных измерений и согласованных фактов. В подходе
КХД согласованность кажется более бесформенной. Вы должны принять
на веру, что если у вас будет единая сильно нормализованная ER-модель
всей корпоративной информации, то вы будете знать, как согласованно
администрировать сотни или тысячи таблиц. Но, в отсутствие должной
точности, можно привести доводы в пользу того, что оба подхода пока
согласуются друг с другом. Оба подхода стремятся применить унифицирующую
связь ко всем распределённым источникам данных.
Побочной проблемой корпоративной модели данных КХД является то,
что часто эти модели являются идеализированными информационными
моделями, а не реальными моделями источников данных. Несмотря на
то, что создание идеализированной модели полезно, я видел ряд этих
больших диаграмм, которые никогда не наполняются. Я также написал
ряд статей в попытке пролить свет на соответствующие заявления о
том, что большие нормализованные модели инкапсулируют «бизнес-правила»
организации. В самом лучшем случае, нормализованные модели реализуют
НЕКОТОРЫЕ из правил ДАННЫХ (в основном, отношения многие-к-1), и
почти НИЧЕГО из того, что эксперт по бизнес-процедурам назвал бизнес-правилами.
Наименования путей соединения таблиц на ER-диаграмме редко, если
когда-либо вообще, переносится в код бэк-офисных ETL-процессов или
фронт-офисных инструментов построения запросов и генерации отчётов.
Даже если мы достигли слабого соглашения относительно того, что
оба подхода имеют одну и ту же цель согласованного представления
данных организации, как только мы погружаемся в проблемы физического
дизайна и внедрения, различия между подходами КХД и шиной ХД начинают
бросаться в глаза.
Как многие из вас знают, согласованные измерения и согласованные
факты принимают специфические формы в архитектуре Шины ХД. Согласованные
измерения – это измерения, у которых есть общие поля, и соответствующие
домены значений этих полей одинаковы. Это даёт гарантию, что вы
сможете выполнять отдельные запросы по удалённым таблицам фактов,
присоединённым к этим измерениям, и сможете слить столбцы в финальный
результат. Конечно же, это операция drill across. Я довольно много
писал о шагах, требующихся для администрирования согласованных измерений
и согласованных фактов в среде распределённых хранилищ данных. Я
никогда не видел сравнимого набора специфических рекомендаций в
подходе КХД. Я нахожу это интересным, поскольку даже в физически
централизованном КХД вы должны хранить данные в физически отдельных
табличных пространствах, а это требует прохождения через ту же логику,
что и при репликации согласованных измерений. Но, я никогда не видел
системного описания подобных процедур у сторонников подхода КХД.
Какие таблицы нужно синхронно реплицировать между табличными пространствами
и когда? Процедуры Шины ХД описывают это очень детально.
Плоская природа таблиц измерений во 2НФ при дизайне Шины ХД позволяет
нам администрировать естественную изменчивость измерения предсказуемым
способом (SCD типов 1, 2, и 3).
И снова, в сильно нормализованном мире КХД я никогда не видел описание
того, как создать эквивалент медленно изменяющихся измерений. Но,
вероятно, это потребует обширного использования временных отметок
во всех сущностях вместе с большими, нежели чем при многомерном
моделировании, усилиями по администрированию ключей. Между прочим,
подход к суррогатным ключам, который я описал для администрирования
SCD вообще говоря, не имеет ничего общего с многомерным моделированием.
В КХД корневая таблица превращённого в снежинку «измерения» должна
будет подвергаться тому же администрированию ключей в том же объёме
(с использованием либо суррогатного ключа, либо сочетания естественного
ключа и даты) с тем же самым количеством повторяющихся записей,
как и при отслеживании тех же медленных изменений в версии Шины
ХД.
Плоская природа таблиц измерений во 2НФ при дизайне Шины ХД позволяет
использовать системный подход при определении агрегатов, единственного
наиболее мощного и эффективного по затратам метода повышения производительности
большого хранилища данных. Наука приёмов многомерной агрегации тесно
связана с использованием согласованных измерений. «Съёжившиеся»
измерения агрегированной таблицы фактов являются отлично согласованными
подмножествами базовых измерений в архитектуре Шины ХД. Подход КХД,
опять же, не имеет системного и документированного подхода к обработке
агрегатов в нормализованной среде, или в предоставлении руководства
для инструментов генерации запросов или разработчикам отчётов относительно
того, как использовать агрегаты. Эта проблема связана с операцией
«drilling down», описанной ниже.
Архитектура КХД является как логически, так и физически централизованной,
что похоже на плановую экономику. Может, это звучит несправедливо,
но, на мой взгляд, этот подход имеет ту же едва различимую, но фатальную
проблему, что и плановая экономика. Вначале всё звучит замечательно,
и идеалистические аргументы трудно опровергать до начала проекта.
Но проблема заключается в том, что полностью централизованный подход
предполагает наличие идеальной информации "a priori" и
идеального принятия решений впоследствии. Несомненно, что это было
одной из основных причин упадка плановых экономик. Архитектура Шины
ХД поощряет непрерывно эволюционирующий дизайн, удовлетворяющий
специфическим критериям «грациозной модификации» схем данных, оставляющей
существующие приложения в работоспособном состоянии. Симметрия подхода
многомерного проектирования Шины ХД позволяет нам вычленить в точности
те места, куда могут быть добавлены новые или изменившиеся данные
для сохранения этого грациозного характера.
Наиболее важно, что ключевым предположением, на котором основано
большинство архитектур КХД, это то, что КХД «высвобождает» витрины
данных. Эти витрины данных часто описываются как «построенные для
ответа на бизнес-вопрос». Практически всегда это проистекает из
неуместной или преждевременной агрегации. Если витрина данных содержит
только агрегированные данные, то, естественно, будет ряд бизнес-вопросов,
на которые будет невозможно ответить. Эти вопросы часто запрашивают
не одну атомарную запись, а точный срез больших объёмов данных.
Окончательное неработающее предположение КХД это то, что если пользователи
хотят задавать какие-то из этих точных вопросов, они должны покинуть
агрегированную многомерную витрину данных и опуститься в атомарные
данные в 3НФ, располагающиеся в бэк-офисе. В этой точке зрения,
на мой взгляд, неправильно ВСЁ. Все усилия, которые мы приложили
при разработке Шины ХД идут прахом при использовании этой гибридной
архитектуры: погружение в детали через согласованные измерения к
атомарным данным; унифицированный подход к кодированию медленно
изменяющихся измерений; использование повышающих производительность
агрегатов; и праведность сохранения промежуточной области бэк-офиса
от выполнения запросов.
В любом случае, как вы, возможно, знаете, книга Data Warehouse
Lifecycle Toolkit (вставить ссылку) посвящена задаче построения
«корпоративного» хранилища данных, но в распределённом стиле и основанного
на архитектуре Шины ХД. Если вы предпочитаете почитать бесплатные
статьи на эту тему, то вот некоторые ссылки на статьи, посвящённые
предметам, обсуждающимся в этом совете, в обратном хронологическом
порядке. Вы, возможно, захотите начать читать с самой старой!
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS