首先介紹一下愛奇藝公司整體的業務情況以及數據倉庫 1.0 的設計和出現的問題，針對數倉 1.0 的缺陷，是如何演進到數倉 2.0 架構以及數倉 2.0 需要解決的問題和需要達成的目標。
這張圖非常清晰的展示了愛奇藝的產品矩陣，早期愛奇藝是視頻業務，后來從視頻業務周邊衍生出來一些新的業務，以視頻業務為主圍繞着核心 IP，衍生出短視頻、小視頻、奇巴布、愛奇藝閱讀、叭噠、泡泡、奇秀直播、愛奇藝知識、體育、電商等眾多業務，從蘋果樹到蘋果園構建了泛娛樂生態矩陣。
可以看到產品矩陣中涉及的業務很多，每個業務都會產生自己的數據，同時也有着自己獨特的產品形態。既要滿足在某個特定業務場景下進行面向業務的數據探查和分析，還要基於跨多個業務場景下，從多個業務共性的角度去提取、淬煉通用的數據，實現跨業務橫向的探索分析，從而實現指導業務、對業務進行數據賦能的目標。同時，每個業務之間也會相互輔助、作用，導致每個業務之間會有頻繁的數據交互。
數據倉庫 1.0
數據倉庫 1.0 的架構圖如上，整體分層分為 5 個部分，最下面是原始數據層，再上面分別是明細層，聚合層以及應用層，右邊是面向整個數倉的維度層，用於管理一致性維度。
-
原始數據層用於保存原始數據，數據來源於各種數據生產系統，主要分三個部分：Pingback投遞，在每個業務產品進行統一規范的埋點，然后將采集到的數據進行上報，最后通過自動化處理將埋點數據進行解析、存儲；業務數據庫，主要是業務后端產生的數據，例如會員訂單、文學訂單等等，經過數據集成的手段將業務庫的數據直接同步到原始數據層進行保存；第三方外部數據，主要來自企業外部的數據源。
-
明細層用於還原業務過程，保存最細粒度的數據，對原始數據按照不同的模式進行ETL處理，完成數據清洗和部分業務邏輯處理等過程。
-
聚合層存放的是非明細的數據，通常是經過各種計算以后得到的輕度聚合和重度聚合數據，主要采用維度建模方法進行構建。
-
應用層是為了滿足業務需要而產生的結果化數據，具有很強的定制性，主要提供給相關數據應用、外部系統，以及對特定數據有需求的人員使用。是數據倉庫和外部的接口，主要對接其他系統，如業務庫、報表系統等。
縱觀數倉 1.0 架構，整個數倉的體系其實還是按照業務的角度去建設，每個業務都會建立符合自己業務特點的一個小型數據倉庫，可以快速的響應業務需求，同時做到靈活多變，支撐業務決策。但隨着數據增長、業務場景更加復雜，缺少公共數據的提煉和匯總，出現煙囪式重復建設、指標口徑不統一、數據有二義性、生產/使用效率低下等問題，同時也缺乏工具平台的有利支撐。
當不同業務之間有數據交叉的場景時，為了盡快響應業務需求，直接從其他業務明細層甚至原始數據層獲取數據，這個時候很容易出現指標統計口徑的不一致。缺少公共聚合數據的沉淀和積累，出現很多數據重疊的現象，導致煙囪式重復建設，資源消耗成本高居不下。在數倉 1.0 建設過程中，雖然有一套比較完整的數據倉庫規范，但是缺少工具平台的支持和管控，經常出現同名不同義，或者指標口徑有二義性的現象，加重了下游的使用成本和開發效率。比較典型的場景是在業務線 A 下有一個維度，在業務線 B 下也有一個維度，但是這兩個維度擁有相同的名字，而且在每個業務線下代表的含義或者屬性是不同的，這個時候如果想面向這兩個業務去做一些數據的交叉探查會消耗很多的線下溝通和排查成本。
數據倉庫 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 整體架構，再來明確和總結下數倉各個組成部分的定位。
-
統一數倉提供底層全面且通用的數據並作為規范的制定者和約束者，為上層提供數據和底層模型，是數據倉庫建設的基礎。
-
業務集市是基於統一數倉的數據和模型，結合業務數據分析目的，按照業務的特色去建設滿足各個業務的數據集合。
-
主題數倉也是基於統一數倉的數據和模型，面向不同實體的分析，建設用戶、內容等領域的數據集合。
業務集市跟主題數倉建設時，盡量保持高內聚和低耦合的原則，防止數據流向過於復雜、層次過於深、不同層次之間依賴混亂而導致后期的維護成本、開發成本越來越大。
數倉建設
下面介紹如何基於數倉 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 方式作為與數據應用/業務中台進行統一交互，來解決上述問題。
模型化
數據模型屏蔽了底層物理實現，同時以標准、規范的方式闡述了業務信息和數據關系邏輯。在未來，我們希望面向用戶的不是各種物理表，而是模型。用戶只需要選擇對應的業務、篩選需要的維度和指標，就可以自動路由到模型上，再依據模型和底層物理表的依賴關系，結合聯邦查詢的能力，自動生成查詢任務，訪問最合適的物理表，將數據輸出給終端用戶。