肖博

vivo數據庫架構師

• 擔任vivo通用存儲研發團隊負責任人，負責vivo通用存儲產品和服務平臺研發工作。

• 曾就職于百度數據庫團隊，負責 MySQL、redis等方向的運維研發。

大家好，我是肖博，今天給大家分享的主題是《大規模多存儲場景的數據庫選型與服務平臺建設之路》，主要圍繞vivo在數據庫選型和服務平臺的實踐來展開，希望能給大家帶來不一樣的啟發。

今天的分享主要分為以下三個部分：

1. 自我認知的革命

2. 需求驅動的數據庫選型

3. 服務驅動的平臺化建設

一、自我認知的革命

1、DBA是誰？

我們先來回答一個問題，DBA是誰？

官方的定義是從事管理和維護數據庫管理系統DBMS的相關工作人員的統稱，屬于運維工程師的一個分支。DBA的核心目標是保障數據庫管理系統的穩定、安全、可靠。

那在開發、測試或者老板的眼里DBA是誰呢？

可以看到上圖這個圓圈里有些標簽，寫著DBA技術能力強，任何時候、什么問題都能搞定；時間很忙（雖然不知道在忙什么）；制定了各種流程規范，這個不讓用，那個方案不行，總是說 NO等等。

這些貼在DBA身上的標簽時間久了之后，有些DBA也會以這些標簽來標榜自己，但大家有沒有仔細想過，DBA到底是誰？當然，思考DBA是誰和經典的哲學問題“我是誰”還是有區別的，思考這個問題主要可以分兩個方面：

1. 你知道DBA在別人心目中的印象嗎？

2. 你知道DBA的工作帶給公司、產品帶來的影響嗎？

帶著這兩個問題，我們接著看下DBA的日常工作。

2、DBA的工作

第一塊工作是保障數據庫產品穩定、可靠、高效、安全地運行，解決數據庫的問題，類似于救火隊員，平時不動聲色，關鍵時刻沖在第一線，當然運維性質的工作都是這樣的。

第二塊是通過流程規范、管控平臺逐步地完善運維體系，防患于未然，未雨綢繆，提前做好規劃工作。

第三塊是數據庫的架構設計與選型，這里看起來比前面的兩個要高級一些，我們都知道好的系統是設計出來的，所以設計工作很關鍵也很重要，這個部分對個人能力的要求會相對高一些。

最后一塊是數據架構的治理，這個是什么意思呢？其實大家平時都會說，數據是公司最寶貴的資產，那么DBA就是負責維護和管控這座金礦的人，深入數據內部管理，更好地理解數據，把數據運用起來。當然這方面的工作可能不是DBA去做，只是DBA個人發展的一個方向。

上面講的這兩部分都是大家普遍認知的內容，也都是大家常規的認識，那我們這一章節叫做“自我認知的革命”，那接下來我們會講一講，如何突破認知，重新定義DBA。

3、打造屬于DBA的品牌

如何對DBA的認知進行革命呢？首先我們把DBA和數據庫管理系統DBMS當作一個產品來進行打造，DBA不再是專門維護和管理 DBMS的運維管理人員，DBA本身也是這個產品的一個模塊。

那么我們產品定位是提供數據庫服務能力；服務對象有，開發、測試、架構師、管理者等有數據庫需求的用戶；這款產品的價值輸出有哪些呢，主要是滿足業務訴求的DBMS和用戶滿意的數據庫服務。

將這些打包成一個整體后，我們就可以打造屬于DBA的品牌，把產品能力和價值映入用戶的心中。這樣做有什么好處呢？

1. 強調DBA本身的價值，DBA的個人能力也是一種產品；

2. DBA和數據庫管理系統的關系變化，不再是管理和被管理的關系，而是統一的關系，都是為業務提供有價值的數據庫服務；

3. DBA不再是用戶眼里那個總是說NO，或者躲在幕后的英雄。而是以產品運營的方式將能力最大化輸出，以解決用戶麻煩的思路去看待問題，更好地服務公司的業務。

二、需求驅動的數據庫選型

1、業務場景是需求的靈魂

現在我們來講第二部分，需求驅動的數據庫選型。首先來看一個概念，什么叫業務場景？業務場景一般指企業和商家需要在用戶某個特定的環節中，適時提供給消費者可能需要的以及關聯的產品或服務。

