在DTCC 2019大會上，阿里云智能數據庫產品事業部高級產品專家蕭少聰做了題為《如何構建云時代DBA的知識體系》的演講，進行云時代以后，IT行業各工種的職責都在發生變化，云數據庫使得日常DBA管理實現更多的自動化，大大提高日常管理效率，同時也對于企業整體投資產出可以更快獲得成效。面對云數據庫的發展趨勢，DBA應如何避免“踩坑”呢？本文就為大家揭曉答案。

專家簡介：蕭少聰（花名：鐵庵），阿里云智能數據庫產品事業部高級產品專家，PostgreSQL中國社區常委。

直播回放

鏈接：https://yq.aliyun.com/live/1046

議題PPT下載，戳這里！

https://yq.aliyun.com/download/3562

本文將主要圍繞以下四個方面進行分享：

管理模式的變化

云數據庫VS.自建數據庫

云DBA知識體系構成

如何成為優秀的云DBA

一、管理模式的變化

對于數據庫技術而言，“云”已經成為大家無法忽視的技術趨勢。在Gartner 2018年的數據庫魔力四象限里面，云計算數據庫廠商已經占LEADERS及VISIONARIES領域的絕對比例，這也代表了業界對于云的認可。

那么，云和傳統架構有什么不同呢？對于傳統數據庫系統而言，需要搭建很多的硬件，連接很多的網線，在自己搭建的私有云里面可能會有一些虛擬化或者容器化的架構，再往上對于DBA而言其實需要的就是一個數據庫，需要能夠連接進去進行操作。當然了，在傳統架構下，DBA能夠對數據庫有更多的操作和配置，但是在云上可能只會提供一部分數據庫配置文件的修改權限，并不會允許修改全部配置，這是因為云為DBA提供的是SLA，也就是說云數據庫提供的是服務。針對于服務而言，不太可能允許DBA去對操作系統進行改變，因為這樣可能會破壞HA，因此會有一些限制，但是對于數據庫操作而言，依舊是通過一個端口就連接進去的。

除了數據庫架構設計之外，傳統架構和云架構在做安裝配置的時候也會有所不同。在傳統架構下，DBA需要去規劃數據庫所有的一切，包括操作系統、硬件以及各種安裝準備以及驗收、切換等一系列演練。在云架構之下，整體的配置、安裝以及部署是不需要DBA敲各種命令或者安裝各種業務系統的，操作系統、參數優化以及整體的HA只需要在云控制臺上點擊幾下就可以配置完成，無論使用阿里的公共云還是私有云都是這樣的狀態。這些就是在管理模式方面或者在系統創建過程中已經能夠看到的變化。

二、云數據庫VS.自建數據庫

有很多人存在這樣一個疑問。那就是“云數據庫和自建數據庫有哪些區別？”。這里首先澄清一個概念，在阿里巴巴看來，真正云托管的數據庫才是云數據庫，而如果只是使用ECS云服務器來自行搭建的數據庫并不算是真正的云數據庫。

實際上，云數據庫最終提供的是一個服務，其包括了系統的可靠性、可用性、安全、備份等一系列的東西，當建立完云數據庫這些都是配置完成的，無需DBA進行二次配置。當然，如果DBA有自己配置的需求，阿里云所提供的云數據庫服務也會提供API接口進行調配，或者也可以通過阿里云的管理平臺進行操作，而不像傳統情況下需要非常高的數據庫初始建設費用。

成本模式的變遷

對于成本而言，傳統情況下自己建設數據中心需要規劃好未來3到5年到底需要多少資源，所以成本是一次性提供的。此外，對于DBA而言，一般將其分為業務DBA和運維DBA，前者為數據庫業務解決問題，發揮功用，后者純粹地負責運維工作，比如安裝、部署、定期進行各種類型的巡檢。未來，運維DBA會因為云架構的體現慢慢地減少，而業務DBA卻不會消亡，因此DBA應該更加關注于企業在做什么業務，數據架構應該如何優化，幫助企業改變本身的運營狀態。

以往成本的開支，一下子就是一臺服務器，但是如今在云上或者互聯網上有很多的創業公司，所謂的“獨角獸”就是從很小規模開始起步，突然之間變成很大。當這些創業公司小的時候或許并不需要購買一臺服務器，通過云架構，就可以從很小開始，逐漸彈性上去，這樣的彈性能力使得IT實現資源的釋放。如果今天還在使用傳統的數據庫服務器購買方式，而競爭對手或許就能夠將節省下來的資金用于技術人員或者業務上去，因為沒有了固定資產初期的開銷，對于創業公司而言，其運行的資金鏈也會更加健康，發展的速度也會更快。

三、云DBA知識體系構成

隨著數據庫技術的發展，企業對于DBA的需求也不斷提高。從對于OLTP這樣的SQL數據庫和NoSQL數據的掌握，進一步演進，為了解決性能問題可能需要Key-Value緩存數據庫，之后建立OLAP數據倉庫，再之后實現大數據離線分析。

而對于初創公司而言，就會發現在最開始可能三兩臺機器就搞定了，只需要一個兼職的DBA。

進一步當開始使用Key-Value緩存數據庫之后，業務越來越重，單臺服務器無法搞定，需要實現HA。此時就比較困難了，因此需要一個比較神奇的DBA，需要DBA什么都懂。

當企業進一步發展到更大的時候，可能不僅僅需要解決一套系統的問題，可能需要解決多套系統的問題。此時可能需要一個DBA團隊，分工會變得更為細致，不僅有專業的DBA，還應該有頂尖的架構級別DBA來解決整體問題。

更進一步，可能需要做數據倉庫和大數據，那么整個DBA團隊的分工就會更加明細。

在企業的實際運行過程中，DBA需要做大量的工作，有的時候甚至是操作系統的各種細節都需要了解清楚才能將數據庫調優好。

云數據庫的理論基礎

而當進入云數據庫時代，需要看到的是另外一種景象。這里有一些云計算的新名詞，比如Region地域、AZ可用區、VPC以及VSwith等，這些都是云DBA需要了解和掌握的。從數據庫的角度來看，云數據庫的確出現了很多新名詞，但是數據庫基礎理論依然是不變的，依然會有實例、高可用、分布式、SQL、ACID和CAP等理論。

運維簡化：自動化部署

以往都會說需要部署一個主備集群，而今天如果想要部署主備集群也會在一個IDC中心進行部署。如果想要部署跨IDC的主備集群，在傳統架構下往往需要購買光纖、光纜，并且需要確定光纖、光纜的延遲情況，判斷其所造成的延遲是否能夠接受。而在云數據庫架構之下，這些信息都不需要進行管理，所需要管理的就是在購買云數據庫時進行選擇，比如選擇跨中心的主備就可以直接建立起來，因此這種復雜架構的構建并不需要自己來規劃，可以節省DBA去做傳統底層業務處理的時間。

運維簡化：跨地域部署及切換

除了對于傳統架構比較容易的同一個城市跨AZ之外，其實如果想要實現跨省就會變得非常復雜了。然而，在云上就會變得非常容易，如果想要實現跨Region的搭建就可以利用阿里云上的DTS工具將數據拉過去，需要進行數據復制的時候才會收費，平時不用的時候甚至可以直接將其關閉掉。

當搭建了跨Region的數據中心之后，后面就會有更多的事情。比如到底敢不敢進行主備切換，以往做主備切換的時候都需要配置一大堆的DNS，自己寫很多腳本做確認，而在云架構底下，只需要通過一個按鈕就可以實現。因此，大家一定要清楚，作為云DBA應該去學習哪些東西，同時需要放棄哪些東西的學習。因此當有云架構之后，DBA可以將重心放到學習如何優化SQL以及各種不同的數據庫特性以及它們之間的組合架構如何解決業務上的問題，而底層的業務架構可以交給云去做。

運維簡化：定期全/增量備份

在云上面，如果需要做定期增量備份也僅僅需要點擊幾個按鈕進行構建即可。

運維簡化：恢復到時間點

無論針對于哪個數據庫，阿里云的服務都可以做到任意時間點的秒級恢復。這一功能并不只是為了幫助用戶找回數據，很多用戶的DBA和開發的互動越來越頻繁，如果開發收到某個時間段系統運行較慢的反饋，就可以直接克隆一個那個時間段的新實例出來，并且只需要按需購買即可，克隆出來實例調試完程序之后直接將其關閉掉即可，一切的成本都在DBA的掌握之中。

運維簡化：按需橫向擴展

DBA對于數據庫的橫向擴展也會做很多動作，傳統的方式通過只讀實例可以做相應的擴展，同時還有像阿里云的DRDS分布式數據庫分片的運行方案，也能夠比較容易地搭建出來，進一步地還可以走向PolarDB，通過分布式的一寫多讀來簡化業務規則。未來，DBA需要重點關注的點在于什么時候使用什么樣的架構。舉例而言，如果需要解決某個大促時間段大量的讀請求問題，應該通過只讀實例來實現。而如果老舊業務完全可以基于互聯網改寫，就可以選擇直接通過DRDS做整個系統的分庫分表操作。如果需要非常強的與關系型數據庫一致性的業務，并且與此同時數據量非常大，可能需要選擇PolarDB的架構，因此DBA需要對于不同的數據庫架構以及其背后原理有自己的理解。

運維簡化：自動讀寫分離
阿里云數據庫幫助用戶實現了讀寫分離，DBA不需要再進行應用程序上的業務改寫，比如對于讀寫分離的設置都可以實現自動化。通過對于請求的分析來判斷應該分發到讀實例還是寫實例。

以上這些都是云數據庫能夠提供的能力，大家會發現以往的管理模型已經都覆蓋到了。未來運維方面的DBA工作可能減輕，因此DBA應該跳到業務方向上進行發展。

四、如何成為優秀的云DBA

在云數據庫的背景下，DBA是否還需要學習每一部分的數據庫管理知識呢？因為人的時間是有限的，未來除非真的要做類似于阿里云的整體管控系統時需要深入底層進行分析，而如果不是，那么這些數據庫管理就可以交給云管控平臺來實現。但是數據庫優化卻需要DBA知道和掌握，這里并不是指修改哪些參數能夠優化成什么樣子，因為這些在云平臺上就已經配置好了，但是DBA需要知道的是針對于某個數據庫，什么樣的索引對它更加有效，表與表之間的關系應該如何建立才能使得數據庫性能更好。

云數據庫提供了很多的集群架構，也并不一定需要全部學習。無論是單節點、雙節點還是三節點，通過阿里云都可以實現一鍵式部署。因此作為DBA更加需要了解不同的數據庫實例之間應該如何進行互動，從而產生對業務有效的架構方案和規劃方案，這正是DBA需要深入思考的，而不是每天都在備份服務器，部署數據庫，檢修各種硬件。

云服務支持邊界

基于云的運行環境，云數據庫服務和DBA的邊界會發生改變。資源調度、基礎優化、平臺能力以及準確輸出都是由云來提供的，而企業的DBA需要做這樣幾件事情：對于表結構需要花費更多的時間來規劃，定義自己企業的SQL標準來規范開發模型，對于SQL以及結構進行優化來提升業務性能。此外，DBA不僅應該關注于數據庫，實際上也應該做企業成本的控制，通過不同的數據模型組合來解決不同的業務問題，也需要了解云數據庫日志的不同，并通過故障檢測自查或者發起服務需求。

性能問題甄別

對于云DBA而言，如果出現了數據庫性能問題應該怎么做呢？其實任何的云廠商都會有自己成熟的一整套監控以及性能分析方案，比如阿里云的方案就源自于阿里巴巴內部的經驗，能夠幫助DBA發現故障并提供解決方案，使用起來非常方便。

云服務支持邊界

此外，阿里云也提供了一種能力，就是阿里云后端的DBA會幫助用戶解決數據庫相關的問題。以往情況下，如果數據庫出現了問題，需要打電話給服務商來約時間解決，存在一定的延遲。而今天在阿里云上面，DBA隨時可以進入。并且阿里云還提供了安全保障，具有完善的授權機制，只有用戶授權阿里云的DBA訪問用戶數據庫或者進行服務的時候，阿里云的DBA才有權限為用戶提供服務，而如果沒有得到授權，阿里云的DBA是不能夠進入的。

高危SQL預防

阿里巴巴具有自己的一整套數據庫開發規范，而用戶的DBA也可以自己定義一套數據庫開發規范，比如可以定義某一個字段是否可以以某種方式編寫，這樣就從系統設計和規范的層面避免爛SQL進入系統，進而造成系統故障。

跨云管理

今天，阿里云本身在運營云，而其實阿里云也會提供跨云的管理工具。無論用戶使用的是哪里的云，只要管理的是MySQL、MongoDB、Redis數據庫都會提供HDM工具來協助用戶管理跨云數據庫。

總結一下，云數據庫帶來了標準化部署、自動化運維、按需擴容以及工具化調優等優勢。對于企業而言，不要再讓DBA為部署和備份等瑣碎的運維工作所纏繞了，他們應該將精力投入到優化架構、寫好SQL以及做好數據庫的整體構造上，進而為企業輸出核心技術生產力。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的把握数据库发展趋势 DBA应如何避免“踩坑”?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。