Umgang mit Zeitzonen im Data Mart / Warehouse

Wir beginnen mit dem Entwurf der Bausteine ​​eines Data Mart / Warehouse und müssen in der Lage sein, alle Zeitzonen zu unterstützen (unsere Kunden kommen aus der ganzen Welt). Beim Lesen von Diskussionen online (und in Büchern) scheint eine gängige Lösung darin zu bestehen, eine separate Datums- und Zeitdimension sowie einen Zeitstempel in den Faktentabellen zu haben.

Die Frage, die ich nur schwer beantworten kann, ist jedoch, was die Datums- und Zeitdimensionen angesichts meiner dynamischen Zeitzonenanforderungen tatsächlich für mich tun. Eine Zeitdimension ist etwas sinnvoller, aber ich habe Schwierigkeiten mit der Datumsdimension. Ein allgemeiner Entwurfsansatz für eine Datumsdimension umfasst normalerweise Eigenschaften wie Tagesname, Wochentag, Monatsname usw. Das Problem, das ich mit all dem habe, ist, dass am Dienstag, dem 31. Dezember 2013, um 23:00 Uhr in UTC Mittwoch ist , 1. Januar 2014 in allen Zeitzonen nach UTC + 2.

Wenn ich also all diese Zeitzonen-Konvertierungen für jede einzelne Abfrage (und jeden Bericht) durchführen muss, wozu dann diese Eigenschaften haben und speichern, die ich wahrscheinlich nie verwenden werde (wie es scheint)? Einige Leute schlagen vor, Faktenzeilen für jede Zeitzone zu haben, aber das scheint mir lächerlich. Wir müssen in der Lage sein, jeden Monat Millionen von Datensätzen zu speichern.

Andere schlagen vor, eine Zeitzonen-Brückentabelle zu haben, die zwar sinnvoll ist, aber auch zusätzliche Komplexität und zusätzliche Verknüpfungen erfordert, um etwas zu erreichen, das meine Client-Apps und -Berichte ab einem Datum leicht herausfinden sollten (die Berichterstellung erfolgt hauptsächlich webbasiert) wo es eine Vielzahl von Bibliotheken gibt, die beim Konvertieren, Anzeigen und Formatieren von Daten helfen können).

Das einzige, woran ich denken kann, ist die Leichtigkeit und möglicherweise Leistung der Gruppierung nach Datum und Stunde, aber wie schlecht es ist, nach Datumsteilen zu gruppieren (wir verwenden MS SQL, aber wir werden Millionen von Zeilen abfragen) oder sollten wir dies berücksichtigen Nur extrem einfache Datums- und Zeitdimensionen mit nicht viel mehr als Stunden-, Tag-, Monats- und Jahreszahlen zum größten Teil, da die meisten Literale wie Montag nicht viel bedeuten würden, wenn Zeitzonen ins Spiel kommen?

Zuerst...

Die Trennung Datime/Timein eine DateDimension und eine TimeDimension ist definitiv der richtige Weg.

Um mehrere Zeitzonen zu verwalten, müssen Sie das DateKeyund das duplizieren, TimeKeydamit Sie Folgendes haben:

• LocalDateKey
• LocalTimeKey
• UtcDateKey
• UtcTimeKey

Du sagst...

Das Problem, das ich mit all dem habe, ist, dass am Dienstag, dem 31. Dezember 2013, um 23:00 Uhr in UTC Mittwoch, der 1. Januar 2014 in allen Zeitzonen nach UTC + 2 ist.

Wenn Sie die 4 Spalten haben, die ich oben aufgeführt habe, können Sie die Faktentabelle mithilfe von Tabellen- Aliasen mit der Datums- und / oder Zeitdimension verknüpfen (in der Kimball-Terminologie werden diese Alias-Dimensionstabellen als "Rollenspieldimensionen" bezeichnet) Sie hätten so etwas wie das Folgende:

/*
    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 

Abschließend...

Da Sie einen Data Mart und keine OLTP-Datenbank erstellen, sollte die Generierung der lokalen und Utc-Zeiten in Ihrer ETL durchgeführt werden , NICHT in clientseitigen Anwendungen aus den folgenden Gründen (abgesehen von der Lokalisierung der UTC-Zeit bis zum Bericht Leserperspektive):

• Wenn sich die Berechnung in Abfragen befindet, bedeutet dies eine zusätzliche Leistungsbelastung, multipliziert mit der Häufigkeit, mit der Sie diese Abfrage für alle Berichte ausführen müssen (dies ist wichtig, wenn Sie Millionen von Zeilen lesen).
• Zusätzliche Belastung, um sicherzustellen, dass die Berechnung bei jeder Abfrage korrekt beibehalten wird (insbesondere, wenn Sie die Sommerzeit berücksichtigen)
• Verhindern Sie das Scannen des Bereichs von Indizes, zu denen die Spalte gehört, da Sie eine Berechnung für die Spalte durchführen, die Abfragen dazu zwingt, Index-Scans anstelle von Suchvorgängen durchzuführen (die normalerweise teurer sind, da jede Datenseite gelesen werden muss). Dies ist als nicht sargable bekannt .
  • Aufgrund von Kommentaren bearbeiten: Dies gilt, wenn Sie die Konvertierung in die eigentliche Abfrage verschieben .
• Wenn Sie das Konzept verwenden, die zusätzlichen UTC-Daten und -Zeiten verfügbar zu haben, hindert Sie nichts daran, dieses Konzept zu übernehmen und zu erweitern, indem Sie dies aufrufen StandardisedDateKeyoder CorporateHQDateKeyanstelle einer UTC-Datumstabelle, die Sie auf der Grundlage eines anderen vom Unternehmen vereinbarten Standards standardisieren
• Mit den zwei separaten Spaltentypen (Lokal und UTC) können Sie die geografische Entfernung nebeneinander vergleichen. Denken Sie -> jemand in Australien gibt einen Datensatz ein, der sowohl mit Local als auch mit UTC mit einem Zeitstempel versehen ist. Jemand in New York liest den Bericht mit dem Datum und der Uhrzeit von Local (Australien) und der New Yorker Darstellung von UTC mit Datum und Uhrzeit und sieht dabei etwas Ihr australisches Gegenstück tat dies mitten am Tag (australische Zeit) mitten in der Nacht (New Yorker Zeit). Dieser Zeitvergleich ist in multinationalen Unternehmen unverzichtbar.

Ich entschuldige mich im Voraus für die Kürze dieser Antwort und plane, näher darauf einzugehen, wenn ich nicht bei der Arbeit bin.

Datums- und Zeittabellen bieten mit Sicherheit Vorteile, da sie eine einfache Aggregation Ihrer Daten ermöglichen. In vielen Fällen ist es die einfachste Möglichkeit, solche Dinge nach Monat oder Werktagen zu sortieren. Dies ersetzt jedoch nicht unbedingt die Nützlichkeit eines Zeitstempels. In Ihrem speziellen Fall ein UTC-Zeitstempel. Sobald Sie diesen Zeitstempel haben, müssen Sie ihn nur noch in der Berichts- oder Präsentationsebene in die Ortszeit ändern. Um Bereichsscans zu vermeiden, stellen Sie sicher, dass Sie Ihren Anforderungsbereich auch in UTC-Zeit konvertieren.

Wenn Sie weitere Fragen oder Kommentare haben, können Sie diese gerne stellen.