Совет №30
Посадите ваши таблицы фактов на диету

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

В середине 90х годов, когда ещё не было Интернета, выяснилось, что, в конечном счёте, может наступить взрыв данных. В то время мы учились как сохранять информацию о каждом телефонном звонке, каждом товаре, выбитом в кассовом чеке, каждой транзакции с ценными бумагами, проведённой на Уолл Стрит и о каждом страховом случае в гигантских страховых компаниях. Действительно, правда, что мы не хранили длинные временные ряды этих данных в наших хранилищах данных, но у нас было чувство, что мы, возможно, достигли физического лимита детальности данных. Возможно, мы, наконец, нашли истинные «атомы» данных.

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

Подождите немного до того момента, когда системы GPS будут встроены в наши автомобили, кредитные карты и телефоны. Каждый человек, в конечном счете, мог бы генерировать одну или более записей каждую секунду 24 часа в сутки!

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

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

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

1. Замените все естественные внешние ключи самыми маленькими возможными целочисленными (суррогатными) ключами.
2. Как часть п. 1, замените все поля типа дата/время на целочисленные суррогатные ключи.
3. Объедините связанные измерения в одно измерение, где это возможно.
4. Сгруппируйте крошечные измерения с низкой кардинальностью в одно измерение, даже если они и не связаны.
5. Уберите все текстовые поля из таблицы фактов. Сделайте их измерениями. В особенности поля с комментариями.
6. Где возможно, замените все длинные целые числа и числа с плавающей точкой на масштабированные целые.

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

Date/Time = 8 byte date-time stamp
Calling Party Phone Number = 10 byte string
Called Party Phone Number = 15 byte string (для обработки международных номеров)
Local Provider Entity = 10 byte string
Long Distance Provider Entity = 10 byte string
Added Value Service Provider Entity = 10 byte string
Dialing Status = 5 byte string (100 возможных величин)
Termination Status = 5 byte string (100 возможных величин)
Duration fact = 4 byte integer
Rated Charge fact = 8 byte float

При таком дизайне каждая запись о звонке занимает 85 байт. Хранение этих сырых данных без индексов потребует 27,9 терабайт. В предположение, что данные приходят непрерывным потоком, нам нужно будет добавлять по 776 гигабайт дискового пространства каждый месяц для хранения только сырых данных!

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

Date = 2 byte tiny integer
Time of Day = 2 byte tiny integer
Calling Party Phone Number = 4 byte integer surrogate key
Called Party Phone Number = 4 byte integer surrogate key
Local Provider Business Entity = 2 byte tiny integer surrogate key
Long Distance Provider Entity = 2 byte tiny integer surrogate key
Added Value Service Provider = 2 byte tiny integer surrogate key
Status = 2 byte tiny integer surrogate key (комбинация Dialing и Termination)
Duration fact = 4 byte integer
Rated Charge fact = 4 byte scaled integer

Мы сделали несколько предположений относительно типов данных, поддерживаемых вашей СУБД. Мы предположили, что для хранения ключей измерений достаточно двухбайтных целых чисел в диапазоне от 0 до 65535.

При этом дизайне пространство, необходимое для хранения сырых данных в нашей таблице фактов составит 9,2 терабайт, экономия достигает 67%! Ежемесячный рост данных при этом составит 256 гигабайт.

Несмотря на то, что эти цифры по-прежнему велики, у нас, всё-таки, остаётся пространство для того, чтобы вздохнуть. Будьте фанатичны, когда проектируете таблицы фактов консервативно. Посадите их на диету.

Ральф Кимбал

Ralph Kimball (ralph@ralphkimball.com)

• Предыдущий совет
• Следующий совет
• Другие советы

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

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.