數(shù)據倉庫架構之數(shù)據架構規(guī)劃與設計

申請免費試用、咨詢電話：400-8352-114

如果說整體架構規(guī)劃是比較遙遠和飄渺的事，那么數(shù)據倉庫架構的中心部分----數(shù)據架構，將為我們打開把遠期規(guī)劃和現(xiàn)實項目的實施緊緊地聯(lián)系在一起，我們可以從現(xiàn)實出發(fā)，找到方向的突破口。BTW，今天在公司洋洋灑灑寫了10多頁關于數(shù)據架構的文檔，為近期項目做技術準備，等架構定了后，我就開始深入熟悉公司具體業(yè)務和現(xiàn)有模型了，現(xiàn)在只是有一定了解而已，但細節(jié)架構是根據實際情況去定制的。

現(xiàn)在簡單說下思路。這些并不是理論，更不是論文，而是經驗的描述，不知道唯業(yè)務流程是論者看到這些，是否認為技術架構對業(yè)務分析的長期有效的支持，是可實現(xiàn)的和很有必要的呢？

一. 數(shù)據流架構，主要是設計數(shù)據流需要多少層次，每個層次的功能必須有獨特的定義。ODS是否只有為數(shù)據倉庫做數(shù)據準備的功能，EDW是否沒計劃和條件去建設范式模型，是否多個集市，多個集市需要統(tǒng)一維度建模，數(shù)據集市到底要滿足哪些BI功能，這些問題都決定了數(shù)據流架構如何去設計。

二.數(shù)據管理架構。

1. 考慮歷史存儲方式，根據數(shù)據使用頻率和價值，是否參考DW2.0理論進行數(shù)據管理。

2. 存儲方式的角度，從粒度上講，維度模型的數(shù)據倉庫到底需要多大的粒度，特別是時間方面的維度，數(shù)據集市到底需要多大的粒度。而從應用數(shù)據方面講，是否需要在數(shù)據集市中將維度信息加在事實表中，需要加多少進去，甚至形成大寬表，方便報表或者查詢以及數(shù)據挖掘。

三. 業(yè)務數(shù)據架構。

目前包括國際大廠商的行業(yè)模型，其實都是從平面角度看業(yè)務，雖然業(yè)務上包括很全，但從技術上講，并不是更合理的模型架構，或者沒有架構，只是平面的模型，是否我們就直接拿來用，不需要架構了？以下做簡要說明：

1. 業(yè)務數(shù)據流。（1）針對表的考慮。需要考慮不同業(yè)務定義中，表當中到底存儲多少信息，是多種定義放一起，還是不同定義存儲在不同的表。高時間粒度事實表是在數(shù)據集市直接通過低粒度事實表匯總，還是從維度建設時就分出來ETL?？紤]擴展原因，最好不要多種定義的數(shù)據放一起，這樣擴展性不強，也不容易維護。

（2）針對字段的考慮。維表主要考慮到維數(shù)據的增強性描述，事實表主要是度量的描述以及退化維的生成，不過衍生度量和退化維一般在統(tǒng)一維度層或者數(shù)據集市中完成，根據是否是企業(yè)級定位而定。

2. 業(yè)務數(shù)據管理架構。一般國際大廠商的行業(yè)模型，會有很多衍生表來描述不同業(yè)務定義的維信息，不過這種擴展性僅僅還是停留在平面層次。如果要適應更大更復雜的業(yè)務變化和組織機構變化需求，我們的管理架構需要細到管理相應的業(yè)務元數(shù)據。根據模型技術的發(fā)展，針對主題模型，我們可以設計出輔助模型來描述元數(shù)據，達到最大的業(yè)務變化/增加、組織結構變化/增加的支持。在實際項目中，根據業(yè)務調研，設計出相應的參考模型組，并維護參考表數(shù)據（一般100條數(shù)據以內），然后在統(tǒng)一維度建模中，由參考表和主體業(yè)務模型關聯(lián)而成統(tǒng)一可信高可擴展性的維表。

四. 數(shù)據安全架構。

一般安全管理分為操作系統(tǒng)級、數(shù)據庫級、Schema級、表/視圖級、數(shù)據級（行數(shù)據），以及BI界面控制級別、CUBE控制等多個層次。這里主要說的是數(shù)據行級。在維度數(shù)據倉庫，達到所謂數(shù)據行級控制，可以通過類似BI界面那樣的多個組合權限組，然后結合事實表進行權限控制。

五.數(shù)據質量架構。

數(shù)據質量控制本身有多個因素組成，包括業(yè)務調研、ETL、測試嚴密性等，這里主要從數(shù)據建模的角度考慮。一般可以設計相應的控制表來一定程度控制，比如維度數(shù)據有效性。