首先，vivo自研了數(shù)據(jù)庫(kù)運(yùn)維平臺(tái)DaaS來(lái)支撐數(shù)據(jù)庫(kù)運(yùn)維工作。在規(guī)模覆蓋、效率提升、故障告警處理等層面均衡發(fā)力，保障了數(shù)據(jù)的穩(wěn)定性，以工單自助，故障自愈為核心，實(shí)現(xiàn)了數(shù)據(jù)庫(kù)的高效運(yùn)維。 

其次，在數(shù)據(jù)庫(kù)資源彈性管理層面，vivo重視資源成本優(yōu)化。圍繞資源分配、資源彈性伸縮、資源隔離分別給出了智能化解決方案，并通過(guò)套餐自動(dòng)優(yōu)化，進(jìn)一步降低了管理成本。

最后，基于個(gè)人隱私數(shù)據(jù)，平臺(tái)也提供了對(duì)業(yè)務(wù)幾乎無(wú)影響的MySQL的透明加密方案，來(lái)減輕因?yàn)殡[私數(shù)據(jù)加密帶來(lái)的研發(fā)和運(yùn)維工作量。

一、云原生時(shí)代數(shù)據(jù)庫(kù)運(yùn)維挑戰(zhàn)

1.1 數(shù)據(jù)庫(kù)運(yùn)維體系演進(jìn)

從數(shù)據(jù)庫(kù)運(yùn)維體系的演進(jìn)歷程來(lái)看，

1、2000年左右，PC互聯(lián)網(wǎng)時(shí)代興起，商業(yè)數(shù)據(jù)庫(kù)是市場(chǎng)主流，而開(kāi)源數(shù)據(jù)庫(kù)方興未艾。普遍的數(shù)據(jù)庫(kù)運(yùn)維方式，還是人工加腳本，當(dāng)時(shí)大部分公司數(shù)據(jù)庫(kù)規(guī)模量相對(duì)不大，這樣做完全夠用。人們面臨的主要運(yùn)維挑戰(zhàn)是商業(yè)數(shù)據(jù)庫(kù)軟硬件成本高，而開(kāi)源數(shù)據(jù)庫(kù)軟件和配套工具不成熟，通常要自研來(lái)滿(mǎn)足開(kāi)源數(shù)據(jù)庫(kù)自身的穩(wěn)定性和擴(kuò)展性要求，門(mén)檻高。

2、到了2010年左右，移動(dòng)互聯(lián)網(wǎng)時(shí)代興起，社會(huì)數(shù)字化進(jìn)程陡然加速，數(shù)據(jù)量規(guī)模大增。此時(shí)，一個(gè)針對(duì)IT基礎(chǔ)設(shè)施的革命性的概念提出來(lái)了，那就是云計(jì)算，簡(jiǎn)單來(lái)說(shuō)，就是通過(guò)網(wǎng)絡(luò)的方式提供服務(wù)器，數(shù)據(jù)庫(kù)，或者某種軟件服務(wù)資源。在數(shù)據(jù)庫(kù)運(yùn)維領(lǐng)域，則自然衍生出了云計(jì)算的一個(gè)分支概念，DaaS，data as a service，數(shù)據(jù)庫(kù)的運(yùn)維方式因此由人工腳本方式轉(zhuǎn)變?yōu)榱藬?shù)據(jù)庫(kù)平臺(tái)的方式。同時(shí)，隨著開(kāi)源數(shù)據(jù)庫(kù)技術(shù)以及各種周邊生態(tài)軟件走向成熟，開(kāi)源數(shù)據(jù)庫(kù)得到了廣泛應(yīng)用。這時(shí)，數(shù)據(jù)庫(kù)運(yùn)維的挑戰(zhàn)變成了如何高效率交付資源，保障數(shù)據(jù)庫(kù)穩(wěn)定性，做好數(shù)據(jù)庫(kù)成本優(yōu)化。

3、到了2020年左右，后移動(dòng)互聯(lián)網(wǎng)時(shí)代，社會(huì)數(shù)字化程度進(jìn)一步加深。云原生的概念被提了出來(lái)。微服務(wù)架構(gòu)，資源彈性，容器等云原生技術(shù)廣為傳播。數(shù)據(jù)庫(kù)的穩(wěn)定性方面，因?yàn)殚_(kāi)源數(shù)據(jù)庫(kù)的高可用體系普遍成熟而大大緩解。數(shù)據(jù)庫(kù)規(guī)模方面，實(shí)例數(shù)量和品類(lèi)都進(jìn)一步大增。數(shù)據(jù)庫(kù)安全方面，2021年8月我國(guó)正式出臺(tái)了個(gè)人信息保護(hù)法，個(gè)人隱私數(shù)據(jù)保護(hù)成為了數(shù)據(jù)庫(kù)運(yùn)維的時(shí)代重點(diǎn)。

1.2 云原生時(shí)代挑戰(zhàn)

這樣的時(shí)代背景下，我以為數(shù)據(jù)庫(kù)運(yùn)維主要有三個(gè)方面的挑戰(zhàn)：

1. 云原生時(shí)代應(yīng)用架構(gòu)普遍微服務(wù)化，一個(gè)系統(tǒng)拆成多個(gè)微服務(wù)，這個(gè)系統(tǒng)的數(shù)據(jù)庫(kù)也分拆成多個(gè)。這導(dǎo)致數(shù)據(jù)庫(kù)實(shí)例成倍增加，數(shù)據(jù)庫(kù)的運(yùn)維工作量也成倍增加。因此大規(guī)模數(shù)據(jù)庫(kù)實(shí)例如何有效運(yùn)維?這就是第一個(gè)挑戰(zhàn)。
2. 云原生理念應(yīng)用架構(gòu)層面的彈性伸縮，自然也要求數(shù)據(jù)庫(kù)層面做到彈性伸縮。具體來(lái)說(shuō)，是效率上做到快速擴(kuò)縮，業(yè)務(wù)無(wú)損，成本上也要做到，按需按量使用。但是主流開(kāi)源數(shù)據(jù)庫(kù)本身是存算一體架構(gòu)，這兩點(diǎn)支持不容易。數(shù)據(jù)庫(kù)如何做好資源彈性伸縮？這是第二個(gè)挑戰(zhàn)。
3. 數(shù)據(jù)庫(kù)安全方面，個(gè)人隱私數(shù)據(jù)需要保護(hù)，這個(gè)必要性無(wú)需多說(shuō)，但是怎么技術(shù)落地？怎么識(shí)別個(gè)人隱私數(shù)據(jù)，識(shí)別之后又如何進(jìn)行數(shù)據(jù)加密。而開(kāi)源數(shù)據(jù)庫(kù)在這方面，即也沒(méi)有具體的落地方案，沒(méi)有提供專(zhuān)門(mén)的工具，這些都有待自己探索。這是第三個(gè)挑戰(zhàn)。

挑戰(zhàn)講完了，接下來(lái)我們看下vivo在這三個(gè)挑戰(zhàn)方向的應(yīng)對(duì)。

二、vivo 大規(guī)模數(shù)據(jù)庫(kù)實(shí)例高效運(yùn)維

2.1 高效運(yùn)維實(shí)踐現(xiàn)狀

vivo是自研了數(shù)據(jù)庫(kù)運(yùn)維平臺(tái)DaaS來(lái)支撐數(shù)據(jù)庫(kù)運(yùn)維工作。

規(guī)模上，支撐了數(shù)萬(wàn)數(shù)據(jù)庫(kù)實(shí)例的運(yùn)維服務(wù)，包含了6種數(shù)據(jù)庫(kù)：MySQL，Redis，MongoDB，Elasticsearch，TiDB5個(gè)開(kāi)源數(shù)據(jù)庫(kù)，1個(gè)公司內(nèi)部自研的磁盤(pán)KV。

