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

При обработке измерений существует три варианта действий:

  1. Если объект (к примеру, Клиент) является новым членом измерения, то мы генерируем для него новый суррогатный ключ.
  2. Если объект является ИЗМЕНИВШИМСЯ вариантом Клиента, то мы используем технику медленно меняющихся измерений 2го типа: присваиваем Клиенту новый суррогатный ключ и сохраняем изменившееся описание клиента отдельной записью в таблицу измерения.
  3. Наконец, если Клиент уже является членом нашего измерения, и при этом его описание не изменялось, то мы просто используем ключ, который у нас уже имеется для этого Клиента.

В течение нескольких последних лет мы используем специальную модификацию этих процедур для работы с Запаздывающими Фактами (Late Arriving Facts), то есть с фактами, появляющимися в хранилище с большой задержкой. Это неприятная ситуация, так как нам необходимо просматривать всю историю измерения, чтобы найти записи, которые были актуальны на определенный момент в прошлом. Почитайте на эту тему статью Backward in Time.

Если бывают Запаздывающие Факты, то возможны ли Ранние Факты (Early Arriving Facts)? Как это может произойти? Бывают ли ситуации, в которых это действительно важно?

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

Но если мы строим хранилище данных реального времени, и должны сделать факт видимым уже СЕЙЧАС, хотя еще и не знаем полного его описания, то возникает интересный выбор. Пересмотрим наши действия по обработке измерений, используя в качестве проблемного измерения тех же Клиентов.

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

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

 

Материал опубликован с разрешения компании Ralph Kimball Associates
Автор оригинала: Ральф Кимбалл
Перевод на русский язык: Егор Демьянов
Оригинальный документ располагается здесь


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

Читайте также: