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