效率上，節(jié)省了92%的數(shù)據(jù)庫(kù)運(yùn)維工作量。月均數(shù)千的總工單量，其中92%都是無(wú)需運(yùn)維參與，由平臺(tái)用戶(hù)自助執(zhí)行。

故障告警處理上，70%的數(shù)據(jù)庫(kù)告警實(shí)現(xiàn)自動(dòng)分析或者處理，進(jìn)一步解放了數(shù)據(jù)庫(kù)運(yùn)維人力，保障了數(shù)據(jù)穩(wěn)定性。

綜上所述，數(shù)據(jù)庫(kù)高效運(yùn)維的核心就是，工單自助，故障自愈。接下來(lái)將詳細(xì)介紹這兩點(diǎn)。

2.2 工單自助

首先看工單自助，要實(shí)現(xiàn)工單自助，主要有三點(diǎn)：

1. 95%運(yùn)維操作平臺(tái)化，用平臺(tái)操作替代手工或者腳本操作。所謂平臺(tái)化的本質(zhì)，就是用代碼的方式，將最佳的運(yùn)維經(jīng)驗(yàn)固化在平臺(tái)中。這才是一切運(yùn)維效率的基礎(chǔ)。
2. 99%工單成功率，一方面是要做到，所有運(yùn)維操作都有工單流記錄，這是運(yùn)維工作量化和進(jìn)步的基礎(chǔ)；另一方面，因?yàn)楫惓５墓芜€是要數(shù)據(jù)庫(kù)專(zhuān)業(yè)運(yùn)維介入處理的,所以只有工單一鍵執(zhí)行成功率達(dá)到99%以上才可以開(kāi)放自助，才談得上提升了效率。
3. 部分開(kāi)源數(shù)據(jù)庫(kù)生態(tài)工具是空白的，例如常見(jiàn)數(shù)據(jù)庫(kù)Redis 要數(shù)據(jù)變更自助，一方面需要做到變更過(guò)程業(yè)務(wù)無(wú)影響，這要求做好變革速度&負(fù)載控制，變更前排除大key等風(fēng)險(xiǎn)因素。另一方面還需要做到變更過(guò)程數(shù)據(jù)安全，這要求變更前做好備份，變更后可隨時(shí)回滾。這些都沒(méi)有現(xiàn)成開(kāi)源工具集成，vivo是通過(guò)自研逐個(gè)填補(bǔ)了這些工具空白。

2.3 故障自愈

隨著數(shù)據(jù)庫(kù)規(guī)模的成倍增加，故障告警的數(shù)目也急劇增多，vivo日均數(shù)百數(shù)據(jù)庫(kù)故障告警，存粹靠手工進(jìn)行告警問(wèn)題排查處理越來(lái)越不能滿(mǎn)足數(shù)據(jù)庫(kù)穩(wěn)定性的要求。

數(shù)據(jù)庫(kù)故障自愈的需求就被自然提了出來(lái)。故障處理簡(jiǎn)單分為：發(fā)現(xiàn)，定位，恢復(fù) 三個(gè)步驟，針對(duì)已經(jīng)發(fā)生的故障我們反復(fù)分析確認(rèn)，其中定位環(huán)節(jié)是最耗時(shí)，所以當(dāng)前故障自愈系統(tǒng)主要做的就是故障分析定位的工作。整體上故障自愈主要是兩個(gè)難點(diǎn)，一個(gè)故障自愈方案的確認(rèn)，另一個(gè)是相關(guān)基礎(chǔ)工具的開(kāi)發(fā)。

通常認(rèn)為故障自愈方案最好是全面信息采集+機(jī)器學(xué)習(xí)自動(dòng)確認(rèn)的，這樣的方案具備普適性，也更有效率且準(zhǔn)確。但是立足于團(tuán)隊(duì)和問(wèn)題現(xiàn)狀，我們認(rèn)為當(dāng)前的故障自愈方案可以是全基于運(yùn)維專(zhuān)家經(jīng)驗(yàn)確認(rèn)的。這是因?yàn)樵跀?shù)據(jù)庫(kù)運(yùn)維方向，目前常見(jiàn)數(shù)據(jù)庫(kù)相關(guān)故障場(chǎng)景不到50個(gè)，且變量因素單一，所以即便憑借優(yōu)秀專(zhuān)家經(jīng)驗(yàn)枚舉處理辦法，也能自動(dòng)解決大部分故障，簡(jiǎn)單實(shí)用。另外在故障自愈的基礎(chǔ)工具上，我們主要自研了：Redis流量分析，熱key分析，MySQL 根因SQL分析等工具。

接下來(lái)介紹故障自愈的邏輯架構(gòu)：

整個(gè)系統(tǒng)是由故障告警驅(qū)動(dòng)，系統(tǒng)獲取到告警消息后去查找相匹配的預(yù)案，然后執(zhí)行預(yù)案中設(shè)定的基礎(chǔ)操作，包括分析操作和恢復(fù)操作，例如Redis流量分析或者M(jìn)ySQL binlog清理等，最終生成執(zhí)行報(bào)告，其中包括中間狀態(tài)的現(xiàn)場(chǎng)監(jiān)控快照，智能的分析結(jié)果等，同時(shí)也提供案例標(biāo)注的能力。最后執(zhí)行結(jié)果會(huì)自動(dòng)分配并通知到對(duì)應(yīng)負(fù)責(zé)的數(shù)據(jù)庫(kù)運(yùn)維人員或者消息群組當(dāng)中。

通過(guò)這套架構(gòu)，最后實(shí)現(xiàn)了超70%的故障自動(dòng)分析或者處理，包括至少30個(gè)基礎(chǔ)能力建設(shè)，26個(gè)故障預(yù)案，10個(gè)故障場(chǎng)景全自動(dòng)處理。

三、vivo 數(shù)據(jù)庫(kù)彈性資源管理

3.1 資源彈性管理問(wèn)題&現(xiàn)狀

我們先來(lái)看vivo數(shù)據(jù)庫(kù)資源管理上要面臨的現(xiàn)狀和問(wèn)題：

1. 傳統(tǒng)數(shù)據(jù)庫(kù)占主流，從數(shù)量上看，線上數(shù)據(jù)庫(kù)數(shù)萬(wàn)個(gè)實(shí)例，85%是REDIS，10%是MySQL，剩下5%是其它數(shù)據(jù)庫(kù)。都是存算一體的傳統(tǒng)數(shù)據(jù)庫(kù)，彈性伸縮能力并不完美，例如開(kāi)源Redis Cluster的彈性伸縮是單線程的，上了一定數(shù)據(jù)規(guī)模后其擴(kuò)縮速度和穩(wěn)定性都有待進(jìn)一步提升。
2. 當(dāng)前數(shù)據(jù)庫(kù)資源管理還沒(méi)有容器化，數(shù)據(jù)庫(kù)資源隔離得另想辦法。同時(shí)對(duì)于Redis等傳統(tǒng)數(shù)據(jù)庫(kù)來(lái)說(shuō)，容器化也不能解決其彈性伸縮的速度和穩(wěn)定性問(wèn)題，這些都只能從數(shù)據(jù)庫(kù)軟件本身上去解決。
3. 目前數(shù)據(jù)庫(kù)資源都是直接部署在物理機(jī)上，PB級(jí)數(shù)據(jù)直接部署在數(shù)千臺(tái)物理機(jī)上，數(shù)據(jù)庫(kù)成本問(wèn)題比較敏感。

3.2 資源彈性管理主要實(shí)現(xiàn)點(diǎn)

針對(duì)上述問(wèn)題，vivo數(shù)據(jù)庫(kù)平臺(tái)主要做了如下工作：

