Phát triển một cơ sở lưu trữ là một công việc lâu dài và nghiêm túc.
Phần lớn vòng đời của một dự án phụ thuộc vào việc mô hình đối tượng và cấu trúc cơ sở được nghĩ ra ngay từ đầu như thế nào.
Cách tiếp cận được chấp nhận rộng rãi đã và vẫn có nhiều lựa chọn khác nhau để kết hợp sơ đồ sao với dạng chuẩn ba. Theo quy định, theo nguyên tắc: dữ liệu ban đầu - 3NF, trưng bày - ngôi sao. Cách tiếp cận này, đã được thử nghiệm theo thời gian và được hỗ trợ bởi số lượng lớn nghiên cứu, là điều đầu tiên (và đôi khi là duy nhất) xuất hiện trong đầu một chuyên gia DWH có kinh nghiệm khi nghĩ về một kho phân tích sẽ trông như thế nào.
Mặt khác, hoạt động kinh doanh nói chung và yêu cầu của khách hàng nói riêng có xu hướng thay đổi nhanh chóng, dữ liệu có xu hướng phát triển cả về “chiều sâu” và “chiều rộng”. Và đây là lúc nhược điểm chính của ngôi sao xuất hiện - hạn chế mềm dẻo.
Và nếu trong cuộc sống yên tĩnh và ấm cúng của bạn với tư cách là nhà phát triển DWH, đột nhiên:
- nhiệm vụ nảy sinh “phải làm ít nhất điều gì đó một cách nhanh chóng, và sau đó chúng ta sẽ thấy”;
- một dự án phát triển nhanh chóng xuất hiện, với việc kết nối các nguồn mới và làm lại mô hình kinh doanh ít nhất một lần một tuần;
- một khách hàng đã xuất hiện, người không biết hệ thống sẽ trông như thế nào và cuối cùng nó sẽ thực hiện những chức năng gì, nhưng sẵn sàng thử nghiệm và tinh chỉnh một cách nhất quán kết quả mong muốn trong khi luôn tiến gần hơn đến kết quả đó;
- Người quản lý dự án ghé vào với một tin vui: “Và bây giờ chúng tôi đã có Agile!”
Hoặc nếu bạn chỉ quan tâm đến việc tìm ra cách khác để có thể xây dựng cơ sở lưu trữ - chào mừng bạn đến với phần cắt!
"linh hoạt" nghĩa là gì?
Trước tiên, hãy xác định những thuộc tính mà một hệ thống phải có để được gọi là “linh hoạt”.
Riêng biệt, điều đáng nói là các thuộc tính được mô tả phải liên quan cụ thể đến hệ thống, không phải quá trình sự phát triển của nó. Do đó, nếu bạn muốn đọc về Agile như một phương pháp phát triển, tốt hơn nên đọc các bài viết khác. Ví dụ như ngay trên Habré có rất nhiều tài liệu thú vị (như и Và ).
Điều này không có nghĩa là quá trình phát triển và cấu trúc của kho dữ liệu hoàn toàn không liên quan. Nhìn chung, việc phát triển kho lưu trữ Agile cho kiến trúc linh hoạt sẽ dễ dàng hơn đáng kể. Tuy nhiên, trên thực tế, thường có các lựa chọn phát triển Agile của DWH cổ điển theo Kimbal và DataVault - theo Waterfall, hơn là sự trùng hợp đáng mừng về tính linh hoạt ở hai hình thức của nó trên một dự án.
Vậy, lưu trữ linh hoạt nên có những khả năng gì? Có ba điểm ở đây:
- Giao hàng sớm và xử lý nhanh chóng - điều này có nghĩa là lý tưởng nhất là phải có được kết quả kinh doanh đầu tiên (ví dụ: báo cáo hoạt động đầu tiên) càng sớm càng tốt, nghĩa là ngay cả trước khi toàn bộ hệ thống được thiết kế và triển khai hoàn chỉnh. Hơn nữa, mỗi lần sửa đổi tiếp theo cũng sẽ mất ít thời gian nhất có thể.
- Tinh chỉnh lặp đi lặp lại - điều này có nghĩa là mỗi cải tiến tiếp theo lý tưởng nhất là không ảnh hưởng đến chức năng đang hoạt động. Chính thời điểm này thường trở thành cơn ác mộng lớn nhất đối với các dự án lớn - sớm hay muộn, các đối tượng riêng lẻ bắt đầu có nhiều kết nối đến mức việc lặp lại hoàn toàn logic trong một bản sao gần đó trở nên dễ dàng hơn là thêm một trường vào bảng hiện có. Và nếu bạn ngạc nhiên rằng việc phân tích tác động của các cải tiến đối với các đối tượng hiện có có thể mất nhiều thời gian hơn bản thân các cải tiến, thì rất có thể bạn chưa làm việc với kho dữ liệu lớn trong ngân hàng hoặc viễn thông.
- Luôn thích ứng với những yêu cầu thay đổi của doanh nghiệp - cấu trúc đối tượng tổng thể phải được thiết kế không chỉ có tính đến khả năng mở rộng mà còn với kỳ vọng rằng hướng mở rộng tiếp theo này thậm chí không thể mơ tới ở giai đoạn thiết kế.
Và đúng vậy, việc đáp ứng tất cả các yêu cầu này trong một hệ thống là có thể (tất nhiên, trong một số trường hợp nhất định và với một số hạn chế).
Dưới đây tôi sẽ xem xét hai phương pháp thiết kế linh hoạt phổ biến nhất cho kho dữ liệu - Mô hình neo и Kho dữ liệu. Bị loại khỏi khung là các kỹ thuật xuất sắc, chẳng hạn như EAV, 6NF (ở dạng thuần túy) và mọi thứ liên quan đến giải pháp NoSQL - không phải vì chúng tệ hơn theo cách nào đó, và thậm chí không phải vì trong trường hợp này bài viết sẽ đe dọa thu được khối lượng của chất phân tán trung bình. Chỉ là tất cả những điều này liên quan đến các giải pháp thuộc một lớp hơi khác - hoặc đến các kỹ thuật mà bạn có thể sử dụng trong các trường hợp cụ thể, bất kể kiến trúc tổng thể của dự án của bạn (như EAV) hoặc đến các mô hình lưu trữ thông tin khác trên toàn cầu (chẳng hạn như cơ sở dữ liệu đồ thị). và các tùy chọn khác NoSQL).
Các vấn đề của cách tiếp cận “cổ điển” và cách giải quyết chúng bằng các phương pháp luận linh hoạt
Theo cách tiếp cận “cổ điển”, ý tôi là ngôi sao cũ tốt bụng (bất kể việc triển khai cụ thể các lớp cơ bản như thế nào, mong những người theo dõi Kimball, Inmon và CDM tha thứ cho tôi).
1. Tính chính xác của các kết nối
Mô hình này dựa trên sự phân chia rõ ràng dữ liệu thành Kích thước и sự thật. Và điều này, chết tiệt, là hợp lý - xét cho cùng, việc phân tích dữ liệu trong phần lớn các trường hợp bắt nguồn từ việc phân tích các chỉ số (sự kiện) nhất định trong các phần (kích thước) nhất định.
Trong trường hợp này, các kết nối giữa các đối tượng được thiết lập dưới dạng mối quan hệ giữa các bảng bằng khóa ngoại. Điều này trông khá tự nhiên, nhưng ngay lập tức dẫn đến hạn chế đầu tiên về tính linh hoạt - định nghĩa chặt chẽ về số lượng của các kết nối.
Điều này có nghĩa là ở giai đoạn thiết kế bảng, bạn phải xác định chính xác cho từng cặp đối tượng liên quan xem chúng có thể liên kết nhiều-nhiều hay chỉ 1-nhiều và “theo hướng nào”. Điều này trực tiếp xác định bảng nào sẽ có khóa chính và bảng nào sẽ có khóa ngoại. Việc thay đổi thái độ này khi nhận được yêu cầu mới rất có thể sẽ dẫn đến việc phải làm lại cơ sở.
Ví dụ: khi thiết kế đối tượng “nhận tiền”, bạn dựa vào lời thề của bộ phận bán hàng, đặt ra khả năng hành động một lần thăng chức cho một số vị trí kiểm tra (nhưng không phải ngược lại):
Và sau một thời gian, các đồng nghiệp đã giới thiệu một chiến lược tiếp thị mới mà họ có thể hành động ở cùng một vị trí nhiều chương trình khuyến mãi cùng lúc. Và bây giờ bạn cần sửa đổi các bảng bằng cách tách mối quan hệ thành một đối tượng riêng biệt.
(Tất cả các đối tượng dẫn xuất tham gia kiểm tra khuyến mãi hiện cũng cần được cải thiện).
Các mối quan hệ trong Data Vault và Anchor Model
Để tránh tình huống này hóa ra khá đơn giản: bạn không cần phải tin tưởng bộ phận bán hàng sẽ làm việc này. tất cả các kết nối ban đầu được lưu trữ trong các bảng riêng biệt và xử lý nó theo dạng nhiều-nhiều.
Cách tiếp cận này được đề xuất Dan Linstedt như một phần của mô hình Kho dữ liệu và được hỗ trợ đầy đủ Lars Rönnbäck в Mô hình neo.
Kết quả là, chúng ta có được đặc điểm nổi bật đầu tiên của các phương pháp linh hoạt:
Mối quan hệ giữa các đối tượng không được lưu trữ trong thuộc tính của thực thể cha mà là một loại đối tượng riêng biệt.
В Kho dữ liệu các bảng liên kết như vậy được gọi là liên kếtvà trong Mô hình neo - Cà vạt. Thoạt nhìn, chúng rất giống nhau, mặc dù sự khác biệt của chúng không dừng lại ở cái tên (điều này sẽ được thảo luận dưới đây). Trong cả hai kiến trúc, bảng liên kết có thể liên kết bất kỳ số lượng thực thể (không nhất thiết phải là 2).
Sự dư thừa này, thoạt nhìn, mang lại sự linh hoạt đáng kể cho việc sửa đổi. Cấu trúc như vậy trở nên chấp nhận không chỉ những thay đổi về số lượng của các liên kết hiện có mà còn đối với việc bổ sung các liên kết mới - nếu bây giờ vị trí kiểm tra cũng có liên kết đến nhân viên thu ngân đã vượt qua nó, thì sự xuất hiện của liên kết đó sẽ chỉ đơn giản là trở thành một tiện ích bổ sung trên các bảng hiện có mà không ảnh hưởng đến bất kỳ đối tượng và quy trình hiện có nào.
2. Sao chép dữ liệu
Vấn đề thứ hai được giải quyết bằng kiến trúc linh hoạt ít rõ ràng hơn và vốn có ngay từ đầu. Các phép đo loại SCD2 (kích thước của loại thứ hai thay đổi từ từ), mặc dù không chỉ có chúng.
Trong kho cổ điển, thứ nguyên thường là một bảng chứa khóa thay thế (dưới dạng PK) và một tập hợp các khóa và thuộc tính nghiệp vụ trong các cột riêng biệt.
Nếu một thứ nguyên hỗ trợ lập phiên bản, ranh giới hiệu lực của phiên bản sẽ được thêm vào tập hợp trường tiêu chuẩn và một số phiên bản xuất hiện trong kho lưu trữ cho một hàng trong nguồn (một phiên bản cho mỗi thay đổi trong thuộc tính được phiên bản).
Nếu một thứ nguyên chứa ít nhất một thuộc tính được phiên bản thay đổi thường xuyên thì số lượng phiên bản của thứ nguyên đó sẽ rất ấn tượng (ngay cả khi các thuộc tính còn lại không được lập phiên bản hoặc không bao giờ thay đổi) và nếu có một số thuộc tính như vậy thì số lượng phiên bản có thể tăng theo cấp số nhân từ số lượng của chúng. Thứ nguyên này có thể chiếm một lượng dung lượng ổ đĩa đáng kể, mặc dù phần lớn dữ liệu mà nó lưu trữ chỉ đơn giản là bản sao của các giá trị thuộc tính bất biến từ các hàng khác.
Đồng thời, nó cũng được sử dụng rất thường xuyên sự không chuẩn hóa - một số thuộc tính được cố ý lưu trữ dưới dạng giá trị chứ không phải dưới dạng liên kết đến sách tham khảo hoặc thứ nguyên khác. Cách tiếp cận này tăng tốc độ truy cập dữ liệu, giảm số lượng kết nối khi truy cập vào một thứ nguyên.
Thông thường điều này dẫn đến cùng một thông tin được lưu trữ đồng thời ở nhiều nơi. Ví dụ: thông tin về khu vực cư trú và danh mục khách hàng có thể được lưu trữ đồng thời trong các thứ nguyên “Khách hàng” và các sự kiện “Mua hàng”, “Giao hàng” và “Cuộc gọi qua Trung tâm cuộc gọi”, cũng như trong các dữ kiện “Khách hàng - Người quản lý khách hàng”. ” bảng liên kết.
Nói chung, những điều được mô tả ở trên áp dụng cho các kích thước thông thường (không được phiên bản), nhưng trong các thứ nguyên đã được phiên bản, chúng có thể có tỷ lệ khác: sự xuất hiện của một phiên bản mới của một đối tượng (đặc biệt là khi nhìn lại) không chỉ dẫn đến việc cập nhật tất cả các thứ liên quan các bảng, mà là sự xuất hiện xếp tầng của các phiên bản mới của các đối tượng liên quan - khi Bảng 1 được sử dụng để xây dựng Bảng 2 và Bảng 2 được sử dụng để xây dựng Bảng 3, v.v. Ngay cả khi không có một thuộc tính nào của Bảng 1 tham gia vào việc xây dựng Bảng 3 (và các thuộc tính khác của Bảng 2 thu được từ các nguồn khác có liên quan), việc lập phiên bản cấu trúc này ở mức tối thiểu sẽ dẫn đến chi phí bổ sung và tối đa là thêm chi phí. các phiên bản trong Bảng 3. không liên quan gì đến nó cả, và tiếp theo trong chuỗi.
3. Độ phức tạp phi tuyến của việc làm lại
Đồng thời, mỗi cửa hàng mới được xây dựng trên cơ sở một cửa hàng khác sẽ tăng số lượng vị trí mà dữ liệu có thể “phân kỳ” khi thực hiện thay đổi đối với ETL. Ngược lại, điều này dẫn đến sự gia tăng độ phức tạp (và thời lượng) của mỗi lần sửa đổi tiếp theo.
Nếu phần trên mô tả các hệ thống có quy trình ETL hiếm khi được sửa đổi, thì bạn có thể sống trong mô hình như vậy - bạn chỉ cần đảm bảo rằng các sửa đổi mới được thực hiện chính xác cho tất cả các đối tượng liên quan. Nếu việc sửa đổi diễn ra thường xuyên, khả năng vô tình “thiếu” một số kết nối sẽ tăng lên đáng kể.
Ngoài ra, nếu chúng tôi tính đến việc ETL “có phiên bản” phức tạp hơn đáng kể so với ETL “không có phiên bản”, thì sẽ rất khó tránh khỏi sai sót khi thường xuyên cập nhật toàn bộ cơ sở này.
Lưu trữ các đối tượng và thuộc tính trong Data Vault và Anchor Model
Cách tiếp cận do các tác giả của kiến trúc linh hoạt đề xuất có thể được xây dựng như sau:
Cần phải tách biệt những gì thay đổi với những gì vẫn giữ nguyên. Tức là lưu trữ khóa riêng biệt với thuộc tính.
Tuy nhiên, người ta không nên nhầm lẫn không được phiên bản thuộc tính với không thay đổi: cái đầu tiên không lưu trữ lịch sử thay đổi của nó, nhưng có thể thay đổi (ví dụ: khi sửa lỗi đầu vào hoặc nhận dữ liệu mới); cái thứ hai không bao giờ thay đổi.
Các quan điểm khác nhau về những gì chính xác có thể được coi là bất biến trong Kho dữ liệu và Mô hình neo.
Từ góc nhìn kiến trúc Kho dữ liệu, có thể coi là không thay đổi cả bộ chìa khóa - tự nhiên (TIN của tổ chức, mã sản phẩm trong hệ thống nguồn, v.v.) và thay thế. Trong trường hợp này, các thuộc tính còn lại có thể được chia thành các nhóm theo nguồn và/hoặc tần suất thay đổi và Duy trì một bảng riêng cho mỗi nhóm với một tập hợp các phiên bản độc lập.
Trong mô hình Mô hình neo coi như không thay đổi khóa thay thế duy nhất nước hoa. Mọi thứ khác (bao gồm cả khóa tự nhiên) chỉ là trường hợp đặc biệt của các thuộc tính của nó. trong đó tất cả các thuộc tính đều độc lập với nhau theo mặc định, vì vậy với mỗi thuộc tính a bàn riêng.
В Kho dữ liệu các bảng chứa khóa thực thể được gọi Hubami. Hub luôn chứa một tập hợp các trường cố định:
- Khóa thực thể tự nhiên
- Phím thay thế
- Liên kết tới nguồn
- Ghi lại thời gian thêm
Bài đăng trong Hub không bao giờ thay đổi và không có phiên bản. Nhìn bên ngoài, các trung tâm rất giống với các bảng loại bản đồ ID được sử dụng trong một số hệ thống để tạo các đại diện thay thế, tuy nhiên, bạn nên sử dụng hàm băm từ một tập hợp khóa doanh nghiệp làm đại diện thay thế trong Data Vault. Cách tiếp cận này đơn giản hóa việc tải các mối quan hệ và thuộc tính từ các nguồn (không cần tham gia trung tâm để lấy đại diện, chỉ cần tính hàm băm của khóa tự nhiên), nhưng có thể gây ra các vấn đề khác (ví dụ: liên quan đến xung đột, viết hoa và không in được) các ký tự trong khóa chuỗi, v.v. .p.), do đó nó thường không được chấp nhận.
Tất cả các thuộc tính thực thể khác được lưu trữ trong các bảng đặc biệt gọi là Vệ tinh. Một trung tâm có thể có nhiều vệ tinh lưu trữ các bộ thuộc tính khác nhau.
Việc phân bổ thuộc tính giữa các vệ tinh diễn ra theo nguyên tắc thay đổi chung — trong một vệ tinh, các thuộc tính không được phiên bản có thể được lưu trữ (ví dụ: ngày sinh và SNILS cho một cá nhân), ở một vệ tinh khác - các thuộc tính được phiên bản hiếm khi thay đổi (ví dụ: họ và số hộ chiếu), ở vệ tinh thứ ba - những thuộc tính thường xuyên thay đổi (ví dụ: địa chỉ giao hàng, danh mục, ngày đặt hàng cuối cùng, v.v.). Trong trường hợp này, việc lập phiên bản được thực hiện ở cấp độ vệ tinh riêng lẻ chứ không phải toàn bộ thực thể, do đó nên phân phối các thuộc tính sao cho sự giao nhau của các phiên bản trong một vệ tinh là tối thiểu (làm giảm tổng số phiên bản được lưu trữ ).
Ngoài ra, để tối ưu hóa quá trình tải dữ liệu, các thuộc tính thu được từ nhiều nguồn khác nhau thường được đưa vào từng vệ tinh.
Vệ tinh liên lạc với Hub thông qua khóa ngoại (tương ứng với số lượng thẻ từ 1 đến nhiều). Điều này có nghĩa là nhiều giá trị thuộc tính (ví dụ: nhiều số điện thoại liên hệ cho một khách hàng) được hỗ trợ bởi kiến trúc “mặc định” này.
В Mô hình neo các bảng lưu trữ khóa được gọi Neo. Và họ giữ:
- Chỉ có khóa thay thế
- Liên kết tới nguồn
- Ghi lại thời gian thêm
Các khóa tự nhiên theo quan điểm của Mô hình neo được xem xét thuộc tính thông thường. Tùy chọn này có vẻ khó hiểu hơn nhưng nó mang lại nhiều phạm vi hơn để xác định đối tượng.
Ví dụ: nếu dữ liệu về cùng một thực thể có thể đến từ các hệ thống khác nhau thì mỗi hệ thống sử dụng khóa tự nhiên riêng. Trong Data Vault, điều này có thể dẫn đến cấu trúc khá cồng kềnh của một số trung tâm (một trung tâm cho mỗi nguồn + một phiên bản chính thống nhất), trong khi ở mô hình Anchor, khóa tự nhiên của mỗi nguồn rơi vào thuộc tính riêng của nó và có thể được sử dụng khi tải độc lập với tất cả những người khác.
Nhưng cũng có một điểm xảo quyệt ở đây: nếu các thuộc tính từ các hệ thống khác nhau được kết hợp trong một thực thể thì rất có thể sẽ có một số thuộc tính quy tắc “dán”, theo đó hệ thống phải hiểu rằng các bản ghi từ các nguồn khác nhau tương ứng với một phiên bản của thực thể.
В Kho dữ liệu những quy tắc này rất có thể sẽ quyết định sự hình thành “trung tâm thay thế” của thực thể chính và không gây ảnh hưởng theo bất kỳ cách nào đến các Hub lưu trữ khóa nguồn tự nhiên và các thuộc tính ban đầu của chúng. Nếu tại một thời điểm nào đó các quy tắc hợp nhất thay đổi (hoặc các thuộc tính mà nó được thực hiện được cập nhật), thì việc định dạng lại các trung tâm thay thế là đủ.
В Mô hình neo một thực thể như vậy rất có thể sẽ được lưu trữ trong mỏ neo duy nhất. Điều này có nghĩa là tất cả các thuộc tính, bất kể chúng đến từ nguồn nào, sẽ bị ràng buộc với cùng một đại diện. Việc tách các bản ghi được hợp nhất sai và nói chung, việc giám sát mức độ liên quan của việc hợp nhất trong một hệ thống như vậy có thể khó khăn hơn nhiều, đặc biệt nếu các quy tắc khá phức tạp và thay đổi thường xuyên và cùng một thuộc tính có thể được lấy từ các nguồn khác nhau (mặc dù điều đó chắc chắn là không thể tránh khỏi). có thể, vì mỗi phiên bản thuộc tính đều giữ lại một liên kết tới nguồn của nó).
Trong mọi trường hợp, nếu hệ thống của bạn được cho là sẽ triển khai chức năng chống trùng lặp, hợp nhất các bản ghi và các phần tử MDM khác, cần đặc biệt chú ý đến các khía cạnh lưu trữ khóa tự nhiên trong các phương pháp linh hoạt. Có khả năng thiết kế Data Vault cồng kềnh hơn sẽ đột nhiên an toàn hơn về các lỗi hợp nhất.
Mô hình neo cũng cung cấp một loại đối tượng bổ sung được gọi là Nút thắt về cơ bản nó đặc biệt loại neo thoái hóa, chỉ có thể chứa một thuộc tính. Các nút này được cho là sẽ được sử dụng để lưu trữ các thư mục phẳng (ví dụ: giới tính, tình trạng hôn nhân, danh mục dịch vụ khách hàng, v.v.). Không giống như mỏ neo, nút thắt không có bảng thuộc tính liên quanvà thuộc tính (tên) duy nhất của nó luôn được lưu trữ trong cùng bảng với khóa. Các Node được kết nối với Anchor bằng các bảng buộc (Tie) giống như cách các Anchor được kết nối với nhau.
Không có ý kiến rõ ràng về việc sử dụng Nodes. Ví dụ, , người tích cực thúc đẩy việc sử dụng Mô hình mỏ neo ở Nga, tin rằng (không phải vô lý) rằng không một cuốn sách tham khảo nào có thể tuyên bố một cách chắc chắn rằng nó luôn luôn sẽ ở dạng tĩnh và một cấp, vì vậy tốt hơn là bạn nên sử dụng ngay Anchor chính thức cho tất cả các đối tượng.
Một điểm khác biệt quan trọng khác giữa Data Vault và mô hình Anchor là tính khả dụng thuộc tính của kết nối:
В Kho dữ liệu Các liên kết là các đối tượng chính thức giống như Hub và có thể có thuộc tính riêng. Trong Mô hình neo Các liên kết chỉ được sử dụng để kết nối các Điểm neo và không thể có thuộc tính riêng của họ. Sự khác biệt này dẫn đến các phương pháp mô hình hóa khác nhau đáng kể sự thật, điều này sẽ được thảo luận thêm.
Lưu trữ sự thật
Trước đó, chúng ta chủ yếu nói về mô hình đo lường. Sự thật ít rõ ràng hơn một chút.
В Kho dữ liệu một đối tượng điển hình để lưu trữ sự kiện là liên kết, trong đó các chỉ số thực của vệ tinh được thêm vào.
Cách tiếp cận này có vẻ trực quan. Nó cung cấp khả năng truy cập dễ dàng vào các chỉ báo được phân tích và nhìn chung tương tự như một bảng dữ kiện truyền thống (chỉ các chỉ báo được lưu trữ không phải trong bảng mà ở bảng “lân cận”). Nhưng cũng có những cạm bẫy: một trong những sửa đổi điển hình của mô hình - mở rộng khóa thực tế - đòi hỏi phải có thêm khóa ngoại mới vào Liên kết. Và điều này lại “phá vỡ” tính mô-đun và có khả năng gây ra nhu cầu sửa đổi các đối tượng khác.
В Mô hình neo Một kết nối không thể có các thuộc tính riêng, vì vậy phương pháp này sẽ không hiệu quả - tất cả các thuộc tính và chỉ báo phải được liên kết với một neo cụ thể. Kết luận từ điều này rất đơn giản - Mỗi sự thật cũng cần có mỏ neo riêng. Đối với một số điều mà chúng ta quen coi là sự thật, điều này có vẻ tự nhiên - ví dụ: thực tế về việc mua hàng có thể được rút gọn hoàn toàn thành đối tượng “đặt hàng” hoặc “biên lai”, truy cập trang web vào một phiên, v.v. Nhưng cũng có những thực tế không dễ dàng tìm thấy một “đối tượng vận chuyển” tự nhiên như vậy - ví dụ như hàng hóa còn sót lại trong kho vào đầu mỗi ngày.
Theo đó, các vấn đề về tính mô-đun khi mở rộng khóa thực tế trong mô hình Anchor không phát sinh (chỉ cần thêm Mối quan hệ mới vào Anchor tương ứng là đủ), nhưng việc thiết kế một mô hình để hiển thị các sự kiện sẽ ít rõ ràng hơn; các Anchor “nhân tạo” có thể xuất hiện hiển thị mô hình đối tượng kinh doanh một cách không rõ ràng.
Làm thế nào đạt được sự linh hoạt
Kết quả xây dựng trong cả hai trường hợp đều chứa nhiều bàn hơn đáng kểhơn so với phép đo truyền thống. Nhưng nó có thể mất không gian đĩa ít hơn đáng kể với cùng một tập hợp các thuộc tính được phiên bản như thứ nguyên truyền thống. Đương nhiên, không có phép thuật nào ở đây cả - tất cả chỉ là về sự bình thường hóa. Bằng cách phân phối các thuộc tính trên các Vệ tinh (trong Kho dữ liệu) hoặc các bảng riêng lẻ (Mô hình neo), chúng tôi giảm (hoặc loại bỏ hoàn toàn) trùng lặp giá trị của một số thuộc tính khi thay đổi các thuộc tính khác.
vì Kho dữ liệu tiền thắng sẽ phụ thuộc vào sự phân bổ thuộc tính giữa các Vệ tinh và đối với Mô hình neo - gần như tỷ lệ thuận với số phiên bản trung bình trên mỗi đối tượng đo.
Tuy nhiên, tiết kiệm không gian là một lợi thế quan trọng nhưng không phải là lợi thế chính của việc lưu trữ các thuộc tính riêng biệt. Cùng với việc lưu trữ riêng biệt các mối quan hệ, phương pháp này làm cho cửa hàng thiết kế mô-đun. Điều này có nghĩa là việc thêm cả thuộc tính riêng lẻ và toàn bộ lĩnh vực chủ đề mới vào mô hình như vậy trông giống như thượng tầng trên một tập hợp các đối tượng hiện có mà không thay đổi chúng. Và đây chính xác là điều làm cho các phương pháp được mô tả trở nên linh hoạt.
Điều này cũng giống như quá trình chuyển đổi từ sản xuất từng chiếc sang sản xuất hàng loạt - nếu theo cách tiếp cận truyền thống, mỗi bảng của mô hình là duy nhất và cần được chú ý đặc biệt, thì trong các phương pháp linh hoạt, nó đã là một tập hợp các “bộ phận” tiêu chuẩn. Một mặt, có nhiều bảng hơn và quá trình tải và truy xuất dữ liệu sẽ phức tạp hơn. Mặt khác, họ trở thành đặc trưng. Điều đó có nghĩa là có thể có tự động và điều khiển siêu dữ liệu. Câu hỏi “chúng ta sẽ bố trí nó như thế nào?”, câu trả lời có thể chiếm một phần đáng kể trong công việc thiết kế các cải tiến, giờ đây đơn giản là không còn giá trị (cũng như câu hỏi về tác động của việc thay đổi mô hình đối với các quy trình làm việc). ).
Điều này không có nghĩa là các nhà phân tích hoàn toàn không cần thiết trong một hệ thống như vậy - ai đó vẫn cần phải xử lý tập hợp các đối tượng có thuộc tính và tìm ra vị trí và cách tải tất cả. Tuy nhiên, khối lượng công việc cũng như khả năng xảy ra lỗi và chi phí xảy ra sẽ giảm đáng kể. Cả ở giai đoạn phân tích và trong quá trình phát triển ETL, phần lớn có thể được giảm xuống để chỉnh sửa siêu dữ liệu.
Mặt tối
Tất cả những điều trên làm cho cả hai phương pháp tiếp cận thực sự linh hoạt, tiên tiến về mặt công nghệ và phù hợp cho việc cải tiến lặp đi lặp lại. Tất nhiên, cũng có một “thùng đựng thuốc mỡ”, mà tôi nghĩ bạn đã có thể đoán được rồi.
Phân rã dữ liệu, làm nền tảng cho tính mô-đun của kiến trúc linh hoạt, dẫn đến sự gia tăng số lượng bảng và theo đó, trên không tham gia khi lấy mẫu. Để đơn giản có được tất cả các thuộc tính của một thứ nguyên, trong một cửa hàng cổ điển, một lựa chọn là đủ, nhưng một kiến trúc linh hoạt sẽ yêu cầu cả một loạt các phép nối. Hơn nữa, nếu tất cả những kết nối báo cáo này có thể được viết trước, thì các nhà phân tích đã quen với việc viết SQL bằng tay sẽ bị thiệt hại gấp đôi.
Có một số sự thật khiến tình huống này trở nên dễ dàng hơn:
Khi làm việc với kích thước lớn, tất cả các thuộc tính của nó hầu như không bao giờ được sử dụng đồng thời. Điều này có nghĩa là có thể có ít kết nối hơn so với cái nhìn đầu tiên về mô hình. Data Vault cũng có thể tính đến tần suất chia sẻ dự kiến khi phân bổ thuộc tính cho vệ tinh. Đồng thời, bản thân Hub hoặc Anchor chủ yếu cần thiết để tạo và ánh xạ các đại diện thay thế ở giai đoạn tải và hiếm khi được sử dụng trong các truy vấn (điều này đặc biệt đúng với Anchor).
Tất cả các kết nối đều bằng khóa. Ngoài ra, cách lưu trữ dữ liệu “nén” hơn giúp giảm chi phí quét bảng khi cần thiết (ví dụ: khi lọc theo giá trị thuộc tính). Điều này có thể dẫn đến thực tế là việc lấy mẫu từ cơ sở dữ liệu đã chuẩn hóa với nhiều liên kết sẽ còn nhanh hơn việc quét một chiều nặng với nhiều phiên bản trên mỗi hàng.
Ví dụ, ở đây trong Bài viết bao gồm một bài kiểm tra so sánh chi tiết về hiệu suất của mô hình Anchor với một mẫu từ một bảng.
Rất nhiều phụ thuộc vào động cơ. Nhiều nền tảng hiện đại có cơ chế tối ưu hóa kết nối nội bộ. Ví dụ: MS SQL và Oracle có thể “bỏ qua” các phép nối vào bảng nếu dữ liệu của chúng không được sử dụng ở bất kỳ đâu ngoại trừ các phép nối khác và không ảnh hưởng đến lựa chọn cuối cùng (loại bỏ bảng/nối) và MPP Vertica , đã được chứng minh là một công cụ tuyệt vời cho Mô hình neo, với một số tối ưu hóa thủ công đối với kế hoạch truy vấn. Mặt khác, việc lưu trữ Mô hình neo, chẳng hạn như trên Click House, vốn có hỗ trợ tham gia hạn chế, có vẻ vẫn chưa phải là một ý tưởng hay.
Ngoài ra, đối với cả hai kiến trúc đều có động tác đặc biệt, giúp truy cập dữ liệu dễ dàng hơn (cả từ quan điểm hiệu suất truy vấn và cho người dùng cuối). Ví dụ, Bảng thời gian trong Data Vault hoặc chức năng bảng đặc biệt trong mô hình Anchor.
trong tổng số
Bản chất chính của các kiến trúc linh hoạt được coi là tính mô-đun trong “thiết kế” của chúng.
Chính thuộc tính này cho phép:
- Sau một số chuẩn bị ban đầu liên quan đến việc triển khai siêu dữ liệu và viết các thuật toán ETL cơ bản, nhanh chóng cung cấp cho khách hàng kết quả đầu tiên dưới dạng một vài báo cáo chứa dữ liệu từ chỉ một vài đối tượng nguồn. Không cần thiết phải suy nghĩ thấu đáo (ngay cả ở cấp cao nhất) toàn bộ mô hình đối tượng.
- Một mô hình dữ liệu có thể bắt đầu hoạt động (và hữu ích) chỉ với 2-3 đối tượng, sau đó phát triển dần dần (liên quan đến mô hình Anchor Nikolai so sánh tốt đẹp với sợi nấm).
- Hầu hết các cải tiến, bao gồm mở rộng lĩnh vực chủ đề và bổ sung thêm nguồn mới không ảnh hưởng đến chức năng hiện có và không gây nguy cơ phá vỡ thứ gì đó đang hoạt động.
- Nhờ phân tách thành các phần tử tiêu chuẩn, các quy trình ETL trong các hệ thống như vậy trông giống nhau, văn bản của chúng phù hợp với thuật toán hóa và cuối cùng, tự động hóa.
Cái giá của sự linh hoạt này là hiệu suất. Điều này không có nghĩa là không thể đạt được hiệu suất chấp nhận được trên những mô hình như vậy. Thường xuyên hơn không, bạn có thể chỉ cần nỗ lực nhiều hơn và chú ý đến từng chi tiết để đạt được số liệu bạn muốn.
ứng dụng
Các loại thực thể Kho dữ liệu
Thông tin thêm về Data Vault:
Các loại thực thể Mô hình neo
Thông tin chi tiết về Mô hình neo:
Bảng tóm tắt các đặc điểm chung và khác biệt của các phương pháp đang xem xét:
Nguồn: www.habr.com