一般來說用戶使用我們的產品后，都會獲得反饋。首先用戶需要接觸和使用到我們的產品或者服務；其次用戶使用后，要么是滿足了用戶的需求，要么是解決了用戶的問題或者在使用過程中遇到了一些困難或者障礙，這樣我們就可以得到用戶對產品的反饋，并形成一個循環。

總的來說，業務場景是需求的靈魂，并且需求不是憑空出現的，是基于業務場景出現的。簡單總結就是：【“誰”在“什么環境下”，“干什么/遇到什么問題”，“如何解決這些問題”，“產生什么樣的價值”】，這點在后面討論數據庫選型和服務平臺建設時，是很關鍵的的一個套路。

2、我們的業務場景-場景分類

接下來說我們的業務場景，這里主要針對的是依附于vivo手機的場景，不包括硬件產品。從軟件產品生態來看，主要分為以下六類：

1. 推薦場景：應用商店、信息流、音樂、視頻、小說等

2. 賬號系統：全系業務場景

3. 廣告場景：信息流、應用商店、小說、視頻等

4. 交易場景：音樂VIP、主題、云服務、游戲等

5. 下載場景：應用商店、系統升級、主題等

6. 推送場景：信息推送、天氣、鬧鐘、語音助手等

上面是一些vivo產品的截圖，有在使用vivo產品的同學可以試用下。應用場景分類之后，我們來看下，針對這些業務場景如何進行數據庫服務選型。

3、數據庫選型實踐

1）數據庫畫像

這里我們使用了雷達圖這個工具，把各種數據庫抽象成為五個方向的能力，并列舉了一些常見數據庫產品：

第一個是數據規模，單集群建議的數據存儲規模。針對業務場景，看看這個場景下的數據規模如何，關于這點沒有絕對的建議，只需按照業界的最佳實踐來做就行。

第二是響應時延，最佳實踐下的平均響應時延。這個很好理解，看你的業務場景是用戶業務還是離線業務，是同步的還是異步等。

第三個是數據模型，這部分比較關鍵，主要指的是結構化、非結構化、事務等，可以抽象為數據模型，或者業務模型都可以。舉個例子，前面提到的賬號或者交易的場景，這種數據肯定需要關系型數據庫來支撐的；前面還提到的推薦業務，可能有幾千個特征或者標簽，這種時候用關系型數據庫來支撐就不太合適。

第四個是數據安全性，指的是存儲系統的穩定性、可靠性、數據的安全性。這也比較好理解，當然絕大多數系統都標榜自己的穩定性和可靠性如何如何，但只需要從原理上仔細對比就可以看出差異，比如使用Redis就不能保證數據一定不丟失，這是由它本身內存這種易失型介質導致的。

第五個是擴展性，主要是指擴展的便利性和擴展時對業務連續性的影響。這個主要還是看業務，如果業務的數據量在未來有擴展的需求，那這個就要重點對待，有些數據庫產品的擴容是很痛苦的或者擴容的過程中對業務的影響并不能做到業務無感知。

這就是用雷達圖把數據庫產品進行抽象對比，這樣就能看出是數據庫產品的特長在哪兒，方便我們去做選型。

最后一點不在這個雷達圖里面，但是至關重要，就是DBA的能力范圍，不要做超越DBA能力范圍的選型。回到前面對 DBA+DBRMS的定義，如果DBA不能cover住這個數據庫產品，那么對外暴露出的就是一個不穩定的、不靠譜的產品，不僅影響公司業務還影響公司口碑。所以在能力范圍內做事情，不反對嘗鮮，但針對生產環境還是要謹慎對待。

最后總結下就是 什么樣的業務在什么場景下需要解決什么問題，用這個邏輯和上面的雷達圖去套，去做選型。那接下來我們看看vivo目前用到了那些數據庫產品。

2）vivo落地的數據庫產品

可以先看這個圖：

標注藍色的為目前用得比較多的，黃色的是我們自己做過改造開發的，紅色是OLAP部分但目前不在我們團隊，綠色是少量試用或者是特定場景使用的。

• MySQL：關系型數據庫

• RDS：公有云廠商提供各種數據庫

• Redis：KV數據庫（緩存）

• ElasticSearch：搜索相關業務

• MongoDB：文檔數據庫

• TIDB：分布式關系型數據庫

• KV Storage：KV數據庫（持久化存儲）

• TSDB：時序數據

• GDB：圖數據

三、服務驅動的平臺化建設

接下來談服務驅動的平臺化建設，還是之前的產品思路，我們先看我們的用戶是誰。

1、誰是數據庫服務平臺的用戶？

1. 軟件開發工程師：在軟件設計實現中完成數據存取的需求

2. 測試工程師：在軟件測試中通過測試數據的構造完成測試任務

3. 數據庫管理員：滿足業務的數據庫各種服務需求

4. 產品經理等：數據報表、數據修訂等需求

當然，以上幾類用戶并沒有先后順序的區別。這塊可能和有些公司建設數據庫服務平臺時有些區別，因為我們不僅要滿足數據庫管理員即DBA的需求，也涵蓋了公司所有對數據庫有需求的用戶。從當前實踐結果來看，不論是PV還是用戶數，都遠超DBA，大概90%以上的用戶是非DBA。

2、用戶需要的運行環境

那么用戶會在什么樣的場景下用我們的服務？

1. 開發環境：在開發環境進行迭代開發業務功能，對性能和可靠性要求一般，但有比較頻繁的變更需求

2. 測試環境：在測試環境驗證服務的功能、性能，測試過程中對可用性和性能有要求，非工作時間各種要求較低

3. 預發環境：在生產環境驗證服務的功能，對數據庫可用性、性能等要求一般

4. 正式環境：在生產環境提供穩定、可靠、高效、安全的數據庫服務

這張圖最下面還有兩塊，一塊是自建的IDC，一塊是公有云的場景，這個主要是和vivo的業務場景有關系，公有云場景主要服務于海外的用戶。

這里還有一部分沒有在圖中展示，我們知道在海外做經營，有些區域的數據合規法比較嚴格，不能和國內有網絡上的互聯互通，這部分一般會做單獨的隔離處理，針對這部分還需要做單獨的處理，由于內容比較復雜，就不展開講了。

3、數據庫產品的生命周期

接下來講四類用戶在四種環境中是如何使用數據庫產品的，這個主要包括了數據庫產品的全生命周期，從數據庫服務的創建到最終下線的全流程。

這個圖里面的箭頭和方向可以忽略，只是表述了全生命周期會經歷那些環節，這些環節之間沒有先后順序。

服務申請包含了服務接入、服務申請；之后的服務部署包括了容量管理、預算管理、服務部署；到了維護環節，有一些監控告警、數據備份、故障演練等操作；業務運行過程種可能有些數據的變更或者數據導出等操作；還有服務的優化，比如服務升級、配置變更、擴縮容；后面的數據回復包括，單實例/Schema恢復、從零恢復；最后的下線回收，這就是整個的環節。

4、數據庫服務產品設計思路

前面我們分析了用戶、場景、產品使用的環節，本質來講是在做需求分析。這些分析完之后我們需要做產品的目標定位以及思考產品的建設思路。

最后我們的產品的愿景定義如下：

1. 打造交互便捷、體驗良好、功能完備的智能存儲管理平臺

2. 打造業界一流的高可用、高性能、低成本的 數據存儲產品與服務

關于產品設計和建設的思路，有以下三點：

1. 不以DBA視角主導產品設計，零基礎也可以玩轉數據庫，這一點也是最關鍵的，不會先入為主，見過很多建設數據庫服務平臺的開發&設計人員本身就是DBA，會有先入為主的思路，做了很多默認的思路，那我們現在著重強調這一點，希望不論是剛入行的開發或者DBA，還是摸爬滾打了很多年的老鳥都能輕松的使用數據庫。

2. 重視用戶交互體驗，平衡可靠性、易用性、操作效率，這塊我們配備了產品經理做產品設計，每半年也會做詳細的用戶滿意度調研，收集用戶的意見

3. 機器學習、混沌工程等只是實現產品功能的一種方法，這塊之所以拿出來講，我們不會標榜我們做的是什么 AIOPS還是什么，這些方法只是我們在解決這類問題的一個方案，如果用機器學習或者深度學習解決更好，我們就用，反之如果傳統的方案能更好的解決，我們不會為了做AI而做AI。

接下來我們看下，平臺的架構設計，這個是簡化了之后的平臺架構圖，中間灰色部分的關聯圖隱藏了，因為關聯關系比較復雜，藍色是我們自己開發的，綠色的是公司現有的能力。

整體思想主要有以下四點：

1. 抽象公共服務（工單、權限等）

2. AGENT負責元數據、監控數據、巡檢任務的上報執行

3. 共建公共能力，不重復造輪子

4. 統一用戶接口，屏蔽公有云與自建IDC區別

5、多運行環境管理

