Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбалл (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается .
Измерение КЛИЕНТ, возможно, одно из самых сложных в хранилище данных.
В большой организации измерение КЛИЕНТ может быть
огромным с миллионами записей
широким с десятками атрибутов
медленно изменяющимися, но иногда и быстро изменяющимися
Но это ещё не всё: в самых больших измерениях КЛИЕНТ часто присутствуют
две категории клиентов, которые я называю Посетитель и Клиент.
Посетитель анонимен. Мы можем видеть их многократно, но мы не знаем
их имён и не имеем других сведений о них. В случае веб-сайта всё,
что мы имеем - это файл cookie, который говорит об их возвращении.
В розничной торговле Посетитель выполняет анонимную транзакцию.
Может быть, у нас есть номер кредитной карты или простой клубной
карты, но мы предполагаем, что о Посетителе у нас нет никакой демографической
информации.
Клиент, в противоположность, надёжно нами зарегистрирован. Мы знаем
имя, адрес клиента, а также располагаем всей информацией, которую
он нам предоставил, или которую мы приобрели от третьих лиц. У нас
есть адрес доставки, история платежей и, возможно, кредитная история
каждого Клиента.
Давайте предположим, что на самом детальном уровне нашего набора
данных 80% записей таблицы фактов вовлекают Посетителей, а 20% -
Клиентов. Давайте также предположим, что накапливаем простые показатели
поведения, состоящие только из свежести (когда мы последний раз
их видели), частоты (сколько раз мы их видели) и интенсивность (сколько
денег мы на них заработали). Таким образом, этот простой дизайн
включает только три показателя, характеризующие Посетителя.
С другой стороны, давайте предположим, что у нас есть 50 атрибутов/показателей,
характеризующих Клиента, которые охватывают все компоненты расположения,
платёжного поведения, кредитного поведения, непосредственно полученные
демографические атрибуты и демографические атрибуты, приобретённые
у третьих сторон.
Давайте сделаем несколько довольно специфических предположений
в целях ясного дизайна. Позже мы сможем их несколько ослабить...
Во-первых, давайте объединим посетителей и клиентов в одно логическое
измерение под названием Покупатель. Настоящему физическому Посетителю/Клиенту
мы дадим уникальный постоянный идентификатор покупателя, но ключ
таблицы мы сделаем суррогатным чтобы иметь возможность отслеживать
изменения измерения ПОКУПАТЕЛЬ, происходящие со временем. Логически,
наше измерение выглядит следующим образом:
*** атрибуты для Посетителей и Клиентов
Суррогатный ключ Покупателя <== простое целое число, возрастающее
с каждым изменением
Shopper ID <== постоянный фиксированный идентификатор для каждого
физического покупателя
Recency Date <== дата последнего визита, тип 1: перезаписывается
Frequency <== количество визитов, тип 1: переписывается
Intensity <== общее количество бизнеса, например, продано итого
в долларах, тип 1
Одно сильное предположение, которое мы сделали здесь, заключается
во включении информации о свежести, частоте и интенсивности в атрибуты
измерения, а не в качестве фактов, а также том, что мы постоянно
переписываем их по мере изменения (медленно изменяющееся измерение
типа 1). Это предположение делает наше измерение Покупатель очень
мощным. Мы можем выполнять классическую сегментацию покупателей
на основе измерения без навигации по таблице фактов в сложном приложении.
Смотрите обсуждение сегментации по свежести-частоте-интенсивности
в моей книге начиная со страницы 73.
Если мы предположим, что многие из последних 50 атрибутов Клиентов
являются текстовыми, мы получим запись размером 500 или более байт.
Предположим, у нас 20 миллионов Покупателей (16 миллионов Посетителей
и 4 миллиона зарегистрированных Клиентов). Очевидно, мы обеспокоены
тем, что в 80% наших записей 50 последних атрибутов не содержат
данных! В 10-гигабайтном измерении это привлекает наше внимание.
Это явный случай когда, в зависимости от базы данных, мы можем захотеть
ввести снежинку.
В базах данных с переменным размером записи, наподобие Oracle,
мы можем просто построить одно измерение ПОКУПАТЕЛЬ со всеми перечисленными
выше атрибутами, не принимая в расчёт проблему с пустыми полями.
Большинство записей о покупателях, которые являются просто Посетителями,
останутся узкими, поскольку в этих базах данных пустые поля не занимают
места на диске.
Но в базах данных с фиксированным размером записей мы, возможно,
не хотим мириться с пустыми полями для всех Посетителей, поэтому
мы разбиваем измерение на базовое измерение и вспомогательное измерение:
Базовое:
Суррогатный ключ Покупателя <== простое целое число, возрастающее
с каждым изменением
Shopper ID <== постоянный фиксированный идентификатор для каждого
физического покупателя
Recency Date <== дата последнего визита, тип 1: перезаписывается
Frequency <== количество визитов, тип 1: переписывается
Intensity
Суррогатный ключ Клиента <== новое поле для связи со снежинкой
Снежинка:
Суррогатный ключ Клиента <== соответствие 1:1 с теми покупателями,
которые являются Клиентами
5 атрибутов имени
10 атрибутов размещения
5 атрибутов платёжного поведения
5 атрибутов кредитного поведения
10 прямых демографических атрибутов
15 приобретённых демографических атрибутов
В базе данных с фиксированным размером строк, используя наше предыдущее
предположения, базовое измерение ПОКУПАТЕЛЬ будет 20 миллионов x
25 байт = 500 МБ, а измерение-снежинка 4 миллиона x 475 байт = 1.9
ГБ. Мы сэкономили 8 гигабайт.
Если ваш генератор отчётов настаивает на классической схеме "звезда"
без снежинок, спрячьте снежинку посредством представления.
Это основы измерения КЛИЕНТ переменной глубины. Я оставил без внимания
множество проблем с таблицей, включая следующие:
как администрировать изменяющиеся атрибуты в части, ответственной
за Клиентов
как не потерять историю показателей свежесть-частота-интенсивность,
при условии, что мы их переписываем
как добавить иерархические отношения ко всему этому, если клиенты
являются организациями
как быть с ограничениями безопасности и конфиденциальности,
которые могут быть наложены сверху
Оставайтесь на нашей волне до следующего совета...
Присылайте мне свои вопросы и комментарии по поводу измерений КЛИЕНТ
переменной глубины.
Ральф Кимбал (ralph@ralphkimball.com)
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS