data-warehouse-design-eae

18 7 0
data-warehouse-design-eae

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Data warehouse Design Các khái niệm 1.1 Định nghĩa Data Warehouse Data warehouse loại data management system design để hỗ trợ hoạt động Business intelligence , đặc biệt analytics Các data warehouses nhằm mục địch thực truy vấn phân tích Khả phân tích data warehouse cho phép tổ chức thu business insights có giá trị từ liệu họ để cải thiện việc đưa định 1.2 Định nghĩa Businness Intellgence BI(Business Intelligence is a set of a processes, architectures, technologies chuyển đồi liệu thành thông tin có ích chuyển hóa thành hoạt động business mang lại lợi ích Lợi ích hệ thống Data Warehouse Business Intelligence Data warehouse mang lại nhiều lợi ích quan trọng: Cung cấp thông tin business nâng cao Tiết kiệm thời gian Nâng cao chất lượng quán liệu Cung cấp lợi cạnh tranh Nâng cao trải nghiệm khách hàng Kiến trúc hệ thống Data Warehouse Business Intelligence 3.1 Data source – Dữ liệu nguồn Dữ liệu nguồn đồ vào DW chia thành nhóm chính: Production data : Các loại data đền từ hệ thống vận hành doanh nghiệp Internal data : Trong tổ chức, khách hàng lưu giữ báo cáo, progiles customer, giữ liệu nội khác Archived data : Dữ liệu lưu trữ định kì hệ thống vận hành External data : Dữ liệu liệu từ external source tạo phận ngoài, liệu liệu thống kế liên quan đến lĩnh vực doanh vực hay giám đốc sử dụng Dữ liệu nguồn hệ quản trị sở liệu MySQL, Oracle, MSSQL, 3.2 Data Warehouse – Kho liệu tập trung Một DW kho liệu trung tâm, nơi liệu lưu trữ từ nhiều nguồn không đồng Hệ thống DW lưu trữ liệu liệu lịch sử DW đọc, khơng sử dụng để ghi hay update thơng thường DW có tính chất điển hình: Subject-Orieted: Mục tiêu kho liệu nhằm mơ hình hóa phân tích liệu Vì liệu data warehouse cung cấp nhìn ngắn gọn đơn giản chủ đề cụ thể customer, product, hay sale, inventory Hình 1.1 Intergrated Hệ thống DW tích hợp liệu từ nhiều nguồn liệu RDBMS, flat files Vì DW địi hỏi việc làm tích hợp suốt trình lưu trữ liệu để đám bảo tính quán nguồn liệu khác Hình 1.2 Time-Variant Dữ liệu lịch sử giữ data warehouse Dữ liệu lịch truy xuất từ tháng, 12 tháng, chí 36, 48 tháng trước Non-volatile: Một liệu đưa vào data warehouse, liệu khơng thay đổi Hình 1.3 3.3 Tầng Business Intelligence(BI) BI bao gồm loạt công cụ ứng dụng phương thức cho phép tổ chức thu thập thông tin từ hệ thống nội nguồn bên ngoài; chuẩn bị sẵn sàng chp việc phân tích, phát triển chạy truy vấn liệul tạo báo cáo, bảng điều khiển trực quan hóa liệu Hình 1.4 Thiết kế conceptual hệ thống Data Warehouse 4.1 MultiDim model Mơ hình hóa Data warehouse q trình thiết kế lược đồ thơng tin chi tiết tóm tắt DW Mục tiêu mơ hình hóa DW phát triển lược đồ mơ tả thực tế mà DW cần hỗ trợ Hình 1.5 Phases in data warehouse design Mơ hình hóa conceptual DW địi hỏi mơ hình rõ ràng Vì hệ thống này, MultiDim model sử dụng model đủ mạnh để biểu diễn mức conceptual tất yếu tố cần thiết kho liệu OLAP applications (dimensions, hierarchies, facts với measures liên quan) 4.2 Key concepts in MultiDim model Các thành phần mơ hình MultiDim : Schema : bao gồm tập hợp dimensions tập facts Dimension : bao gồm level nhiều phân cấp Level : mức tương đương với loại thực thể tỏng ER model Fact : liên quan đến vài levels(ví dụ: Sales fact liên quan đến Employee, Customer, Order, Product Time levels) Hierarchy : bao gồm số levels liên quan Level thấp gọi con, level cao gọi cha ( ví dụ lelvel Product liên quan đến lelvel cha Category) Thiết kế logical hệ thống Data Warehouse 5.1 Cách tiếp cận biểu diễn mơ hình MultiDim Dựa cách mà data cube lưu trữ, vài cách tiếp cận phổ biển để implement mô hình đa chiều, là: Relational OLAP (ROLAP) : lưu trữ liệu CSDL quan hệ, hỗ trợ phần mở rộng cho SQL phương pháp truy cập đặc biệt để triển khai hiệu mơ hình liệu đa chiều hoạt động liên quan Multidimensional OLAP (MOLAP): lưu trữ liệu cấu trúc liệu đa chiều chuyện biệt( ví dụ arrays) triển khai hoạt động OLAP cấu trúc liệu Hybrid OLAP ( HOLAP) : kết hợp cách tiếp cận ROLAP MOLAP Mỗi cách tiếp cận có ưu, nhược điểm riêng Tuy vào mục đích, yêu cầu mà lựa chọn phù hợp cách tiếp cận 5.2 Thiết kế thành phần Data Warehouse 5.2.1 Các lược đồ CSDL Data Warehouse Biểu diễn liệu quan hệ mơ hình đa chiều dựa lược đồ : Star schema: bảng fact trung tâm set bảng dimensions Snowflake schema: tránh dư thừa start schemas cách normalize bảng dimensions Vì mà bảng dimensions biểu diễn vài bảng liên quan ràng buộc Starflake schema: kết hợp star snowflake schema Một vài abnrg dimensions normailize, số bảng khác khơng Constellation schema: có nhiều bảng fact chia sẻ bảng dimension tables Star schema Là mơ hình đơn giàn sử dụng DWH Star 3w schema sử dụng rộng rãi data marts Hình 1.6 Ví dụ star schema Với star schema,các bảng dimensions star schema thơng thường khơng chuẩn hóa Vì mà có dư thừa liệu Tuy nhiên, điểm mạnh star schema tốc độ truy vấn Snowflake schema Lược đồ snowflake tránh thừa liệu lược đồ star cách chuẩn hóa bảng dimension Vì thế, dimension biểu diễn vài bảng liên quan ràng buộc toàn vẹn tham chiếu Hình 1.7 Ví dụ snowflake schema Việc chuẩn hóa bang khiến việc maintain dễ dàng tối ưu không gian lưu trữ, Tuy nhiên performance bị ảnh hưởng có nhiều phép join thực truy vấn yêu cầu duyệt qua phân cấp Starflake schema Star schema kết hợp star snowflake schemas Một vài dimensions chuẩn hóa, số khác lại khơng Constellation schema Constellation schema có nhiều bảng fact chia sẻ bảng dimensions Hình 1.x Ví dụ constellation chema 5.2.2 Thiết kế CSDL chủ đề (Data Mart) Data Mart coi DW thu nhỏ, tập trung vào khu vực chức tổ chức Dữ liệu data mart tập hợp liệu lưu trữ DW Data Mart thiết kế để sử dụng cho phận, đơn vị, nhóm người dùng cụ thể( Sales, Marketing, HR Finance ) Một data mart tạo từ data warehouse theo hướng tiếp cận top-down ngược lại xây dựng từ data sources trước xây dựng DW Có loại data marts dựa mối quan hệ với DW data sources sử dụng để tạo hệ thống : dependent, independent, hybrid Dependent Data Marts Được tạo từ enterprise DW tồn Đây cách tiếp cận top-down việc lưu trữ tất liệu business vị trí trung tâm, sau trích xuất sau phần liệu xác định rõ ràng để phân tích Từ DW, tập hợp liệu cụ thể tổng hợp, tái cấu trúc load vào data mart Nó logical view tập vật lý DW • Logical view : bảng/view virtual tách biệt riêng mặt logic, khơng mặt vật lý khỏi kho liệu • Physical subset : liệu trích xuất vào sở liệu vật lý riêng biệt với DW Independent Data Marts Một independent Data Mart hệ thống độc lập, tạo mà không sử dụng DW, tập trung vào chủ đề business function Dữ liệu extract từ internal external data source, hai, xử lý, load vào data mart repository Xây dựng phát triển independent data mart khơng khó Chúng có lợi đạt dược mục tiêu ngắn hạn trở nên cồng kềnh khó quản lý nhu cầu kinh doanh mở rộng trở nên phức tạp Hybrid Data Marts Kết hợp liệu từ DW tồn hệ thống hoạt động khác Tương tự DW, data mart tổ chức cách sử dụng star, snowflake, starflake, lược đồ khác Lợi ích star schema việc sử dụng phép join phụ thuộc bảng dimensions 5.2.3 Thiết kế CSDL tích hợp(Enterprise Model-EM) 5.2.3.1 Hướng tiếp cận Việc thiết kế CSDL tích hợp khơng phải việc dễ dàng Có cách tiệp cận để xây dựng nên CSDL tích hợp Top-down : Xây dựng DW từ nhiều data source, đòi hỏi có nhìn tổng quan hiểu biết nghiệp vụ Bottom-up : Lây data mart làm trung tâm, kết hợp data mart lại để có DW Việc xây dựng nên data mart nhanh, nhiên việc kết hợp khơng đơn giản Khơng có cách tiếp cận tốt cả, tùy vào quy mô, thời gian, nguồn lực doanh nghiệp mà chọn cách tiếp cận phù hợp Top-down Với cách tiếp cận này, mơ hình CSDL coi mơ hình có tính thích ứng mạnh với thay đổi business Đó lí mà tổ chức lớn thích làm theo cách tiếp cận Việc tạo data mart từ data warehouse dễ Tuy nhiên, cost time để desig maintain cao, điểm yếu với cách tiếp cận Bottom-up Với cách tiếp cận này, report tạo nhanh chóng Cost time để thiết kể mơ hình tương đối thấp 5.2.3.2 Các loại Data Warehouse Phụ thuộc vào nhiều yếu tố lượng liệu, độ phức tạp phân tích, vấn đề bảo mật hay ngân sách mà có options khác để thiết kế hệ thống Traditional data warehouse Yêu cầu cung cấp tài nguyên IT máy chủ, phần mềm on-premise, DW truyền thống đặt chỗ để thu thập, lưu trữ, phân tích liệu Virtual data warehouse Được sử dụng thay cho DW cổ điển Về bản, nhiều DB connect ảo với nhau, mà có truy vấn hệ thống Cloud data warehouse Cloud DW khái niệm thay đổi Cloud DW thu thập, lưu trữ phân tích liệu môi trường cloud mà không cần đầu từ vào phần cứng nhân viên IT chuyên biệt Cloud DW xây dựng để làm việc với liệu lớn Tuy nhiên DW xây tảng cloud khác khác Google, Oracle, Microsoft “ Classic Cloud DW Analysis 5.2.4 Thiết kế CSDL trung chuyển (Data Staging Area – DSA) Kho liệu trung chuyển nơi liệu lưu trữ làm thực bược biến đổi trước đưa vào DW Khu vực sử dụng để xử lý liệu q trình trích xuất, biến đổi tải (ETL) DSA thiết kế lợi ích mà mang lại Động lực ta sử dụng DSA tăng hiệu trình xử lý ETL, đồng thời đám bảo tính tồn vẹn liệu hỗ trợ hoạt động chất lượng liệu Các chức DSA: Consolidation Một chức DSA hợp liệu từ nhiều nguồn liệu Chức DSA hoạt động “bể” lớn liệu từ nhiều hệ thống nguồn đượcc tạm thời đặt để xử lý thêm Recoverability Dữ liệu cần phục hồi trường hợp bị hỏng Vì bước DSA đóng vai trị điểm khôi phục trường hợp liệu bị hỏng giai đoạn sau Backup Backup cho phép lưu, nén lưu trữ liệu xuống cập CSDL Auditing Dữ liệu DSA làm q trình đánh giá trở nên đơn gian nhiều cách so sánh tệp đầu vào ban đầu( với quy tắc chuyển đổi) với liệu đầu Data quality Chất lượng liệu đóng vai trị quan trọng DW DSA nơi mà liệu làm sạch, kiểm tra, hợp trước đưa vào DW Điều làm giảm rủi ro mặt liệu(một số trường liệu unique bị trùng lặp, số trường mandatory bị NULL ) Thông thường, DSA thiết kế với lớp RAW STAGE Khu vực RAW, nới mà liệu nguồn đổ Dữ liệu thực bước làm chuyển hóa, sau load vào khu vực STAGE Ở khu vực STAGING bảng liệu thêm mới, bảng chứa liệu transform tổng hợp 5.2.5 Thiết kế tiến trình Thu thập, làm tích hợp liệu(ETL) Q trình ETL liệu q trình xun suốt từ DW xây dựng Quá trình ETL gồm bước: Extract – Transform – Load 5.2.5.1 Extract Là hoạt động trích xuất liệu từ hệ thống nguồn để sử dụng tiếp môi trường DW Đây hoạt đọng trình ETL Việc thiết kế tạo q trình trích xuất thường tác vụ tiêu tốn nhiều thời gian Hệ thống nguồn có thẻ phức tạp khơng có nhiều tài liệu mơ tả, việc xác định liệu cần thiết để trích xuất điều khơng dễ Dữ liệu cần trích xuất bình thường khơng lần mà cịn nhiều lần theo cách định kì để cấp tất liệu thay đổi vào kho liệu giữ cho cập nhật Hệ thống nguồn có thay đổi mặt cấu trúc pahri đảm bảo luồng liệu liệu cần lấy không thay đổi Các phương pháp trích xuất phụ thuộc nhiều vào hệ thống nguồn nhu cầu môi trường kinh doanh Phương pháp trích xuất chia thành loại : Logical Extraction Physical Extraction Logical Extraction Phương pháp có loại: Full extraction Incremental extraction Full extraction Dữ liệu trích xuất hồn tồn từ hệ thống nguồn Bởi q trình trích xuất phản ảnh tất liệu có hệ thống nguồn, nên khơng cần theo dõi thay đổi với nguồn liệu ể từ lần trích xuất thành cơng cuối Incremental extraction Tại thời điểm cụ thể, liệu có thay đổi kề từ kiện xác định rõ lịch sử trích xuất Sự kiện lần cuối liệu trích xuất kiện kinh doanh phức tạp Thông thường kiện gọi giá trị watermark Giá trị watermark timestamp id thực thể Incremental extraction đòi hỏi việc cần lưu lại giá trị kiện sau liệu trích xuất Physical Extraction Phụ thuộc vào cách chọn phương pháp trích xuất logical khả năng, hạn chế phái nguồn liệu có thẻ trích xuất vật lý hai chế online offline Online extraction Dữ liệu trích xuất trực tếp từ hệ thống nguồn Q trình trích xuất trực tiếp kết nối đến hệ thống nguồn để tự truy cập bảng hệ thống nguồn đến hệ thống lưu trữ trung gian liệu trung gian theo cách cấu hình sẵn Offline extraction Dữ liệu trích xuất khơng trực tiếp từ hệ thống nguồn xây dựng cách rõ ràng nằm bên ngồi hệ thống nguồn Dữ liệu có sẵn cấu trúc : flat files, dump files 5.2.5.2 Loading and Transform Từ góc độ kiến trúc, việc transform liệu thực theo cách: Multistage Data Transform in DW Pipelined Data Transform in DW Multistage Data Transform in DW Hình 1.8 Multistage Data Transform Dữ liệu chuyển đổi qua nhiều bước Một chiến lược thường áp dụng thực chuyển đổi hoạt độnn SQL riêng biệt tạo bảng tạm thời riêng biệt Các bảng new_table_step hình lưu trữ kết tăng dần sau bước chuyển đổi Chiến lược giúp tạo điểm checkpoint, khiến việc monitor tải khởi đọng dễ dàng Tuy nhiên, nhược điểm chiến lược việc tốn thời gian nhớ Có thể kết hợp nhiều việc chuyển đổi liệu logic thành câu lệnh SQL SQL procedure Việc cung cấp hiệu suất tốt so với việc thực đơn lẻ, độc lập bước Nhưng gây khó khăn việc khơi phục phép biến đổi không thành công Pipelined Data Transform in DW Hình 1.9 Pipelined Data Transform Chiến lược hiểu việc loading diễn loading Điều khiến trình ETL có performance cao 5.3 Thiết kế tầng khai thác phân tích thơng tin 5.3.1 Thiết kế CSDL đa chiều với OLAP 5.3.2 Thiết kế tầng khai thác phân tích thơng tin Revision #4 Created Sat, Dec 5, 2020 2:13 AM Updated Thu, Dec 16, 2021 9:57 AM by Jeng Nguyen

Ngày đăng: 08/04/2022, 09:31

Hình ảnh liên quan

Hình 1.1 - data-warehouse-design-eae

Hình 1.1.

Xem tại trang 3 của tài liệu.
Hình 1.2 - data-warehouse-design-eae

Hình 1.2.

Xem tại trang 4 của tài liệu.
Hình 1.3 - data-warehouse-design-eae

Hình 1.3.

Xem tại trang 4 của tài liệu.
Mô hình hóa Data warehouse là quá trình thiết kế các lược đồ thông tin chi tiết và tóm tắt của DW - data-warehouse-design-eae

h.

ình hóa Data warehouse là quá trình thiết kế các lược đồ thông tin chi tiết và tóm tắt của DW Xem tại trang 5 của tài liệu.
Mô hình hóa conceptual DW đòi hỏi một mô hình rõ ràng. Vì thế trong hệ thống này, MultiDim model được sử dụng vì model này đủ mạnh để biểu diễn ở mức conceptual tất cả các yếu tố cần  thiết trong kho dữ liệu và OLAP applications (dimensions, hierarchies,  - data-warehouse-design-eae

h.

ình hóa conceptual DW đòi hỏi một mô hình rõ ràng. Vì thế trong hệ thống này, MultiDim model được sử dụng vì model này đủ mạnh để biểu diễn ở mức conceptual tất cả các yếu tố cần thiết trong kho dữ liệu và OLAP applications (dimensions, hierarchies, Xem tại trang 6 của tài liệu.
Với star schema,các bảng dimensions trong star schema thông thường không được chuẩn hóa - data-warehouse-design-eae

i.

star schema,các bảng dimensions trong star schema thông thường không được chuẩn hóa Xem tại trang 8 của tài liệu.
Lược đồ snowflake tránh được sự dữ thừa dữ liệu của lược đồ star bằng cách chuẩn hóa các bảng dimension - data-warehouse-design-eae

c.

đồ snowflake tránh được sự dữ thừa dữ liệu của lược đồ star bằng cách chuẩn hóa các bảng dimension Xem tại trang 9 của tài liệu.
Hình 1.x Ví dụ constellation chema - data-warehouse-design-eae

Hình 1.x.

Ví dụ constellation chema Xem tại trang 10 của tài liệu.
Hình 1.8 Multistage Data Transform - data-warehouse-design-eae

Hình 1.8.

Multistage Data Transform Xem tại trang 17 của tài liệu.