Kiến trúc dàn dữ liệu

Đây là một câu hỏi về thiết kế kho dữ liệu. Chúng tôi đang thiết lập một kho dữ liệu chăm sóc sức khỏe và bắt đầu với 2 hệ thống nguồn chính kết hợp với khoảng 20.000 bảng và 2 TB dữ liệu. 1) Đó là dữ liệu có chiều cao 2) Chúng tôi sẽ không ảnh hưởng nhiều đến các hệ thống OLTP

Chúng tôi đã chọn một thiết kế Kimball gia tăng. Câu hỏi của tôi là, nếu tất cả các dữ liệu được dàn dựng, sau đó sắp xếp vào các phần chèn / cập nhật và đưa vào kho dữ liệu. Sau đó, dữ liệu dàn sẽ được xóa cho tải gia tăng tiếp theo.

Điều này để lại cho bạn 1 bản sao của dữ liệu.

Phương pháp khác là tăng dần nó thành dàn, sắp xếp nó vào các phần chèn / cập nhật và lưu trữ nó ở cùng định dạng với các hệ thống nguồn. Sau đó, chúng tôi sẽ kết hợp dữ liệu từ các hệ thống nguồn vào kho dữ liệu từ bản sao đầy đủ.

Điều này về cơ bản sẽ để lại cho bạn 2 bản sao của dữ liệu, một bản dưới dạng các hệ thống nguồn và 1 được tải vào kho dữ liệu thực tế.

Thực hành tốt nhất cho việc này là gì? Ban đầu tôi nghĩ tốt nhất là chỉ lưu trữ bản sao trong kho dữ liệu và xóa các bảng nguồn mỗi lần tải.

Tuy nhiên, trong trường hợp đó, nếu bạn phải quay lại kích thước hiện có và thêm một cột, bạn sẽ phải tải lại tất cả các bảng nguồn phụ thuộc. Thêm vào đó bạn sẽ mất lịch sử?

Có vẻ như thực sự không hiệu quả để lưu trữ hai lần mặc dù .... chỉ muốn một số suy nghĩ về thiết kế, kinh nghiệm của bạn và thực hành tốt nhất.

Cá nhân tôi có các bảng phân tầng để trích xuất, chuyển đổi và lưu trữ dữ liệu liên tục.

Việc bạn thực hiện xuất khẩu đầy đủ hay tải gia tăng sẽ phụ thuộc vào công cụ bạn có, chiến lược của bạn và liệu lược đồ ứng dụng và dữ liệu của bạn có hỗ trợ hay không. Đôi khi bạn không thể tránh xuất khẩu đầy đủ.

Thêm một cột vào một thứ nguyên không phải là một vấn đề lớn, nhưng việc lấp đầy dữ liệu lịch sử có thể rất khó khăn hoặc có thể không thể thực hiện được. Cố gắng xây dựng lại cách ứng dụng nhìn vào một thời điểm hồi tưởng sẽ là một công việc chính. Bạn sẽ cần một trường hợp rất tốt để biện minh cho điều đó.

Tất cả những điều bạn đề cập là có thể, nhưng chỉ bạn mới có thể quyết định xem chi phí / lợi ích có xứng đáng hay không.

Chúng tôi thường thấy rằng ODS (Kho lưu trữ dữ liệu hoạt động, bản sao của hệ thống nguồn) trước tiên rất hữu ích để phân lớp quy trình ETL của bạn (cho vay để bảo trì và khắc phục sự cố), nhưng sau đó trở nên rất hữu ích cho báo cáo hoạt động.

Bạn cũng có khả năng thêm các chỉ mục và viết các truy vấn điên rồ. chống lại nó

Bạn cũng có thể sử dụng nó để khắc phục sự cố (vì bạn có một bản sao dữ liệu mà bạn đã tải từ thay vì một mục tiêu di động trong nguồn thực). Sau đó, nếu bạn có thể nhận được các công cụ sao chép của mình để đưa nguồn cấp dữ liệu vào ODS cứ sau năm phút, bạn có một kiến ​​trúc rất hữu ích.

Hãy quên đi 'không hiệu quả' ở đây. Bạn sẽ gặp phải sự kém hiệu quả khi bạn không thể khắc phục sự cố quy trình ETL của mình vì nó bị nén thành một lớp và bạn không có lớp ODS để khắc phục sự cố.

Nó phụ thuộc rất nhiều vào thông số kỹ thuật của bạn. Không gian lưu trữ không quá đắt đối với một dự án như thế này (bảng 20K sẽ yêu cầu ngân sách phát triển lớn hơn nhiều).

Hãy nhớ rằng DWH thường nên duy trì thêm lịch sử của hệ thống Nguồn, vì vậy, nếu bạn nghĩ rằng bạn sẽ muốn nhìn lại và thêm một cột thứ nguyên mới hoặc một thực tế mới, một đề xuất tốt là xây dựng Kho dữ liệu giữa Nguồn của bạn Hệ thống và Bảng dữ liệu Kimball của bạn.

Bạn có được lịch sử tài liệu và chi tiết và linh hoạt hơn trên lớp Data Mart, cần phải ở gần người dùng và do đó cần rất nhiều tính linh hoạt khả thi.