分享嘉賓：翟東波 搜狐媒體
編輯整理：王洪達
出品平臺：DataFunTalk、AI啓蒙者
導讀：本次分享的主題爲搜狐智能媒體數據倉庫體系建設實踐，會對數據倉庫中的基本概念進行簡單梳理，明確數據倉庫體系建設涵蓋的相關流程，主要劃分爲批量 ( 非實時 ) 數據處理和實時數據處理兩大部分：
批量數據處理：根據不同的業務需求場景，需要對數據進行分層，上層數據基於底層數據通過aggregation、join等計算生成，上層數據生產任務依賴於底層數據產生任務，任務調度管理成爲批量數據處理的一個核心功能訴求，以及由此衍生出的數據血緣管理、數據質量管理、數據權限管理等等一系列功能，這方面也有不少開源的產品，但在設計上或多或少都存在一些問題，本次演講會介紹搜狐智能媒體團隊自研的任務調度管理、元信息管理、數據質量管理、數據權限管理等系統的技術實踐；
實時數據處理：目前業界的焦點都在stream processing系統上，但針對很多aggregation、join等應用場景，stream processing並不能很好的勝任，能夠支持數據實時導和MPP查詢引擎的系統--比如Apache Doris，才能很好地滿足這些應用場景，本次演講會介紹Apache Doris在搜狐智能媒體的一些技術實踐。
01
數據倉庫體系建設主要工作
1. 數據倉庫定義
數據倉庫是1991年Bill Inmon在《Building the Data Warehouse》中最開始提出的概念。數據倉庫的定義是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用於支持管理決策。從定義中，可以看出數據倉庫不僅僅是一個數據存儲計算軟件或產品，而是包含整個數據分析處理過程體系。
2. 數據分析
數據倉庫主要是供給數據數據分析使用的，其分類主要參考商業智能分爲三大部分：
Data Reporting：分析維度較少，延遲較低，併發度較高
OLAP：分析維度、延遲和併發度都比較適中
Data Mining：分析維度可能幾百上千，維度較多，對於延遲的容忍度較高，一般用戶較少，併發度較低
3. OLAP
OLAP是數據倉庫中最經常使用數據處理和分析技術，是Edgar F.Codd在1993年發表於《Providing OLAP(On-line Analytical Processing) to User-Analysts:An IT Mandate 》論文中。OLAP主要是針對OLTP對比來說的：
OLTP：支持業務處理，操作數據或者業務數據，不適合支持決策分析
OLAP：支持決策分析、多維分析/多維數據庫
上方圖中可以看出，OLTP產生的業務數據彙總到OLAP的數據倉庫中，然後數據倉庫中產生的分析結果會促進業務系統的改進。
4. 多維模型 ( Multidimensional Model）
前面提到的多維分析是建立在多維模型之上的：
多維模型就是OLAP中的數據組織範型
主要概念：多維數據集 ( Cube )；維度 ( Dimension )；維度層次 ( Hierarchy )；維度級別 ( Level )；維度成員 ( Member )；度量/指標 ( Measure )
多維分析操作：上卷 ( Roll-up );下鑽 ( Drill-down )；切片 ( Silce )；切塊 ( Dice )；旋轉 ( Pivot )
5. 多維分析操作
① 上卷
雖然多維分析都是對立方體的操作，但是可以映射到關係模型的sql語句上來；上卷就是通過group by把一些多的維度去掉。
② 下鑽
下鑽操作，對應到關係模型的sql語句就是對一些低層次維度進行group by。
③ 切片
切片操作，對應到關係模型的sql語句就是增加一個where條件。
④ 切塊
切塊操作，對應到關係模型的sql語句就是增加兩個where條件。
⑤ 旋轉
旋轉操作，對應到關係模型的sql語句就是select時，把列的順序重新編排一下。
6. OLAP Cube構建
Cube構建主要包含兩類：
維度構建：擴展 ( 例如：a. 通過時間戳字段擴展天、小時和分鐘維度；b. 利用Id關聯將維度表的屬性放到Cube裏面來 )；剪裁 ( 類似於上卷操作，縮減維度 )
指標構建：聯合 ( 指標在兩個Cube裏面，通過union all方式放到一個Cube裏面 )
7. OLAP多維數據庫
OLAP多維數據庫按照存儲格式劃分：
ROLAP：基於關係型模型的數據庫
MOLAP：基於多維模型的數據庫，如上圖所示，將不同的維度組成一個CuboId，然後將結果存儲到KV數據庫中，MOLAP大概就是這樣
HOLAP：就是講ROLAP和MOLAP的一些特點綜合起來
ROLAP和MOLAP對比來看：
查詢速度：嚴格按照多維分析方式查詢，MOLAP查詢速度會更快一些，但是目前隨着ROLAP的幾十年發展，包含分佈式和索引的一些優化，查詢速度已經開始接近於MOLAP
裝載速度：因爲MOLAP需要做一些組合，所以裝載速度慢於ROLAP
存儲空間：MOLAP存儲空間膨脹還是比較厲害的，所以要大於ROLAP
分析靈活性：MOLAP基本上只能基於KV查詢，ROLAP是基於關係型的，靈活性上MOLAP要比ROLAP差的較多
8. 維度建模
提到ROLAP就要提到維度建模，維度建模是數據倉庫另一位大師Ralph Kimall倡導的，關係建模方法，就是將維度模型映射到關係模型：
維度表
事實表
星型模型/雪花模型/星座模型
9. 表分層
另一個比較重要的就是數據倉庫都是面向主題的，一般創建Cube都會對錶進行分層，主要分爲下面幾個層次：STG原始數據層、ODS操作數據層、DWD明細數據層、DWS彙總數據層、ADS應用數據層、DIM維度層。
這樣分層的優勢是：
防止煙囪模式，減少重複開發
將複雜問題簡單化
層次清晰，便於使用和理解
10. 數據倉庫體系架構
此處數據倉庫體系架構主要參考了Lambda架構，按照數據時效性，分爲實時層和批量層，只做新增和讀取，一般不做刪除和修改：
批量數據一般是小時級滯後，是最終標準
實時數據一般是秒、分鐘級滯後，只作參考
批量數據層從原始的業務數據系統或者行爲日誌系統抽取數據到STG層，然後經由ODS、DWD、DWS層最終到ADS層供給應用方使用；實時數據層一般沒有那麼多層次，經過Spark Streaming等處理後直接放到Kafka裏面，最後存儲到ADS層供給業務系統使用
02
整體方案
上面主要講了數據倉庫體系建設主要工作，也就是需求；接下來講一下搜狐智能媒體的相關技術實踐。
1. 搜狐智能媒體數據倉庫技術架構
首先簡單分析一下計算泛型，主要是根據Michael Stonebraker的論文《One Size Fits All》，不同場景選用不同的數據庫：
批量數據計算：交互式分析 ( 場景：報表、OLAP、Ad HOC；技術：Impala、Apache Doris )；批量處理 ( 場景：ETL、數據挖掘；技術：Hive、Spark )
實時數據計算：流處理 ( 場景：ETL、複雜事件處理；技術：Spark Streaming、Flink )；統計分析 ( 場景：報表、Ad HOC；技術：Apache Doris )
2. Apache Doris
Apache Doris是百度開發的MPP架構的分析性數據庫，看一下和其他技術選型的對比：
Kylin：MOLAP型數據庫，因爲目前主流應該是ROLAP數據庫，所以沒有考慮
ClickHouse/Druid/Elaticsearch：早期的典型的兩階段計算，沒法做複雜的SQL處理，從分析複雜性角度上沒有考慮
Impala/Presto：目前比較主流是MPP架構的數據庫，Presto和Hawq可以認爲是查詢引擎，依賴HDFS作爲存儲引擎，HDFS適合批量數據導入，對實時數據導入支持不好；Impala也是查詢引擎，但Impala既可以使用HDFS作爲批量數據存儲引擎，也可以使用KUDU作爲實時數據存儲引擎，但Impala的缺點是部署依賴太多，另外kudu只支持Unique Key模式，數據導入性能較Doris差，且對聚合查詢不友好
03
批量數據管理
1. 批量數據管理
批量數據管理和業界的方案基本相似，分爲數據任務管理、數據元信息管理、數據質量管理和數據安全管理。
批量數據處理都是對全域數據在Hadoop上進行一些分析計算，最後供給業務層使用；在Hadoop上分析計算時候我們會進行上述的管理，首先對執行的數據任務進行管理，然後對產生的數據質量進行校驗，校驗通過後才能給業務方使用，基於這之上做了元信息和安全的管理。
2. 數據任務管理
① Workflow管理系統
數據任務管理實際上就是Workflow的管理，Workflow是指一類能夠完全自動執行的經營過程，根據一系列過程規則，將文檔、信息或任務在不同的執行者之間進行傳遞與執行；Workflow管理系統通過計算機軟件對工作流的經營過程進行定義、執行並監控。
數據處理任務Workflow就是將節點通過數據流向依賴在一起，形成DAG有向無環圖；可以根據任務依賴，自動執行任務，在任務之間傳遞數據。
開源的數據倉庫Workflow管理系統：
目前用的比較多的框架有國外的Azkaban、Oozie和Airflow，但是他們都存在一些問題：
以Flow爲單位進行編輯、管理和發佈部署，對多人協同開發不友好
複雜的任務依賴不友好，如天依賴小時任務，需要寫代碼調度的輔助代碼
新建任務或修復任務，需要有補數據功能，以Flow爲單位進行調度，不適合補數據處理
② DAG節點=>任務&實例
在數據任務管理中，將DAG節點抽象爲兩個概念：任務和實例。
任務：用戶以任務爲單位進行編輯，使用SQL、Shell等進行數據處理代碼，支持最細小時粒度的週期屬性，可配置依賴父節點、就近依賴和自依賴以及一些其他屬性、告警等
實例：按天或小時爲單位，根據任務週期屬性，生成一個或多個實例，並制定每個實例運行時間；繼承對應任務中的數據處理代碼；根據任務依賴屬性和運行時間動態生成；依賴的父節點運行成功或者自身運行時間已到則會生成一個實例
③ 實例依賴生成規則
上圖展示了實例依賴生成的具體規則。
④ 實例依賴示例
根據上面舉的例子來看上圖實例依賴的示例，通過小時級表數據彙總成天級表數據，父任務會在每小時調度一次，子任務在每天的0點9分執行一次，然後根據父任務的結果產生一個天級別的數據；父任務要設置自依賴，子任務要設置就近依賴，這樣就可以通過這樣的語義設置很方便地達到業務要求。
⑤ 補歷史數據
介紹一下補歷史數據的問題，一個大的DAG任務中需要新增數據處理任務，或者是某個任務運行或邏輯有問題，就把這塊的根節點拿出來從對應的時間段開始向下遊修復數據，這樣的模型實現起來就比較方便了。
3. 數據質量管理
表爲校驗單位：一個任務實例可以產生多張表數據
校驗規則：以表爲單位進行配置；一張表可以對應多個規則；數據行數、關鍵指標等校驗
觸發：任務實力執行完後觸發；嚴重的質量問題可以阻塞下游實例調度
4. 數據元信息管理
元信息管理主要功能包含：表的創建、修改、查詢；表的生命週期管理；表的大小、分區等信息統計；表的名稱、字段等搜索；表及字段的血緣關係。
主要說一下血緣解析的做法，這塊是設計時候的難點：目前業內的大部分做法是通過hive的hook將字段信息釋放出來，然後直接導入到mysql表裏面；但目前沒有采用這種方案原因是集羣不是自主維護，另外就是它是在任務執行完之後才執行，我們需要在任務保存時候就要進行數據血緣關係的解析。
在這塊有調研一些方案：阿里的Druid提供一些解析功能，但是對Hive支持不是很好；利用Anltr結合網上開源的一些代碼進行解析，但是對Hive的集成也是有一定問題的；後來調研了Hive的代碼，發現可以重寫SematicAnalyzer函數，放到自己代碼裏面，像是hook那樣在保存或者執行代碼時候解析血緣關係。
接下來看一下上圖的Hive的整個生命操作流程：
HQL->Parser->Semantic Analyzer->Logic Plan Generator->Logical Optimizer->Physical Plan Generator->Physical Optimizer->Execution
血緣解析：
血緣解析這塊主要分爲兩部分：
表血緣解析：解析SQL語句獲得抽象語法樹；對抽象語法樹進行驗證和裁剪；遍歷抽象語法樹獲取上游表名 ( TOK_TAB ) 和下游表名 ( TOK_TABREF )
字段血緣解析：註冊UDF；重構SemanticAnalyzer；邏輯計劃生成和邏輯計劃優化；添加postExecHook，執行LineageLogger獲得Lineage Context；從LineageContext中組裝血緣信息
5. 數據安全管理
有了數據血緣關係之後做數據安全管理就很簡單了，目前只做了表級別的安全管理，字段級別太複雜，可能會對用戶使用產生一定的影響。
數據安全管理流程是：用戶針對要使用的表進行權限申請，然後管理者就會對錶權限進行審批或者回收；在數據任務執行前，會進行表權限的校驗，如果沒有權限則會暫停任務執行，並通過使用方。
04
實時數據管理
實時數據管理比較簡單一點，表沒有很分散，不需要Workflow方式執行；只需要把Kafka的Topic抽象成一張表，然後在Apache Doris裏面再建一張表，將兩邊字段映射起來，然後下發一個任務，任務方式有兩種：一種是寫個Sql下發到Spark Streaming導入到Apache Doris裏面；另一種是創建一個Doris的Routine Load任務，這裏面主要是看Doris的使用，提供代碼支持解析這種Json格式數據，只需要先在Doris裏面先創建一張表，然後創建一個Routine Load任務從Kafka中消費Json格式數據直接處理映射到表中。
05
總結
簡單總結下：我們在做整個項目時的思想是產品化、服務化，可以方便業務對接。在做技術實踐時，選擇可靠的開源產品和開源代碼，並借鑑可靠的業務解決方案，可以幫助我們快速實踐應用。
