Обработка часовых поясов в витрине данных / хранилище

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

Тем не менее, вопрос, на который мне трудно ответить, заключается в том, насколько полезны измерения даты и времени для меня, учитывая мои требования к динамическому часовому поясу? Измерение времени имеет немного больше смысла, но я испытываю трудности с измерением даты. Общий подход к проектированию для измерения даты обычно включает такие свойства, как название дня, день недели, название месяца и т. Д. Проблема, с которой я сталкиваюсь, заключается в том, что 23:00 во вторник, 31 декабря 2013 г. в UTC, - среда 1 января 2014 г. во всех часовых поясах после UTC + 2.

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

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

Единственное, о чем я могу думать, - это простота и, возможно, производительность группировки по дате и часу, но насколько плохой практикой является группирование по дате (мы используем MS SQL, но мы будем запрашивать миллионы строк), или мы должны рассмотреть просто чрезвычайно простые измерения даты и времени, по большей части не более чем числа часов, дней, месяцев и годов, поскольку большинство литералов, таких как понедельник, не будут иметь большого значения, когда в игру вступят часовые пояса?

Во-первых...

Разделение Datime/Timeна Dateизмерение и Timeизмерение - определенно путь.

Для управления несколькими часовыми поясами необходимо продублировать DateKeyи TimeKeyтак, чтобы у вас было следующее:

• LocalDateKey
• LocalTimeKey
• UtcDateKey
• UtcTimeKey

Ты говоришь...

Проблема, с которой я сталкиваюсь, заключается в том, что во вторник, 31 декабря 2013 года, в UTC у меня будет среда, 1 января 2014 года, во все часовые пояса после UTC + 2.

Имея 4 столбца, которые я перечислил выше, вы сможете присоединить таблицу фактов к измерению «Дата и / или время», используя псевдонимы таблиц (в терминологии Кимбалла эти таблицы измерений с псевдонимами известны как «Измерения ролевой игры»), поэтому у вас будет что-то вроде следующего:

/*
    Assumes the following:
        - [DateLongName] has the format of this example "Tuesday, December 31, 2013"
        - [TimeShortName] has the format of this example "11:00 PM"
        - Both [DateLongName] & [TimeShortName] are strings
*/
select
    -- Returns a string matching this example  "11:00 PM Tuesday, December 31, 2013"
    localTime.TimeShortName + ' ' + localDate.DateLongName
    ,utcTime.TimeShortName + ' ' + utcDate.DateLongName
    ,f.*
from
    FactTableName  AS f

    -- Local Date and Local Time joins          
    inner join dbo.Date  AS localDate
        on localDate.DateKey = f.LocalDateKey

    inner join dbo.Time  AS localTime
        on localTime.TimeKey = f.LocalTimeKey 

    -- Utc Date and Utc Time joins    
    inner join dbo.Date  AS utcDate
        on utcDate.DateKey = f.UtcDateKey

    inner join dbo.Time  AS utcTime
        on utcTime.TimeKey = f.UtcTimeKey 

В заключение...

Поскольку вы строите витрину данных, а не базу данных OLTP, генерация локального и Utc-времени должна выполняться в вашем ETL , а не в любых клиентских приложениях по следующим причинам (кроме локализации времени UTC для отчет читателя):

• Наличие вычислений в любых запросах накладывает на них дополнительное бремя производительности, умноженное на количество раз, которое вы должны выполнить указанный запрос для всех ваших отчетов (это важно при чтении миллионов строк)
• Дополнительное бремя обеспечения правильности расчетов поддерживается в каждом запросе (особенно если учесть летнее время)
• Запретить сканирование диапазона любых индексов, частью которых является столбец, так как вы будете выполнять вычисление для столбца, которое заставляет запросы выполнять сканирование индекса вместо поиска (которые, как правило, более дороги, так как каждая страница данных необходима для чтения); это известно как не - sargable .
  • Изменить из-за комментариев: это применимо, если вы нажмете конверсию вниз в фактический запрос .
• Используя концепцию наличия дополнительных дат и времени UTC, ничто не мешает вам принять эту концепцию и расширить ее, назвав ее StandardisedDateKey, или CorporateHQDateKey, если вместо таблицы дат UTC вы стандартизируете на основе какого-либо другого бизнес-согласованного стандарта
• Наличие двух отдельных типов столбцов (локальный и UTC) позволяет проводить параллельное сравнение по географическому расстоянию. Подумайте -> кто-то в Австралии вводит запись с отметкой времени в местном и UTC, кто-то в Нью-Йорке читает отчет с датой и временем в местном (Австралия) и нью-йоркским представлением даты и времени в формате UTC, таким образом, видя что-то их австралийский коллега сделал это в середине дня (по времени Австралии), случился среди ночи (по нью-йоркскому времени). Такое сравнение времени незаменимо в многонациональном бизнесе.

Я заранее прошу прощения за краткость этого ответа и планирую уточнить, когда я не на работе.

Несомненно, есть преимущества наличия таблиц даты и времени, поскольку они позволяют легко объединять ваши данные. Во многих случаях это самый простой способ сортировать вещи такого рода по месяцам или рабочим дням. Однако это не обязательно заменяет полезность метки времени. В вашем конкретном случае отметка времени UTC. Когда у вас есть эта временная метка, все, что вам нужно сделать, это изменить ее на местное время в отчете или на уровне представления. Чтобы избежать сканирования диапазона, убедитесь, что вы также конвертируете диапазон своего запроса во время UTC.

Если любые другие вопросы или комментарии, не стесняйтесь спрашивать.