1. 資源分配上，實(shí)行單機(jī)器多實(shí)例多版本多套餐混合部署，同類(lèi)數(shù)據(jù)庫(kù)資源池統(tǒng)一，提升資源利用率。
2. 資源彈性伸縮上，自研多線程Redis Cluster擴(kuò)縮工具，顯著加速Redis Cluster擴(kuò)縮容過(guò)程，同時(shí)增加限速，大key巡檢，歷史負(fù)載檢測(cè)，腦裂檢測(cè)等功能盡量增擴(kuò)縮容穩(wěn)定性。
3. 資源隔離上，則采用兩個(gè)措施。
   （1）程序配置實(shí)現(xiàn)隔離，如Redis，線程模型決定了幾乎只消耗一個(gè)CPU核心，而內(nèi)存占用也主要由配置決定，其它網(wǎng)絡(luò)磁盤(pán)很少存在爭(zhēng)用，所以混部就沒(méi)隔離問(wèn)題了。
   （2）通過(guò)巡檢和容量預(yù)測(cè)的方式實(shí)現(xiàn)軟隔離，盡量解決非突增的資源爭(zhēng)用問(wèn)題。

3.3 套餐自動(dòng)優(yōu)化

在資源成本優(yōu)化上，除了剛才提過(guò)的混合部署，還可以做套餐自動(dòng)優(yōu)化，進(jìn)一步降低成本。

下面介紹下具體的套餐自動(dòng)優(yōu)化流程：

• 第一步 平臺(tái)自動(dòng)掃描全網(wǎng)數(shù)據(jù)庫(kù)實(shí)例，挑出其中被認(rèn)定是滿(mǎn)足縮容條件的。
• 第二步 平臺(tái)自動(dòng)發(fā)送縮容工單交由實(shí)例對(duì)應(yīng)的業(yè)務(wù)項(xiàng)目經(jīng)理審批。
• 第三步 根據(jù)審批結(jié)果執(zhí)行縮容，或者放棄本次縮容。

大概在這個(gè)功能上線后的4個(gè)月內(nèi)，平臺(tái)自動(dòng)發(fā)起超千次縮容，節(jié)省了超百T空間。

四、vivo個(gè)人隱私數(shù)據(jù)全鏈路保護(hù)

4.1 隱私保護(hù)數(shù)據(jù)庫(kù)層面現(xiàn)狀

在線數(shù)據(jù)庫(kù)有數(shù)十萬(wàn)張“表”，總計(jì)超千萬(wàn)個(gè)字段，其中隱私數(shù)據(jù)識(shí)別覆蓋100% ，涉及MySQL，MongoDB，Elasticsearch，TiDB四種數(shù)據(jù)庫(kù)，人工抽查識(shí)別準(zhǔn)確度79%。

而當(dāng)個(gè)人隱私數(shù)據(jù)識(shí)別出來(lái)了，處理的主要手段就是加密，所以平臺(tái)也提供了對(duì)業(yè)務(wù)幾乎無(wú)影響的，MySQL的透明加密方案，來(lái)減輕因?yàn)殡[私數(shù)據(jù)加密帶來(lái)的研發(fā)和運(yùn)維工作量。

4.2 全鏈路功能

隱私數(shù)據(jù)庫(kù)保護(hù)應(yīng)該是貫穿業(yè)務(wù)研發(fā)階段，運(yùn)營(yíng)階段的全鏈路保護(hù)。

• 研發(fā)階段：統(tǒng)一數(shù)據(jù)庫(kù)建表入口，同時(shí)提供平臺(tái)工具便于用戶(hù)對(duì)新建表中的隱私數(shù)據(jù)字段進(jìn)行標(biāo)記，這主要解決日常新增數(shù)據(jù)結(jié)構(gòu)的識(shí)別問(wèn)題。
• 運(yùn)營(yíng)階段：定期掃描全網(wǎng)表結(jié)構(gòu)數(shù)據(jù)，自動(dòng)識(shí)別未標(biāo)記的隱私數(shù)據(jù)，并人工抽查校準(zhǔn)，這主要解決存量數(shù)據(jù)結(jié)構(gòu)的識(shí)別問(wèn)題，同時(shí)也是研發(fā)階段識(shí)別的補(bǔ)充。
• 運(yùn)營(yíng)階段操作：數(shù)據(jù)查詢(xún)結(jié)果中包含隱私數(shù)據(jù)自動(dòng)加密顯示.數(shù)據(jù)導(dǎo)出隱私數(shù)據(jù)時(shí)自動(dòng)加密，并添加水印。

4.3 最后的防線：數(shù)據(jù)庫(kù)加密

對(duì)于數(shù)據(jù)安全來(lái)說(shuō)，數(shù)據(jù)庫(kù)加密是最后一道防線。前面提到隱私數(shù)據(jù)識(shí)別出來(lái)了，那么加密的目標(biāo)有了。基礎(chǔ)加密算法業(yè)界也比較成熟，加密方式也不缺。唯一的問(wèn)題是，加密的過(guò)程。

對(duì)于新增業(yè)務(wù)來(lái)所，加密過(guò)程比較簡(jiǎn)單，沒(méi)有業(yè)務(wù)訪問(wèn)怎么做都行。但是對(duì)于存量的成熟業(yè)務(wù)來(lái)說(shuō)，幾十張表，數(shù)據(jù)規(guī)模千萬(wàn)記錄都是常事，怎么加密還能不影響用戶(hù)訪問(wèn)，就是個(gè)麻煩的問(wèn)題。為了解決這個(gè)痛點(diǎn)，目前數(shù)據(jù)庫(kù)平臺(tái)提供了一個(gè)存量業(yè)務(wù)數(shù)據(jù)無(wú)損加密方案，因?yàn)橹饕[私數(shù)據(jù)都在MySQL中，所以這是基于MySQL的。

首先介紹加密涉及的三個(gè)組件：數(shù)據(jù)庫(kù)平臺(tái)是用戶(hù)操作入口，表結(jié)構(gòu)變更工具gh-ost負(fù)責(zé)歷史數(shù)據(jù)加密轉(zhuǎn)化，MySQL代理負(fù)責(zé)讓加解密過(guò)程對(duì)業(yè)務(wù)程序透明。

接下來(lái)介紹無(wú)損加密的主要流程：

• 第一步、用戶(hù)要在數(shù)據(jù)庫(kù)平臺(tái)上配置需要加密的字段。如果不需要對(duì)歷史數(shù)據(jù)加密那么整個(gè)加密配置流程就結(jié)束了。
• 第二步、如果要加密歷史數(shù)據(jù)，就會(huì)產(chǎn)生一個(gè)數(shù)據(jù)清洗工單，交給表結(jié)構(gòu)變更工具gh-ost執(zhí)行，具體過(guò)程就是新增一個(gè)密文列復(fù)制明文列數(shù)據(jù)并加密。然后MySQL代理會(huì)自動(dòng)將明文列請(qǐng)求轉(zhuǎn)向密文列，至此數(shù)據(jù)清洗完成。
• 第三步、步驟2執(zhí)行后，業(yè)務(wù)如果發(fā)現(xiàn)有問(wèn)題，可以隨時(shí)回滾。業(yè)務(wù)方認(rèn)定數(shù)據(jù)加密后服務(wù)穩(wěn)定時(shí)，就可以選擇回收明文列，最后更新MySQL代理配置，去掉明文數(shù)據(jù)同步更新，整個(gè)加密過(guò)程就算完結(jié)，全程幾乎無(wú)需業(yè)務(wù)改動(dòng)代碼，且對(duì)業(yè)務(wù)無(wú)損。

五、未來(lái)展望

5.1 故障處理

個(gè)人認(rèn)為故障自愈的演進(jìn)可以分為三個(gè)階段：

• 階段一：專(zhuān)家經(jīng)驗(yàn)式枚舉故障自愈（這是當(dāng)前所在的階段）。
• 階段二：在階段一基礎(chǔ)上引入AI判斷，形成AI判斷為輔，專(zhuān)家經(jīng)驗(yàn)為主的故障處理體系。
• 階段三：構(gòu)建AI判斷為主，專(zhuān)家經(jīng)驗(yàn)為輔的自愈系統(tǒng)，進(jìn)一步提升自動(dòng)化程度。

3.2 資源管理

接下來(lái)在彈性資源管理這個(gè)方向，個(gè)人認(rèn)為其發(fā)展可以分為三個(gè)階段：

• 階段一：數(shù)據(jù)庫(kù)混合資源管理（這是當(dāng)前所在的階段，套餐，版本可以混合）。
• 階段二：數(shù)據(jù)庫(kù)容器混合資源管理，這一階段主要是利用容器消除機(jī)型隔離，品類(lèi)隔離，有助于更高密度資源部署以及套餐統(tǒng)一標(biāo)準(zhǔn)化的實(shí)現(xiàn)。
• 階段三：存算分離架構(gòu)數(shù)據(jù)庫(kù)的資源管理。在底層資源調(diào)度層面發(fā)揮到極致后，只能通過(guò)數(shù)據(jù)庫(kù)架構(gòu)本身的升級(jí)提升資源彈性。

5.3 隱私數(shù)據(jù)治理

在個(gè)人隱私數(shù)據(jù)這個(gè)方向，還有兩個(gè)待解決的問(wèn)題：

1. 第一個(gè)是，非結(jié)構(gòu)化數(shù)據(jù)隱私自動(dòng)識(shí)別和加密問(wèn)題。結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，就是MySQL，MongoDB這種，通過(guò)字段的可以批量識(shí)別和處理一個(gè)表或者集合的隱私數(shù)據(jù)。但是對(duì)于Redis這種結(jié)構(gòu)，當(dāng)前一次只能識(shí)別和處理一個(gè)key-value鍵值對(duì)。解決思路是，非結(jié)構(gòu)化轉(zhuǎn)為半結(jié)構(gòu)化數(shù)據(jù)，例如特定前綴key或者正則key，綁定固定的value結(jié)構(gòu)。
2. 第二個(gè)問(wèn)題是，隱私數(shù)據(jù)的識(shí)別準(zhǔn)確率問(wèn)題，當(dāng)前只有79%，這個(gè)目前思路是人工標(biāo)注+AI識(shí)別。

5.4 數(shù)據(jù)庫(kù)平臺(tái)的未來(lái)展望

最后談下數(shù)據(jù)庫(kù)平臺(tái)建設(shè)，概括來(lái)說(shuō)8個(gè)字，統(tǒng)一標(biāo)準(zhǔn)，開(kāi)源共建。

展開(kāi)來(lái)說(shuō)，如今的數(shù)據(jù)庫(kù)技術(shù)市場(chǎng)百花齊放，DBengines網(wǎng)站榜上有名的數(shù)據(jù)庫(kù)就有395種，單個(gè)系統(tǒng)構(gòu)建依賴(lài)多個(gè)品類(lèi)數(shù)據(jù)庫(kù)的情況逐漸普及，通過(guò)統(tǒng)一的數(shù)據(jù)庫(kù)平臺(tái)來(lái)支撐數(shù)據(jù)庫(kù)運(yùn)維工作，幾乎成了企業(yè)的剛性需求。但我們?nèi)狈σ粋€(gè)公認(rèn)的跨品類(lèi)的數(shù)據(jù)庫(kù)運(yùn)維標(biāo)準(zhǔn)，也缺乏一個(gè)主流的跨越多品類(lèi)的開(kāi)源數(shù)據(jù)庫(kù)平臺(tái)。

個(gè)人期望用這樣的開(kāi)源平臺(tái)來(lái)承載數(shù)據(jù)庫(kù)廠商，數(shù)據(jù)庫(kù)生態(tài)工具開(kāi)發(fā)者以及企業(yè)用戶(hù)對(duì)數(shù)據(jù)庫(kù)服務(wù)共建的訴求，加速數(shù)據(jù)庫(kù)服務(wù)建設(shè)速度，讓云原生時(shí)代沒(méi)有難運(yùn)維的數(shù)據(jù)庫(kù)。