OneData模型實施過程是怎樣的

這篇文章的內容主要圍繞OneData模型實施過程是怎樣的進行講述，文章內容清晰易懂，條理清晰，非常適合新手學習，值得大家去閱讀。感興趣的朋友可以跟隨小編一起閱讀吧。希望大家通過這篇文章有所收獲！

1．業界常用的模型實施過程

Kimball模型實施過程

Kimball維度建模主要探討需求分析、高層模型、詳細模型和模型審查整個過程。

構建維度模型一般要經歷三個階段：第一個階段是高層設計時期，定義業務過程維度模型的范圍，提供每種星形模式的技術和功能描述；第二個階段是詳細模型設計時期，對每個星形模型添加屬性和度量信息；第三個階段是進行模型的審查、再設計和驗證等工作，第四個階段是產生詳細設計文檔，提交ETL設計和開發。

高層模型：高層模型設計階段的直接產出目標是創建高層維度模型圖，它是對業務過程中的維表和事實表的圖形描述。確定維表創建初始屬性列表，為每個事實表創建提議度量。

詳細模型：詳細的維度建模過程是為高層模型填補缺失的信息，解決設計問題，并不斷測試模型能否滿足業務需求，確保模型的完備性。確定每個維表的屬性和每個事實表的度量，并確定信息來源的位置、定義，確定屬性和度量如何填入模型的初步業務規則。

模型審查、再設計和驗證：本階段主要召集相關人員進行模型的審查和驗證，根據審查結果對詳細維度進行再設計。

提交ETL設計和開發：最后，完成模型詳細設計文檔，提交ETL開發人員，進入ETL設計和開發階段，由ETL人員完成物理模型的設計和開發。

上述內容主要引用自Ralph Kimball等的The Data Warehouse Lifecycle Toolkit，具體細節請參考原著作。

Inmon模型實施過程

Inmon對數據模型的定位是：扮演著通往數據倉庫其他部分的智能路線圖的角色。由于數據倉庫的建設不是一蹴而就的，為了協調不同人員的工作以及適應不同類型的用戶，非常有必要建立一個路線圖——數據模型，描述數據倉庫各部分是如何結合在一起的。

Inmon將模型劃分為三個層次，分別是ERD（Entity Relationship Diagram，實體關系圖）層、DIS（Data Item Set，數據項集）層和物理層（Physical Model，物理模型）。

ERD層是數據模型的最高層，該層描述了公司業務中的實體或主題域以及它們之間的關系；DIS層是中間層，該層描述了數據模型中的關鍵字、屬性以及細節數據之間的關系；物理層是數據建模的最底層，該層描述了數據模型的物理特性。

Inmon對于構建數據倉庫模型建議采用螺旋式開發方法，采用迭代方式完成多次需求。但需要采用統一的ERD模型，才能夠將每次迭代的結果整合在一起。ERD模型是高度抽象的數據模型，描述了企業完整的數據。而每次迭代則是完成ERD模型的子集，通過DIS和物理數據模型實現。

上述內容主要引用自Inmon的Building the Data Warehouse，具體細節請參考原著作。

其他模型實施過程

在實踐中經常會用到如下數據倉庫模型層次的劃分，和Kimball、Inmon的模型實施理論有一定的相通性，但不涉及具體的模型表達。

業務建模，生成業務模型，主要解決業務層面的分解和程序化。

領域建模，生成領域模型，主要是對業務模型進行抽象處理，生成領域概念模型。

邏輯建模，生成邏輯模型，主要是將領域模型的概念實體以及實體之間的關系進行數據庫層次的邏輯化。

物理建模，生成物理模型，主要解決邏輯模型針對不同關系數據庫的物理化以及性能等一些具體的技術問題。

2．OneData實施過程

重點講解怎么使用OneData這套體系和相配套的工具實施大數據系統的模型建設，在講解中會以阿里巴巴的具體業務進行說明。

指導方針

首先，在建設大數據數據倉庫時，要進行充分的業務調研和需求分析。這是數據倉庫建設的基石，業務調研和需求分析做得是否充分直接決定了數據倉庫建設是否成功。其次，進行數據總體架構設計，主要是根據數據域對數據進行劃分；按照維度建模理論，構建總線矩陣、抽象出業務過程和維度。再次，對報表需求進行抽象整理出相關指標體系，使用OneData工具完成指標規范定義和模型設計。最后，就是代碼研發和運維。本文將會重點講解物理模型設計之前（含）步驟的內容。

實施工作流

數據調研——業務調研：整個阿里集團涉及的業務涵蓋電商、數字娛樂、導航（高德）、移動互聯網服務等領域。各個領域又涵蓋多個業務線，如電商領域就涵蓋了C類（淘寶、天貓、天貓國際）與B類（阿里巴巴中文站、國際站、速賣通）業務。數據倉庫是要涵蓋所有業務領域，還是各個業務領域獨自建設，業務領域內的業務線也同樣面臨著這個問題。所以要構建大數據數據倉庫，就需要了解各個業務領域、業務線的業務有什么共同點和不同點，以及各個業務線可以細分為哪幾個業務模塊，每個業務模塊具體的業務流程又是怎樣的。業務調研是否充分，將會直接決定數據倉庫建設是否成功。

在阿里巴巴，一般各個業務領域獨自建設數據倉庫，業務領域內的業務線由于業務相似、業務相關性較大，進行統一集中建設。

數據調研——需求調研：可以想象一下，在沒有考慮分析師、業務運營人員的數據需求的情況下，根據業務調研建設的數據倉庫無疑等于閉門造車。了解了業務系統的業務后并不代表就可以進行實施了，此刻要做的就是收集數據使用者的需求，可以去找分析師、業務運營人員了解他們有什么數據訴求，此時更多的就是報表需求。

需求調研的途徑有兩種：一是根據與分析師、業務運營人員的溝通（郵件、IM）獲知需求；二是對報表系統中現有的報表進行研究分析。通過需求調研分析后，就清楚數據要做成什么樣的。很多時候，都是由具體的數據需求驅動數據倉庫團隊去了解業務系統的業務數據，這兩者并沒有嚴格的先后順序。

舉例：分析師需要了解大淘寶（淘寶、天貓、天貓國際）一級類目的成交金額。當獲知這個需求后，我們要分析根據什么（維度）匯總，以及匯總什么（度量），這里類目是維度，金額是度量；明細數據和匯總數據應該怎樣設計？這是一個公用的報表嗎？是需要沉淀到匯總表里面，還是在報表工具中進行匯總？
架構設計——數據域劃分：數據域是指面向業務分析，將業務過程或者維度進行抽象的集合。業務過程可以概括為一個個不可拆分的行為事件，如下單、支付、退款。為保障整個體系的生命力，數據域需要抽象提煉，并且長期維護和更新，但不輕易變動。在劃分數據域時，既能涵蓋當前所有的業務需求，又能在新業務進入時無影響地被包含進已有的數據域中或者擴展新的數據域。

架構設計——構建總線矩陣：在進行充分的業務調研和需求調研后，就要構建總線矩陣了。需要做兩件事情：明確每個數據域下有哪些業務過程；業務過程與哪些維度相關，并定義每個數據域下的業務過程和維度。

規范定義：規范定義主要定義指標體系，包括原子指標、修飾詞、時間周期和派生指標。

模型設計：模型設計主要包括維度及屬性的規范定義，維表、明細事實表和匯總事實表的模型設計。相關實踐詳解請參考后續章節。

感謝你的閱讀，相信你對“OneData模型實施過程是怎樣的”這一問題有一定的了解，快去動手實踐吧，如果想了解更多相關知識點，可以關注億速云網站！小編會繼續為大家帶來更好的文章！