關於數倉建設及資料治理的超全概括

　　本文分為兩大節介紹,第一節是數倉建設,第二節是資料治理,內容較長,還請耐心閱讀!

　　在談數倉之前,先來看下面幾個問題:

　　數倉為什麼要分層?

　　用空間換時間,透過大量的預處理來提升應用系統的使用者體驗(效率),因此資料倉儲會存在大量冗餘的資料;不分層的話,如果源業務系統的業務規則發生變化將會影響整個資料清洗過程,工作量巨大。

　　透過資料分層管理可以簡化資料清洗的過程,因為把原來一步的工作分到了多個步驟去完成,相當於把一個複雜的工作拆成了多個簡單的工作,把一個大的黑盒變成了一個白盒,每一層的處理邏輯都相對簡單和容易理解,這樣我們比較容易保證每一個步驟的正確性,當資料發生錯誤的時候,往往我們只需要區域性調整某個步驟即可。

　　資料倉儲之父 Bill Inmon對資料倉儲做了定義——面向主題的、整合的、相對穩定的、反映歷史變化的資料集合,用於支援管理決策。從定義上來看,資料倉儲的關鍵詞為面向主題、整合、穩定、反映歷史變化、支援管理決策,而這些關鍵詞的實現就體現在分層架構內。

　　一個好的分層架構,有以下好處:

　　清晰資料結構:每一個資料分層都有對應的作用域,在使用資料的時候能更方便的定位和理解。

　　資料血緣追蹤:提供給業務人員或下游系統的資料服務時都是目標資料,目標資料的資料來源一般都來自於多張表資料。若出現目標資料異常時,清晰的血緣關係可以快速定位問題所在。而且,血緣管理也是後設資料管理重要的一部分。

　　減少重複開發:資料的逐層加工原則,下層包含了上層資料加工所需要的全量資料,這樣的加工方式避免了每個資料開發人員都重新從源系統抽取資料進行加工。

　　資料關係條理化:源系統間存在複雜的資料關係,比如客戶資訊同時存在於核心系統、信貸系統、理財系統、資金系統,取數時該如何決策呢?資料倉儲會對相同主題的資料進行統一建模,把複雜的資料關係梳理成條理清晰的資料模型,使用時就可避免上述問題了。

　　遮蔽原始資料的影響:資料的逐層加工原則,上層的資料都由下一層的資料加工獲取,不允許跳級取數。而原始資料位於數倉的最底層,離應用層資料還有多層的資料加工,所以加工應用層資料的過程中就會把原始資料的變更消除掉,保持應用層的穩定性。

　　數倉分幾層最好?

　　目前市場上主流的分層方式眼花繚亂,不過看事情不能只看表面,還要看到內在的規律,不能為了分層而分層,沒有最好的,只有適合的。

　　分層是以解決當前業務快速的資料支撐為目的,為未來抽象出共性的框架並能夠賦能給其他業務線,同時為業務發展提供穩定、準確的資料支撐,並能夠按照已有的模型為新業務發展提供方向,也就是資料驅動和賦能。

　　如何搭建一個好的數倉?

　　穩定:資料產出穩定且有保障。

　　可信:資料乾淨、資料質量高。

　　豐富:資料涵蓋的業務足夠廣泛。

　　透明:資料構成體系足夠透明。

　　數倉設計

　　數倉設計的3個維度:

　　功能架構:結構層次清晰。

　　資料架構:資料質量有保障。

　　技術架構:易擴充套件、易用。

　　數倉架構

　　按照資料流入流出的過程,資料倉儲架構可分為:源資料、資料倉儲、資料應用。

　　資料倉儲

　　資料倉儲的資料來源於不同的源資料,並提供多樣的資料應用,資料自下而上流入資料倉儲後向上層開放應用,而資料倉儲只是中間整合化資料管理的一個平臺。

　　源資料:此層資料無任何更改,直接沿用外圍系統資料結構和資料,不對外開放;為臨時儲存層,是介面資料的臨時儲存區域,為後一步的資料處理做準備。

　　資料倉儲:也稱為細節層,DW層的資料應該是一致的、準確的、乾淨的資料,即對源系統資料進行了清洗(去除了雜質)後的資料。

　　資料應用:前端應用直接讀取的資料來源;根據報表、專題分析需求而計算生成的資料。

　　資料倉儲從各資料來源獲取資料及在資料倉儲內的資料轉換和流動都可以認為是ETL(抽取Extra, 轉化Transfer, 裝載Load)的過程,ETL是資料倉儲的流水線,也可以認為是資料倉儲的血液,它維繫著資料倉儲中資料的新陳代謝,而資料倉儲日常的管理和維護工作的大部分精力就是保持ETL的正常和穩定。

　　建設資料倉儲猶如創造一條新的生命,分層架構只是這條生命的邏輯骨架而已。想要在骨架上長出血肉,就必須進行合適的資料建模,資料倉儲的強壯還是孱弱,健美還是醜陋,就取決於建模的結果。

　　數倉建模方法

　　資料倉儲的建模方法有很多種,每一種建模方法代表了哲學上的一個觀點,代表了一種歸納、概括世界的一種方法。常見的有 正規化建模法、維度建模法、實體建模法等,每種方法從本質上將是從不同的角度看待業務中的問題。

　　1． 正規化建模法

　　正規化建模法其實是我們在構建資料模型常用的一個方法,該方法的主要由 Inmon 所提倡,主要解決關係型資料庫的資料儲存,利用的一種技術層面上的方法。目前,我們在關係型資料庫中的建模方法,大部分採用的是三正規化建模法。

　　正規化 是符合某一種級別的關係模式的集合。構造資料庫必須遵循一定的規則,而在關係型資料庫中這種規則就是正規化,這一過程也被稱為規範化。目前關聯式資料庫有六種正規化:第一正規化(1NF)、第二正規化(2NF)、第三正規化(3NF)、Boyce-Codd正規化(BCNF)、第四正規化(4NF)和第五正規化(5NF)。

　　在資料倉儲的模型設計中,一般採用第三正規化。一個符合第三正規化的關係必須具有以下三個條件 :

　　每個屬性值唯一,不具有多義性 ;

　　每個非主屬性必須完全依賴於整個主鍵,而非主鍵的一部分 ;

　　每個非主屬性不能依賴於其他關係中的屬性,因為這樣的話,這種屬性應該歸到其他關係中去。

　　正規化建模

　　根據 Inmon 的觀點,資料倉儲模型的建設方法和業務系統的企業資料模型類似。在業務系統中,企業資料模型決定了資料的來源,而企業資料模型也分為兩個層次,即主題域模型和邏輯模型。同樣,主題域模型可以看成是業務模型的概念模型,而邏輯模型則是域模型在關係型資料庫上的例項化。

　　2． 實體建模法

　　實體建模法並不是資料倉儲建模中常見的一個方法,它來源於哲學的一個流派。從哲學的意義上說,客觀世界應該是可以細分的,客觀世界應該可以分成由一個個實體,以及實體與實體之間的關係組成。那麼我們在資料倉儲的建模過程中完全可以引入這個抽象的方法,將整個業務也可以劃分成一個個的實體,而每個實體之間的關係,以及針對這些關係的說明就是我們資料建模需要做的工作。

　　雖然實體法粗看起來好像有一些抽象,其實理解起來很容易。即我們可以將任何一個業務過程劃分成 3 個部分,實體,事件,說明,如下圖所示:

　　實體建模

　　上圖表述的是一個抽象的含義,如果我們描述一個簡單的事實:“小明開車去學校上學”。以這個業務事實為例,我們可以把“小明”,“學校”看成是一個實體,“上學”描述的是一個業務過程,我們在這裡可以抽象為一個具體“事件”,而“開車去”則可以看成是事件“上學”的一個說明。

　　3． 維度建模法

　　維度模型是資料倉儲領域另一位大師Ralph Kimall所倡導,他的《資料倉儲工具箱》是資料倉儲工程領域最流行的數倉建模經典。維度建模以分析決策的需求出發構建模型,構建的資料模型為分析需求服務,因此它重點解決使用者如何更快速完成分析需求,同時還有較好的大規模複雜查詢的響應效能。

　　星形模型

　　典型的代表是我們比較熟知的星形模型(Star-schema),以及在一些特殊場景下適用的雪花模型(Snow-schema)。

　　維度建模中比較重要的概念就是 事實表(Fact table)和維度表(Dimension table)。其最簡單的描述就是,按照事實表、維度表來構建資料倉儲、資料集市。

　　目前在網際網路公司最常用的建模方法就是維度建模。

　　維度建模怎麼建:

　　在實際業務中,給了我們一堆資料,我們怎麼拿這些資料進行數倉建設呢,數倉工具箱作者根據自身60多年的實際業務經驗,給我們總結了如下四步。

　　數倉工具箱中的維度建模四步走:

　　維度建模四步走

　　這四步是環環相扣,步步相連。下面詳細拆解下每個步驟怎麼做

　　1、選擇業務過程

　　維度建模是緊貼業務的,所以必須以業務為根基進行建模,那麼選擇業務過程,顧名思義就是在整個業務流程中選取我們需要建模的業務,根據運營提供的需求及日後的易擴充套件性等進行選擇業務。比如商城,整個商城流程分為商家端,使用者端,平臺端,運營需求是總訂單量,訂單人數,及使用者的購買情況等,我們選擇業務過程就選擇使用者端的資料,商家及平臺端暫不考慮。業務選擇非常重要,因為後面所有的步驟都是基於此業務資料展開的。

　　2、宣告粒度

　　先舉個例子:對於使用者來說,一個使用者有一個身份證號,一個戶籍地址,多個手機號,多張銀行卡,那麼與使用者粒度相同的粒度屬性有身份證粒度,戶籍地址粒度,比使用者粒度更細的粒度有手機號粒度,銀行卡粒度,存在一對一的關係就是相同粒度。為什麼要提相同粒度呢,因為維度建模中要求我們,在同一事實表中,必須具有相同的粒度,同一事實表中不要混用多種不同的粒度,不同的粒度資料建立不同的事實表。並且從給定的業務過程獲取資料時,強烈建議從關注原子粒度開始設計,也就是從最細粒度開始,因為原子粒度能夠承受無法預期的使用者查詢。但是上卷彙總粒度對查詢效能的提升很重要的,所以對於有明確需求的資料,我們建立針對需求的上卷彙總粒度,對需求不明朗的資料我們建立原子粒度。

　　3、確認維度

　　維度表是作為業務分析的入口和描述性標識,所以也被稱為資料倉儲的“靈魂”。在一堆的資料中怎麼確認哪些是維度屬性呢,如果該列是對具體值的描述,是一個文字或常量,某一約束和行標識的參與者,此時該屬性往往是維度屬性,數倉工具箱中告訴我們牢牢掌握事實表的粒度,就能將所有可能存在的維度區分開,並且要確保維度表中不能出現重複資料,應使維度主鍵唯一

　　4、確認事實

　　事實表是用來度量的,基本上都以數量值表示,事實表中的每行對應一個度量,每行中的資料是一個特定級別的細節資料,稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重複計算度量的問題。有時候往往不能確定該列資料是事實屬性還是維度屬性。記住最實用的事實就是數值型別和可加類事實。所以可以透過分析該列是否是一種包含多個值並作為計算的參與者的度量,這種情況下該列往往是事實。

　　其中粒度是非常重要的,粒度用於確定事實表的行表示什麼,建議從關注原子級別的粒度資料開始設計,因為原子粒度能夠承受無法預估的使用者查詢,而且原子資料可以以各種可能的方式進行上卷,而一旦選擇了高粒度,則無法滿足使用者下鑽細節的需求。

　　事實是整個維度建模的核心,其中雪花模型或者星型模型都是基於一張事實表透過外健關聯維表進行擴充套件,生成一份能夠支撐可預知查詢需求的模型寬表,而且最後的查詢也是落在事實表中進行。

　　實際業務中數倉分層

　　數倉分層要結合公司業務進行,並且需要清晰明確各層職責,要保證資料層的穩定又要遮蔽對下游影響,一般採用如下分層結構:

　　資料分層架構資料層具體實現

　　使用四張圖說明每層的具體實現

　　資料來源層ODS

　　資料來源層

　　資料來源層主要將各個業務資料匯入到大資料平臺,作為業務資料的快照儲存。

　　資料明細層DW

　　資料明細層

　　事實表中的每行對應一個度量,每行中的資料是一個特定級別的細節資料,稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度。這樣能確保不會出現重複計算度量的問題。

　　維度表一般都是單一主鍵,少數是聯合主鍵,注意維度表不要出現重複資料,否則和事實表關聯會出現資料發散問題。

　　有時候往往不能確定該列資料是事實屬性還是維度屬性。記住最實用的事實就是數值型別和可加類事實。所以可以透過分析該列是否是一種包含多個值並作為計算的參與者的度量,這種情況下該列往往是事實;如果該列是對具體值的描述,是一個文字或常量,某一約束和行標識的參與者,此時該屬性往往是維度屬性。但是還是要結合業務進行最終判斷是維度還是事實。

　　資料輕度彙總層DM

　　資料輕度彙總層

　　此層命名為輕彙總層,就代表這一層已經開始對資料進行彙總,但是不是完全彙總,只是對相同粒度的資料進行關聯彙總,不同粒度但是有關係的資料也可進行彙總,此時需要將粒度透過聚合等操作進行統一。

　　資料應用層APP

　　資料應用層

　　資料應用層的表就是提供給使用者使用的,數倉建設到此就接近尾聲了,接下來就根據不同的需求進行不同的取數,如直接進行報表展示,或提供給資料分析的同事所需的資料,或其他的業務支撐。

　　一張圖總結下資料倉儲的構建整體流程:

　　數倉整體流程資料治理

　　數倉建設真正的難點不在於數倉設計,而在於後續業務發展起來,業務線變的龐大之後的資料治理,包括資產治理、資料質量監控、資料指標體系的建設等。

　　其實資料治理的範圍很⼴,包含資料本⾝的管理、資料安全、資料質量、資料成本等。在DAMA 資料管理知識體系指南中,資料治理位於資料管理“車輪圖”的正中央,是資料架構、資料建模、資料儲存、資料安全、資料質量、後設資料管理、主資料管理等10大資料管理領域的總綱,為各項資料管理活動提供總體指導策略。

　　資料治理之道是什麼1． 資料治理需要體系建設

　　為發揮資料價值需要滿足三個要素:合理的平臺架構、完善的治理服務、體系化的運營手段。

　　根據企業的規模、所屬行業、資料量等情況選擇合適的平臺架構;治理服務需要貫穿資料全生命週期,保證資料在採集、加工、共享、儲存、應用整個過程中的完整性、準確性、一致性和實效性;運營手段則應當包括規範的最佳化、組織的最佳化、平臺的最佳化以及流程的最佳化等等方面。

　　2． 資料治理需要夯實基礎

　　資料治理需要循序漸進,但在建設初期至少需要關注三個方面:資料規範、資料質量、資料安全。規範化的模型管理是保障資料可以被治理的前提條件,高質量的資料是資料可用的前提條件,資料的安全管控是資料可以共享交換的前提條件。

　　3． 資料治理需要IT賦能

　　資料治理不是一堆規範文件的堆砌,而是需要將治理過程中所產生的的規範、流程、標準落地到IT平臺上,在資料生產過程中透過“以終為始”前向的方式進行資料治理,避免事後稽核帶來各種被動和運維成本的增加。

　　4． 資料治理需要聚焦資料

　　資料治理的本質是管理資料,因此需要加強後設資料管理和主資料管理,從源頭治理資料,補齊資料的相關屬性和資訊,比如:後設資料、質量、安全、業務邏輯、血緣等,透過後設資料驅動的方式管理資料生產、加工和使用。

　　5． 資料治理需要建管一體化

　　資料模型血緣與任務排程的一致性是建管一體化的關鍵,有助於解決資料管理與資料生產口徑不一致的問題,避免出現兩張皮的低效管理模式。

　　淺談資料治理方式

　　如上面所說,資料治理的範圍非常廣,其中最重要的是資料質量治理,而資料質量涉及的範圍也很廣,貫穿數倉的整個生命週期,從資料產生->資料接入->資料儲存->資料處理->資料輸出->資料展示,每個階段都需要質量治理,評價維度包括完整性、規範性、一致性、準確性、唯一性、關聯性等。

　　在系統建設的各個階段都應該根據標準進行資料質量檢測和規範,及時進行治理,避免事後的清洗工作。

　　質量檢測可參考以下維度:

　　維度衡量標準完整性業務指定必須的資料是否缺失,不允許為空字元或者空值等。例如,資料來源是否完整、維度取值是否完整、資料取值是否完整等時效性當需要使用時,資料能否反映當前事實。即資料必須及時,能夠滿足系統對資料時間的要求。例如處理(獲取、整理、清洗、載入等)的及時性唯一性在指定的資料集中資料值是否唯一參照完整性資料項是否在父表中有定義依賴一致性資料項取值是否滿足與其他資料項之間的依賴關係正確性資料內容和定義是否一致精確性資料精度是否達到業務規則要求的位數技術有效性資料項是否按已定義的格式標準組織業務有效性資料項是否符合已定義的可信度根據客戶調查或客戶主動提供獲得可用性資料可用的時間和資料需要被訪問時間的比例可訪問性資料是否便於自動化讀取

　　下面是根據美團的技術文章總結的幾點具體治理方式:

　　1． 規範治理

　　規範是數倉建設的保障。為了避免出現指標重複建設和資料質量差的情況,統一按照最詳細、可落地的方法進行規範建設。

　　(1) 詞根

　　詞根是維度和指標管理的基礎,劃分為普通詞根與專有詞根,提高詞根的易用性和關聯性。

　　普通詞根:描述事物的最小單元體,如:交易-trade。

　　專有詞根:具備約定成俗或行業專屬的描述體,如:美元-USD。

　　(2) 表命名規範

　　通用規範

　　表名、欄位名採用一個下劃線分隔詞根(示例:clienttype->client_type)。

　　每部分使用小寫英文單詞,屬於通用欄位的必須滿足通用欄位資訊的定義。

　　表名、欄位名需以字母為開頭。

　　表名、欄位名最長不超過64個英文字元。

　　優先使用詞根中已有關鍵字(數倉標準配置中的詞根管理),定期Review新增命名的不合理性。

　　在表名自定義部分禁止採用非標準的縮寫。

　　表命名規則

　　表名稱 = 型別 + 業務主題 + 子主題 + 表含義 + 儲存格式 + 更新頻率 +結尾,如下圖所示:

　　統一的表命名規範

　　(3) 指標命名規範

　　結合指標的特性以及詞根管理規範,將指標進行結構化處理。

　　基礎指標詞根,即所有指標必須包含以下基礎詞根:

　　業務修飾詞,用於描述業務場景的詞彙,例如trade-交易。

　　3．日期修飾詞,用於修飾業務發生的時間區間。

　　4．聚合修飾詞,對結果進行聚集操作。

　　5．基礎指標,單一的業務修飾詞+基礎指標詞根構建基礎指標 ,例如:交易金額-trade_amt。

　　6．派生指標,多修飾詞+基礎指標詞根構建派生指標。派生指標繼承基礎指標的特性,例如:安裝門店數量-install_poi_cnt。

　　7．普通指標命名規範,與欄位命名規範一致,由詞彙轉換即可以。

　　2． 架構治理

　　(1) 資料分層

　　優秀可靠的數倉體系,往往需要清晰的資料分層結構,即要保證資料層的穩定又要遮蔽對下游的影響,並且要避免鏈路過長,一般的分層架構如下:

　　(2) 資料流向

　　穩定業務按照標準的資料流向進行開發,即ODS-->DWD-->DWA-->APP。非穩定業務或探索性需求,可以遵循ODS->DWD->APP或者ODS->DWD->DWT->APP兩個模型資料流。在保障了資料鏈路的合理性之後,又在此基礎上確認了模型分層引用原則:

　　正常流向:ODS>DWD->DWT->DWA->APP,當出現ODS >DWD->DWA->APP這種關係時,說明主題域未覆蓋全。應將DWD資料落到DWT中,對於使用頻度非常低的表允許DWD->DWA。

　　儘量避免出現DWA寬表中使用DWD又使用(該DWD所歸屬主題域)DWT的表。

　　同一主題域內對於DWT生成DWT的表,原則上要儘量避免,否則會影響ETL的效率。

　　DWT、DWA和APP中禁止直接使用ODS的表, ODS的表只能被DWD引用。

　　禁止出現反向依賴,例如DWT的表依賴DWA的表。

　　3． 後設資料治理

　　後設資料可分為技術後設資料和業務後設資料:

　　技術後設資料為開發和管理資料倉儲的IT 人員使用,它描述了與資料倉儲開發、管理和維護相關的資料,包括資料來源資訊、資料轉換描述、資料倉儲模型、資料清洗與更新規則、資料對映和訪問許可權等。

　　常見的技術後設資料有:

　　儲存後設資料:如表、欄位、分割槽等資訊。

　　執行後設資料:如大資料平臺上所有作業執行等資訊:類似於 Hive Job 日誌,包括作業型別、例項名稱、輸入輸出、 SQL 、執行引數、執行時間,執行引擎等。

　　資料開發平臺中資料同步、計算任務、任務排程等資訊:包括資料同步的輸入輸出表和欄位,以及同步任務本身的節點資訊:計算任務主要有輸入輸出、任務本身的節點資訊 任務排程主要有任務的依賴型別、依賴關係等,以及不同型別排程任務的執行日誌等。

　　資料質量和運維相關後設資料:如任務監控、運維報警、資料質量、故障等資訊,包括任務監控執行日誌、告警配置及執行日誌、故障資訊等。

　　業務後設資料為管理層和業務分析人員服務,從業務角度描述資料,包括商務術語、資料倉儲中有什麼資料、資料的位置和資料的可用性等,幫助業務人員更好地理解資料倉儲中哪些資料是可用的以及如何使用。

　　常見的業務後設資料有維度及屬性(包括維度編碼,欄位型別,建立人,建立時間,狀態等)、業務過程、指標(包含指標名稱,指標編碼,業務口徑,指標型別,責任人,建立時間,狀態,sql等),安全等級,計算邏輯等的規範化定義,用於更好地管理和使用資料。資料應用後設資料,如資料包表、資料產品等的配置和執行後設資料。

　　後設資料不僅定義了資料倉儲中資料的模式、來源、抽取和轉換規則等,而且是整個資料倉儲系統執行的基礎,後設資料把資料倉儲系統中各個鬆散的元件聯絡起來,組成了一個有機的整體。

　　後設資料治理主要解決三個問題:

　　透過建立相應的組織、流程和工具,推動業務標準的落地實施,實現指標的規範定義,消除指標認知的歧義;

　　基於業務現狀和未來的演進方式,對業務模型進行抽象,制定清晰的主題、業務過程和分析方向,構建完備的技術後設資料,對物理模型進行準確完善的描述,並打通技術後設資料與業務後設資料的關係,對物理模型進行完備的刻畫;

　　透過後設資料建設,為使用資料提效,解決“找數、理解數、評估”難題以及“取數、資料視覺化”等難題。

　　4． 安全治理

　　圍繞資料安全標準,首先要有資料的分級、分類標準,確保資料在上線前有著準確的密級。第二,針對資料使用方,要有明確的角色授權標準,透過分級分類和角色授權,來保障重要資料拿不走。第三,針對敏感資料,要有隱私管理標準,保障敏感資料的安全儲存,即使未授權使用者繞過許可權管理拿到敏感資料,也要確保其看不懂。第四,透過制定審計標準,為後續的審計提供審計依據,確保資料走不脫。

　　5． 資料生命週期治理

　　任何事物都具有一定的生命週期,資料也不例外。從資料的產生、加工、使用乃至消亡都應該有一個科學的管理辦法,將極少或者不再使用的資料從系統中剝離出來,並透過核實的儲存裝置進行保留,不僅能夠提高系統的執行效率,更好的服務客戶,還能大幅度減少因為資料長期儲存帶來的儲存成本。資料生命週期一般包含線上階段、歸檔階段(有時還會進一步劃分為線上歸檔階段和離線歸檔階段)、銷燬階段三大階段,管理內容包括建立合理的資料類別,針對不同類別的資料制定各個階段的保留時間、儲存介質、清理規則和方式、注意事項等。

　　從上圖資料生命週期中各引數間的關係中我們可以瞭解到,資料生命週期管理可以使得高價值資料的查詢效率大幅提升,而且高價格的儲存介質的採購量也可以減少很多;但是隨著資料的使用程度的下降,資料被逐漸歸檔,查詢時間也慢慢的變長;最後隨著資料的使用頻率和價值基本沒有了之後,就可以逐漸銷燬了。