干貨：數(shù)據(jù)中臺的深度思考與總結(jié)

干貨：數(shù)據(jù)中臺的深度思考與總結(jié)

應(yīng)

用

數(shù)

據(jù)

中

臺

存儡、受胃.分析引■

RDBMSGreenPlumESHddoopSparkFilnk

I

KafkaHBaseKuduHrveTensor^lowStorm

云

ADSFTPMongo底

IfUTAJS網(wǎng)絡(luò)5G網(wǎng)絡(luò)多元平臺混合云為源本她機(jī)房

I數(shù)據(jù)匯聚

數(shù)據(jù)匯聚是數(shù)據(jù)中臺必須提供的核心工具，把各種異構(gòu)

網(wǎng)絡(luò)、異構(gòu)數(shù)據(jù)源的數(shù)據(jù)方便地采集到數(shù)據(jù)中臺中進(jìn)行

集中存儲，為后續(xù)的加工建模做準(zhǔn)備。數(shù)據(jù)匯聚方式一

般有數(shù)據(jù)庫同步、埋點(diǎn)、網(wǎng)絡(luò)爬蟲、消息隊(duì)列等；從匯

聚的時(shí)效性來分，有離線批量匯聚和實(shí)時(shí)采集。

I數(shù)據(jù)采集工具

CanaLDataX、Sqoop

|數(shù)據(jù)開發(fā)

數(shù)據(jù)開發(fā)模塊主要面向開發(fā)人員、分析人員，提供離

線、實(shí)時(shí)、算法開發(fā)工具。

|離線開發(fā)

作業(yè)調(diào)度

?依賴調(diào)度：所有父作業(yè)運(yùn)行完成后，當(dāng)前作業(yè)才能開始運(yùn)

行。圖64中的作業(yè)B,只有父作業(yè)A和C運(yùn)行完成后，才

能開始被調(diào)度。?時(shí)間調(diào)度：可指定作業(yè)的調(diào)度開始時(shí)間。

圖64中的作業(yè)B,只有到達(dá)05:00后才能開始被調(diào)度。

基線控制

在大數(shù)據(jù)離線作業(yè)中，作業(yè)執(zhí)行時(shí)間較長，經(jīng)常遇到急

著用數(shù)據(jù)發(fā)現(xiàn)數(shù)據(jù)還沒出來的情況。采用算法對作業(yè)完

成時(shí)間進(jìn)行智能預(yù)測，根據(jù)預(yù)測，當(dāng)作業(yè)無法正常產(chǎn)出

且動態(tài)調(diào)整無法完成時(shí)，調(diào)度中心會及時(shí)通過監(jiān)控告警

通知運(yùn)維值班人員提前介入處理，為大數(shù)據(jù)作業(yè)執(zhí)行留

出充裕的時(shí)間。

異構(gòu)存儲

企業(yè)內(nèi)部的存儲計(jì)算引擎呈多元化趨勢。離線開發(fā)中心

針對每種類型的計(jì)算引擎會開發(fā)不同的組件，例如，針

對Oracle開發(fā)Oracle插件，針對Hadoop體系分別

開發(fā)出Hive、Spark.MR等插件。用戶在界面新建各

種作業(yè)類型，在執(zhí)行時(shí)自動根據(jù)作業(yè)的類型尋找相應(yīng)的

插件來運(yùn)行作業(yè)。

代碼校驗(yàn)

對于常見的SQL任務(wù)類型，SQL檢查器會做好嚴(yán)格的

管控，做到事前發(fā)現(xiàn)問題。

多環(huán)境級聯(lián)

通過環(huán)境級聯(lián)的方式靈活支持企業(yè)的各類環(huán)境需求，方

便對資源、權(quán)限進(jìn)行控制和隔離。每個(gè)環(huán)境有獨(dú)立的

Hive數(shù)據(jù)庫、Yarn調(diào)度隊(duì)列，甚至不同的Hadoop

集群。常見的環(huán)境如下：

.單一環(huán)境：只有一個(gè)生產(chǎn)環(huán)境，內(nèi)部管理簡單。

?經(jīng)典環(huán)境：開發(fā)環(huán)境中存放脫敏數(shù)據(jù)、供開發(fā)測試使用，

上生產(chǎn)環(huán)境走發(fā)布流程，用于真實(shí)數(shù)據(jù)生產(chǎn)。

?任務(wù)、資源和函數(shù)必須在開發(fā)環(huán)境下進(jìn)行新建、修改或刪

除，再經(jīng)過提交、創(chuàng)建發(fā)布包、同意發(fā)布三個(gè)操作后，才能

同步到生產(chǎn)環(huán)境。

?復(fù)雜環(huán)境：企業(yè)有外部人員和內(nèi)部人員，會給外部人員提

供一個(gè)脫敏管控的環(huán)境，外部人員開發(fā)完的數(shù)據(jù)模型經(jīng)過測

試后發(fā)布到內(nèi)部開發(fā)環(huán)境。

推薦依賴

