導讀： 本文主要介紹如何透過數倉平臺進行資料建模，從而構建統一、規範化、標準化的資料倉庫體系，以及圍繞核心資料倉庫元資料中心建設資料圖譜等方面的實踐和心得，來解決實際場景中遇到的各種問題，學習資料倉庫整體建設思想以及元資料應用服務搭建。首先會介紹下愛奇藝公司整體的業務情況以及資料倉庫1.0的設計和出現的問題，針對數倉1.0的缺陷，是如何演進到數倉2.0架構以及數倉2.0需要解決的問題和需要達成的目標。
這張圖非常清晰的展示了愛奇藝的產品矩陣，早期愛奇藝是影片業務，後來從影片業務周邊衍生出來一些新的業務，以影片業務為主圍繞著核心IP，衍生出短影片、小影片、奇巴布、愛奇藝閱讀、叭噠、泡泡、奇秀直播、愛奇藝知識、體育、電商等眾多業務，從蘋果樹到蘋果園構建了泛娛樂生態矩陣。
可以看到產品矩陣中涉及的業務很多，每個業務都會產生自己的資料，同時也有著自己獨特的產品形態。既要滿足在某個特定業務場景下進行面向業務的資料探查和分析，還要基於跨多個業務場景下，從多個業務共性的角度去提取、淬鍊通用的資料，實現跨業務橫向的探索分析，從而實現指導業務、對業務進行資料賦能的目標。同時，每個業務之間也會相互輔助、作用，導致每個業務之間會有頻繁的資料互動。
01資料倉庫 1.0資料倉庫1.0的架構圖如上，整體分層分為5個部分，最下面是原始資料層，再上面分別是明細層，聚合層以及應用層，右邊是面向整個數倉的維度層，用於管理一致性維度。
原始資料層： 用於儲存原始資料，資料來源於各種資料生產系統，主要分三個部分：Pingback投遞，在每個業務產品進行統一規範的埋點，然後將採集到的資料進行上報，最後透過自動化處理將埋點資料進行解析、儲存；業務資料庫，主要是業務後端產生的資料，例如會員訂單、文學訂單等等，經過資料整合的手段將業務庫的資料直接同步到原始資料層進行儲存；第三方外部資料，主要來自企業外部的資料來源。明細層： 用於還原業務過程，儲存最細粒度的資料，對原始資料按照不同的模式進行ETL處理，完成資料清洗和部分業務邏輯處理等過程。
聚合層： 存放的是非明細的資料，通常是經過各種計算以後得到的輕度聚合和重度聚合資料，主要採用維度建模方法進行構建。
應用層： 是為了滿足業務需要而產生的結果化資料，具有很強的定製性，主要提供給相關資料應用、外部系統，以及對特定資料有需求的人員使用。是資料倉庫和外部的介面，主要對接其他系統，如業務庫、報表系統等。
縱觀數倉1.0架構，整個數倉的體系其實還是按照業務的角度去建設，每個業務都會建立符合自己業務特點的一個小型資料倉庫，可以快速的響應業務需求，同時做到靈活多變，支撐業務決策。但隨著資料增長、業務場景更加複雜，缺少公共資料的提煉和彙總，出現煙囪式重複建設、指標口徑不統一、資料有二義性、生產/使用效率低下等問題，同時也缺乏工具平臺的有利支撐。
當不同業務之間有資料交叉的場景時，為了儘快響應業務需求，直接從其他業務明細層甚至原始資料層獲取資料，這個時候很容易出現指標統計口徑的不一致。缺少公共聚合資料的沉澱和積累，出現很多資料重疊的現象，導致煙囪式重複建設，資源消耗成本高居不下。在數倉1.0建設過程中，雖然有一套比較完整的資料倉庫規範，但是缺少工具平臺的支援和管控，經常出現同名不同義，或者指標口徑有二義性的現象，加重了下游的使用成本和開發效率。比較典型的場景是在業務線A下有一個維度，在業務線B下也有一個維度，但是這兩個維度擁有相同的名字，而且在每個業務線下代表的含義或者屬性是不同的，這個時候如果想面向這兩個業務去做一些資料的交叉探查會消耗很多的線下溝通和排查成本。
02資料倉庫 2.0針對1.0的缺陷，我們對數倉架構進行了升級，並逐漸向資料倉庫2.0時代演進。在數倉2.0設計之初，首先需要明確大方向和目標：
明確分層和組成，以及不同部分的定位和相互關係。規範化、標準化整個資料建模流程，之前因為缺少工具支援，無法體現資料建模工作的必要性和重要性，因此提供一套完整的工具平臺實現從0到1輔助資料倉庫2.0的整體建設。這是個永遠繞不開的話題，資料一定要保持口徑統一。不管從哪個產品線或者業務線出來的資料，統計口徑要一致、明確，沒有二異性。提高效率，結合前三點，將整個數倉架構梳理清晰，儘量降低資料之間橫向的複雜互動，保持資料流向的清晰、簡潔，解決煙囪式重複建設，從而提高生產、使用效率，降低成本。數倉2.0的誕生，是為了解決1.0時代面臨的各種資料問題，使資料工作產生更大的價值。透過統一口徑、規範命名、建立統一的指標和維度體系、使用標準化的建模方式等手段，打通和標準化公司資料，同時下沉通用邏輯來提升計算效率，降低使用成本；配套多種資料中臺工具，可以讓更多的人員參與到資料使用和分析工作中來，使資料決策深入到公司的每一個角落，達到資料驅動發展的最終目標。
縱觀整個資料倉庫2.0架構，從分層來講跟1.0的區別不大，主要分為原始資料層、明細層，彙總層、應用層以及統一的維度層，上圖可以看出，對整個數倉組成做了較大調整，劃分為三個部分，分別為統一數倉、業務集市和主題數倉，同時也明確了每個組成部分的分工、定位以及相互之間的資料引用流向。
統一數倉： 主要分為統一明細資料層和統一聚合資料層。明細層負責對接下層所有的原始資料，百分之百還原所有業務域和業務過程的資料，同時遮蔽底層原始資料變動對上層造成的影響，是整個數倉2.0的底層基礎。透過明細層完成業務關係到資料關係邏輯轉換，並補充相關的維度，儲存最細粒度資料，進行復雜業務邏輯分離、資料清洗、統一規範化資料格式等ETL過程。聚合層負責對通用的指標進行沉澱，向上提供統一口徑的計算指標，同時避免重複計算。除此之外，還會提供基於OneID體系的統一累計裝置庫和新增裝置庫供上層使用。
業務集市： 主要以業務訴求為主，建設滿足業務分析的各種資料集合。在業務集市建設過程中，我們按照儘可能細的粒度去劃分業務集市，且每個業務集市之間不會出現資料依賴和橫向引用，在應用層可以跨集市進行彙總計算對外提供資料服務。這樣做的好處是，如果出現一些組織架構調整或者工作職責的變更等情況，每個業務集市無需調整，只需在應用層做相應的修改即可，同時也避免因為計算任務程式碼混在一起、資料許可權拆分等問題帶來的資料變更成本。
主題數倉： 以公司範圍內公共的主題域/主題角度，以一致性維度為基礎，跨各業務做資料的整合分析和相關建設，包括流量數倉、內容數倉、使用者數倉等。
應用層： 包括業務報表、內容分析、使用者運營等資料應用產品，按照具體的場景和需求，從業務集市和主題數倉獲取資料。
說完數倉2.0整體架構，再來明確和總結下數倉各個組成部分的定位。統一數倉提供底層全面且通用的資料並作為規範的制定者和約束者，為上層提供資料和底層模型，是資料倉庫建設的基礎。業務集市是基於統一數倉的資料和模型，結合業務資料分析目的，按照業務的特色去建設滿足各個業務的資料集合。主題數倉也是基於統一數倉的資料和模型，面向不同實體的分析，建設使用者、內容等領域的資料集合。業務集市跟主題數倉建設時，儘量保持高內聚和低耦合的原則，防止資料流向過於複雜、層次過於深、不同層次之間依賴混亂而導致後期的維護成本、開發成本越來越大。03數倉建設下面介紹如何基於數倉2.0架構和一致性維度/指標體系，構建數倉平臺，規範化數倉建模流程。資料倉平臺的架構如上圖，最底層的是基礎服務，最終生成的物理表可能會有Hive、MySQL、Kafka，ClickHouse等。再往上一層是工單管理、許可權管理、資源管理，作為平臺的輔助功能。工單管理用來對維度/指標的建立/修改操作進行審批，我們專門成立了資料倉委員會來對維度/指標的制定進行把控，同時結合實際情況，對數倉建設進行相應調整。許可權管理對不同使用者的操作許可權進行管理，根據開發者許可權展示相應的入口。
數倉管理和資料模型模組是整個數倉平臺的核心。數倉管理負責對數倉建設過程中需要的原子組成部分進行抽象的整合管理，主要包括業務管理、主題管理、維度管理、指標管理等。只有在這些基礎環節準備好的情況下，才能進行後續的數倉建模工作。我們把資料建模分為三個環節，分別為業務建模、資料建模和物理建模，在後面會針對每個環節進行詳細闡述。
數倉平臺對外提供統一的API，包括維度和指標，用於對接其他周邊系統以及最上層的產品應用。例如在報表系統對指標定義、計算口徑、說明進行統一的展示，確保指標在資料生產-使用的流轉過程中傳達準確的資訊。數倉平臺將資料建模過程產生的元資料資訊統一推送到元資料中心，用於資料圖譜服務進行資料發現和資料理解。
在介紹資料建模流程之前，先講下一致性維度和指標體系的建設。目前數倉建設主要基於維度建模理論，所以一致性維度是底層的基石。在資料倉平臺中，我們把維度分為三種類型，分別是普通維度、列舉維度和虛擬維度。
普通維度：最常見的維度型別，通常有一張對應的維表存在，每個維度都由一個主鍵和多個維度屬性組成，如使用者維度，內容維度等；列舉維度：是普通維度的一種特例，也稱為字典維度，列舉以及標準化列舉值以表示維度物件，以Key-Value的形式存在，例如：是否XX，0代表否，1代表是；虛擬維度：沒有具體業務實體承載、沒有可固化資料範圍邏輯定義的維度物件，例如隨機數、會話ID等。建立維度時，需要補充一些標籤屬性，例如維度的英文名、中文名、描述、通用性，它所屬的實體（例如：時間、空間、應用等），其中透過“通用性“把維度分為業務維度和通用維度：如果某個維度只能被一個業務使用，定為業務維度，也就是說它的適用範圍只能在某一個業務下，其他業務不可用；會被兩個及以上的業務使用，定義為通用維度。實際上，兩種型別會隨著時間而產生變化，一個維度在開始階段只被一個業務使用，但隨著業務的發展，後期會被多個業務使用，當業務維度升級成通用維度時，構建業務維度的通用維度映象。
一個維度會包含若干維度屬性，每個維度屬性包含英文名、中文名、資料型別、說明等，同時需要定義維度屬性最終在物理表中的欄位名稱，以此來實現數倉範圍內的同名同義和全域性唯一性。
關於維度建設理論，這裡不再詳細展開，有興趣的同學可以網上搜索相關文章和書籍進行了解和學習。04指標體系指標體系由指標元資料（原子指標元資料和複合指標元資料）、修飾詞、時間週期、統計指標（原子指標和複合指標）組成。
指標元資料：是統計指標的一種抽象，所有的指標必須派生於某個指標元資料。原子指標元資料/度量：是業務過程中不可再拆解的最小單元，一般是由 動作 + 計量組成，同時，原子指標元資料等同於度量，是描述一個事實的計量單位；元資料是指標對某種業務過程事實的一種抽象，如果不加修飾詞和時間週期，不能代表具體的統計意義。複合指標元資料：是多個原子指標元資料或複合指標元資料透過計算處理得到的，是對複合指標的一種抽象，如果需要作為統計指標使用需要增加對應的時間週期和修飾詞，如點選率、佔比、轉化率等。修飾詞：修飾詞可以被理解為統計指標存在的環境，用於明確統計指標的具體含義、細化口徑的描述，每個統計指標可以有一個或者多個修飾詞存在，和維度屬性可以相互轉化，如：北京的使用者、電影頻道頁等。時間週期：時間週期是用來描述統計指標的時間範圍，可以認為是一種特殊的修飾詞，並且在統計指標中，這個特殊的修飾詞是必須明確的，如：當日、最近30天等。統計指標：分為原子指標和複合指標，是指標元資料的例項化，代表了具體的事實衡量指標。原子指標：原子指標=一個元指標+多個修飾詞(可選)+時間週期，是描述一個業務過程的統計意義，如：最近一天播放次數等。複合指標：是透過多個原子指標或複合指標計算獲得的，描述多個業務過程的關係，如：最近一天播放完成率，最近30天人均啟動次數等。指標體系在資料倉平臺中的管控非常嚴格，指標相關的構建一般需要經過開發、產品、分析師、業務多方合作，結合實際場景需求系統化、規範化總結和提煉出來的。
05建模流程統一數倉建模是業務層建模的基礎，需要涵蓋儘可能多的業務過程和維度，包括業務建模、資料建模和物理建模三個階段。
業務建模是基於業務已有資訊，結合建模同學對業務的理解，對業務進行梳理，此時不會面向具體的分析細節，確認範圍主要是業務域、業務過程和實體之間的關係，輸出業務匯流排矩陣。業務建模的目的是為了對業務需求進行分解，轉化為資料理解，包括的具體流程有：劃分業務域、確認業務過程、設計事件事實，確認相關實體、關聯事件、構建業務匯流排矩陣。
業務域劃分，業務域是業務過程的集合，是對業務各個環節的粗粒度劃分，將相關的業務過程聚集到一個業務域下，例如播放域。確認業務過程：業務過程是業務中的原子行為，不能再進行拆解，我們需要在業務建模過程中，確認有哪些業務過程，並明確業務過程所屬的業務域，一個業務過程只能屬於一個業務域。設計事件事實。確認相關實體：從較粗的粒度確認一個業務過程涉及到的實體範圍，防止遺漏分析角度，同時為關聯事件實體提供聯接節點。關聯事件事實：統一數倉建模需要將已有的事件事實欄位都涵蓋到，並透過實體進行更多維度的關聯。構建業務匯流排矩陣：橫縱座標分別為描述事實本身的業務域、業務過程，以及描述事實環境的維度和實體。資料建模階段主要是為了將業務匯流排矩陣進行細化，完成業務關係到資料關係邏輯轉換，並補充相關的維度，輸出星型（雪花）模型。
確認業務：一般不跨業務，針對單個業務進行建模。確認業務過程：可以面向單個或者多個業務過程。確認維度：業務過程中包含的維度。確認度量：業務過程中涉及到的度量。退化維度屬性：為了下游使用更加高效，把一些通用的維度屬性退化到明細層模型，儘量減少與維表之間的join操作，提高效率。構建星型模型：指導後續開發操作。物理建模實際上是對資料模型的物化過程，物化過程會根據不同引擎在流程上有細微差別，最終將資料模型物化成Hive的物理表/檢視，甚至是帶有Schema結構的Kafka Topic，下面以Hive物理表為例描述整個過程。
確認資料模型：選擇需要物化的資料模型。確認表名：根據數倉規範補充完善表名資訊，例如計算週期、表型別、業務資訊等。確認描述/使用說明：補充對錶資訊的中文描述以及使用注意事項。確認分割槽欄位：例如天級、小時級。確認生命週期：根據資料重要性，設定資料保留的時間範圍，例如30天、1年等。生成物理表：同時將表的業務元資料資訊錄入到元資料中心，與模型完全對應，表名、欄位名、欄位型別等資訊標準化、統一化。如之前所述，統一數倉作為底層模型和資料的基礎來源，業務集市/主題數倉基於已有的底層模型進行建模，主要包括資料建模，物理建模（當然，可以透過統一數倉業務建模階段輸出的業務匯流排矩陣更加了解業務）。
業務層資料建模的目標是輸出主題的資料星型模型，根據不同的主題和分析場景，選取相關的業務過程，使用合理的建模手段進行資料建模，主要流程包括：確認主題、選取業務過程、確認粒度、確認維度、確認統計指標，最終輸出星型模型。
確認主題：根據具體的分析需求確認主題。選取業務過程：確認需要分析的業務以及業務過程。確認統一數倉模型：系統自動推薦相關的模型，選擇滿足條件的模型，並在此基礎上進行後續建模工作。確認粒度：相同粒度模型可以進行指標的合併。確認維度：選取後續需要下鑽分析的維度，選取過程是在業務過程的範圍內進行，不能超出維度能夠關聯的範圍。確認統計指標：選取業務過程相關的度量（原子指標元資料）派生的統計指標。構建星型模型。物理建模流程與之前所述相同，不再重複介紹。下圖是資料建模階段產出的星型模型例項，在模型圖中，將關聯的業務資訊和資料邏輯進行清晰的表達，輔助後續資料開發工作。
06資料圖譜資料圖譜以元資料為中心，提供完整、標準的元資料查詢能力，降低資料發現和資料理解的成本，構建核心資料資產目錄，提高資料使用效率。
下圖是元資料中心的架構圖，在底層使用開源框架Atlas，並針對性的進行二次開發，JanusGraph儲存元資料資訊和資料血緣，ES提供統一的元資料搜尋服務。
元資料中心主要負責元資料的採集管理，以及資料血緣的構建。元資料可以分為技術元資料+業務元資料，透過不同的平臺或者不同的底層基礎服務元件進行自動化同步和採集，例如透過HiveHook方式，自動採集Hive表的技術元資料資訊，同時數倉平臺負責將建模過程中的業務元資料資訊同步到元資料中心。與此對應，資料血緣構建透過兩部分實現，第一部分透過HiveHook、SparkHook機制，當SQL/計算任務執行完成後，自動解析輸入表和輸出表，同時擷取SQL/計算任務提交時的工作流任務資訊，自動化注入血緣；另外，在大資料開發平臺中，公司內部有自研的一套資料整合產品（BabelX），也實現了Hook機制，對資料血緣進行了整合支援。第二部分是向周邊系統服務定期拉取輸入/輸出關係實現的。我們已經打通了從Pingback-BI報表的全鏈路血緣，實現透過任何一個節點向上/向下追溯整條血緣鏈路的源頭/末端。
在以往，開發或者使用過程中，如果需要資料，大部分都是透過線下溝通的方式，找產品、找開發，經過若干輪的不懈努力才能找到，這種方式會消耗很大的溝通成本和人力成本。當找到資料後，又面臨著如何理解資料、如何正確使用資料，即使有著良好的文件規範，也難免出現更新不及時、資訊表達不準確甚至某種資訊無法在文件中進行表達。如果命不好或者資訊傳遞不準確，還會出現找到的資料和預期不符，需要重新進行溝通尋找。基於元資料中心，我們建設了資料圖譜服務，用於資料發現和資料理解，在資料圖譜建設時，有著清晰和明確的目標：建立高效的環境，支援快速的“找資料”，直觀的理解和使用資料，實現指導資料開發、提高開發效率等“用資料”需求。
“找資料“，也就是資料發現，需要提供基於“某種共識”的關鍵字搜尋能力，比如維度組合、指標組合，自動呈現匹配符合目標維度+指標矩陣的資料，並結合排序、二次篩選功能，逐漸縮小目標範圍，進行最終定位。如果搜尋非標準化的資訊，例如描述，可能出現的現象是表達不準確/二義性造成的誤導。同時，也需要結構化目錄或者嚮導式查詢的功能，能夠以簡單、快捷的方式看到業務的全景展示以及業務下面有哪些資料。例如，數倉地圖提供列表模型和圖譜模型：列表模式以目錄方式展示資料表、維度、指標，展示資料表所屬業務、主題等資訊，經過簡單篩選進行瀏覽定位；圖譜模式以拓撲圖形式對所有業務和業務過程/主題進行圖形化彙總，展示業務和資料模型全景，根據嚮導進行逐層篩選，最終定位目標資料。
“用資料”，也就是找到資料之後，如何高效的理解資料體現的業務資訊並正確的加以利用。因此，面向資料使用場景構建一個元資料的知識圖譜，獲取相關的技術元資料和業務元資料並進行友好分類展示，例如：基礎資訊包括資料所屬專案、負責人、許可權審批人員等；業務資訊包含資料所屬業務、業務域、主題域等；數倉標籤包括中文名、說明、主題模型、維度/指標等；資料資產資訊包括資產等級、SLA、質量分數等。
以Hive表為例，將Hive所有相關的資訊全部採集到元資料中心裡面，並按照標籤方式進行分類，讓資料使用者可以透過搜尋、目錄瀏覽等方式快速的找到資料，同時全方位的理解資料表達的業務含義，方便使用。
07資料血緣如之前所述，我們構建了從Pingback-BI報表的全鏈路血緣，在每個對應的環節都注入了輸入/輸出資訊以及對應的工作流任務資訊，資料血緣的價值不再過多闡述。透過資料血緣可以進行影響評估、故障排查、鏈路分析等工作。例如，當資料鏈路中某張表出現了質量問題需要進行修復回溯資料或者表進行了大的升級，需要下游配合遷移，可以透過資料血緣匯出所有的下游表、對應的工作流任務以及Owner，能夠幫助資料的生產者或者管理者快速協調下游進行變更操作。新員工可以透過血緣更加清晰的瞭解整個數倉構建流程，對此，資料血緣工具提供了鏈路剪枝和過濾功能，當資料下游過多時，透過根據某些條件進行剪枝和過濾，方便清晰的檢視某條分支鏈路。當BI報表達到下線標準時，可以透過全鏈路血緣找到對應鏈路的計算任務進行下線，解決上線容易下線難的問題，提高資源利用率和節省成本的目的。
基於全鏈路資料血緣的另一個應用是資產定級，在資料治理環節，我們首先要對資料進行資產定級打標，從而根據不同級別指定相應的治理策略，級別越高，對SLA、資料質量的要求越高。資產定級打標透過自動化+手動打標實現，在資料血緣的末端，也就是資料應用，以BI報表為例，每張報表會有重要級別標籤，結合資料血緣，向上回溯，實現對資料資產自動化打標工作。因為所有資料並不是都會生成報表，所以只能透過人工標註的方式。在後續的工作中，我們希望透過資料服務進行收口，也就是對資料API進行等級劃分，將資料API整合到全鏈路血緣，打通資料API-資料應用的血緣，從而更加全面的自動化覆蓋資料資產等級標籤。
智慧化： 用資料質量平臺建設舉例說明，以往通常的做法是，平臺提供自定義質量規則校驗和稽查能力，開發者透過人工方式進行規則和閾值設定，當表數量越來越多時，會消耗大量人力成本，即使憑藉專家經驗，也無法做出將節假日因素計算在內的動態閾值方案。 我們目前正在嘗試的一種方案是，採集數倉核心欄位並制定通用的資料質量規則（例如錶行數、去重數、空值率等），自動採集歷史資料進行樣本收集和訓練，對未來走勢進行預測，設定動態閾值，實現資料質量的自動化覆蓋，一方面節省人力，另外一方面在智慧預測的過程中可以考慮節假日因素，提高資料質量監測的準確性，減少由於節假日出現的誤報。
自動化： 基於數倉平臺將資料建模的工作進行規範化、流程化，在後續的工作中，積累沉澱出一些通用的模型和流程，實現自動化程式碼生成。
服務化： 在以往，資料對接資料應用/業務時，大部分都是直接訪問底層資料來源，這就造成了資料接入方式多種多樣，接入效率低下、資料和介面無法共享、底層資料變更，影響資料應用等問題。 在現有資料中臺建設過程中，我們建設統一的資料服務，資料以API方式作為與資料應用/業務中臺進行統一互動，來解決上述問題。
模型化： 資料模型遮蔽了底層物理實現，同時以標準、規範的方式闡述了業務資訊和資料關係邏輯。 在未來，我們希望面向使用者的不是各種物理表，而是模型。 使用者只需要選擇對應的業務、篩選需要的維度和指標，就可以自動路由到模型上，再依據模型和底層物理表的依賴關係，結合聯邦查詢的能力，自動生成查詢任務，訪問最合適的物理表，將資料輸出給終端使用者。