Menangani zona waktu di data mart / gudang

Kami mulai merancang blok bangunan data mart / gudang dan kami harus dapat mendukung semua zona waktu (klien kami berasal dari seluruh dunia). Dari membaca diskusi online (dan dalam buku), solusi umum tampaknya memiliki dimensi tanggal dan waktu yang terpisah serta cap waktu di tabel fakta.

Namun, pertanyaan saya mengalami kesulitan menjawab adalah apa gunanya dimensi tanggal dan waktu untuk saya mempertimbangkan persyaratan zona waktu dinamis saya? Dimensi waktu sedikit lebih masuk akal tetapi saya mengalami kesulitan dengan dimensi tanggal. Pendekatan desain umum untuk dimensi tanggal biasanya mencakup properti seperti nama hari, hari minggu, nama bulan, dll. Masalah yang saya alami dengan semua itu adalah bahwa pukul 11:00 pada hari Selasa, 31 Desember 2013 di UTC adalah hari Rabu , 1 Januari 2014 di semua zona waktu setelah UTC + 2.

Jadi jika saya harus melakukan semua konversi zona waktu ini pada setiap kueri (dan laporan) lalu apa gunanya memiliki dan menyimpan properti ini yang mungkin tidak akan pernah saya gunakan (sepertinya)? Beberapa orang menyarankan memiliki baris fakta untuk setiap zona waktu tetapi itu tampak konyol bagi saya. Kita harus dapat menyimpan jutaan catatan setiap bulan.

Yang lain menyarankan memiliki tabel jembatan zona waktu yang walaupun masuk akal, tetapi juga tampaknya lebih rumit dan tambahan untuk mencapai sesuatu yang aplikasi dan laporan klien saya harus dapat dengan mudah mengetahui dari suatu tanggal (pelaporan akan terutama berbasis web di mana ada segudang perpustakaan untuk membantu dalam mengkonversi, menampilkan dan memformat tanggal).

Satu-satunya hal yang dapat saya pikirkan adalah kemudahan dan kemungkinan kinerja pengelompokan berdasarkan tanggal dan jam, tetapi seberapa buruk suatu praktik dikelompokkan berdasarkan datepart (kami menggunakan MS SQL tetapi kami akan meminta jutaan baris) atau harus kami pertimbangkan hanya dimensi tanggal dan waktu yang sangat sederhana dengan angka tidak lebih dari jam, hari, bulan dan tahun untuk sebagian besar karena sebagian besar literal seperti Senin tidak akan berarti banyak ketika zona waktu ikut bermain?

Pertama...

Memisahkan Datime/Timemenjadi Datedimensi dan Timedimensi pasti cara untuk pergi.

Untuk mengelola beberapa zona waktu, Anda harus menduplikasi DateKeydan TimeKeyagar Anda memiliki yang berikut ini:

• LocalDateKey
• LocalTimeKey
• UtcDateKey
• UtcTimeKey

Kamu bilang...

Masalah saya dengan semua itu adalah bahwa 11:00 PM pada hari Selasa, 31 Desember 2013 di UTC adalah Rabu, 1 Januari 2014 di semua zona waktu setelah UTC + 2.

Dengan memiliki 4 kolom yang saya daftarkan di atas Anda, akan dapat bergabung dengan tabel fakta ke dimensi Tanggal dan / atau Menggunakan Table Alias (dalam terminologi Kimball tabel-tabel dimensi alias ini dikenal sebagai "Dimensi Bermain Peran"), jadi Anda akan memiliki sesuatu seperti berikut:

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

Sebagai penutup ...

Saat Anda membangun data mart, dan bukan database OLTP, pembuatan waktu Lokal dan Utc harus dilakukan dalam ETL Anda , BUKAN dalam aplikasi sisi klien karena alasan berikut (selain dari lokalisasi waktu UTC ke perspektif pembaca laporan):

• Memiliki penghitungan berada di kueri menempatkan beban kinerja ekstra pada mereka, dikalikan dengan berapa kali Anda harus menjalankan kata query untuk setiap laporan yang Anda miliki (ini penting ketika membaca jutaan baris)
• Beban ekstra untuk memastikan perhitungan dipertahankan dengan benar di setiap kueri (terutama saat Anda memperhitungkan waktu musim panas)
• Cegah pemindaian rentang indeks apa pun yang menjadi bagian kolom, karena Anda akan melakukan penghitungan pada kolom yang memaksa kueri untuk melakukan pemindaian indeks alih-alih mencari (yang biasanya lebih mahal karena setiap halaman data perlu dibaca); ini dikenal sebagai non- sargable .
  • Edit karena komentar: Ini berlaku jika Anda mendorong konversi ke bawah ke permintaan sebenarnya .
• Menggunakan konsep memiliki tanggal dan waktu UTC tambahan yang tersedia, tidak ada yang menghentikan Anda dari mengambil konsep ini dan memperpanjangnya dengan menyebutnya StandardisedDateKey, atau CorporateHQDateKey, di mana alih-alih tabel tanggal UTC yang Anda distandarisasi berdasarkan beberapa bisnis lain yang disepakati standar
• Memiliki dua jenis kolom terpisah (Lokal dan UTC), memungkinkan untuk perbandingan berdampingan melintasi jarak geografis. Pikirkan -> seseorang di Australia memasuki catatan yang timestamped dengan baik lokal dan UTC, seseorang di New York membaca laporan dengan lokal (Australia) tanggal dan waktu dan representasi New York dari tanggal UTC dan waktu, dengan demikian melihat sesuatu yang rekan Australia mereka lakukan pada tengah hari (waktu Australia) terjadi di tengah malam waktu mereka (waktu New York). Perbandingan waktu ini sangat diperlukan dalam bisnis multi-nasional.

Saya meminta maaf sebelumnya atas singkatnya jawaban ini dan berencana untuk menguraikan ketika saya tidak di tempat kerja.

Tentunya ada keuntungan memiliki tabel tanggal dan waktu karena memungkinkan agregasi data Anda dengan mudah. Dalam banyak kasus, ini adalah cara paling sederhana untuk mengurutkan berdasarkan bulan atau hari kerja hal-hal seperti itu. Namun ini tidak serta merta menggantikan kegunaan cap waktu. Dalam kasus khusus Anda, cap waktu UTC. Setelah Anda memiliki cap waktu itu, yang harus Anda lakukan adalah mengubahnya ke waktu lokal di lapisan laporan atau presentasi. Untuk menghindari pemindaian jangkauan, pastikan Anda juga mengubah rentang permintaan Anda ke waktu UTC.

Jika ada pertanyaan atau komentar lain, jangan ragu untuk bertanya.