隨著業(yè)務(wù)的不斷深入，數(shù)據(jù)開發(fā)人員需要開發(fā)的作業(yè)會

不斷累加。既能保證準(zhǔn)確找到需要定位的上游作業(yè)，又

能保證不會形成環(huán)路。

輸出表:tableD

?獲取推薦依賴的核心原理在于上下游作業(yè)輸入和輸出的表

級血緣依賴圖；

?通過血緣分析當(dāng)前作業(yè)的輸入和輸出，找到合適的上游作

業(yè)；

?對合適的作業(yè)進(jìn)行環(huán)路檢測，剔除存在閉環(huán)的作業(yè)；?返回

合適的節(jié)點(diǎn)列表。

數(shù)據(jù)權(quán)限

企業(yè)內(nèi)部計(jì)算引擎多樣化，數(shù)據(jù)權(quán)限管理面臨如下問

題：

?部分引擎擁有獨(dú)立的權(quán)限管理系統(tǒng)(例如Oracle.

HANA、LibrA)，導(dǎo)致權(quán)限申請需要到每一種引擎上單獨(dú)

操作，讓使用變得復(fù)雜。

?同一種計(jì)算引擎，不同廠商的權(quán)限系統(tǒng)有多種，例如

Hadoop自身無數(shù)據(jù)權(quán)限系統(tǒng)，由不同廠商各自去實(shí)現(xiàn)，

目前主要有兩種策略：

?RBAC(Role-BasedAccessControl):如Cloudera

用的是Sentry,華為的FI也是類似的機(jī)制?PBAC

(Policy-BasedAccessControl):如Hortonworks用

的Ranger

?數(shù)據(jù)權(quán)限是由大數(shù)據(jù)集群或數(shù)據(jù)庫運(yùn)維人員管理的，開發(fā)

人員無法直接操作或者接觸，所有的權(quán)限申請都需要運(yùn)維人

員開通，造成運(yùn)維人員負(fù)擔(dān)過重。在實(shí)際開發(fā)中，一般需要

運(yùn)維人員把整個(gè)庫的權(quán)限授權(quán)給某個(gè)開發(fā)負(fù)責(zé)人，然后庫里

面的表、字段、函數(shù)的權(quán)限管理由開發(fā)負(fù)責(zé)人負(fù)責(zé)就行。

?數(shù)據(jù)權(quán)限管理中心提供界面化操作，數(shù)據(jù)申請方直接在頁

面上進(jìn)行各種權(quán)限的申請，數(shù)據(jù)管理方在界面上審核權(quán)限，

執(zhí)行同意或拒絕操作。同時(shí)，所有權(quán)限的申請、審批都會有

記錄，便于進(jìn)行權(quán)限審計(jì)。在統(tǒng)一數(shù)據(jù)權(quán)限服務(wù)中，會對接

底層的各種權(quán)限管理系統(tǒng)，例如Sentry.Ranger.

Oracle,同時(shí)對數(shù)據(jù)權(quán)限管理中心提供服務(wù)，執(zhí)行權(quán)限的

申請、授權(quán)、撤銷等操作。

|實(shí)時(shí)開發(fā)

?元數(shù)據(jù)管理?SQL驅(qū)動?組件化開發(fā)

|智能運(yùn)維

任務(wù)的管理、代碼發(fā)布、運(yùn)維、監(jiān)控、告警等一系列集

成工具，方便使用，提升效率。重跑、重跑下游、補(bǔ)數(shù)

據(jù)。

|數(shù)據(jù)體系

有了數(shù)據(jù)匯聚、數(shù)據(jù)開發(fā)模塊，中臺已經(jīng)具備傳統(tǒng)數(shù)據(jù)

倉庫（后面簡稱：數(shù)倉）平臺的基本能力，可以做數(shù)據(jù)

的匯聚以及各種數(shù)據(jù)開發(fā)，就可以建立企業(yè)的數(shù)據(jù)體

系。之前說數(shù)據(jù)體系是中臺的血肉，開發(fā)、管理、使用

的都是數(shù)據(jù)。

中臺數(shù)據(jù)體系應(yīng)具備以下特征：

?覆蓋全域數(shù)據(jù)：數(shù)據(jù)集中建設(shè)、覆蓋所有業(yè)務(wù)過程數(shù)據(jù)，

業(yè)務(wù)中臺在數(shù)據(jù)體系中總能找到需要的數(shù)據(jù)。

?結(jié)構(gòu)層次清晰：縱向的數(shù)據(jù)分層、橫向主題域、業(yè)務(wù)過程

劃分，讓整個(gè)層次結(jié)構(gòu)清晰易理解。

?數(shù)據(jù)準(zhǔn)確一致：定義一致性指標(biāo)，統(tǒng)一命名、統(tǒng)一業(yè)務(wù)含

義、統(tǒng)一計(jì)算口徑，并有專業(yè)團(tuán)隊(duì)負(fù)責(zé)建模，保證數(shù)據(jù)的準(zhǔn)

