一、業(yè)務(wù)場景

(資料圖片僅供參考)

在開始講解之前，我先為大家介紹一下B站的業(yè)務(wù)場景。B站的業(yè)務(wù)大體上可以分為以下幾類：

1、點播類業(yè)務(wù)

點播類業(yè)務(wù)就是大家經(jīng)?？吹囊曨l以及稿件之類相關(guān)的業(yè)務(wù)，這類數(shù)據(jù)使用場景的特點有：

數(shù)據(jù)一致性要求較高耗時敏感流量大可用性要求高

2、直播類業(yè)務(wù)

直播類業(yè)務(wù)對應(yīng)B站的S12、跨晚、拜年祭等，有以下幾個特點：

數(shù)據(jù)一致性要求較高熱點數(shù)據(jù)，如S12的主播房間平時流量中等，大型直播流量會呈現(xiàn)爆炸性增長可用性要求高

3、游戲類業(yè)務(wù)

數(shù)據(jù)一致性要求較高耗時敏感流量大可用性要求高

4、電商類業(yè)務(wù)

如B站本身的會員購，這類業(yè)務(wù)的要求如下：

數(shù)據(jù)一致性要求較高熱點數(shù)據(jù)，集中在秒殺場景及熱門番劇平時流量中等，熱門番劇及商品會呈現(xiàn)爆炸性增長可用性要求高

5、支付類業(yè)務(wù)

數(shù)據(jù)一致性要求極高可用性要求高流量不大

二、架構(gòu)演進

介紹完B站的業(yè)務(wù)場景之后，接下來是B站整體數(shù)據(jù)庫的架構(gòu)演進歷史。

1、1.0階段

1.0階段對于所有互聯(lián)網(wǎng)公司而言，其實都有類似的架構(gòu)——簡單的主從，所有流量集中在一個主庫上。另外，與以前使用的商業(yè)數(shù)據(jù)庫類似場景——單實例多庫。這種架構(gòu)在公司剛起步的時候是比較方便的，便于業(yè)務(wù)的快速迭代，但是隨著流量的增長，會出現(xiàn)以下幾個問題：

1）單機的性能瓶頸

服務(wù)器的CPU、內(nèi)存、存儲的限制我們不可能一直垂直升級，從而出現(xiàn)了我們第一個架構(gòu)演進的小版本——讀寫分離和一主多從，此場景有兩個核心要求：

數(shù)據(jù)一致性要求較低數(shù)據(jù)敏感度要求較低

滿足以上兩個要求的場景可以很好地規(guī)避因MySQL主從復(fù)制存在的延遲所帶來的問題，同時又可以滿足業(yè)務(wù)快速增長帶來的流量壓力。

2）各業(yè)務(wù)互相影響

隨著業(yè)務(wù)的發(fā)展，各個業(yè)務(wù)之間的互相影響推動了我們架構(gòu)的第二個小版本出現(xiàn)——按照業(yè)務(wù)庫進行遷移拆分。

基于讀寫分離和業(yè)務(wù)庫維度的拆分還是無法避免各個功能模塊的互相影響。在這種情況下，架構(gòu)1.0階段的第三個小版本應(yīng)運而生——基于業(yè)務(wù)的功能維度進行拆分，將一個X庫拆分為n個庫，拆分完之后分布在不同的實例。在每個不同的實例下，我們會有不同數(shù)量的從庫支撐業(yè)務(wù)的流量增長，以滿足大部分場景的業(yè)務(wù)需求。現(xiàn)在B站也有很多業(yè)務(wù)采用類似的架構(gòu)，通過進行垂直業(yè)務(wù)拆分滿足我們的業(yè)務(wù)增長。

2、2.0階段

架構(gòu)2.0階段——水平拆分。成熟、穩(wěn)定、定制的Proxy是水平拆分的利器，而一個符合要求的Proxy是需要時間進行打磨。為滿足業(yè)務(wù)的快速發(fā)展，我們選擇在業(yè)務(wù)層實現(xiàn)，也就是我們在代碼層實現(xiàn)路由，雖然配置時會比較繁瑣，但能夠滿足大部分業(yè)務(wù)場景，很多互聯(lián)網(wǎng)公司也有類似的階段。在業(yè)務(wù)側(cè)進行水平拆分之后，我們其實面臨著一個新的問題——跨實例查詢。

3、3.0階段

1）第一個階段

