把握資料庫發展趨勢 DBA應如何避免“踩坑”?
在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以及做好資料庫的整體構造上，進而為企業輸出核心技術生產力。
原文連結
本文為雲棲社群原創內容，未經