確一致。

?性能提升：統(tǒng)一的規(guī)劃設(shè)計(jì)，選用合理的數(shù)據(jù)模型，清晰

的定義并統(tǒng)一規(guī)范，并且考慮使用場景，使整體性能更好。

?降低成本：數(shù)據(jù)體系的建設(shè)使得數(shù)據(jù)能被業(yè)務(wù)共享，這避

免了大量煙囪式的重復(fù)建設(shè)，節(jié)約了計(jì)算、存儲和人力成

本。

?方便易用：易用的總體原則是越往后越能方便地直接使用

數(shù)據(jù)，把一些復(fù)雜的處理盡可能前置，必要時(shí)做適當(dāng)?shù)娜哂?/p>

處理。

不同行業(yè)的數(shù)據(jù)體系建設(shè)：

地產(chǎn)行業(yè)

應(yīng)用數(shù)據(jù)層

精準(zhǔn)營銷拿地決策供應(yīng)商評估產(chǎn)品定價(jià)…

ADS

標(biāo)簽數(shù)據(jù)層

客戶標(biāo)簽項(xiàng)目標(biāo)簽樓盤標(biāo)簽土地標(biāo)簽供應(yīng)商標(biāo)簽

TDM

統(tǒng)一數(shù)倉層

產(chǎn)品域客戶域供應(yīng)商域財(cái)務(wù)域營銷域客服與售后域

DW

貼源數(shù)據(jù)層ERPCRM售樓系統(tǒng)物業(yè)系統(tǒng)商業(yè)管理酒店系統(tǒng)客廠與統(tǒng)小溥在尋優(yōu)

數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)數(shù)括一‘奴器

ODS

證券行業(yè)

應(yīng)用數(shù)據(jù)層

投資者行為信用業(yè)務(wù)營銷客戶畫像

ADS

標(biāo)簽數(shù)據(jù)層

個(gè)人客戶標(biāo)簽機(jī)構(gòu)客戶標(biāo)簽基金產(chǎn)品標(biāo)簽交易對手標(biāo)簽

TDM

統(tǒng)一數(shù)倉層

客戶域營銷域零售經(jīng)紀(jì)域機(jī)構(gòu)經(jīng)紀(jì)域投資顧問域管理支撐域運(yùn)營域

DW

貼源數(shù)據(jù)層CRM集中交易融資融券網(wǎng)上交易資產(chǎn)管理風(fēng)險(xiǎn)【'V

ODS數(shù)據(jù)系統(tǒng)數(shù)據(jù)系統(tǒng)數(shù)據(jù)系統(tǒng)數(shù)據(jù)系統(tǒng)數(shù)據(jù)系統(tǒng)數(shù)據(jù)系統(tǒng)數(shù)套

零售行業(yè)

應(yīng)用數(shù)據(jù)層

紅包推送營銷網(wǎng)人個(gè)性推薦

ADS

標(biāo)簽數(shù)據(jù)層

會員標(biāo)簽門店標(biāo)簽商品標(biāo)簽

TDM

統(tǒng)一數(shù)倉層

會員域門店域供應(yīng)商域商品域訂單域財(cái)務(wù)域營銷域日志域渠道域終端域

DW

貼源數(shù)據(jù)層CRM門店零售管理線上交易庫存管理線上日志J?-

ODS數(shù)據(jù)系統(tǒng)數(shù)據(jù)數(shù)據(jù)系統(tǒng)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)

制造行業(yè)

應(yīng)用數(shù)據(jù)層

阿米巴運(yùn)營數(shù)字化決策產(chǎn)品質(zhì)量

ADS

標(biāo)簽數(shù)據(jù)層

員工標(biāo)簽供應(yīng)商標(biāo)簽原材料標(biāo)簽

TDM

統(tǒng)一數(shù)倉層

客戶域工廠域供應(yīng)商域產(chǎn)品域訂單域財(cái)務(wù)域營銷域

DW

貼源數(shù)據(jù)層CRMWMSERPMES庫存管理設(shè)備管：/zhjj?等瑟

ODS數(shù)據(jù)系統(tǒng)數(shù)據(jù)數(shù)據(jù)系統(tǒng)數(shù)據(jù)系統(tǒng)數(shù)據(jù)系統(tǒng)數(shù)據(jù)系統(tǒng)數(shù)據(jù),

傳媒行業(yè)

應(yīng)用數(shù)據(jù)層

內(nèi)容推薦精準(zhǔn)營銷知識運(yùn)營

ADS

標(biāo)簽數(shù)據(jù)層

用戶標(biāo)簽期刊標(biāo)簽營銷標(biāo)簽

TDM

統(tǒng)一數(shù)倉層

用戶域內(nèi)容域財(cái)務(wù)域

DW

貼源數(shù)據(jù)層內(nèi)容管理排版流程ERP音頻視加一圖片

ODS系統(tǒng)數(shù)據(jù)管理系統(tǒng)數(shù)據(jù)數(shù)據(jù)數(shù)據(jù)二Z“啜裙？

檢務(wù)行業(yè)

應(yīng)用數(shù)據(jù)層

公益訴訟相關(guān)表刑事檢察相關(guān)表案件業(yè)務(wù)相關(guān)表

ADS

標(biāo)簽數(shù)據(jù)層

自然人標(biāo)簽企業(yè)法人標(biāo)簽案件標(biāo)簽公益線索標(biāo)簽

TDM

統(tǒng)一數(shù)倉層

公益訴訟域刑事檢察域民事檢察域行政檢察域案件業(yè)務(wù)域

DW

貼源數(shù)據(jù)層執(zhí)法信息法院裁判民生互聯(lián)網(wǎng)群眾舉報(bào)-%.濟(jì)而酣0

ODS系統(tǒng)數(shù)據(jù)文書熱線數(shù)據(jù)數(shù)據(jù)~"-蜓靠坡田

貼源數(shù)據(jù)層ODS

對各業(yè)務(wù)系統(tǒng)數(shù)據(jù)進(jìn)行采集、匯聚，盡可能保留原始業(yè)

務(wù)流程數(shù)據(jù)，與業(yè)務(wù)系統(tǒng)基本保持一致，僅做簡單整

合、非結(jié)構(gòu)化數(shù)據(jù)結(jié)構(gòu)化處理或者增加標(biāo)識數(shù)據(jù)日期描

述信息，不做深度清洗加工。

?表名：ODS_系統(tǒng)簡稱一業(yè)務(wù)系統(tǒng)表名

-字段名：與業(yè)務(wù)系統(tǒng)字段名保持一致，字段類型也盡可能

保持一致?對于數(shù)據(jù)量比較大的業(yè)務(wù)表，采用增量同步的方

式，則要同時(shí)建立增量表和全量表，增量表命名加后綴：

ODS_系統(tǒng)簡稱一業(yè)務(wù)系統(tǒng)表名.delta。

?對于日志、文件等半結(jié)構(gòu)數(shù)據(jù)，不僅要存儲原始數(shù)據(jù)，還

要存儲結(jié)構(gòu)化之后的數(shù)據(jù)。

使用DataX同步數(shù)據(jù)步驟：

1）確定業(yè)務(wù)系統(tǒng)源表與貼源數(shù)據(jù)層目標(biāo)表

2）配置數(shù)據(jù)字段映射關(guān)系，目標(biāo)表可能會增加采集日

期、分區(qū)、原系統(tǒng)標(biāo)識等必要信息，業(yè)務(wù)相關(guān)內(nèi)容不做

轉(zhuǎn)換

3）如果是增量同步或著有條件的同步部分?jǐn)?shù)據(jù)，則配

置數(shù)據(jù)同步條件

4）清理目標(biāo)表對應(yīng)數(shù)據(jù)

5）啟動同步任務(wù)，往貼源數(shù)據(jù)層目標(biāo)表導(dǎo)入數(shù)據(jù)

6）驗(yàn)證任務(wù)是否可以正確運(yùn)行，并且采集到準(zhǔn)確數(shù)據(jù)

7）發(fā)布采集任務(wù)，加入生產(chǎn)調(diào)度，并配置相關(guān)限速、

容錯(cuò)、質(zhì)量監(jiān)控、告警機(jī)制

統(tǒng)一數(shù)倉層DW

?明細(xì)數(shù)據(jù)層DWD?匯總數(shù)據(jù)層DWS

與傳統(tǒng)數(shù)據(jù)倉庫功能基本一致，對全歷史業(yè)務(wù)過程數(shù)據(jù)

進(jìn)行建模存儲。對來源于業(yè)務(wù)系統(tǒng)的數(shù)據(jù)進(jìn)行重新組

織。業(yè)務(wù)系統(tǒng)是按照業(yè)務(wù)流程方便操作的方式來組織數(shù)

據(jù)的，而統(tǒng)一數(shù)倉層從業(yè)務(wù)易理解的視角來重新組織，

定義一致的指標(biāo)、維度，各業(yè)務(wù)板塊、業(yè)務(wù)域按照統(tǒng)一

規(guī)范獨(dú)立建設(shè)，從而形成統(tǒng)一規(guī)范的標(biāo)準(zhǔn)業(yè)務(wù)數(shù)據(jù)體

系。

?標(biāo)簽數(shù)據(jù)層TDM

面向?qū)ο蠼＃瑢鐦I(yè)務(wù)板塊、跨數(shù)據(jù)域的特定對象數(shù)

據(jù)進(jìn)行整合，通過IDMapping把各個(gè)業(yè)務(wù)板塊、各個(gè)

業(yè)務(wù)過程中的同一對象的數(shù)據(jù)打通，形成對象的全域標(biāo)

簽體系，方便深度分析、挖掘、應(yīng)用。

身份信息

客戶標(biāo)簽體系

應(yīng)用數(shù)據(jù)層ADS

按照業(yè)務(wù)的需要從統(tǒng)一數(shù)倉層、標(biāo)簽數(shù)據(jù)層抽取數(shù)據(jù)，

并面向業(yè)務(wù)的特殊需要加工業(yè)務(wù)特定數(shù)據(jù)，以滿足業(yè)務(wù)

及性能需求，向特定應(yīng)用組裝應(yīng)用數(shù)據(jù)。

數(shù)據(jù)資產(chǎn)管理

數(shù)據(jù)資產(chǎn)管理包括對數(shù)據(jù)資產(chǎn)目錄、元數(shù)據(jù)、數(shù)據(jù)質(zhì)

量、數(shù)據(jù)血緣、數(shù)據(jù)生命周期等進(jìn)行管理和展示，以一

種更直觀的方式展現(xiàn)企業(yè)的數(shù)據(jù)資產(chǎn)，提升企業(yè)的數(shù)據(jù)

意識。

數(shù)據(jù)資產(chǎn)對上支持以價(jià)值挖掘和業(yè)務(wù)賦能為導(dǎo)向的數(shù)據(jù)

應(yīng)用開發(fā)，對下依托大數(shù)據(jù)平臺實(shí)現(xiàn)數(shù)據(jù)全生命周期的

管理，并對企業(yè)數(shù)據(jù)資產(chǎn)的價(jià)值、質(zhì)量進(jìn)行評估，促進(jìn)

企業(yè)數(shù)據(jù)資產(chǎn)不斷自我完善，持續(xù)向業(yè)務(wù)輸出動力。

I數(shù)據(jù)治理

傳統(tǒng)的數(shù)據(jù)治理通常包含數(shù)據(jù)標(biāo)準(zhǔn)管理、元數(shù)據(jù)管理、

數(shù)據(jù)質(zhì)量管理、數(shù)據(jù)安全管理、數(shù)據(jù)生命周期管理等內(nèi)

容。

I數(shù)據(jù)服務(wù)體系

前面利用數(shù)據(jù)匯聚、數(shù)據(jù)開發(fā)建設(shè)企業(yè)的數(shù)據(jù)資產(chǎn)，利

用數(shù)據(jù)管理展現(xiàn)企業(yè)的數(shù)據(jù)資產(chǎn)，但是并沒有發(fā)揮數(shù)據(jù)

的價(jià)值。數(shù)據(jù)服務(wù)體系就是把數(shù)據(jù)變?yōu)橐环N服務(wù)能力，

通過數(shù)據(jù)服務(wù)讓數(shù)據(jù)參與到業(yè)務(wù)，快速開發(fā)企業(yè)的業(yè)務(wù)

中臺等。

查詢服務(wù)

輸入特定的查詢條件，返回該條件下的數(shù)據(jù)，以API形

式供上層應(yīng)用調(diào)用。

1）支持配置查詢標(biāo)識，底層數(shù)據(jù)組織一般會對該標(biāo)識

建立索引，以加快查詢速度

2）支持配置過濾項(xiàng)

3）支持查詢結(jié)果配置，包括數(shù)據(jù)排序規(guī)則和分頁規(guī)

則。

|分析服務(wù)

借助分析組件高效的大數(shù)據(jù)分析能力，對數(shù)據(jù)進(jìn)行關(guān)聯(lián)

分析，分析結(jié)果通過API形式供上層應(yīng)用調(diào)用。

1）支持多源數(shù)據(jù)接入：企業(yè)的數(shù)據(jù)經(jīng)過清洗加工轉(zhuǎn)換

成數(shù)據(jù)資產(chǎn)后，最終通過服務(wù)作用于業(yè)務(wù)系統(tǒng)，基于企

業(yè)異構(gòu)存儲的現(xiàn)狀，要求分析服務(wù)能夠支持與Hive、

ES、Greenplum.MySQL、Oracle.本地文件等多

種數(shù)據(jù)源進(jìn)行連接。

2）高性能即席查詢：隨著企業(yè)數(shù)據(jù)爆發(fā)式增長，傳統(tǒng)

的數(shù)據(jù)分析工具遇到分析能力的瓶頸，也就是對大數(shù)據(jù)

量的分析越來越乏力。因此，這就要求分析服務(wù)內(nèi)置高

速計(jì)算引擎，以對數(shù)據(jù)進(jìn)行高性能的即席計(jì)算，實(shí)現(xiàn)億

級數(shù)據(jù)毫秒級（至多秒級）分析和計(jì)算，減少用戶等待

時(shí)間。

3）多維數(shù)據(jù)分析

分析服務(wù)除了支持常規(guī)的數(shù)據(jù)分析、上卷下鉆、切片切

塊之外，還應(yīng)該支持多維的數(shù)據(jù)分析以及深層次的數(shù)據(jù)

挖掘，發(fā)現(xiàn)數(shù)據(jù)背后的關(guān)聯(lián)關(guān)系。

4）靈活對接業(yè)務(wù)系統(tǒng)

|推薦服務(wù)

按約定的格式提供歷史日志行為數(shù)據(jù)和實(shí)時(shí)訪問數(shù)據(jù)，

推薦模型就會生成相應(yīng)的推薦API,從而為上層應(yīng)用提

供推薦服務(wù)。

推薦服務(wù)即所謂的千人干面，對不同的人對物的行為進(jìn)

行數(shù)據(jù)挖掘，構(gòu)建每個(gè)人與物之間的關(guān)系程度，來推薦

人、物以滿足用戶的興趣愛好，以提升用戶對業(yè)務(wù)的粘

性。每個(gè)人打開手機(jī)淘寶看到的內(nèi)容都不一樣，這就是

一種基于人的興趣愛好的推薦服務(wù)能力。

1）支持不同行業(yè)的推薦：不同行業(yè)背后的推薦邏輯是

有區(qū)別的

2）支持不同場景的推薦：以內(nèi)容資訊為例，在用戶冷

啟動場景下，應(yīng)該推薦哪些資訊？在用戶已有瀏覽行為

的場景下，又該為其推薦哪些資訊？

3）支持推薦效果優(yōu)化：從導(dǎo)入的原始數(shù)據(jù)開始，經(jīng)過

推薦組件生成推薦數(shù)據(jù)，再根據(jù)用戶的瀏覽數(shù)據(jù)不斷修

正推薦模型，從而使推薦效果不斷優(yōu)化

|圈人服務(wù)

從全量用戶數(shù)據(jù)中，基于標(biāo)簽組合篩選符合指定特征條

件的人群，并通過API形式供上層應(yīng)用調(diào)用。

1）支持人群圈選：通過SQL代碼或標(biāo)簽取值組合等多

種方式，實(shí)現(xiàn)人員查找，幫用戶找到對的人群

2）支持人群計(jì)量：營銷部門或者廣告公司使用圈人服

務(wù)圈選出目標(biāo)人群后，往往還要考慮人群量是否符合預(yù)

期，因?yàn)轭A(yù)算有限，不可能不計(jì)成本的對人群進(jìn)行營

銷。

3）支持多渠道對接：將人群名單導(dǎo)出到相應(yīng)的下游系

統(tǒng)。最簡單的名單導(dǎo)出方式是先下載文件，再由業(yè)務(wù)人

員導(dǎo)入相應(yīng)的業(yè)務(wù)系統(tǒng)中。或者直接對接到短信系統(tǒng)、

微信投放接口、營銷活動系統(tǒng)等。

離線平臺

蘇寧離線平臺產(chǎn)品功能圖:

鎂開發(fā)

新建編輯刪除圖形化可視化即時(shí)編輯實(shí)時(shí)生效資源上傳下載

復(fù)制任務(wù)導(dǎo)入導(dǎo)出大任務(wù)流自助拆分豐富彳竊參數(shù)

任務(wù)分類管理SQL解析任務(wù)模板樣例搬豐富任務(wù)類型

幫助手冊任務(wù)交接根據(jù)血緣信息，自動建立任務(wù)依賴關(guān)系

____________________fE務(wù)運(yùn)維

上下線失敗重試殺死

忽略失敗,ms調(diào)度狀態(tài)自助分析操作日志崛

任務(wù)鏈依賴分析任務(wù)發(fā)布管理任務(wù)異常自助診斷知識庫建立

任務(wù)運(yùn)行分析任務(wù)優(yōu)化建議任務(wù)監(jiān)控和告警任夠腦1崛

11

蘇寧調(diào)度模塊功能圖：

調(diào)度方式調(diào)度執(zhí)行計(jì)劃工作流的敢放

定時(shí)分片DAG靜態(tài)計(jì)劃動態(tài)計(jì)劃靜態(tài)顯式定義動態(tài)隱式定義

、業(yè)依賴1系依賴策略

任務(wù)依賴數(shù)據(jù)依賴時(shí)間依賴

_流控策略

執(zhí)行時(shí)間任務(wù)組并發(fā)

彳鎊犧系統(tǒng)級內(nèi)部控制

任務(wù)的提交來源

調(diào)度類型資源使用情況

調(diào)度高可靠性隔離對外API

定時(shí)領(lǐng)提前領(lǐng)ilim聯(lián)公共資源夕陪15資源狀態(tài)發(fā)布

輟級資源黑白名單幅沖峨3ng

HA主備分布式集群安全性

蘇寧離線平臺整體架構(gòu)圖：

跨任務(wù)流依賴的實(shí)現(xiàn)：

FTP事件機(jī)制，即在FTP服務(wù)器上建立標(biāo)識文件，一

個(gè)事件對應(yīng)一個(gè)標(biāo)識文件地址，當(dāng)FTP服務(wù)器上的標(biāo)

識文件生成的時(shí)候，我們認(rèn)為業(yè)務(wù)系統(tǒng)已經(jīng)完成作業(yè)，

需要觸發(fā)平臺任務(wù)執(zhí)行。

"華佗"平臺，實(shí)施任務(wù)診斷：

2c數(shù)的：61DE若委任務(wù)設(shè)計(jì)掰霰中心運(yùn)笫中心HJREe?RBWe系箍配百頻*W＞，

2018-11-0117:10^4

比歷史早均/

￡￡??a平白運(yùn)行徉禽

ApproSOtflAOBXJWGENiAfrttS

w*atior.l53201I-U-0117:1

工博

&?ttW9154924^0.107L,2018-11-0117:11^6SUCCHDED

W88?

wesai

^18-n-oi儂

2018-11-0117J2：26SUCCEEDED

LSB

Q施作日芯599707

4p|dic?tion.lS3

運(yùn)維&?申蕾2018-11-4117:2*0

91S4928300.102018-11-01X724^?6SUCaEDED

3:52ma日本

400325

?ppIkAtion.lSJ

#154928200.10鑿…聲—awSUCCEEDED

596129

4ppJlc<ition_153

2018-11-0117J口得

WM928200.10201S-110117^3>46SUCCHDED

3:19iXaEe

M01M

?ppiicMion_153^MWWt,?>W-

2018-11-0117:1

91MW8200.102018-11-011M?C05SUCCEEDED[JW?)gwiJu*

1:22*>?產(chǎn)？專

5965a、Cznisneng

&中icati8」，3

201B-11-0117il____________________

9154928200.10瑞“5x-2018-lt-Ol1721:53SUCCEEDED

4Q7Qg

立即觸發(fā)的任務(wù)，放入DelayQueue的隊(duì)列頭部，周

期調(diào)度的任務(wù)，使用Quartz,依賴觸發(fā)的任務(wù)，使用

zk,各個(gè)子節(jié)點(diǎn)監(jiān)聽自己的父節(jié)點(diǎn)，所有父節(jié)點(diǎn)執(zhí)行完

畢則可觸發(fā)執(zhí)行

|實(shí)時(shí)平臺

美團(tuán)點(diǎn)評

^01ApacheFlink

監(jiān)控報(bào)警鏈路

日志指標(biāo)收集

蜿TL集中化

解析展示

多mT式防itM合工

監(jiān)控報(bào)詈o

ApacheFhnk中文學(xué)習(xí)網(wǎng)站：eEus:（二Zhj二92ng

OApachaFlickCommuAftyOwn*產(chǎn)*Q業(yè)用途

使用了Grafana,可以內(nèi)嵌到自己的平臺。

bilibili

?SQL化編程

?DAG拖拽編程

?一體化托管運(yùn)維

實(shí)時(shí)平臺由實(shí)時(shí)傳輸和實(shí)時(shí)計(jì)算兩部分組成，平臺底層

統(tǒng)一管理元數(shù)據(jù)、血緣、權(quán)限以及作業(yè)運(yùn)維等。實(shí)時(shí)傳

輸主要負(fù)責(zé)將數(shù)據(jù)傳入到大數(shù)據(jù)體系中。實(shí)時(shí)計(jì)算基于

BSQL提供各種應(yīng)用場景支持。

如下圖所示，實(shí)時(shí)傳輸有APP日志、數(shù)據(jù)庫Binlog.

服務(wù)端日志或系統(tǒng)日志。bilibili內(nèi)部的Lancer?系統(tǒng)

解決數(shù)據(jù)落地到或計(jì)算體系主要圍繞

KafkaHDFSO

Saber構(gòu)建一套BSQL,底層基于YARN進(jìn)行調(diào)度管

理。

上層核心基于Flink構(gòu)建運(yùn)行池。再向上一層滿足多種

維表場景，包括MySQL、Redis、HBaseo狀態(tài)

(State)部分在RocksDB基礎(chǔ)上，還擴(kuò)展了

MapDB、RedisoFlink需要10密集是很麻煩的問

題，因?yàn)镕link的資源調(diào)度體系內(nèi)有內(nèi)存和CPU，但

10單位未做統(tǒng)一管理。當(dāng)某一個(gè)作業(yè)對10有強(qiáng)烈的需

求時(shí)，需要分配很多以CPU或內(nèi)存為單位的資源，目

未必能夠很好的滿足I。的擴(kuò)展。所以本質(zhì)上bilibili

現(xiàn)階段是將I。密集的資源的State轉(zhuǎn)移到Redis上

做緩解。數(shù)據(jù)經(jīng)過BSQL計(jì)算完成之后傳輸?shù)綄?shí)時(shí)數(shù)

倉，如Kafka.HBase.ES或MySQL、TiDBo最終

到AI或BL報(bào)表以及日志中心。

FLINK2

FORWARD*

平臺架構(gòu)

Theplatformarchitecture

zhisheng

場景

?AI工程方向，解決了廣告、搜索、推薦的流式Joiner和

維表Joiner

?實(shí)時(shí)計(jì)算的特征支持，支持Player以及CDN的質(zhì)量監(jiān)

控。包括直播、PCU、卡頓率、CDN質(zhì)量等；

?用戶增長，即如何借助實(shí)時(shí)計(jì)算進(jìn)行渠道分析、調(diào)整渠道

投放效果；

?實(shí)時(shí)ETL,包括Boss實(shí)時(shí)播報(bào)、實(shí)時(shí)大屏、看板等。

網(wǎng)易

目前網(wǎng)易流計(jì)算覆蓋了絕大多數(shù)場景，包括廣告、電商

大屏、ETL、數(shù)據(jù)分析、推薦、風(fēng)控、搜索、直播等。

事件管理

對于分布式平臺的任務(wù)操作而言，當(dāng)前任務(wù)啟動過程中

只允許一個(gè)人操作，而不允許兩個(gè)人同時(shí)操作，這就需

要以下幾個(gè)模塊來共同配合：

?Server:事件執(zhí)行的發(fā)起者，接受事件的請求，進(jìn)行數(shù)據(jù)

校驗(yàn)，拼裝，將事件發(fā)送給Kernel執(zhí)行。

?Kernel:事件具體邏輯的執(zhí)行者，根據(jù)請求向集群發(fā)送指

令（Shell腳本方式）。

?Admin:事件執(zhí)行結(jié)果的確認(rèn)者，根據(jù)事件類型，獲取事

件的最終結(jié)果，保證結(jié)果的正確性。

FLINK飛

FORWARD^

事件管理

Eventmanagement

事件包括任務(wù)的啟動和停止兩個(gè)操作，由Server.

Kernel,Admin三個(gè)模塊共同完成

Theeventincludestwooperationsoftaskstartandstop,

whicharecompletedbythreemodules:Server,Kerneland

Admin

Server:事件執(zhí)行的發(fā)起者.接受事件的請求，進(jìn)

行數(shù)據(jù)校驗(yàn).拼裝，將事件發(fā)送給kernel執(zhí)行

Server:Theinitiatorofeventexecution,acceptstherequest

oftheevent,performsdataverificationandassembly,and

sendstheeventtothekernelforexecution

Kernel:事件具體邏輯的執(zhí)行者，根據(jù)請求向集群

發(fā)送指令(shell腳本方式)

KernekTheexecutoroftheeventspecificlogic,sends

instructionstotheclusteraccordingtotherequest(shell

scriptmode)

Admin事件執(zhí)行結(jié)果的確認(rèn)者，根據(jù)事件類型，

獲取事件的最終結(jié)果.保證結(jié)果的正確性

AdminTheconfirmeroftheeventexecutionresult,obtains

thefinalresultoftheeventaccordingtotheeventtypeto

ensurethecorrectnessoftheresult

以啟動場景為例：

首先，Server會接收到來自用戶的啟動請求，之后會

創(chuàng)建一個(gè)分布式鎖，Admin會監(jiān)控這個(gè)鎖。

然后，Server向Kernel提交任務(wù)，提交之后會立即

返回，返回之后就會立即更新數(shù)據(jù)庫中的狀態(tài)，將狀態(tài)

更新為啟動中，這樣在頁面上用戶就能夠看到任務(wù)是啟

動中的狀態(tài)了。

接下來，Server就會等待內(nèi)核的Shell腳本的執(zhí)行結(jié)

果，如果Shell腳本執(zhí)行成功了，就會去寫

Zookeeper,寫完Zookeeper之后Admin模塊就

會馬上檢測到Zookeeper節(jié)點(diǎn)有狀態(tài)發(fā)生了修改，

Admin會立即去獲取YARN上的任務(wù)狀態(tài)，如果獲取

到任務(wù)狀態(tài)是運(yùn)行中，就將數(shù)據(jù)庫的任務(wù)狀態(tài)更新為運(yùn)

行中，這會在前端看到任務(wù)就已經(jīng)是運(yùn)行狀態(tài)了。

最后一步是Admin更為完數(shù)據(jù)庫之后，會釋放掉

Zookeeper上的鎖，其他人這時(shí)候就可以操作這個(gè)任

務(wù)了。

Server.Kernel和Admin這三個(gè)模塊都是不可靠

的，那么如何保證其穩(wěn)定和高可用呢？Server可以通

過部署多個(gè)，水平擴(kuò)展來實(shí)現(xiàn)，Kernel則會由Server

來進(jìn)行監(jiān)聽，當(dāng)發(fā)現(xiàn)Kernel掛了，可以由Server重

新拉起或者重新創(chuàng)建。而Admin的高可用則是通過熱

備來實(shí)現(xiàn)的，如果主Admin掛掉了，可以馬上遷移到

備Admin,備Admin可以迅速將元數(shù)據(jù)以及任務(wù)信

息全部加載進(jìn)來接替工作，進(jìn)而實(shí)現(xiàn)高可用。

平臺任務(wù)狀態(tài)管理

平臺的任務(wù)狀態(tài)主要由Server和Admin來控制。

Server主要控制初始狀態(tài)的執(zhí)行，Admin則主要負(fù)責(zé)

控制所有與YARN相關(guān)的狀態(tài)交互。