Совет №32
Выполняем работу на этапе извлечения данных
Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбалл (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
Наша миссия дизайнеров хранилища данных заключается в наиболее
эффективной публикации данных. Это означает перевод данных в формат
и в схему, наиболее лёгкие для использования конечными пользователями
и разработчиками приложений.
В бэк-офисе нашего хранилища данных мы должны противостоять нашим
естественным минималистским тенденциям, когда мы готовим данные
для потребления конечными пользователями и разработчиками приложений.
Во многих важных случаях мы должны взвешенно искать компромисс между:
- возрастающей бэк-офисной обработкой и
- возрастающими требованиями к фронт-офисному пространству для хранения
взамен на:
- симметричные предсказуемые схемы, доступные для понимания конечными
пользователями,
- меньшую сложность приложений и
- улучшенную производительность запросов и отчётов.
Поиск этих компромиссов должен быть явной целью проектирования
для архитектора хранилища данных. Хороший архитектор хранилища данных
будет сопротивляться порыву возложить на пользователей и разработчиков
приложений дополнительный анализ и манипулирование таблицами. Опасайтесь
поставщиков, предлагающих сложные схемы! Но, естественно, эти компромиссы
должны быть выбраны благоразумно и без крайностей. Давайте посмотрим
на несколько ситуаций, где мы выполняем достаточное количество работы
на этапе извлечения данных, чтобы, действительно, почувствовать
большую разницу. Мы также попытаемся очертить некоторые границы
с тем, чтобы не перестараться и не испортить окончательный результат.
Мы начнём с нескольких достаточно узких примеров, и постепенно расширим
наши рамки.
Моделирование событий в нескольких часовых поясах
Практически все измеряемые величины записываются в наше хранилище
данных с одной или несколькими временными отметками. Иногда они
представляют собой просто календарные даты, но всё больше мы начинаем
записывать и время с точностью до минут и секунд. Помимо этого,
наши предприятия, как правило, работают в нескольких часовых поясах,
в Соединённых Штатах, Европе или Азии, или по всему миру. В таких
случаях перед нами предстаёт естественная диллема. Либо мы стандартизуем
все наши временные отметки и приводим их к единому хорошо определённому
часовому поясу, или мы приводим все наши временные отметки к местному
времени возникновения события. Если мы хотим выполнять преобразование
из GMT к местному времени, возможно, нам нужно выяснить в каком
часовом поясе был сделан замер, и применить простое смещение. К
сожалению, это не работает. Фактически, это замечательным образом
приводит к провалу. Правила международных часовых поясов ужасно
запутаны. Существует более 500 различных географических областей
со своими собственными правилами образования часовых поясов. Мораль
истории такова: не проводите вычислений часовых поясов в вашем приложении,
добавьте лучше дополнительный внешний ключ со ссылкой на временную
отметку везде, где у вас есть существующая временная отметка, и
сохраните ОБА времени в ваших данных – стандартное и местное. Другими
словами, проведите эту работу во время извлечения данных, и поступитесь
небольшим количеством дискового пространства.
Многословные календарные измерения
Все таблицы фактов многомерных хранилищ данных должны остерегаться
присутствия явных календарных дат в пользу целочисленных внешних
ключей, ссылающихся на многословные календарные измерения. Эта рекомендация
основана не на тупом следовании концепции консистентности многомерного
дизайна, а на осознании того, что календари сложны, а приложениям
необходима помощь в навигации. Например, «родные» для SQL временные
отметки не определяют, является ли день последним днём месяца. При
использовании правильного календарного измерения последний день
месяца можно определить как булев флаг, упрощая при этом приложения.
Только вообразите себе написание запроса на основе простой даты
SQL, который должен выполнить ограничение по последним дням каждого
месяца. Это пример того, как добавление механизма к явному календарному
измерению упрощает запросы и ускоряет обработку за счёт избавления
от сложного SQL.
Ведение книг в нескольких валютах
Случай с часовыми поясами, рассмотренный в первом примере, часто
повторяется в похожей проблеме моделирования транзакций в нескольких
валютах. И снова, у нас возможность выбора из двух равноправных
законных вариантов. Если транзакция случилась в определённой валюте
(скажем, в швейцарских франках), мы, очевидно, хотим сохранить в
точности эту информацию. Но если у нас неразбериха с валютами, то
довольно сложно просуммировать результаты и получить международный
итог. Снова мы применяем похожий подход, расширяя каждую денежную
величину до двух полей – значения в местной валюте и значения в
стандартной валюте. В данном случае нам также необходимо добавить
измерение Валюта к каждой таблице фактов для того, чтобы безошибочно
определить местную валюту. Место совершения транзакции не является
надёжным индикатором типа местной валюты.
Противопоставление единиц измерения в продуктовой цепочке
Многие из нас думают, что метрики продуктовой цепочки достаточно
просты, и не имеют сложности, присущей, например, финансам. Тогда
проведите некоторое время с людьми из производства, сбытовиками
и розничными торговцами, каждый из которых говорит об одних и тех
же продуктах в одной и той же цепочке. Люди с производства хотят
видеть всё в машинах и палетах. Сбытовики хотят всё видеть в количестве
отгрузок. Розничные торговцы заинтересованы только в количестве
сосканированных единиц. Так, что же вам поместить в разные таблицы
фактов, чтобы все были счастливы? НЕПРАВИЛЬНЫЙ ответ заключается
в публикации каждого факта в своей локальной единице измерения и
перекладывании на приложение работы по поиску правильных коэффициентов
для перевода в таблицах измерений продуктов! Да, теоретически всё
это возможно, но эта архитектура даёт неразумную нагрузку на последний
шаг обработки, где живут конечные пользователи и разработчики приложений.
Вместо этого представьте все измеряемые факты в единой стандартной
единице измерения, а затем в самой таблице фактов разместите коэффициенты
преобразования во все необходимые единицы измерения. Таким образом,
приложения, запрашивающие данные о цепочке, в любом случае будут
иметь непротиворечивый способ конвертации всех числовых значений
в характерные для конечного пользователя единицы измерения.
Физическое завершение дизайна прибылей и убытков (P&L)
Таблица фактов прибылей и убытков является очень мощной, поскольку
предоставляет все компоненты доходов и расходов (возможно) с низким
уровнем детализации. После предоставления этого замечательного уровня
детальности проектировщики иногда компрометируют свой дизайн, не
предоставляя всех промежуточных уровней P&L. Например, чистая
прибыль вычисляется путём вычитания расходов из чистых доходов.
Эта чистая прибыль должна быть явным полем в данных, даже если она
равна алгебраической сумме других полей в той же самой записи. Было
бы, действительно, очень жаль, если бы пользователь или разработчик
приложения запутался бы на последнем шаге, и рассчитал бы чистую
прибыль неправильно.
Гетерогенные продукты
В финансовых отраслях, таких как банки и страхование часто возникает
характерный конфликт между необходимостью видеть все счета в едином
представлении «домохозяйства» клиента, и необходимостью видеть детальные
атрибуты и метрики каждого типа счёта. В большом розничном банке
может быть 25 бизнес-направлений и более 200 специальных метрик,
относящихся ко всем различным типам счетов. Вы просто не можете
создать гигантскую таблицу фактов и гигантскую таблицу измерения,
которые могут вместить все гетерогенные продукты. Решение заключается
в публикации данных дважды. Сначала создайте единую базовую таблицу
фактов всего с четырьмя или пятью метриками, такими как остаток,
которые будут общими для всех типов счетов. Затем опубликуйте данные
вторично с отдельными таблицами фактов и таблицами измерений для
каждого из 25 бизнес-направлений. Хотя это может показаться расточительным,
поскольку гигантская таблица фактов фактически публикуется дважды,
это предоставляет разделить приложения для «домохозяйств» и бизнес-направлений.
Агрегаты в целом
Агрегаты похожи на индексы: они представляют собой специальные
структуры данных для повышения производительности. Агрегаты являются
значительным отвлекающим фактором в бэк-офисной обработке. Они потребляют
процессорные ресурсы, добавляют сложности к ETL, а также потребляют
массу дискового пространства. НО, агрегаты остаются единственным
мощным инструментом в арсенале проектировщика хранилищ данных, позволяющим
эффективно поднять производительность.
Многомерное моделирование в целом
Теперь я надеюсь, что стал очевидным факт, что наиболее частый
компромисс бэк-офисной обработки, использующийся для пользы конечного
пользователя – это практика многомерного моделирования. Многомерная
модель – это вторая нормальная форма от модели в третьей (или высшей)
нормальной форме. Схлопывание снежинок и других сложных структур
моделей более высших нормальных форм в характерные плоские таблицы
измерений делает дизайны простыми, симметричными и понимаемыми.
Более того, поставщики СУБД смогли сфокусировать свои алгоритмы
обработки на этом хорошо понимаемом примере, чтобы заставить многомерные
модели работать действительно быстро. В противоположность другим
техникам, рассмотренным в этом совете, подход многомерного моделирования
можно применять практически во всех горизонтальных и вертикальных
приложениях.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS