訂閱
糾錯
加入自媒體

一文了解數倉建設及數據治理

2021-07-21 10:21
園陌
關注

實際業務中數倉分層

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

數據分層架構數據層具體實現

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

數據源層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. 數據生命周期治理

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

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

image.png


<上一頁  1  2  
聲明: 本文由入駐維科號的作者撰寫,觀點僅代表作者本人,不代表OFweek立場。如有侵權或其他問題,請聯系舉報。

發表評論

0條評論,0人參與

請輸入評論內容...

請輸入評論/評論長度6~500個字

您提交的評論過于頻繁,請輸入驗證碼繼續

暫無評論

暫無評論

    人工智能 獵頭職位 更多
    掃碼關注公眾號
    OFweek人工智能網
    獲取更多精彩內容
    文章糾錯
    x
    *文字標題:
    *糾錯內容:
    聯系郵箱:
    *驗 證 碼:

    粵公網安備 44030502002758號