Xử lý múi giờ trong dữ liệu mart / kho

Chúng tôi đang bắt đầu thiết kế các khối xây dựng của một trung tâm dữ liệu / kho dữ liệu và chúng tôi cần có khả năng hỗ trợ tất cả các múi giờ (khách hàng của chúng tôi đến từ khắp nơi trên thế giới). Từ việc đọc các cuộc thảo luận trực tuyến (và trong sách), một giải pháp chung dường như là có một chiều ngày và thời gian riêng biệt cũng như dấu thời gian trong các bảng thực tế.

Tuy nhiên, câu hỏi tôi gặp khó khăn khi trả lời là kích thước ngày và giờ thực sự tốt cho tôi khi xem xét các yêu cầu múi giờ động của tôi? Thứ nguyên thời gian có ý nghĩa hơn một chút nhưng tôi gặp khó khăn với thứ nguyên ngày. Cách tiếp cận thiết kế chung cho thứ nguyên ngày thường bao gồm các thuộc tính như tên ngày, ngày trong tuần, tên tháng, v.v. Vấn đề tôi gặp phải với tất cả đó là 11:00 PM vào thứ ba, ngày 31 tháng 12 năm 2013 tại UTC là thứ tư , Ngày 1 tháng 1 năm 2014 trong tất cả các múi giờ sau UTC + 2.

Vì vậy, nếu tôi sẽ phải thực hiện tất cả các chuyển đổi múi giờ này trên mỗi và mọi truy vấn (và báo cáo) thì điểm cần có và lưu trữ các thuộc tính này mà tôi có thể sẽ không bao giờ sử dụng (có vẻ như) là gì? Một số người đề nghị có các hàng thực tế cho từng múi giờ nhưng điều đó có vẻ vô lý với tôi. Chúng tôi cần có khả năng lưu trữ hàng triệu hồ sơ mỗi tháng.

Những người khác đề nghị có một bảng cầu múi giờ, mặc dù có ý nghĩa, nó cũng có vẻ như phức tạp hơn và tham gia thêm để hoàn thành một cái gì đó mà các ứng dụng và báo cáo khách hàng của tôi có thể dễ dàng tìm ra từ một ngày (báo cáo sẽ chủ yếu dựa trên web nơi có vô số thư viện để hỗ trợ chuyển đổi, hiển thị và định dạng ngày).

Điều duy nhất tôi có thể nghĩ đến là sự dễ dàng và có thể là hiệu suất của việc phân nhóm theo ngày và giờ nhưng thực tiễn của việc thực hành theo nhóm theo ngày như thế nào (chúng tôi đang sử dụng MS SQL nhưng chúng tôi sẽ truy vấn hàng triệu hàng) hoặc chúng tôi nên xem xét chỉ các kích thước ngày và giờ cực kỳ đơn giản với số lượng không nhiều hơn số giờ, ngày, tháng và năm đối với hầu hết các phần như chữ thứ hai sẽ không có ý nghĩa nhiều khi múi giờ phát huy tác dụng?

Thứ nhất ...

Tách Datime/Timethành một Datechiều và một Timechiều chắc chắn là con đường để đi.

Để quản lý nhiều múi giờ, bạn cần nhân đôi DateKeyvà TimeKeyđể bạn có các mục sau:

• LocalDateKey
• LocalTimeKey
• UtcDateKey
• UtcTimeKey

Bạn nói...

Vấn đề tôi gặp phải với tất cả đó là 11:00 PM vào thứ ba ngày 31 tháng 12 năm 2013 tại UTC là thứ Tư, ngày 1 tháng 1 năm 2014 trong tất cả các múi giờ sau UTC + 2.

Bằng cách có 4 cột tôi đã liệt kê ở trên, bạn sẽ có thể tham gia bảng thực tế vào thứ nguyên Ngày và / hoặc Thời gian bằng cách sử dụng Bí danh Bảng (theo thuật ngữ Kimball, các bảng kích thước bí danh này được gọi là "Kích thước đóng vai"), vì vậy bạn sẽ có một cái gì đó như sau:

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

Kết thúc ...

Khi bạn đang xây dựng một trung tâm dữ liệu chứ không phải cơ sở dữ liệu OLTP, việc tạo thời gian cục bộ và thời gian Utc nên được thực hiện trong ETL của bạn , KHÔNG phải trong bất kỳ ứng dụng phía máy khách nào vì những lý do sau (ngoài việc bản địa hóa thời gian UTC sang quan điểm của người đọc báo cáo):

• Việc tính toán nằm trong bất kỳ truy vấn nào đặt thêm gánh nặng hiệu suất cho chúng, nhân với số lần bạn phải chạy truy vấn đã nói cho bất kỳ báo cáo nào bạn có (điều này quan trọng khi đọc hàng triệu hàng)
• Thêm gánh nặng đảm bảo tính toán được duy trì chính xác trong mỗi truy vấn (đặc biệt là khi bạn tính đến thời gian tiết kiệm ánh sáng ban ngày)
• Ngăn chặn quét phạm vi của bất kỳ chỉ mục nào mà cột là một phần của, vì bạn sẽ thực hiện một phép tính trên cột để buộc các truy vấn thực hiện quét chỉ mục thay vì tìm kiếm (thường tốn kém hơn khi cần đọc từng trang dữ liệu); này được biết đến như là không sargable .
  • Chỉnh sửa do nhận xét: Điều này áp dụng nếu bạn đẩy chuyển đổi xuống truy vấn thực tế .
• Sử dụng khái niệm có sẵn ngày và giờ UTC bổ sung, không có gì ngăn bạn lấy khái niệm này và mở rộng nó bằng cách gọi nó StandardisedDateKey, hoặc CorporateHQDateKey, thay vì bảng ngày UTC bạn chuẩn hóa dựa trên một số tiêu chuẩn kinh doanh khác đã thỏa thuận
• Có hai loại cột riêng biệt (Địa phương và UTC), cho phép so sánh song song giữa các khoảng cách địa lý. Nghĩ -> một người nào đó ở Úc đi vào một kỷ lục được timestamped với cả hai địa phương và UTC, một người nào đó ở New York lần đọc báo cáo với (Australia) ngày và thời gian địa phương và đại diện New York từ ngày UTC và thời gian, do đó nhìn thấy một cái gì đó đối tác Úc của họ đã làm vào giữa ngày (giờ Úc) xảy ra vào giữa đêm thời gian của họ (giờ New York). Sự so sánh thời gian này là không thể thiếu trong các doanh nghiệp đa quốc gia.

Tôi xin lỗi trước thời hạn vì sự ngắn gọn của câu trả lời này và lên kế hoạch chi tiết khi tôi không làm việc.

Có nhiều lợi thế nhất định để có bảng ngày và thời gian vì chúng cho phép tổng hợp dữ liệu của bạn dễ dàng. Trong nhiều trường hợp, đó là cách đơn giản nhất để sắp xếp theo tháng hoặc ngày làm việc những thứ thuộc về bản chất đó. Tuy nhiên, điều này không nhất thiết thay thế sự hữu ích của dấu thời gian. Trong trường hợp cụ thể của bạn một dấu thời gian UTC. Khi bạn có dấu thời gian đó, tất cả những gì bạn phải làm là thay đổi thời gian đó thành giờ địa phương trong báo cáo hoặc lớp trình bày. Để tránh quét phạm vi, hãy đảm bảo bạn cũng đang chuyển đổi phạm vi yêu cầu của mình sang thời gian UTC.

Nếu bất kỳ câu hỏi hoặc ý kiến ​​khác cảm thấy tự do để hỏi.