Проект хранилища данных: объединенное измерение даты и времени в сравнении с отдельными измерениями и часовыми поясами дня и времени


10

Мы только начинаем проектировать новое хранилище данных и пытаемся спроектировать, как будут работать наши измерения даты и времени. Нам нужно иметь возможность поддерживать несколько часовых поясов (вероятно, по крайней мере GMT, IST, PST и EST). Сначала мы думали, что у нас будет одно общее объединенное измерение даты и времени, вплоть до, возможно, 15-минутной детализации, таким образом, у нас будет один ключ в наших таблицах фактов, и все разные данные даты и времени для всех поддерживаемых часовых поясов находятся в одной таблице измерений. (т. е. ключ даты, дата по Гринвичу, время по Гринвичу, дата по Гринвичу, время по Гринвичу и т. д.)

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

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

Если мы сделаем 15-минутное зерно, у нас будет 131 400 (24 * 15 * 365) строк в год в нашей таблице измерений даты и времени, которая не звучит слишком ужасно для производительности, но мы не будем знать наверняка, пока мы не протестируем некоторые прототип запросов. Другая проблема, связанная с наличием отдельных ключей часовых поясов в таблице фактов, заключается в том, что запрос должен присоединить таблицу измерений к другому столбцу на основе желаемого часового пояса, возможно, это то, что SSAS позаботится о вас, я не уверен ,

спасибо за любые мысли, -Matt


1
Этот вопрос также существует в переполнении стека: stackoverflow.com/questions/2507289/… .
Джон на все руки

Ответы:


5

Разделяя дату и время, вы сможете легко составлять статистику по времени. например: если вы хотите выполнить запрос, чтобы определить, какой период времени наиболее занят. Это очень легко сделать, используя отдельное измерение времени.

Кроме того, у вас должен быть только один ключ времени. Выберите время по Гринвичу / Восточному поясному времени - затем используйте это в таблице фактов. Если вам нужно запускать отчеты, основанные на другом часовом поясе, просто преобразуйте их в свое приложение или запрос.


Хорошо, это имеет смысл, пользователи не могут сгруппировать данные, основываясь на их часовом поясе, но это, вероятно, то, без чего мы могли бы жить, чтобы упростить дизайн.
Мэтт Палмерли

@MattPalmerlee: пользователи могут группировать по часовому поясу, если вы им это дадите. Обычно я включаю его в Geographyтаблицу, но если ничего не применимо, вы можете добавить его в качестве атрибута таблицы фактов.
Джон на все руки

5

Просто следите за тем, как мы решили реализовать наш DataWarehouse для поддержки нескольких часовых поясов и быть максимально эффективными: мы решили создать таблицу часовых поясов (идентификатор, имя и т. Д.), А также «Часовой пояс». мост "таблица, которая выглядит так:

time_zone_bridge
---------------
date_key_utc
time_key_utc
timezone_id
date_key_local
time_key_local

Таким образом, мы можем сохранить наши обычные таблицы измерений даты и времени небольшими, все наши факты связаны с ключами даты / времени UTC, тогда, если нам нужно составить отчет / сгруппировать по другому часовому поясу, нам просто нужно присоединиться через таблицу моста часового пояса. и связать локальные ключи даты / времени с таблицами измерений даты и времени. Мы заполняем нашу таблицу мостов часовых поясов, используя код C #, вызываемый из SSIS, поскольку это было гораздо менее сложно, чем делать TZ-вещи из SqlServer напрямую.


Я также думаю, что ваше решение, вероятно, имеет смысл, не вдаваясь во что-то слишком сложное. Я тестирую свой DW, используя таблицу timeZone и TimeZoneBridge, аналогичные вашей. Он также имеет таблицы TimeDimension и DateDimension. Я создал кластерный индекс для date_key_local, time_key_local и timezone_id, чтобы преобразование местного времени в UTC с использованием TimeZoneBridge было быстрым.
2012 г.

1
Наш основной кластеризованный ключ для таблицы мостов находится в столбцах даты / времени utc + идентификатор часового пояса (если я правильно помню), поскольку все временные ключи таблиц фактов будут в utc, вы будете подключаться к мосту через utc keys + tz id, может быть лучше использовать кластеризованный индекс для них. Делайте то, что имеет смысл для ваших нужд, хотя. Я рад, что мой ответ помог кому-то, я думаю, что это хороший подход, и из всех наших тестов он все еще достаточно быстр, просто будьте осторожны, когда дело доходит до предложения WHERE: отфильтруйте диапазоны дат, которые вы хотите, как можно раньше возможно в ваших запросах.
Мэтт Палмерли

