作者：孟帥帥、劉晨陽、呂小正
01 背景
隨著公司業(yè)務(wù)的發(fā)展，對于數(shù)據(jù)的需求會越來越多。怎么在業(yè)務(wù)系統(tǒng)中高效的使用數(shù)據(jù)，讓業(yè)務(wù)系統(tǒng)處理大數(shù)據(jù)時化繁為簡，數(shù)據(jù)服務(wù)化基本是必經(jīng)之路。那么什么是數(shù)據(jù)服務(wù)化，簡單理解就是數(shù)據(jù)SaaS，通過一些數(shù)據(jù)庫語言把數(shù)據(jù)轉(zhuǎn)化成服務(wù)，如API、RPC、數(shù)據(jù)文件 等不同的數(shù)據(jù)方式提供給業(yè)務(wù)系統(tǒng)使用。經(jīng)過多年對各個業(yè)務(wù)系統(tǒng)對接調(diào)研發(fā)現(xiàn)，大家感受到了無標準、不統(tǒng)一及煙囪式建設(shè)的服務(wù)接口的痛點，希望可以建設(shè)一套標準的，中臺化的數(shù)據(jù)服務(wù)平臺。數(shù)據(jù)服務(wù)中臺以解決業(yè)務(wù)中痛點為優(yōu)先，主要的痛點如下：
1. 數(shù)據(jù)接入方式多樣，對接效率較低
2. 數(shù)據(jù)出口多，口徑不統(tǒng)一
3. 數(shù)據(jù)及接口無法共享，建設(shè)成本高
4. 數(shù)據(jù)鏈路不清晰，故障影響難以評估
5. 服務(wù)質(zhì)量標準不統(tǒng)一，質(zhì)量問題較多針對以上痛點，我們需要思考一個問題：我們到底需要一個什么的數(shù)據(jù)服務(wù)平臺，平臺應(yīng)該有哪些特性？從功能上看，我們認為一個完整的數(shù)據(jù)服務(wù)平臺應(yīng)包括以下功能：
1. 接口的規(guī)范化定義
2. 通用的數(shù)據(jù)服務(wù)網(wǎng)關(guān)
3. 數(shù)據(jù)鏈路可管理可維護
4. 服務(wù)可以觀測可運維
5. 服務(wù)可復(fù)用除了滿足以上功能外，我們也希望這個數(shù)據(jù)服務(wù)平臺具備以下特性：1. 靈活性：數(shù)據(jù)的迭代及變更，可以讓下游無感
2. 便捷性：能夠快速的完成數(shù)據(jù)的服務(wù)化，接入效率高
3. 低成本：讓數(shù)據(jù)可以復(fù)用而非復(fù)制，減少數(shù)據(jù)的冗余生產(chǎn)
02 架構(gòu)設(shè)計
數(shù)據(jù)服務(wù)中臺的經(jīng)過多次迭代，如上圖所示。中臺構(gòu)建于數(shù)據(jù)倉庫之上，自下向上包括：數(shù)據(jù)構(gòu)建層、數(shù)據(jù)查詢層、服務(wù)接口、服務(wù)網(wǎng)關(guān)及服務(wù)的應(yīng)用體系，除此之外，中臺還包括數(shù)據(jù)標準的管理、數(shù)據(jù)安全管理、運維監(jiān)控等模塊。今天主要介紹中臺的核心服務(wù)化鏈路，即：數(shù)據(jù)構(gòu)建-->數(shù)據(jù)查詢-->服務(wù)接口與網(wǎng)關(guān)。
2.1 數(shù)據(jù)構(gòu)建
我們知道數(shù)倉中的數(shù)據(jù)一般是hive表，維度建模思想下，單表并不能完整表達業(yè)務(wù)邏輯，需要對數(shù)據(jù)表進行重新構(gòu)建，構(gòu)建統(tǒng)一的面向業(yè)務(wù)的數(shù)據(jù)模型層，同時數(shù)倉中物理表對于線上業(yè)務(wù)系統(tǒng)的使用有很高的延遲，也不可以直接讀取，所以在數(shù)倉的基礎(chǔ)上，抽象出數(shù)據(jù)構(gòu)建層。數(shù)據(jù)服務(wù)中臺中，我們把用戶分為兩大類角色即：數(shù)據(jù)生產(chǎn)者及數(shù)據(jù)消費者。數(shù)據(jù)構(gòu)建層是面向數(shù)據(jù)生產(chǎn)者(一般指數(shù)倉開發(fā)) 進行數(shù)據(jù)定義的層次，核心能力包括：模型定義、模型加速及API的構(gòu)建。
2.1.1 模型定義
B站數(shù)倉建設(shè)以業(yè)務(wù)過程為驅(qū)動，采用經(jīng)典的維度建模的方式。維度建模以分析決策的需求出發(fā)構(gòu)建模型，構(gòu)建的數(shù)據(jù)模型為分析需求服務(wù)，因此它重點解決用戶如何更快速完成分析需求，同時還有較好的大規(guī)模復(fù)雜查詢的響應(yīng)性能。為了適應(yīng)各種數(shù)據(jù)分析場景的數(shù)據(jù)獲取需求，我們支持構(gòu)建多種邏輯數(shù)據(jù)模型，根據(jù)事實表與維表的關(guān)系，經(jīng)常將數(shù)據(jù)模型分為單例模型、星型模型、雪花模型及星座模型。
單例模型：1張事實表，一般為dws或者ads層的匯總實時表；星形模型：1張事實表+N張維度表，如播放相關(guān)事實表可以通過稿件ID關(guān)聯(lián)稿件維表獲取稿件相關(guān)屬性信息；雪花模型：1張事實表+N張維度表+M張非直接關(guān)聯(lián)事實表的維度表，如播放事實表通過稿件ID關(guān)聯(lián)稿件維度表，又通過稿件維度表中的品類ID關(guān)聯(lián)品類維度表；星座模型：N張事實表+M張與事實表關(guān)聯(lián)的維度表，如播放模型與DAU模型通過公共維度關(guān)聯(lián)，獲取公共維度下的DAU指標與播放指標。
2.1.2 模型加速
我們知道，數(shù)倉的模型一般存在hive中，hive表對于線上API的使用有極大的困難，所以就需要把2.1.1中構(gòu)建的數(shù)據(jù)模型進行模型加速。數(shù)據(jù)服務(wù)作為一個通用的數(shù)據(jù)獲取平臺，既要滿足不同的應(yīng)用場景，同時也要考慮成本因素。我們從性能及靈活度兩個方便，對使用場景了做了劃分。不同的使用場景，其加速方式及目標引擎有所不同。我們從性能及靈活性上對使用場景進行劃分：
明細加速：實現(xiàn)把邏輯模型中的數(shù)據(jù)從冷引擎到熱引擎的鏡像復(fù)制，極大保留了模型的原始數(shù)據(jù)的業(yè)務(wù)特性，可以更好的支持對模型中不同的維度及指標做多維分析或者范圍查詢，在熱引擎中，加速數(shù)據(jù)的查詢效率。預(yù)計算加速：根據(jù)數(shù)據(jù)獲取需求，從邏輯模型中的明細數(shù)據(jù)進行預(yù)計算及處理，直接聚合到所需粒度的數(shù)據(jù)，并將數(shù)據(jù)寫入熱引擎中。由于數(shù)據(jù)已經(jīng)預(yù)計算處理，在數(shù)據(jù)查詢時極大減少了引擎的計算，查詢效率更高，但也損失了如多維分析及維度下鉆查詢的靈活性。不同的場景有不同的加速方式及引擎選擇的組合，針對四種類型的場景，推薦的組合如下：
- 在線場景：預(yù)計算+kv存儲，一般應(yīng)用于C端及B端的數(shù)據(jù)需求，有著極高的服務(wù)性能要求，且線上數(shù)據(jù)不會快速的變化，靈活度要求低。
- 準在線場景：預(yù)計算 + tidb/MySQL，一般應(yīng)用于活動或者運營系統(tǒng)后臺，服務(wù)性能要求不會同線上場景那么高，但同時要求支持范圍查詢，有一定的查詢靈活度；對于數(shù)據(jù)量較大的查詢場景，可以選擇分布式數(shù)據(jù)庫 Tidb，其他可以選擇Mysql。
- OLAP場景：明細+ ClickHouse/Iceberg，一般應(yīng)用于數(shù)據(jù)分析系統(tǒng)，需要對數(shù)據(jù)進行多維分析，所以需要明細加速。ClickHouse 作為一款OLAP分析引擎，比較適合作為目標引擎，如果考慮到成本因素，也可以使用湖倉一體技術(shù)Iceberg，數(shù)據(jù)無需出倉既可在倉內(nèi)完成數(shù)據(jù)的加速，性能雖不及ClickHouse，但也可以達到秒級的響應(yīng)，特別是在使用成本及查詢語法通用性上更有優(yōu)勢。
- 離線場景：離線數(shù)據(jù)獲取，一般訪問原始hive數(shù)據(jù)源即可。
2.1.3 API構(gòu)建
API參數(shù)定義
為了對API標準化，我們調(diào)研了公司內(nèi)的各業(yè)務(wù)的API的使用要求，統(tǒng)一API標準元素，包括: APIID、API名稱、請求方式、請求路徑、返回參數(shù)、請求參數(shù)、響應(yīng)時間要求、QPS預(yù)估、應(yīng)用場景等。
API取數(shù)邏輯構(gòu)建
API的取數(shù)邏輯的配置，中臺支持多種配置方法，包括：自定義sql構(gòu)建、模型構(gòu)建及指標維度構(gòu)建。下面針對這三種構(gòu)建方法分別介紹：
自定義sql構(gòu)建：為了支持復(fù)雜邏輯的數(shù)據(jù)獲取，系統(tǒng)通過過引入MyBatis相關(guān)的包，能夠支持類似mybatis動態(tài)sql方式，通過支持Mybatis標簽的SQL語法來編寫查詢邏輯。目前支持的標簽類型包括：if、foreach和where。根據(jù)用戶傳入的變量動態(tài)構(gòu)建SQL實例，從而擴展了模型API化的能力。
select a.field1 AS alias_1, a.field2 as alias_2, a.field3 as alias_3, b.field1 as alias_4 from fact_table a left outer join table_dim b on a.id = b.id a.field = ${ input_1,type = number } and b.field = $ { input_2,type = number }
模型構(gòu)建：模型構(gòu)建是一種可視化的配置方式，用戶不用要sql的代碼編輯能力，搜索想要服務(wù)化的模型，即可在模型上配置出API的取數(shù)邏輯；
指標維度構(gòu)建：指標維度構(gòu)建是在模型構(gòu)建的基礎(chǔ)上的一種更高級模式，用戶無需實現(xiàn)指定模型進行構(gòu)建，可以先配置請求參數(shù)及返回參數(shù)，系統(tǒng)根據(jù)管理的模型元數(shù)據(jù)信息，按照一定的規(guī)則自動篩選出可以服務(wù)化的模型列表并給出推薦優(yōu)先級。
2.2 數(shù)據(jù)查詢
數(shù)據(jù)查詢層是服務(wù)接口層與數(shù)據(jù)模型層的中間層，主要功能是通過接口獲取請求參數(shù)，經(jīng)過解析、調(diào)度、翻譯及計算后返回數(shù)據(jù)結(jié)果。數(shù)據(jù)查詢層分為兩種查詢方式：原子計算及復(fù)合計算。原子計算處理返回格式相對單一、指標維度統(tǒng)一及引擎單次處理即可用的數(shù)據(jù)查詢，一般用于線上的單點查詢、范圍查詢場景等；復(fù)合計算是在原子的計算的基礎(chǔ)上，按照一定的算法對原子計算的結(jié)果進行二次加工，一般包括數(shù)據(jù)編排、指標間結(jié)果或維度間結(jié)果的處理等，返回的數(shù)據(jù)結(jié)構(gòu)一般可以直接應(yīng)用于數(shù)據(jù)產(chǎn)品中。
2.2.1 原子計算
原子計算需要把獲取到的接口參數(shù)進行解析、拆分、翻譯及多次引擎的單次查詢獲取結(jié)果并返回，整體流程如下圖所示。流程整體分為三部分：調(diào)度、翻譯、引擎查詢。
調(diào)度：調(diào)度是一次原子計算的入口及出口，負責(zé)任務(wù)的解析、拆分及結(jié)果的處理。調(diào)度獲取到的參數(shù)是一段DSL，包括指標、維度、篩選條件、分頁信息等。步驟1，解析的過程是把DSL信息與API配置進行匹配，并得出本次數(shù)據(jù)請求需要的模型。在一個API中，用戶可以配置多個數(shù)據(jù)模型，不同的指標維度查詢中，需要用的模型就會不同，解析過程需要根據(jù)查詢條件按照預(yù)設(shè)計好的規(guī)則進行排序擇優(yōu)，追求最好的查詢準確性及效率。排序擇優(yōu)的算法參考Oracle查詢優(yōu)化器的做法，結(jié)合CBO及RBO算法選擇最優(yōu)的查詢模型。步驟2，任務(wù)拆分是把解析的結(jié)果拆成子任務(wù)查詢，解決異構(gòu)數(shù)據(jù)源的結(jié)果獲取問題。因為一次查詢中可能會從多個模型中獲取，模型也可以在多個引擎或集群中。為保證結(jié)果的的準確獲取及查詢效率，我們采用了拆分子任務(wù)的方式進行并發(fā)數(shù)據(jù)查詢，子任務(wù)的查詢結(jié)果經(jīng)過二次加工處理返回。步驟3，結(jié)果處理器是一個內(nèi)存計算器，負責(zé)把子任務(wù)的查詢結(jié)果進行拼接、排序、分頁及格式轉(zhuǎn)換等，返回統(tǒng)一格式的數(shù)據(jù)結(jié)果，讓下游無感知數(shù)據(jù)的處理過程。
翻譯：步驟3-1，翻譯模塊是把子任務(wù)的查詢信息翻譯成對應(yīng)引擎可以識別的sql語法。AST是abstract syntax tree的縮寫，也就是抽象語法樹。翻譯模塊區(qū)別于引擎對執(zhí)行SQL進行語法樹解析的過程，而是逆向從構(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ù)，進行運算表達式計算，如 sum，count(distnct ..)，sum(case when then end)，sum()/count() 等其他一些自定義語法表達式。通過兩次的AST構(gòu)建，可以完整表達一次原子計算所需的數(shù)據(jù)獲取邏輯。根據(jù)構(gòu)建的AST，系統(tǒng)會各個引擎的查詢特性及方言，優(yōu)化查詢語法，提升查詢性能，最終轉(zhuǎn)化成可被引擎識別的查詢SQL。
引擎適配器：步驟3-2，引擎層負責(zé)執(zhí)行各個子任務(wù)的查詢SQL，系統(tǒng)適配了目前公司內(nèi)部多種數(shù)據(jù)引擎，包括自研KV、TiDB、Mysql、ClickHouse、Iceberg等。除接入不同的引擎連接協(xié)議，在不同引擎的連接方式上也做了優(yōu)化，如：mysql、tidb 由單次短連接改為連接池，減少連接的頻繁創(chuàng)建及銷毀帶來的開銷問題；自研KV多可用區(qū)連接，擴大在線服務(wù)可用的服務(wù)范圍；OLAP引擎如ClickHouse、Iceberg的超時自取消功能，減少服務(wù)占用及降低引擎壓力等。
2.2.2 復(fù)合計算
二次計算是解決單一sql或者單一引擎不能直接獲取數(shù)據(jù)結(jié)果的數(shù)據(jù)二次加工過程。基于原子計算得出的一個m*n的二維數(shù)組，可以計算指標在時間軸上的變化趨勢，如：同比、環(huán)比、增長率等，也可以算指標在不同維度間的關(guān)系，如：占比、漏斗、下鉆等，同時也可以支持一些統(tǒng)計分析，如：協(xié)方差、TGI、置信度等。二次計算不僅支持通用的算法口徑，也可以支持自定義函數(shù)，二次計算的能力避免了數(shù)據(jù)輸出后在外部不受管控的加工，讓數(shù)據(jù)所得及所用，處理流程如下圖所示：
2.3 服務(wù)網(wǎng)關(guān)及接口
數(shù)據(jù)服務(wù)層是對模型中的數(shù)據(jù)進行服務(wù)化的過程，主要包含三個過程：服務(wù)網(wǎng)關(guān)、服務(wù)接口及數(shù)據(jù)查詢。
2.3.1 服務(wù)網(wǎng)關(guān)
API Gateway（API GW / API 網(wǎng)關(guān)），系統(tǒng)在系統(tǒng)邊界上提供給外部訪問內(nèi)部接口服務(wù)的統(tǒng)一入口。在數(shù)據(jù)服務(wù)中，網(wǎng)關(guān)需要核心具備的功能包括：鑒權(quán)、限流及監(jiān)控。網(wǎng)關(guān)使得業(yè)務(wù)對接數(shù)據(jù)服務(wù)時有了統(tǒng)一的標準，使得API有了復(fù)用的可能。
鑒權(quán)：數(shù)據(jù)服務(wù)中，數(shù)據(jù)安全非常重要。數(shù)據(jù)服務(wù)中，為每個應(yīng)用分配一對AppKey 及 secret；對于已經(jīng)發(fā)布上線的API，負責(zé)人可以對應(yīng)用進行授權(quán)，只有API被授權(quán)給某個應(yīng)用，應(yīng)用才可以通過appKey 及 secret 訪問該API。
限流：限流是對系統(tǒng)的保護及減少API相互影響的重要手段。應(yīng)用在申請API調(diào)用時，需要給出合理的QPS預(yù)估，API會根據(jù)總QPS需求調(diào)整資源部署；過大的QPS的請求且沒有限制時，容易超出服務(wù)負載而發(fā)生故障，對于復(fù)用的API也可能產(chǎn)生相互影響。所以每個應(yīng)用申請的API都有QPS限制，超出閾值，多余流量會廢棄。
監(jiān)控：服務(wù)監(jiān)控可以比較直觀的觀察的api的運行狀態(tài)，監(jiān)控類型包括訪問總請求數(shù)、訪問成功率、訪問失敗數(shù)及訪問失敗類型分布，另外也補充了對API的安全監(jiān)控及QPS監(jiān)控等。
2.3.2 服務(wù)接口
根據(jù)數(shù)據(jù)場景及數(shù)據(jù)內(nèi)容，接口形式分為同步查詢與異步查詢，接口類型包括DSL接口、模板查詢接口、自定義SQL接口等。
同步查詢：對于線上應(yīng)用查詢，要求響應(yīng)速度快且數(shù)據(jù)結(jié)果較小的查詢，建議同步查詢，可以快速獲取到結(jié)果。
異步查詢：對于離線分析或者大數(shù)據(jù)量下載場景，響應(yīng)速度要求不高，但是返回的數(shù)據(jù)量比較大，建議走異步查詢，異步查詢的流程如下圖所示：
DSL接口：用 DSL (Domain SpecificLanguage ，領(lǐng)域?qū)Ｓ谜Z言）來描述取數(shù)需求，計算層可以解析DSL并計算，通過DSL所有的簡單查詢服務(wù)減少到只有一個接口。
message OpenApiReq { OsHeader osHeader = 1; repeated OperatorVo filters = 2; repeated string metrics = 3; repeated string dims = 4; repeated string orderFields = 5; PageVo pageVo = 6; repeated OperatorVo metricFilters = 7; }
模板查詢接口：數(shù)倉同學(xué)按照業(yè)務(wù)需求，把數(shù)據(jù)的計算邏輯固定為一個模板，下游在調(diào)用時不必關(guān)心表在哪里及怎么計算，只需根據(jù)模板中設(shè)置的變量傳參獲取數(shù)據(jù)，減少了不必要的溝通，提高了對接效率。
message SqlQueryReq { OsHeader osHeader = 1; repeated OperatorVo filters = 2; }
SQL接口：業(yè)務(wù)方可以通過寫 SQL 的查詢數(shù)據(jù) ，由服務(wù)提供者自己來維護 SQL ，走向 DevOps。
message AsyncSqlQueryReq{ string appKey = 1; string secret = 2; string engine = 3; string sql = 4; }
03 通用解決方案
3.1 口徑統(tǒng)一及溯源
如前文提到，口徑不統(tǒng)一及鏈路不清晰造成較高的維護成本，總體解決思路是統(tǒng)一入口及統(tǒng)一出口，并在過程中進行全鏈路管理，方案如下圖所示：
統(tǒng)一定義：口徑不易維護的原因之一是管理不統(tǒng)一，散落在各個地方，導(dǎo)致大家沒有統(tǒng)一的視角管理及查看口徑。我們的的解決方案是口徑統(tǒng)一在指標平臺管理，其中把指標的定義及模型的定義解耦。指標定義是對分析對象的業(yè)務(wù)過程進行描述，計算方法的定義約束，可在數(shù)據(jù)模型建設(shè)之前確定，一般有數(shù)據(jù)產(chǎn)品角色實施；模型定義是根據(jù)數(shù)據(jù)需求及指標定義進行構(gòu)建生產(chǎn)，模型中指定了模型字段與指標的關(guān)系，決定了模型中哪些字段可以生產(chǎn)哪些指標，一般有數(shù)倉開發(fā)角色實施。通過把指標定義與模型定義解耦，減少了不同角色間的溝通成本，讓口徑的定義可以延續(xù)到數(shù)據(jù)生產(chǎn)中。
統(tǒng)一出口：口徑不易維護的另外的一個原因是定義與生產(chǎn)分離，出口不可控。我們打通了指標的定義及生產(chǎn)流程：模型的出倉可以自動化完成，出倉過程中的計算邏輯是基于指標平臺中的定義自動生成的，減少了人工的干預(yù)，避免定義與生產(chǎn)的不一致；其次，API的取數(shù)邏輯非人工定義，也是基于指標定義，自動翻譯取數(shù)邏輯及路由計算引擎，避免生產(chǎn)與消費過程中的不一致。通過定義與生產(chǎn)的打通，生產(chǎn)與消費的打通，數(shù)據(jù)流通過程中完全基于統(tǒng)一的定義，達到了最終的定義與消費的一致性。
全鏈路監(jiān)控：數(shù)據(jù)從定義到生產(chǎn)到消費環(huán)節(jié)，有完整的監(jiān)控鏈路，以此來確保口徑的持續(xù)一致性。指標一致性監(jiān)控：維度建模的數(shù)倉中，同一個指標由于分析思路或者需求場景，最終生產(chǎn)此指標的模型可能是多個，那么就需要保障指標在不同模型間的口徑一致性。通過一致性對比或者閉環(huán)公式校驗等手段，發(fā)現(xiàn)指標口徑不一致，然后通過口徑變更、模型換綁等治理方法來持續(xù)保障指標口徑的一致；出倉一致性監(jiān)控：出倉過程中數(shù)據(jù)集成工具保障了實時的一致性，這里需要保障的是，由于歷史數(shù)據(jù)變更導(dǎo)致的出倉前后數(shù)據(jù)不一致的問題；服務(wù)質(zhì)量監(jiān)控：從數(shù)據(jù)出口監(jiān)控數(shù)據(jù)的質(zhì)量情況，主要包括閾值監(jiān)控，波動率監(jiān)控等，發(fā)現(xiàn)質(zhì)量問題，保障出口的最終口徑一致性。
3.2 降本增效
中臺的建設(shè)最終是要為企業(yè)降本增效的。過往中，不同業(yè)務(wù)線重復(fù)建設(shè)，垂直產(chǎn)品線煙囪式的開發(fā)，使得數(shù)據(jù)成為一個個孤島，雖能滿足單一業(yè)務(wù)場景，但是卻增加了各個業(yè)務(wù)線的合作成本。我們的建設(shè)思路是，首先將公共、通用的部分抽離出來，形成可復(fù)用服務(wù)，讓業(yè)務(wù)可以快速完成數(shù)據(jù)鏈路的搭建，減少業(yè)務(wù)重復(fù)造輪子，降低研發(fā)成本；其次，統(tǒng)一服務(wù)標準，通過快速復(fù)用已建設(shè)的數(shù)據(jù)鏈路搭建的能力，讓數(shù)據(jù)從定義-->生產(chǎn)-->消費的整個周期縮短，提升對接效率，為數(shù)據(jù)在不同部門間流轉(zhuǎn)創(chuàng)造可能。
降本：數(shù)據(jù)建設(shè)成本：通過模型、指標標準化的定義與管理，數(shù)據(jù)建設(shè)中的一個個表或者模型成為一個可以復(fù)用的標準數(shù)據(jù)資產(chǎn)，數(shù)據(jù)建設(shè)中只需增量建設(shè)，規(guī)避重復(fù)建設(shè)，降低數(shù)據(jù)的建設(shè)成本。服務(wù)研發(fā)成本：服務(wù)通過標準化方式構(gòu)建，下游使用無歧義，使得API復(fù)用成為可能，減少了服務(wù)研發(fā)成本，服務(wù)資源可以重復(fù)利用。提效：數(shù)據(jù)構(gòu)建提效：數(shù)據(jù)構(gòu)建時，通過元數(shù)據(jù)的管理，自動化及半自動化的構(gòu)建出模型及指標，提高了數(shù)據(jù)構(gòu)建效率；另外構(gòu)建出的數(shù)據(jù)資產(chǎn)是標準化的，消除了數(shù)據(jù)格式、生產(chǎn)、存儲等差異性，下游消費時不用關(guān)心底層的邏輯，提高了應(yīng)用的效率。服務(wù)使用提效：標準化的API，在系統(tǒng)對接時可以實現(xiàn)一次對接溝通，多次復(fù)用，提高了API的對接效率。
3.3 服務(wù)高可用
服務(wù)隔離：隔離是將服務(wù)或資源分割開。服務(wù)隔離是為了在服務(wù)發(fā)生故障時，能減少傳播范圍和影響范圍，故障發(fā)生后不會發(fā)生滾雪球效應(yīng)，從而保證只有出問題的服務(wù)不可用，我們根據(jù)服務(wù)的保障等級，劃分為5個服務(wù)資源組，不同資源組相互獨立，不會產(chǎn)生相互影響；存儲資源隔離是通過資源隔離來減少資源競爭，保障服務(wù)間的相互不影響和可用性，我們將資源隔離做到API級別，不同API間及不同等級間做隔離，充分保障資源間的相互不影響。
異地雙活：異地雙活的目的也就是容災(zāi)，當(dāng)某個地方服務(wù)出現(xiàn)了災(zāi)難性故障，而服務(wù)仍然能正常提供服務(wù)。我們根據(jù)業(yè)務(wù)的部署情況，選擇距離業(yè)務(wù)較近的A、B兩地機房部署服務(wù)，正常情況下同機房的請求鏈路為主鏈路，當(dāng)某地服務(wù)宕機，則會自動降級到另外一地的服務(wù)。
緩存：緩存可以讓數(shù)據(jù)更接近使用者，目的是讓訪問的速率更快。對于數(shù)據(jù)時效性要求低但是請求熱度高的接口可以進行緩存，命中緩存后，請求不會到達引擎執(zhí)行層，可以有以下優(yōu)勢：
1. 請求鏈路減少
2. 系統(tǒng)響應(yīng)時間更快
3. 降低了服務(wù)后端及引擎的負載。但是，緩存也會帶來問題，如：
1. 需要保障緩存一致問題
2. 緩存維護成本。數(shù)據(jù)服務(wù)平臺中，緩存有兩層：本地緩存及分布式緩存。
本地緩存：數(shù)據(jù)存儲在本地內(nèi)存，沒有網(wǎng)絡(luò)開銷，速度最快缺點：受服務(wù)內(nèi)存限制，存儲容量較小，數(shù)據(jù)在多個服務(wù)間不可以共享場景：對于熱key及響應(yīng)時間要求極高的api，優(yōu)先使用本地緩存分布式緩存：優(yōu)點：存儲容量更大、可靠性更好、可以在集群間共享缺點：訪問緩存有網(wǎng)絡(luò)開銷場景：緩存數(shù)據(jù)量較大、可靠性要求較高、需要在集群間共享；不同的緩存策略引擎選擇會不同，對于緩存時間長且數(shù)據(jù)量稍大的API，分布式緩存會使用公司內(nèi)自研kv，自研kv在使用成本及大Value上更有優(yōu)勢，其他緩存策略可以使用redis緩存，單API只會在一種引擎內(nèi)。緩存版本管理：多進程間及緩存層級間緩存不一致問題，維護全局視角下API粒度的版本號，來統(tǒng)一進程間的緩存數(shù)據(jù)底層數(shù)據(jù)變更時，利用版本號的切換，解決由于緩存清除時效性不一致帶來的緩存問題
04 落地成果
平臺從零到一建設(shè)一年左右，已經(jīng)逐步承接公司C端及B端的數(shù)據(jù)需求。在體量上，平臺上的 API 數(shù)量已達500以上，日常QPS達數(shù)十萬，經(jīng)歷B站多種大型賽事及活動的洗禮，支持數(shù)據(jù)平臺內(nèi)各種數(shù)據(jù)服務(wù)需求，包括在線應(yīng)用、數(shù)據(jù)產(chǎn)品、BI工具產(chǎn)品及報表等。除了以上業(yè)務(wù)成果外，數(shù)據(jù)服務(wù)平臺通過沉底技術(shù)、制定標準、優(yōu)化流程等，目前平臺的新流程在效率上有極大提升，創(chuàng)建API從近5天降低到1天內(nèi)。在成本方面，平臺也通過多項綜合措施，包括模型復(fù)用、API復(fù)用、應(yīng)用治理，API的生產(chǎn)成本可以降低18%左右。數(shù)據(jù)服務(wù)中臺化加快了研發(fā)周期、節(jié)省了研發(fā)成本，讓有限的資源快速高效迭代出新的業(yè)務(wù)。
05 未來規(guī)劃
穩(wěn)定性服務(wù)穩(wěn)定性在任何時候都是生命線，當(dāng)前的服務(wù)框架中實現(xiàn)細節(jié)仍有優(yōu)化空間，魯棒性有待加強。未來需要針對服務(wù)框架中的實現(xiàn)問題，特別是在隔離級別，資源分配，單點故障等進行優(yōu)化及迭代，讓服務(wù)可以輕松扛過災(zāi)難級故障，未來也需要更多的故障演練來持續(xù)維護服務(wù)的穩(wěn)定性。
智能化當(dāng)前服務(wù)由于從源頭管控了數(shù)據(jù)標準，使得數(shù)據(jù)在提供服務(wù)時需要較多的元數(shù)據(jù)注冊及數(shù)據(jù)構(gòu)建工作，從中長期的角度看，這些注冊的元數(shù)據(jù)雖可以更好的維護數(shù)據(jù)標準，減少重復(fù)建設(shè)，但也提高了數(shù)據(jù)服務(wù)化的難易程度，未來需要打通更多的系統(tǒng)，減少不必要的信息錄入，引入自動化檢測手段，讓服務(wù)化更加智能。
服務(wù)治理隨著數(shù)據(jù)服務(wù)越來越多的被廣泛使用，服務(wù)的治理越來越凸顯重要。我們發(fā)現(xiàn)，API市場中存在著api無熱度、api資源使用率低、api訪問成功率低等問題，針對這些問題需要建立長效的治理機制，長期保障API的穩(wěn)定、可靠與低成本。
