一、數(shù)據(jù)服務(wù)中臺建設(shè)背景

1、數(shù)據(jù)獲取過程中的痛點(diǎn)

在分享數(shù)據(jù)服務(wù)中臺建設(shè)之前，想從兩個(gè)案例開始，從中可以感受傳統(tǒng)數(shù)據(jù)獲取過程中的一些痛點(diǎn)。

案例一：數(shù)據(jù)需求方A，需要獲取每日up主的收入進(jìn)行數(shù)據(jù)分析。首先，A需要向數(shù)據(jù)產(chǎn)品提取數(shù)需求，數(shù)據(jù)產(chǎn)品會(huì)與其溝通指標(biāo)口徑，如up主的范圍，收入定義，還有沒有其他要下鉆的維度等等；口徑定義清楚之后，數(shù)據(jù)產(chǎn)品把需求提給對應(yīng)的數(shù)據(jù)分析師，分析師拿到需求和口徑定義后，找數(shù)據(jù)源、手工SQL邏輯，從而拉取到對應(yīng)的數(shù)據(jù)，最后提供給A。

案例二：數(shù)據(jù)需求方B，需要獲取up主的收入數(shù)據(jù)，用于線上系統(tǒng)的展示。同樣，也是需要提需求給數(shù)據(jù)產(chǎn)品，數(shù)據(jù)產(chǎn)品也是需要與其一起定義指標(biāo)口徑，確定好口徑之后把需求提給數(shù)倉同學(xué)。數(shù)倉同學(xué)拿到需求及口徑定義之后進(jìn)行手工建模；建模完成后，與對應(yīng)的業(yè)務(wù)系統(tǒng)開發(fā)進(jìn)行溝通，因?yàn)閷τ跀?shù)據(jù)量大小、性能要求、取數(shù)方式等不同，數(shù)據(jù)的出倉選型方案大不相同，所以需要與數(shù)據(jù)系統(tǒng)開發(fā)進(jìn)行多次有效的溝通才能夠確定存儲(chǔ)選型。數(shù)據(jù)出倉完成后，系統(tǒng)開發(fā)需要手工編寫API，經(jīng)過聯(lián)調(diào)測試發(fā)布到線上。

從這兩個(gè)案例中，可以總結(jié)出兩個(gè)問題：一、成本高，主要體現(xiàn)消費(fèi)鏈路長、溝通成本高，不同需求可能會(huì)并造成模型重復(fù)建設(shè)；二、治理難，數(shù)據(jù)鏈路及血緣不清晰，上游數(shù)據(jù)發(fā)生了變更下游無法評估影響，另外，不同鏈路口徑難以保障。

上面兩個(gè)案例，也是煙囪式開發(fā)的典型場景。本身煙囪式開發(fā)會(huì)有比較多的弊端。弊端一：重復(fù)建設(shè)，包括重復(fù)計(jì)算、重復(fù)存儲(chǔ)，造成資源浪費(fèi)，同時(shí)功能上的重復(fù)建設(shè)也會(huì)造成人力資源浪費(fèi)。弊端二：交付效率低，不同的系統(tǒng)、不同的開發(fā)同學(xué)對接不同的數(shù)據(jù)源，數(shù)據(jù)服務(wù)質(zhì)量不可控，整個(gè)對接的標(biāo)準(zhǔn)也不夠統(tǒng)一。

2、一站式數(shù)據(jù)服務(wù)中臺建設(shè)

基于上述痛點(diǎn)，經(jīng)過多次沉淀與總結(jié)，最終對數(shù)據(jù)服務(wù)中臺有了一個(gè)清洗的定位，即能夠一站式地完成數(shù)據(jù)的統(tǒng)一定義、統(tǒng)一生產(chǎn)和統(tǒng)一消費(fèi)。

• 統(tǒng)一定義 即：通過建立數(shù)據(jù)標(biāo)準(zhǔn)及指標(biāo)體系，統(tǒng)一業(yè)務(wù)對數(shù)據(jù)的認(rèn)知與理解，實(shí)現(xiàn)數(shù)據(jù)的標(biāo)準(zhǔn)管理
• 統(tǒng)一生產(chǎn) 即：通過自動(dòng)化、半自動(dòng)化的方法，統(tǒng)一數(shù)據(jù)的加工生產(chǎn)過程，讓數(shù)據(jù)的血緣關(guān)系更加清晰，提升數(shù)據(jù)生產(chǎn)的效率，避免數(shù)據(jù)重復(fù)建設(shè)。
• 統(tǒng)一消費(fèi) 即：通過建立通用的數(shù)據(jù)服務(wù)網(wǎng)關(guān)，實(shí)現(xiàn)數(shù)據(jù)查詢出口統(tǒng)一、保障公司通用數(shù)據(jù)產(chǎn)品指標(biāo)數(shù)據(jù)準(zhǔn)確性與一致性。

二、數(shù)據(jù)服務(wù)中臺框架

下圖展示了B站數(shù)據(jù)服務(wù)中臺的整體框架?？梢钥吹秸麄€(gè)中臺是架構(gòu)于數(shù)倉之上的，自下而上分為多個(gè)層次，包括數(shù)據(jù)構(gòu)建層、數(shù)據(jù)查詢層、服務(wù)接口層、服務(wù)網(wǎng)關(guān)，以及基于整個(gè)服務(wù)體系構(gòu)建的產(chǎn)品體系，包括指標(biāo)管理、模型管理、自助分析等等。

1、服務(wù)框架

中臺中，我們把用戶定義為兩大類角色，一類是數(shù)據(jù)生產(chǎn)者，另一類是消費(fèi)者。數(shù)據(jù)構(gòu)建層面向數(shù)據(jù)生產(chǎn)者，它的核心能力包括模型的定義、模型加速以及API的構(gòu)建。

數(shù)據(jù)構(gòu)建層：在維度建模思想中，數(shù)倉一般是分層分主題建設(shè)，可以快速地滿足不同的業(yè)務(wù)場景的數(shù)據(jù)分析需求。那么在數(shù)據(jù)消費(fèi)過程中，就需要多表關(guān)聯(lián)形成分析視圖進(jìn)行數(shù)據(jù)分析。在平臺上可以快速地通過自動(dòng)化、半自動(dòng)化方式構(gòu)建出表與表之間的關(guān)系，生成一個(gè)邏輯模型，這個(gè)過程是數(shù)據(jù)模型的邏輯構(gòu)建。我們知道，數(shù)倉中數(shù)據(jù)一般存儲(chǔ)于冷引擎，對于線上系統(tǒng)的使用會(huì)有比較高的數(shù)據(jù)延遲，不具有可用性，那么平臺上也實(shí)現(xiàn)了模型的自動(dòng)的加速過程，讓數(shù)據(jù)從冷引擎加速到熱引擎，提升數(shù)據(jù)消費(fèi)效率。構(gòu)建層另外一塊能力是API構(gòu)建。API構(gòu)建，主要是定義API 的請求參數(shù)、返回參數(shù)、數(shù)據(jù)源及數(shù)據(jù)的計(jì)算方式等等。單個(gè)的 API 就構(gòu)成了一個(gè)標(biāo)準(zhǔn)的數(shù)據(jù)單位，經(jīng)測試聯(lián)調(diào)完成之后，即可發(fā)布到 API 的市場，供不同業(yè)務(wù)申請使用。

數(shù)據(jù)查詢層：通過接口獲取用戶的請求參數(shù)，查詢層經(jīng)過解析、調(diào)度、翻譯及計(jì)算后返回?cái)?shù)據(jù)結(jié)果。查詢層主要提供兩種計(jì)算能力，原子計(jì)算及二次計(jì)算（復(fù)合計(jì)算）。原子計(jì)算主要處理的是格式相對單一，指標(biāo)維度統(tǒng)一，引擎固定的場景，如些正查、反查、范圍查等等。二次計(jì)算是在原子計(jì)算的基礎(chǔ)上，采用一定的編排算法，去對于結(jié)果集進(jìn)行二次加工。

服務(wù)接口層：接口形式分為同步接口和異步接口。請求方式包括DSL接口、模板接口、公共接口以及UDF接口等。同步接口主要是針對線上應(yīng)用的一些查詢場景，要求響應(yīng)速度快，數(shù)據(jù)結(jié)果集相對較小，可直接快速地獲取到數(shù)據(jù)并應(yīng)用于系統(tǒng)。異步接口主要是針對于離線分析或者大數(shù)據(jù)量的文件下載的場景，對于響應(yīng)速度要求不高，但是對于返回的數(shù)據(jù)量可能會(huì)要求比較大。

服務(wù)網(wǎng)關(guān)層：是提供給外部訪問我們內(nèi)部服務(wù)的一個(gè)統(tǒng)一入口，在數(shù)據(jù)服務(wù)中網(wǎng)關(guān)具備的核心能力主要是降級（如數(shù)據(jù)未就緒降級）、限流（流量峰值控制，保護(hù)服務(wù)穩(wěn)定）、鑒權(quán)（屏蔽非法流量，保障數(shù)據(jù)安全）、緩存（熱點(diǎn)數(shù)據(jù)，提升性能）。

2、核心流程

主要是從兩個(gè)核心角色看數(shù)據(jù)流轉(zhuǎn)方式：數(shù)據(jù)開發(fā)和業(yè)務(wù)開發(fā)，數(shù)據(jù)開發(fā)即數(shù)據(jù)生產(chǎn)者，業(yè)務(wù)開發(fā)及數(shù)據(jù)消費(fèi)者。數(shù)據(jù)開發(fā)在數(shù)據(jù)生產(chǎn)過程主要經(jīng)歷四個(gè)步驟：口徑的定義、數(shù)據(jù)的構(gòu)建、數(shù)據(jù)加速和API發(fā)布。

第一步：首先對指標(biāo)進(jìn)行定義，包括指標(biāo)名稱、指標(biāo)領(lǐng)域、指標(biāo)口徑等信息。

第二步：構(gòu)建數(shù)據(jù)模型，在平臺上通過托拉拽的方式構(gòu)建指標(biāo)維度模型，以及定義模型中字段與指標(biāo)維度的關(guān)系，計(jì)算方法，更新周期等技術(shù)口徑。

完成了前兩個(gè)步驟，基本實(shí)現(xiàn)了數(shù)倉開發(fā)同學(xué)對指標(biāo)數(shù)據(jù)的定義與管理工作了。當(dāng)有數(shù)據(jù)消費(fèi)的需求時(shí)，則可以根據(jù)需求場景在平臺做自動(dòng)數(shù)據(jù)加速。

第三步：加速數(shù)據(jù)模型，根據(jù)消費(fèi)場景，選擇需求所需的指標(biāo)維度信息，平臺自動(dòng)實(shí)現(xiàn)了目標(biāo)表的DDL、SQL邏輯的自動(dòng)生成、調(diào)度依賴配置、告警等過程。

第四步：構(gòu)建API，根據(jù)業(yè)務(wù)數(shù)據(jù)請求及返回要求，選擇數(shù)據(jù)源、定義字段的請求、返回參數(shù)屬性，主備鏈路信息等，測試完成后即可完成一個(gè)API的市場發(fā)布。

在數(shù)據(jù)消費(fèi)側(cè)，當(dāng)業(yè)務(wù)有數(shù)據(jù)需求時(shí)，去 API 市場里面找到數(shù)據(jù)生產(chǎn)者已經(jīng)生產(chǎn)好的API，申請權(quán)限就可以使用了。如果API市場里面沒有所需要的數(shù)據(jù)，就要走另外一條流程，提一個(gè)數(shù)據(jù)開發(fā)的需求給數(shù)據(jù)開發(fā)同學(xué)，然后數(shù)據(jù)開發(fā)同學(xué)增量地去構(gòu)建一個(gè)數(shù)據(jù)結(jié)果到平臺中去。當(dāng)業(yè)務(wù)開發(fā)同學(xué)申請完這個(gè)API的使用權(quán)限之后，平臺會(huì)授權(quán)給他一串密鑰以及資源的標(biāo)識。業(yè)務(wù)開發(fā)只需對接一次服務(wù)網(wǎng)關(guān)，即可重復(fù)利用。

把數(shù)據(jù)的生產(chǎn)與消費(fèi)的開發(fā)流程解耦，數(shù)倉開發(fā)同學(xué)不用過多參與業(yè)務(wù)系統(tǒng)的開發(fā)過程，可以更加專注做指標(biāo)的增量建設(shè)；對業(yè)務(wù)開發(fā)屏蔽了數(shù)據(jù)的加工處理過程，無需深入理解大數(shù)據(jù)知識，專注開發(fā)業(yè)務(wù)需求即可。

（1）模型構(gòu)建

平臺中對于模型的構(gòu)建，支持多種構(gòu)建方式，包括單例、星型、雪花以及星座模型等等。當(dāng)模型構(gòu)建完成后，平臺支持支持的物化加速能力支持也表豐富。從性能及靈活度兩個(gè)方便，對使用場景了做了劃分。不同的使用場景，其加速方式及目標(biāo)引擎有所不同。

明細(xì)加速：實(shí)現(xiàn)把邏輯模型中的數(shù)據(jù)從冷引擎到熱引擎的鏡像復(fù)制，極大保留了模型的原始數(shù)據(jù)的業(yè)務(wù)特性，可以更好的支持對模型中不同的維度及指標(biāo)做多維分析或者范圍查詢，在熱引擎中，加速數(shù)據(jù)的查詢效率。

預(yù)計(jì)算加速：根據(jù)數(shù)據(jù)獲取需求，從邏輯模型中的明細(xì)數(shù)據(jù)進(jìn)行預(yù)計(jì)算及處理，直接聚合到所需粒度的數(shù)據(jù)，并將數(shù)據(jù)寫入熱引擎中。由于數(shù)據(jù)已經(jīng)預(yù)計(jì)算處理，在數(shù)據(jù)查詢時(shí)極大減少了引擎的計(jì)算，查詢效率更高，但也損失了如多維分析及維度下鉆查詢的靈活性。

不同的場景有不同的加速方式及引擎選擇的組合，針對四種類型的場景，推薦的組合如下：

在線場景：預(yù)計(jì)算+kv存儲(chǔ)，一般應(yīng)用于C端及B端的數(shù)據(jù)需求，有著極高的服務(wù)性能要求，且線上數(shù)據(jù)不會(huì)快速的變化，靈活度要求低。

準(zhǔn)在線場景：預(yù)計(jì)算 + tidb/mysql，一般應(yīng)用于活動(dòng)或者運(yùn)營系統(tǒng)后臺，服務(wù)性能要求不會(huì)同線上場景那么高，但同時(shí)要求支持范圍查詢，有一定的查詢靈活度；對于數(shù)據(jù)量較大的查詢場景，可以選擇分布式數(shù)據(jù)庫 Tidb，其他可以選擇Mysql。

OLAP場景：明細(xì)+ ClickHouse/Iceberg，一般應(yīng)用于數(shù)據(jù)分析系統(tǒng)，需要對數(shù)據(jù)進(jìn)行多維分析，所以需要明細(xì)加速。ClickHouse 作為一款OLAP分析引擎，比較適合作為目標(biāo)引擎，如果考慮到成本因素，也可以使用湖倉一體技術(shù)Iceberg，數(shù)據(jù)無需出倉既可在倉內(nèi)完成數(shù)據(jù)的加速，性能雖不及ClickHouse，但也可以達(dá)到秒級的響應(yīng)，特別是在使用成本及查詢語法通用性上更有優(yōu)勢。

離線場景：離線數(shù)據(jù)獲取，一般訪問原始hive數(shù)據(jù)源即可。

（2）API構(gòu)建

API構(gòu)建方式有兩種：一種是通過模型構(gòu)建，這是一種可視化的配置方式，用戶已經(jīng)明確知道要對某一個(gè)模型進(jìn)行數(shù)據(jù)服務(wù)化，不需要用SQL編碼，通過拖拉拽的方式就可以配置出來。另一種是基于指標(biāo)維度的構(gòu)建，指標(biāo)維度構(gòu)建是在模型構(gòu)建的基礎(chǔ)上的一種更高級模式，用戶無需實(shí)現(xiàn)指定模型進(jìn)行構(gòu)建，可以先配置請求參數(shù)及返回參數(shù)，系統(tǒng)根據(jù)管理的模型元數(shù)據(jù)信息，按照一定的規(guī)則自動(dòng)篩選出可以服務(wù)化的模型列表并給出推薦優(yōu)先級。

數(shù)據(jù)查詢：

下面介紹數(shù)據(jù)查詢的能力，整體分為五個(gè)步驟。

步驟1：一個(gè)查詢的DSL信息如下圖圖所示。解析的過程是把DSL信息與API配置進(jìn)行匹配，并得出本次數(shù)據(jù)請求需要的模型。

步驟2：任務(wù)拆分是把解析的結(jié)果拆成子任務(wù)查詢，解決異構(gòu)數(shù)據(jù)源的結(jié)果獲取問題。因?yàn)橐淮尾樵冎锌赡軙?huì)從多個(gè)模型中獲取，模型也可以在多個(gè)引擎或集群中。為保證結(jié)果的的準(zhǔn)確獲取及查詢效率，我們采用了拆分子任務(wù)的方式進(jìn)行并發(fā)數(shù)據(jù)查詢，子任務(wù)的查詢結(jié)果經(jīng)過二次加工處理返回。

步驟3：結(jié)果處理器是一個(gè)內(nèi)存計(jì)算器，負(fù)責(zé)把子任務(wù)的查詢結(jié)果進(jìn)行拼接、排序、分頁及格式轉(zhuǎn)換等，返回統(tǒng)一格式的數(shù)據(jù)結(jié)果，讓下游無感知數(shù)據(jù)的處理過程。

步驟3-1：翻譯模塊是把子任務(wù)的查詢信息翻譯成對應(yīng)引擎可以識別的sql語法。AST是abstract syntax tree的縮寫，也就是抽象語法樹。翻譯模塊區(qū)別于引擎對執(zhí)行SQL進(jìn)行語法樹解析的過程，而是逆向從構(gòu)建AST開始，并最終翻譯成SQL的過程。構(gòu)建AST的算法如下圖所示：

第一層AST從下面的"SELECT"開始，第一層語法樹是構(gòu)建出本次查詢需要用的有效數(shù)據(jù)，包括構(gòu)建模型關(guān)系、模型字段的篩選及數(shù)據(jù)范圍的篩選

第二層AST從上面的"SELECT"開始，第二層語法樹是基于第一層構(gòu)建的有效數(shù)據(jù)，進(jìn)行運(yùn)算表達(dá)式計(jì)算，如 sum，count(distnct ..)，sum(case when then end)，sum()/count() 等其他一些自定義語法表達(dá)式。

通過兩次的AST構(gòu)建，可以完整表達(dá)一次原子計(jì)算所需的數(shù)據(jù)獲取邏輯。根據(jù)構(gòu)建的AST，系統(tǒng)會(huì)各個(gè)引擎的查詢特性及方言，優(yōu)化查詢語法，提升查詢性能，最終轉(zhuǎn)化成可被引擎識別的查詢SQL。

步驟3-2：引擎層負(fù)責(zé)執(zhí)行各個(gè)子任務(wù)的查詢SQL，系統(tǒng)適配了目前公司內(nèi)部多種數(shù)據(jù)引擎，包括自研KV、TiDB、Mysql、ClickHouse、Iceberg等。除接入不同的引擎連接協(xié)議，在不同引擎的連接方式上也做了優(yōu)化，如：mysql、tidb 由單次短連接改為連接池，減少連接的頻繁創(chuàng)建及銷毀帶來的開銷問題；自研KV多可用區(qū)連接，擴(kuò)大在線服務(wù)可用的服務(wù)范圍；OLAP引擎如ClickHouse、Iceberg的超時(shí)自取消功能，減少服務(wù)占用及降低引擎壓力等。

三、數(shù)據(jù)服務(wù)中臺實(shí)踐方案

1、全鏈路管控

在數(shù)據(jù)服務(wù)中臺實(shí)踐中，最重要的是實(shí)現(xiàn)全鏈路管控，讓數(shù)據(jù)在服務(wù)化的過程中做到統(tǒng)一定義、統(tǒng)一生產(chǎn)、統(tǒng)一消費(fèi)。

統(tǒng)一定義：口徑不易維護(hù)的原因之一是管理不統(tǒng)一，散落在各個(gè)地方，導(dǎo)致大家沒有統(tǒng)一的視角管理及查看口徑。我們的的解決方案是口徑統(tǒng)一在指標(biāo)平臺管理，其中把指標(biāo)的定義及模型的定義解耦。指標(biāo)定義是對分析對象的業(yè)務(wù)過程進(jìn)行描述，計(jì)算方法的定義約束，可在數(shù)據(jù)模型建設(shè)之前確定，一般有數(shù)據(jù)產(chǎn)品角色實(shí)施；模型定義是根據(jù)數(shù)據(jù)需求及指標(biāo)定義進(jìn)行構(gòu)建生產(chǎn)，模型中指定了模型字段與指標(biāo)的關(guān)系，決定了模型中哪些字段可以生產(chǎn)哪些指標(biāo)，一般有數(shù)倉開發(fā)角色實(shí)施。通過把指標(biāo)定義與模型定義解耦，減少了不同角色間的溝通成本，讓口徑的定義可以延續(xù)到數(shù)據(jù)生產(chǎn)中。

統(tǒng)一出口：口徑不易維護(hù)的另外的一個(gè)原因是定義與生產(chǎn)分離，出口不可控。我們打通了指標(biāo)的定義及生產(chǎn)流程：模型的出倉可以自動(dòng)化完成，出倉過程中的計(jì)算邏輯是基于指標(biāo)平臺中的定義自動(dòng)生成的，減少了人工的干預(yù)，避免定義與生產(chǎn)的不一致；其次，API的取數(shù)邏輯非人工定義，也是基于指標(biāo)定義，自動(dòng)翻譯取數(shù)邏輯及路由計(jì)算引擎，避免生產(chǎn)與消費(fèi)過程中的不一致。通過定義與生產(chǎn)的打通，生產(chǎn)與消費(fèi)的打通，數(shù)據(jù)流通過程中完全基于統(tǒng)一的定義，達(dá)到了最終的定義與消費(fèi)的一致性。

全鏈路監(jiān)控：數(shù)據(jù)從定義到生產(chǎn)到消費(fèi)環(huán)節(jié)，有完整的監(jiān)控鏈路，以此來確保口徑的持續(xù)一致性。指標(biāo)一致性監(jiān)控：維度建模的數(shù)倉中，同一個(gè)指標(biāo)由于分析思路或者需求場景，最終生產(chǎn)此指標(biāo)的模型可能是多個(gè)，那么就需要保障指標(biāo)在不同模型間的口徑一致性。通過一致性對比或者閉環(huán)公式校驗(yàn)等手段，發(fā)現(xiàn)指標(biāo)口徑不一致，然后通過口徑變更、模型換綁等治理方法來持續(xù)保障指標(biāo)口徑的一致；出倉一致性監(jiān)控：出倉過程中數(shù)據(jù)集成工具保障了實(shí)時(shí)的一致性，這里需要保障的是，由于歷史數(shù)據(jù)變更導(dǎo)致的出倉前后數(shù)據(jù)不一致的問題；服務(wù)質(zhì)量監(jiān)控：從數(shù)據(jù)出口監(jiān)控?cái)?shù)據(jù)的質(zhì)量情況，主要包括閾值監(jiān)控，波動(dòng)率監(jiān)控等，發(fā)現(xiàn)質(zhì)量問題，保障出口的最終口徑一致性。

2、降本增效

中臺的建設(shè)最終是要為企業(yè)降本增效的。過往中，不同業(yè)務(wù)線重復(fù)建設(shè)，垂直產(chǎn)品線煙囪式的開發(fā)，使得數(shù)據(jù)成為一個(gè)個(gè)孤島，雖能滿足單一業(yè)務(wù)場景，但是卻增加了各個(gè)業(yè)務(wù)線的合作成本。

我們的建設(shè)思路是，首先將公共、通用的部分抽離出來，形成可復(fù)用服務(wù)，讓業(yè)務(wù)可以快速完成數(shù)據(jù)鏈路的搭建，減少業(yè)務(wù)重復(fù)造輪子，降低研發(fā)成本；其次，統(tǒng)一服務(wù)標(biāo)準(zhǔn)，通過快速復(fù)用已建設(shè)的數(shù)據(jù)鏈路搭建的能力，讓數(shù)據(jù)從定義-->生產(chǎn)-->消費(fèi)的整個(gè)周期縮短，提升對接效率，為數(shù)據(jù)在不同部門間流轉(zhuǎn)創(chuàng)造可能。

降本：

數(shù)據(jù)建設(shè)成本：通過模型、指標(biāo)標(biāo)準(zhǔn)化的定義與管理，數(shù)據(jù)建設(shè)中的一個(gè)個(gè)表或者模型成為一個(gè)可以復(fù)用的標(biāo)準(zhǔn)數(shù)據(jù)資產(chǎn)，數(shù)據(jù)建設(shè)中只需增量建設(shè)，規(guī)避重復(fù)建設(shè)，降低數(shù)據(jù)的建設(shè)成本。

服務(wù)研發(fā)成本：服務(wù)通過標(biāo)準(zhǔn)化方式構(gòu)建，下游使用無歧義，使得API復(fù)用成為可能，減少了服務(wù)研發(fā)成本，服務(wù)資源可以重復(fù)利用。

提效：

數(shù)據(jù)構(gòu)建提效：數(shù)據(jù)構(gòu)建時(shí)，通過元數(shù)據(jù)的管理，自動(dòng)化及半自動(dòng)化的構(gòu)建出模型及指標(biāo)，提高了數(shù)據(jù)構(gòu)建效率；另外構(gòu)建出的數(shù)據(jù)資產(chǎn)是標(biāo)準(zhǔn)化的，消除了數(shù)據(jù)格式、生產(chǎn)、存儲(chǔ)等差異性，下游消費(fèi)時(shí)不用關(guān)心底層的邏輯，提高了應(yīng)用的效率。

服務(wù)使用提效：標(biāo)準(zhǔn)化的API，在系統(tǒng)對接時(shí)可以實(shí)現(xiàn)一次對接溝通，多次復(fù)用，提高了API的對接效率。

3、高可用建設(shè)

服務(wù)隔離：隔離是將服務(wù)或資源分割開。服務(wù)隔離是為了在服務(wù)發(fā)生故障時(shí)，能減少傳播范圍和影響范圍，故障發(fā)生后不會(huì)發(fā)生滾雪球效應(yīng)，從而保證只有出問題的服務(wù)不可用，我們根據(jù)服務(wù)的保障等級，劃分為5個(gè)服務(wù)資源組，不同資源組相互獨(dú)立，不會(huì)產(chǎn)生相互影響；存儲(chǔ)資源隔離是通過資源隔離來減少資源競爭，保障服務(wù)間的相互不影響和可用性，我們將資源隔離做到API級別，不同API間及不同等級間做隔離，充分保障資源間的相互不影響。

異地雙活：異地雙活的目的也就是容災(zāi)，當(dāng)某個(gè)地方服務(wù)出現(xiàn)了災(zāi)難性故障，而服務(wù)仍然能正常提供服務(wù)。我們根據(jù)業(yè)務(wù)的部署情況，選擇距離業(yè)務(wù)較近的A、B兩地機(jī)房部署服務(wù)，正常情況下同機(jī)房的請求鏈路為主鏈路，當(dāng)某地服務(wù)宕機(jī)，則會(huì)自動(dòng)降級到另外一地的服務(wù)。

四、數(shù)據(jù)服務(wù)中臺成果&規(guī)劃

最后分享我們的數(shù)據(jù)服務(wù)中臺目前取得的成果，以及未來的建設(shè)規(guī)劃。

B站數(shù)據(jù)服務(wù)中臺上線一年左右，目前支持三大類數(shù)據(jù)使用場景，一種是API的使用場景，提供了API市場，包括在線、準(zhǔn)在線、OLAP分析，以及實(shí)時(shí)的場景；第二塊是支撐數(shù)據(jù)產(chǎn)品建設(shè)，包括業(yè)務(wù)分析產(chǎn)品、平臺分析產(chǎn)品、主題分析產(chǎn)品等；第三是支持BI工具，比如自助取數(shù)、異動(dòng)分析、下鉆分析、自助報(bào)表等。

API的數(shù)量目前有600個(gè)以上，在性能和穩(wěn)定性方面都有著不錯(cuò)的表現(xiàn)，數(shù)據(jù)開發(fā)周期從原來平均1周的時(shí)間，縮短到現(xiàn)在的1天左右。

未來我們會(huì)從五個(gè)方向去做數(shù)據(jù)服務(wù)中臺建設(shè)：

第一個(gè)是服務(wù)治理方向，根據(jù)服務(wù)等級、服務(wù)監(jiān)控、數(shù)據(jù)鏈路的信息，讓服務(wù)能夠高質(zhì)量、低成本、強(qiáng)有效地運(yùn)行。

第二個(gè)方向是支持更多的場景，比如推動(dòng)一些平臺類的產(chǎn)品接入，包括標(biāo)簽平臺、AB 平臺的等能夠從服務(wù)中臺管理及使用數(shù)據(jù)。

第三是服務(wù)編排，我們希望服務(wù)能夠更加貼近于業(yè)務(wù)的需求，讓數(shù)據(jù)能夠做到即取即可用。

第四是降級容災(zāi)，希望能夠做到日常的災(zāi)備演練、主備功能切換演練等。

最后就是持續(xù)的降本增效，在大數(shù)據(jù)計(jì)算資源效率、存儲(chǔ)效率方面持續(xù)投入研發(fā)，向高效率、低成本更進(jìn)一步。