前面講到我們的用戶會在多種環境使用我們的數據庫產品，那一般情況下，測試開發環境和生產環境是會做網絡隔離的，vivo也是這么做的，為了解決這個問題，我們做了很多的改造和適配，主要有以下幾點：

1. 統一權限與接入Portal，不要測試開發一套環境，生產環境一套環境，這樣割裂的操作對用戶體驗有很大的傷害

2. 生產環境與測試開發環境隔離

3. 統一元數據管理

這個架構我做下簡單的介紹，這里的Tomcat代表的是我們的平臺服務，因為我們的平臺服務是用JAVA寫的，整個平臺里面的數據庫從功能來看，主要分為兩類，一類是 提供給我們用戶用的數據；一類是我們平臺自己用的數據庫。平臺用的數據庫就是我們的元數據，這塊一定要統一，因為在權限和資產管理上必須要統一。

前端在接入層需要帶上環境的標志，接入網關根據環境標志進行流量路由，因為生環境的Tomcat服務是沒有辦法直接管理測試環境的數據庫環境的，所以我們在開發&測試環境也需要部署我們的平臺服務。

我們給數據庫定義了很多套餐，按照套餐來分配并且這些套餐是和環境有映射關系的，這樣我就可以用一套代碼通過環境和用戶的需求來管理資源。

6、數據庫產品能力矩陣

最后我們看下我們目前已經建成的一些能力，上層主要分為 可用性、效率、成本、安全四塊。中間的部分是我們的數據存儲產品，這塊就不詳細展開講了。

>>>>

Q&A

Q1：請問這個平臺有用到開源框架嘛，多少人開發的，用了多久？

A：數據庫服務平臺的架構比較通用，后端服務為Spring Boot框架的微服務架構，前端采用的是Vue，部分組件如SQL審核、SQL優化、容量預測等組件采用了Golang或者Python編寫；平臺從2018年下半年開始建設，歷經約2年時間，參與平臺研發的同學5-7人左右。

Q2：如何順利實現云下IDC數據遷移到公有云上，數據庫之間如何驗證？

A：云下IDC遷移到公有云上，這方面公有云廠商提供了很多的工具，如阿里云提供的DTS工具，此類產品一般自帶數據一致性校驗功能。當然也可以使用一些業界通用的工具去校驗數據，另外不論系統做哪種層面的數據校驗，最好讓業務也進行配合驗證下。

Q3：用了運維平臺后，對于DBA來說，除了處理工單日產工作外，還有哪些技術棧需要學習/儲備的？DBA需不需花大精力參加進來開發維護平臺？

A：日常變更的操作更多的是開放給開發人員來自助操作，目前我們這邊的數據庫服務平臺由專門的開發同學負責，不是DBA兼職進行開發，DBA未來更多的往技術運營方向發展，深入業務線，為業務的架構、設計等出謀劃策。

Q4：能否就多種數據庫的統一訪問服務如何構建指點一下？

A：這塊目前還在構想中，需要很多的底層基礎能力支撐，比如正在建設的各種數據存儲產品、存儲中間件，當這些產品都成熟穩定后，可以再上層抽象一層數據庫網關，結合數據模型和流量模型進行調度，對外暴露固定的幾種訪問接口即可。

Q5：你們做過哪些數據庫的擴容？如何實現的？擴容時有沒有數據的遷移？

A：目前平臺已經支持的有 MySQL、Redis、ElasticSearch的擴容，其他數據庫組件擴容還在建設中，擴容過載中均涉及到數據遷移操作。MySQL的擴容目前支持兩種，升級套餐和增加只讀節點，Redis的擴容包括增加單實例容量和增加集群節點兩種，增加集群節點需要大量的數據遷移操作，這方面做的優化比較多。

Q6：DBA后期的職責定位是？

A：給業務提供數據庫解決方案，解決數據庫疑難雜癥，數據庫服務運營等。

Q7：數據庫中間件開發需要具備什么能力？我在工作中遇到一個問題，我們測試數據需求很大，測試數據要到多個項目的數據庫中查詢，然后查詢結果寫到我們測試的庫里。目前采用的方式是寫好了SQL語句查庫，查詢涉及700多張表。查詢結果往往好幾個小時還回不來。請問有沒有能夠提高效率的方法？數據庫是MySQL。

A：數據庫中間件編程來說，我們團隊目前用到的有Golang和C++，初次之外還需要對網絡、系統、OS內核、分布式等理論知識需要較深的掌握。多表聯合查詢性能較低的話，單從數據庫層面來看解決方案有限，可以考慮一些 ELT的方案。