進入B站演進的3.0階段，我們引入了TiDB，將之前業(yè)務(wù)層面的分片數(shù)據(jù)通過TiDB本身的DTS同步到TiDB集群，從而滿足了大部分業(yè)務(wù)的查詢需求。同時我們在部分場景的業(yè)務(wù)下直接嘗試使用TiDB。

引入TiDB之后，基于B站的特點，我們對其進行了本地化定制。由于TiDB Server是無狀態(tài)的，而官方對于如何路由到每個節(jié)點也沒有一個通用的解決方案。因此我們結(jié)合 B站的基礎(chǔ)平臺能力，將TiDB Server全部在PaaS上進行容器化，同時把我們的服務(wù)發(fā)現(xiàn)能力和TiDB Server進行整合，并對相應(yīng)語言的SDK進行改造，從而實現(xiàn)了TiDB Server的負(fù)載均衡，解決了TiDB Server本身的瓶頸，如：故障切換、業(yè)務(wù)快速感知節(jié)點變化、連接數(shù)等。

2）第二個階段

到了3.0的第二個階段，我們已經(jīng)把Proxy打磨為一個很成熟的產(chǎn)品，同時為滿足支撐了異地多活的場景，我們還定制了DTS，把我們數(shù)據(jù)庫的部署從同城多活直接做到了異地多活，也就是兩地三中心的架構(gòu)。

首先，在DTS方面，我們也基于B站本身技術(shù)棧的特點做了大量的定制，與其它公司開源的組件有部分不同。例如沖突檢測，我們提供了多種可選擇的規(guī)則，包括基于特定字段的以及全字段匹配的，同時對于沖突字段數(shù)據(jù)的R數(shù)據(jù)處理，我們一般會有兩種途徑：

一是直接沖突的場景，將不重要的數(shù)據(jù)直接打入到我們的隊列里，也就是我們公司之前的Data Bus里；二是業(yè)務(wù)方可以基于打到Data Bus里的數(shù)據(jù)做沖突數(shù)據(jù)處理，通過DTS提供一個接口將數(shù)據(jù)回寫到特定的機房，因為當(dāng)需要把數(shù)據(jù)重新寫入數(shù)據(jù)庫時，也是需要做防回環(huán)的處理，所以我們DTS上提供一個接口供業(yè)務(wù)使用。

其次，在主從切換的時候，由于兩地三中心要保證數(shù)據(jù)可以進行來回切換，切換期間雖然是全局進行，但是一些邊緣場景下仍然會存在數(shù)據(jù)沖突的問題。所以我們也提供了一個在主從切換下數(shù)據(jù)沖突以及相關(guān)信息的打撈隊列，實現(xiàn)二次處理的功能，這也是我們中間 DTS提供的一個能力。

Proxy的能力與各家主流的功能是類似的，都能夠支持讀寫分離、分庫分表、限流、黑白名單等。對于Proxy的部署，我們采取了兩種方案：

一是集中式部署，類似于大家常說的網(wǎng)關(guān)模式，能夠便捷地進行統(tǒng)一的限流及資源的調(diào)控；二是Sidecar模式，應(yīng)用層在使用方面比較簡單，直接配置本地IP即可，但是同時已帶來其他問題，如全局的管控（限流、連接等）、成本等。

三、架構(gòu)設(shè)計

接下來為大家介紹的是B站對于不同數(shù)據(jù)量的場景的架構(gòu)設(shè)計理念。

1、大型直播活動

整體概括起來有以下四種類型：

1）高并發(fā)寫入

高并發(fā)寫入考驗的是主庫的寫入能力和從庫的復(fù)制能力。

2）高并發(fā)查詢

高并發(fā)查詢一般都會引入緩存的能力，緩存主要涉及以下幾種：

分布式緩存主要解決容量的問題；Local Cache在應(yīng)用層提供能力，在應(yīng)用本地可以緩存部分?jǐn)?shù)據(jù)，但是數(shù)據(jù)可能存在不及時的問題；多級緩存能夠緩解爆炸性增長的流量帶來的壓力。

3）實時排序

實時排序最直觀的場景就是觀眾在直播間刷禮物的時候展示出來的名次，為保證時效性以及順序，我們一般會采用Redis有序集合。

4）預(yù)期外突發(fā)流量

預(yù)期外突發(fā)流量對于我們而言考驗的主要是應(yīng)用層的快速擴容以及如何對流量進行削峰，同時保證數(shù)據(jù)庫比較平穩(wěn)地寫入，也就是異步寫入的場景。今年最明顯的預(yù)期外突發(fā)流量場景是佩洛西事件，比我們平常的流量大了將近5倍。

2、電商大促

整體上歸納下來有以下幾個特點：

1）秒殺場景

秒殺場景主要涉及合適的選型和請求最簡化?；诠镜幕ㄟM行定制，才可以實現(xiàn)最好的性能和體驗。

2）訂單

訂單有很明顯的冷熱數(shù)據(jù)特征。一般情況下，我們的訂單會被進行一年前、兩年前以及實時訂單的不同拆分。這塊對于數(shù)據(jù)庫而言考驗的是數(shù)據(jù)的歸檔及查詢能力。

3）庫存

庫存與秒殺場景存在一定關(guān)聯(lián)，但并不是完全相關(guān)。秒殺場景會涉及到庫存，但是庫存在平常也會一直使用，因此兩者不能進行強掛鉤。

庫存場景主要在于保證減庫存的準(zhǔn)確性，以及減少用戶端在訪問時可能存在的沖突，另外是一致性的問題，也就是在秒殺和減庫存時不能出現(xiàn)超賣的情況，避免對商家造成虧本。

4）流量削峰

流量削峰與大型直播賽事遇到的突發(fā)流量是不同的，因為這一部分流量是我們已知的，已經(jīng)預(yù)估好會有多少流量，因此我們一般會進行隊列處理以及做分層。

前面介紹了大型直播賽事和電商大促兩個典型場景，我們做了一部分?jǐn)?shù)據(jù)庫架構(gòu)設(shè)計以及與應(yīng)用端的聯(lián)動。下面介紹我們真正進行數(shù)據(jù)庫架構(gòu)設(shè)計時，需要考慮哪些關(guān)鍵點。

3、數(shù)據(jù)

首先需要考慮數(shù)據(jù)，按照我們數(shù)據(jù)類型的使用場景，我們可以將數(shù)據(jù)分為以下三種：

1）配置型

配置型類似于我們的數(shù)據(jù)字典以及一些權(quán)限配置，特點包括：

量小幾乎無事務(wù)依賴讀多寫少

如果需要對配置型數(shù)據(jù)進行高并發(fā)訪問，只需要加緩存即可，不需要做過多處理。

2）日志型

日志型數(shù)據(jù)包括交易流水、訂單狀態(tài)等，我認(rèn)為日志型數(shù)據(jù)也可以稱為流水型數(shù)據(jù)，特點包括：

量大：無法避免，因為我們需要記錄中間各部狀態(tài)；無事務(wù)依賴：我們后續(xù)進行的更多是查詢而很少更改；寫多讀少：讀的比例一般是寫的幾十分之一。

3）狀態(tài)型

數(shù)據(jù)量：與業(yè)務(wù)有關(guān)，狀態(tài)型數(shù)據(jù)可以理解為我們的訂單，以及直播場景里刷禮物的扣減情況；事務(wù)強依賴：必須保證用戶下單成功之后的庫存扣減，以及用戶給主播打賞之后平臺的扣減和主播收到的禮物；讀多寫多：與用戶的進程掛鉤，寫和讀的場景都比較多。

綜上所述，對于數(shù)據(jù)一般通過數(shù)據(jù)量、事務(wù)和讀寫請求三個維度進行判斷，從而對數(shù)據(jù)進行規(guī)整和梳理，對比上述我列出的三種數(shù)據(jù)類型，可以得出數(shù)據(jù)的特定類型。有了數(shù)據(jù)類型之后，我們就可以考慮進行下一個階段，即業(yè)務(wù)對數(shù)據(jù)庫的要求。

4、業(yè)務(wù)

業(yè)務(wù)對數(shù)據(jù)庫選型的要求相對而言比較多，包括事務(wù)、性能、擴縮容、高可用、遷移。

1）事務(wù)

對事務(wù)的要求需要基于數(shù)據(jù)類型進行判斷。

2）性能

一些業(yè)務(wù)對耗時比較敏感，也就是性能要求比較高，要求必須在多少毫秒以內(nèi)將數(shù)據(jù)結(jié)果反饋回來。那么在進行數(shù)據(jù)庫選型時，我們需要考慮該數(shù)據(jù)庫能否承載這么高的性能反應(yīng)。

3）擴縮容

如果業(yè)務(wù)要上一個新業(yè)務(wù)，要考慮滿足一年至兩年的增長的需求，因此數(shù)據(jù)庫的擴縮容能力非常重要。如果之前申請的數(shù)據(jù)量比較大，但是業(yè)務(wù)發(fā)展沒有達到預(yù)期，那么數(shù)據(jù)庫需要縮容，所以這一方面對于數(shù)據(jù)庫選型也是有要求的。

4）高可用

高可用需要進行取舍，如果要保證數(shù)據(jù)的強一致性，以及性能的穩(wěn)定性，必須舍棄一部分東西，具體要與業(yè)務(wù)溝通和協(xié)調(diào)，從而保證實際效果符合業(yè)務(wù)要求。

5）遷移

遷移不僅是業(yè)務(wù)代碼的改造，從A類數(shù)據(jù)庫遷到B類數(shù)據(jù)庫還需要考慮數(shù)據(jù)庫的遷移成本，以及能否支撐同構(gòu)和異構(gòu)。對于業(yè)務(wù)而言，業(yè)務(wù)更多考慮的是遷移帶來的業(yè)務(wù)改造成本，一般業(yè)務(wù)會比較喜歡協(xié)議無變更、基礎(chǔ)操作語法不變的平滑遷移。

5、數(shù)據(jù)庫

數(shù)據(jù)庫我們要考慮的關(guān)鍵點有：

1）事務(wù)

如果你想要強事務(wù)依賴，可以用傳統(tǒng)型數(shù)據(jù)庫，以及現(xiàn)有的NewSQL，比如TiDB、OceanBase等。如果不考慮事務(wù)，數(shù)據(jù)庫選擇會更多，比如Redis、MongoDB，主要取決于具體的使用場景和數(shù)據(jù)庫要承擔(dān)的能力。

2）性能

每一種數(shù)據(jù)庫的性能不同，以關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫為例，MongoDB和MySQL兩者的性能差別是很大的，依然取決于數(shù)據(jù)庫要承擔(dān)的能力。

3）擴縮容、高可用

擴縮容和高可用不需要進行過多的解釋，因為高可用是DBA選擇數(shù)據(jù)庫的硬性要求。

4）遷移

這一部分的遷移與業(yè)務(wù)的遷移存在差異，業(yè)務(wù)的遷移主要考慮業(yè)務(wù)改造成本，數(shù)據(jù)庫的遷移需要考慮以下三點：

數(shù)據(jù)是否一致數(shù)據(jù)遷移時是否有增量數(shù)據(jù)遷移會對業(yè)務(wù)產(chǎn)生什么影響

如果業(yè)務(wù)允許直接一刀切，那么方案則比較簡單；如果業(yè)務(wù)要求無損，那么如何評估方案也是需要大家進行考量的。

5）備份/還原

如果可能出現(xiàn)數(shù)據(jù)需要恢復(fù)的場景，則必須考慮備份/還原的能力。我們一般會更傾向于做物理備份，因為物理備份還原比較快，但是一些數(shù)據(jù)庫沒有提供物理備份的能力，如MongoDB。Redis我們也不會做持續(xù)化的備份，因為會導(dǎo)致性能的嚴(yán)重下降。

6）容災(zāi)

容災(zāi)是第一部分B站數(shù)據(jù)庫架構(gòu)演進我們提到的兩地三中心和同城多活需要具備的一個能力。

7）穩(wěn)定性

數(shù)據(jù)庫的要求是能夠平穩(wěn)地對外提供服務(wù)，因此穩(wěn)定性非常關(guān)鍵。

8）成本

我們不可能為了保證性能無限地往數(shù)據(jù)庫里加機器，因為成本會很高。同時需要考慮開源數(shù)據(jù)庫和商業(yè)數(shù)據(jù)庫的選擇，在一定程度上商業(yè)數(shù)據(jù)庫的性能比同等規(guī)格的開源數(shù)據(jù)庫更好，但是需要考慮維護成本和二次定制化能力的成本。

9）定制化

商業(yè)數(shù)據(jù)庫有時不會讓我們做更多的定制化開發(fā)，但是這會給我們的上下游依賴帶來一個問題，因為大部分場景我們會依賴于類似MySQL的binlog，下游的刷緩存能力以及大數(shù)據(jù)的實時數(shù)倉能力都需要依靠binlog去往下游，也就是CDC能力。那么這一方面也是數(shù)據(jù)庫選型需要進行評估的重要能力。

6、策略

1）多維度綜合考慮

數(shù)據(jù)庫架構(gòu)選型并不是從一個維度考慮的，每個數(shù)據(jù)庫有自身的使用場景和特點，因此數(shù)據(jù)庫架構(gòu)選型需要從多個維度綜合考慮，包括數(shù)據(jù)的維度、業(yè)務(wù)的真實訴求、DBA團隊能提供的數(shù)據(jù)庫能力，以及公司對于數(shù)據(jù)庫的支撐能力，主要是公司其他團隊如開發(fā)和平臺類支撐。

2）滿足未來三到五年需求

數(shù)據(jù)庫架構(gòu)例如擴縮容能力，必須滿足未來3～5年的需求，而不是頻繁地迭代和更新，否則對業(yè)務(wù)而言是有損的。

3）穩(wěn)定為主

數(shù)據(jù)庫需要平穩(wěn)運行，而不是天天宕機，因此數(shù)據(jù)庫架構(gòu)選型需要以穩(wěn)定為主。

上圖的右側(cè)是目前B站的數(shù)據(jù)庫團隊使用的數(shù)據(jù)庫占比，可以看出：

Redis、MySQL分別占比第一和第二；占比第三的是MC，因MC無高可用，這一方面需要從業(yè)務(wù)層進行設(shè)計，如MC異常后的回源能力；其他數(shù)據(jù)庫相對數(shù)量較少。

總體來說，B站的數(shù)據(jù)庫特點是Redis和MySQL為主，其它數(shù)據(jù)庫主要是基于我們的使用場景進行選擇和提供。

四、穩(wěn)定性

今天主要是想向大家介紹B站萬億級數(shù)據(jù)庫選型與架構(gòu)設(shè)計實踐，所以需要考慮數(shù)據(jù)庫如何提供穩(wěn)定性能力。

1、高可用

在提供穩(wěn)定性方面，主要是如何保證數(shù)據(jù)庫高可用。BRM是我們基于B站的業(yè)務(wù)特點自研的MySQL高可用組件，在該架構(gòu)上我們提供了兩個功能節(jié)點Leader和Follower，能夠?qū)簝?nèi)的所有節(jié)點進行管理和探活。不管在哪個節(jié)點進行注冊，我們都可以將其注冊到整個集群。因為內(nèi)部有一個網(wǎng)關(guān)會把所有請求轉(zhuǎn)發(fā)到主節(jié)點，同時再分發(fā)到剩下的Follower節(jié)點上。

Leader和Follower都參與投票決策，用以規(guī)避因網(wǎng)絡(luò)抖動問題導(dǎo)致BRM誤判數(shù)據(jù)庫不可用，然后由Leader節(jié)點根據(jù)投票結(jié)果判斷該節(jié)點到底是否宕機。

整體概括起來，我們自研的BRM會有以下六個核心功能：

多節(jié)點部署：解決MHA單點風(fēng)險；?支持跨機房：跨機房部署解決因網(wǎng)絡(luò)異常引起的誤切風(fēng)險；支持權(quán)重：B站的數(shù)據(jù)庫有單機房、同城多活和異地多活,如何保證切到想要的節(jié)點上。通過對不同節(jié)點設(shè)置權(quán)重，實現(xiàn)類似MongoDB一樣的基于權(quán)重的選主能力；多節(jié)點投票決策：通過多個BRM節(jié)點對同一個實例探測，滿足多數(shù)節(jié)點一致才判定實例不可用；?專線抖動誤切預(yù)防：通過多機房多節(jié)點部署我們可以預(yù)防因?qū)＞€抖動導(dǎo)致的主節(jié)點誤切，也可以避免跨機房專線異常造成的誤判；熔斷機制：如果出現(xiàn)機房宕機的情況，我們可以先切一部分，查看故障發(fā)生的原因，確認(rèn)沒有問題之后再把熔斷機制放開。

2、預(yù)警

保證系統(tǒng)的平穩(wěn)運行，也涉及到預(yù)警的能力。對于數(shù)據(jù)庫的預(yù)警，真正比較具有可預(yù)測性和可觀察性的是慢查詢。數(shù)據(jù)庫的CPU和IO之類的也可以作為參考，但是會存在一定的誤判，所以我們的方案是針對慢查詢，并且做了一套慢查詢預(yù)警體系。

首先對于DB層的慢查詢，我們做了流式的采集上報和實時分析。在實時分析之后，可能會存在誤報的情況，因為如果集群在常態(tài)情況下，每天固定某個時刻都會出現(xiàn)比如100條慢查詢，那么此時是否該報，其實這本身是一個業(yè)務(wù)某個時間點的特定行為，不會影響整體行為，所以需要將其屏蔽。針對這一方面，我們引入多次線性回歸，通過多次線性回歸實現(xiàn)了對偶發(fā)性的抖動的過濾，不同業(yè)務(wù)級別環(huán)比倍數(shù)、持續(xù)性增長（未到閾值倍數(shù)，但持續(xù)增長或存在）慢查詢的預(yù)警，并且基于規(guī)則引擎實現(xiàn)自定義處理。

3、Proxy

通過對Proxy的大量使用，我們可以實現(xiàn)針對某個數(shù)據(jù)庫、某個服務(wù)、某類SQL指紋進行攔截、限流、熔斷，以阻止某些異常流量打崩數(shù)據(jù)的場景，也可以做比較輕松狀態(tài)下的讀寫分離。

我們也可以做多機房路由，將機動架構(gòu)下的數(shù)據(jù)流量轉(zhuǎn)發(fā)到主庫，同時能夠動態(tài)發(fā)現(xiàn)拓?fù)浣Y(jié)構(gòu)的變化，新增或刪除從庫以及節(jié)點的變化都比較易于發(fā)現(xiàn)。

同時我們可以去做更精細(xì)化的Sidecar模式，從而減少業(yè)務(wù)技術(shù)與能力，通過Sidecar模式使用Proxy，可以滿足大家在大量場景下的能力。

4、多活

多活是為了保證在一個機房掛掉之后，我們可以有另外的機房支撐這一方面的能力，我前面講到的Proxy、BRM以及DTS等都是用于滿足多活的訴求。通過多活我們可以保證最大能力的冗災(zāi)，同時對用戶的影響達到最小，當(dāng)一個機房掛掉之后，影響的用戶可能只有一部分，快速將用戶全部導(dǎo)流到另外一個機房可以為用戶提供平穩(wěn)的使用體驗。

五、效率

最后是自動化效率的問題，不管是TiDB這種原生的分布式數(shù)據(jù)庫還是我們基于Proxy和業(yè)務(wù)層自研的分布式數(shù)據(jù)庫能力，同時比如Redis這種超大規(guī)模集群，我們現(xiàn)在經(jīng)常會超過Redis本身的上限，因gossip通信機制，如果節(jié)點數(shù)量過大會導(dǎo)致節(jié)點間的心跳請求將帶寬占滿，所以我們的自動化如何提供效率？以下是自動化運維演進的方向：

當(dāng)前我們?nèi)匀惶幱谧詣踊\維的階段，自動化平臺能力的核心有四個方面，分別是資源管理研發(fā)自助、運維操作和風(fēng)險管理。

自動化運維平臺

1、資源管理

資源管理簡單理解就是資源如何進行分配，有多個維度：

主機管理；Operator管理：無論是否上k8s都要提供Operator的管理能力；資源池管理：涉及到如何提高機器使用度的問題；資源報表：涉及到賬單能力，通過賬單可以明確告訴業(yè)務(wù)哪個地方使用不合理，哪個成本可以節(jié)省，以及哪個架構(gòu)可以調(diào)整。

2、研發(fā)自助

日常情況下，研發(fā)有很多事情需要做，例如查詢、導(dǎo)入、加字段以及健康檢查等。資源申請指的是我們辦了一些比較簡單的常規(guī)業(yè)務(wù)，他們可以基于我們前面講到的策略進行匹配后選擇數(shù)據(jù)庫。到DBA審核的時候，我們會評估他們寫入的內(nèi)容是否合理，保證不會出現(xiàn)由于架構(gòu)設(shè)計失敗引發(fā)重構(gòu)的問題。

3、運維操作

集群管理、實例管理和數(shù)據(jù)管理是一些比較日常的運維操作，整體上由平臺化進行支撐，大部分可以通過自動化解決，不需要人工進行管理。

4、風(fēng)險管理

風(fēng)險管理包括監(jiān)控與告警、健康度報表以及接入信息脫敏和存儲信息脫敏。B站涉及到電商和支付方面，需要對一些數(shù)據(jù)和用戶信息進行大量的脫敏，通過數(shù)據(jù)掃描保證數(shù)據(jù)的合規(guī)。

以上就是我們自動化平臺的能力。

關(guān)鍵詞： 數(shù)據(jù)一致性 需要考慮 數(shù)據(jù)類型 風(fēng)險管理 資源管理