Это содержит только целые даты? Или, если у вас есть 86000 значений «ключ даты / времени» в вашей таблице фактов, таблица мостов будет иметь 86000 строк * n поддерживаемых часовых поясов, и это только на один день?
Аарон Бертран

1
возможно, вы можете добавить точное определение таблицы, чтобы читатели могли видеть первичные, уникальные ограничения.
ypercubeᵀᴹ

@AaronBertrand - это зависит от того, какую грань (или гранулярность вы выберете) для отслеживания ваших данных, в нашем случае нам потребовалась только 15-минутная гранулярность в наших таблицах фактов, так что это всего 4 * 24 = 96 записей в день на часовой пояс, который мы хотели поддерживать что вполне разумно.
Мэтт Палмерли

2

Я видел, что идея склада с использованием комбинированного DateTimeизмерения отклонена, но я не видел действительно четкой причины, почему. Немного упрощаясь, вот таблица фактов, которую я сейчас строю:

Transactions
(
...
CreatedDateTimeSK         INT NOT NULL,  -- Four bytes per date...
AuthorizedDateTimeSK      INT NOT NULL,
BatchSubmittedDateTimeSK  INT NOT NULL,
BatchApprovedDateTimeSK   INT NOT NULL,
SettlementDateTimeSK      INT NOT NULL,
LocalTimeZoneSK           TINYINT NOT NULL  -- ...plus one byte for the time zone
)

В DateTimeполе присоединиться к таблице DateTime:

DateTimes
(
DateTimeSK   INT NOT NULL PRIMARY KEY,
SQLDate      DATE NOT NULL,
SQLDateTime  DATETIME2(0) NOT NULL,
Year         SMALLINT NOT NULL,
Month        TINYINT NOT NULL,
Day          TINYINT NOT NULL,
Hour         TINYINT NOT NULL,
Minute       TINYINT NOT NULL CHECK (Minute IN (0, 30)),
...
)

Это с разрешением в полчаса, так что в день записывается 48 записей, 350 400 за 20 лет - вполне управляемо.

Дата / время события переводятся в UTC при сохранении, но с LocalTimeZoneSKполем и таблицей мостов мы можем легко объединиться, чтобы получить местное время:

TimeZoneBridge
(
DateTimeSK       INT NOT NULL,
TimeZoneSK       TINYINT NOT NULL,
PRIMARY KEY (DateTimeSK, TimeZoneSK),
LocalDateTimeSK  INT NOT NULL
)

Чтобы получить транзакции, созданные сегодня, время UTC:

SELECT COUNT(*)
FROM Transactions AS T
  INNER JOIN DateTimes AS CD ON T.CreatedDateTimeSK = CD.DateTimeSK
WHERE CD.SQLDate = '2014-08-22'

Чтобы получить транзакции, созданные сегодня, по местному времени для транзакции:

SELECT COUNT(*)
FROM Transactions AS T
  INNER JOIN TimeZoneBridge AS TZB ON T.CreatedDateTimeSK = TZB.DateTimeSK AND T.TimeZoneSK = TZB.TimeZoneSK
  INNER JOIN DateTimes AS CD ON TZB.LocalDateTimeSK = CD.DateTimeSK
WHERE CD.SQLDate = '2014-08-22'

Вы можете захотеть , чтобы упростить вещи, заменив TimeZoneSKс REALсмещением (например, -5,0 для США Центральной поясному времени), но это будет разрушаться , если некоторые даты / времени для записи фактов в летнее время , а некоторые нет.

Если события для записи факта могут происходить в разных часовых поясах, например, при отправке или полете, вам нужно поле часового пояса для каждой даты, и вы получите до пяти байт на дату.


Это творческий подход. Однако, как вы говорите, у вас будет только 350 400 строк в объединенной таблице затемнения даты и времени, если вы начнете изменять зерно на более точное разрешение, вы быстро попадете в миллионы записей. Если вы решили использовать измерение даты, отличное от измерения времени, у вас будет только 48 строк в таблице измерения времени и только 365 строк в год в таблице измерения даты (или 7300 строк за 20 лет). Ваша таблица фактов тогда просто имеет столбец для date_key и time_key. Это также делает его более гибким, если у вас есть некоторые таблицы фактов, которые требуют только детализации даты.
Мэтт Палмерли

1
Миллион строк в измерении меня не касается - данные меняются только раз в десять лет, а индекс покрытия для PK и двух или трех наиболее часто используемых полей будет занимать тривиальный объем оперативной памяти сервера. Однако добавление полдюжины SMALLINTсекунд в таблицу фактов с миллиардами строк составляет 12 ГБ плюс накладные расходы, и теперь вы говорите на реальные деньги. Для дат, которые должны хранить только дату, вы, конечно, можете указать их на запись «12:00 AM» для соответствующей даты.
Джон на все руки
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.