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