2019阿里雲峯會·上海開發者大會於7月24日盛大開幕，本次峯會與未來世界的開發者們分享開源大數據、IT基礎設施雲化、數據庫、雲原生、物聯網等領域的技術乾貨，共同探討前沿科技趨勢。本文整理自數據庫專場中阿里雲智能技術專家王天振 (爲知)的精彩演講，傳統數據庫研發模式不僅困難重重，並且效率低下，而基於DMS的企業級數據庫新型研發模式卻能夠做到研發高效，變更穩定和數據安全，本文就爲大家介紹阿里巴巴根據自身經驗沉澱下來的企業級數據庫新型研發模式。
數據庫專場PPT下載
本文內容整理自演講視頻以及PPT。
本次分享的內容是企業級數據庫新型研發模式，這種研發模式在阿里巴巴集團內部已經應用了將近十年的時間。阿里巴巴內部有大約數十萬的研發人員，而這數十萬研發人員每天都會產生很多數據庫變更、查詢以及數據導出的需求。而在阿里內部，僅通過兩位數的DBA就能夠滿足數十萬研發人員全部的數據庫操作需求，這背後所依靠的正是企業級數據庫新型研發模式。
本次分享將主要圍繞以下三個方面：
一、雲時代數據庫的研發挑戰
二、新型研發模式概述
三、數據管理DMS最佳實踐
一、雲時代數據庫的研發挑戰
數據庫研發的全生命週期
數據庫研發的全生命週期如下圖所示。這裏的數據庫研發指的是一款產品在其創作與迭代過程中，研發人員所需要參與的涉及到數據庫的相關工作，這些工作就叫做數據庫研發。數據庫研發的全生命週期主要劃分成了7個部分，分別是實例管理、權限管控、表結構設計、數據階段、SQL查詢、SQL審覈以及性能診斷&優化，這些都需要研發人員、DBA、運維人員以及項目的負責人蔘與進來。
傳統數據庫研發面臨的挑戰
傳統數據庫研發方式需要面對三個主要的挑戰，即研發效低、數據安全無保障、變更風險大。
研發效率低：傳統數據庫研發模式下，研發人員、運維人員甚至測試人員等產品中涉及到的所有相關人員可能都需要接觸數據庫，在這個過程中需要與DBA進行溝通，比如研發人員告知DBA今晚8點想要發佈一個表結構。然而，在晚上8點的時候可能突然出現了業務高峯，就需要取消表結構的發佈，這樣的過程需要研發人員與DBA以及項目Leader反覆溝通，使得溝通成本變得非常高。此外，這種方式也使得研發規範難以落實，研發規範往往是根據DBA的經驗總結而成的，可能推薦了主鍵的使用方式以及索引和列的類型等。但是，由於研發人員的能力參差不齊，想要讓整個研發團隊的全體成員都能夠遵守研發規範，往往很難落實。如果通過文本或者培訓來落實，不僅成本比較高，而且難度也比較大。而且多環境研發也是一個難題。對於產品研發而言，可能有測試環境、開發環境，如果處在金融領域，可能有更加複雜的環境。針對不同的環境，研發方式也各有不同，如果還是需要和人進行溝通，就會使得溝通成本、研發時間以及功能上線時間都無法控制，進而造成研發效率的低下。
數據安全無保障：傳統數據庫研發模式下，DBA會給研發人員一個數據庫賬號，或者團隊共用一個賬號。這些賬號可以實時地獲取數據庫信息，如果數據庫中存儲了業務敏感信息，還有可能在不知情的情況下發生信息泄露。而傳統數據庫研發模式下，往往沒有審計或者審計比較弱，研發人員到底查了多少條數據，返回了哪些數據，DBA可能也不清楚。此外，當有人員離職或者轉崗的時候，對於數據庫賬號的處理問題，都是數據安全需要考慮的範圍。
變更風險大：首先，表結構變更鎖表會影響業務，比如在傳統數據庫研發中做了一個DDL，直接把線上的IOPS打上去了或者直接鎖表，使得業務無法讀取數據。這種情況下，如果比較嚴重就會造成故障，如果不嚴重可能使得業務出現抖動。其次，變更誤操作無法實現快速恢復，本來只需要更新10條數據，但是遺漏了WHERE條件就將全部的數據都修改了，這樣該怎麼辦？最後，業務高峯期的變更更加難以防範，研發人員提出在8點進行變更，而DBA可能因爲負責多條業務線不清楚每條業務線的高峯期，而在8點做變更時遇到業務高峯期，產生了故障。因此，如何從研發層面攔截高峯期的變更也都是傳統數據庫研發模式所需要面對的挑戰。
二、新型研發模式概述
阿里巴巴擁有數十萬的研發人員，如果不去解決在數據庫研發生命週期中的這三個問題，就會使得業務受到嚴重受影響。因此，阿里巴巴在使用DMS的過程中，提出了一種新型的數據庫研發模式。阿里巴巴所提出的新型數據庫研發模式需要多種角色參與進來，技術負責人需要把控所有數據庫，可能由CTO或者數據庫團隊的Leader承擔；還有就是DBA或者運維人員；再有安全管理人員，最後還有產品研發團隊的成員。
數據庫新型研發模式主要分爲兩個階段。第一階段從技術負責人開始，會先把DBA、業務Leader以及研發等的角色劃分出來，並且制定安全規則，比如每個人能查多少數據，每天可以查多少次，以及變更時間範圍等，還需要進行資源採購，這些就是技術負責人需要做的事情。DBA和運維人員需要制定一些規範，比如每個表裏面不能超過幾個索引，必須有什麼樣的主鍵和UK，表名或者列名必須要加有什麼樣的業務屬性等。此外，還需要設置一定的變更規範，比如幾點可以變更，同時可以變更幾張表，以及表的大小限制等，這些規範都需要由DBA來落實。下一個步驟就到研發、測試和運營人員了，此時資源、規範以及業務線都已經準備好了，所需要做的就是申請數據庫的權限，進而執行數據查詢、導出以及對於表結構的變更和性能的查詢等，這些研發人員常用的需求在研發流程中都可以實現全自助。
在第二階段，研發人員發起一個申請工單提交上去，DMS會將DBA的經驗和建議提供給研發人員，幫助研發人員優化自身的SQL。如果因爲某些原因或者需求必須要違背一定的規範，就需要上升到另外一級進行審批把控。在這個部分，DMS會將風險收集起來提供給審批人，而整個審批過程可以實現自定義，也就是說企業可以根據自身的業務屬性決定誰來審批。審批把控通過之後，則直接由發起人進行SQL的落地執行。最後一點就是全局風險掌控，技術負責人可以在產品裏面查看今天業務被查詢了多少次，有幾個張表發生了變更，業務增長情況如何，哪些人員查詢了哪些庫，返回了多少數據，並且可以看到一些數據庫風險報告和數據安全報告，包括安全管理人員提供的數據審計報告，這大致就是整個新型數據庫研發流程。
三、數據管理DMS最佳實踐
數據管理DMS簡介
下圖基本上展示了DMS的整個能力範圍，其下層支持了二十多種的數據源接入，並且能夠進行統一的管理。DMS上層提供了非常豐富的功能供研發使用，基本上不需要DBA參與中間過程，而只需要做把控就好了。在風險把控之外需要進行審批的，纔會上升到上一級，而不需要風險上升的只需要進行審計即可。DMS通過研發規範、權限控制、操作攔截以及數據脫敏、變更回滾等功能，保證了數據安全，並且提升研發效率。
安全與效率:權限管控
接下來從幾個場景來介紹數據管理DMS最佳實踐。第一個場景就是權限管控。簡單而言，創建一個新的業務，這個業務涉及到新的數據庫，這種情況下，運營、開發、測試、審計以及實習生等都需要擁有查詢數據庫的權限。因此就需要給與他們一個賬號，傳統數據庫研發模式中，都是找DBA進行溝通或者爲團隊提供一個通用賬號。如果和DBA進行溝通，DBA還需要根據具體的需求在郵件裏面寫清楚爲研發人員申請了什麼賬號，並且需要去數據庫實例上爲用戶賦予相應的權限，整個流程很複雜，溝通成本也很高。
如上圖所示，傳統的數據庫研發模式有幾個缺點。首先，DBA進行賬號授權，僅僅是數據庫層面的操作，而無法打通企業的組織架構，DBA並不清楚賬號的真實使用者是誰，只能認爲記錄下來是誰就是誰。其次，還有多庫多賬號問題。DBA手中可能管理了10個實例和200個數據庫，這些實例和庫甚至到表級別都需要細分下來進行整理，這個過程中授權數量非常龐大，實例數和機器的數量也很多。第三點，溝通效率低，並且運維成本高。第四點就是SQL查詢和執行記錄的審計比較困難，數據庫本身的審計能力基本爲零，可能DBA只能看到SQL執行了，但是並不能看到SQL影響了多少行數據以及具體造成了什麼影響，也無法知道具體是誰執行的。此外，在傳統的數據庫研發模式下，可能因爲上述與DBA溝通的方式過於繁瑣和困難，因此一些企業或者團隊乾脆使用通用賬號，這就會帶來安全上的問題等。以上這些是現有的場景，也是所需要面對的挑戰。
而在企業DMS中，則爲數據庫和人員構建了新的授權管理體系，即DMS統一授權管理體系。此時，數據庫只需要將權限授予DMS，而DMS可以再將權限進一步授權給研發、運維等人員。相關的人員只需要在DMS中輸入所需要申請哪個庫的哪種類型的權限（可以細化爲查詢、導出以及變更三種類型），申請時間爲多久等信息即可。並且不同於數據庫權限僅能限制到表級別，DMS授予的權限可以細化到列級別。對於敏感列的數據而言，可能查詢出來就直接是脫敏之後的數據了。當相關人員輸入完上述信息，提交申請，如果所申請的是非核心數據庫的權限，直接到研發Leader或者DBA審批完成就可以獲得了，如果出現人員離職或者過期等情況，數據庫權限都可以實現自動回收。這樣不僅能夠解決傳統授權方式所帶來的一些問題，還能夠使得效率大大提升，並且需要參與的人員也更少。
常規的數據查詢需求有風險嗎?
這裏有一個問題，就是常規的數據查詢需求有風險嗎？比如研發人員說他要排查線上的問題，運維人員說他要查過去一年的業務數據，如果處在金融場景的話，大部分企業可能都不會給這些人員真正的數據庫賬號，因此面對這樣的需求就會落到兩種解決方案上。
第一種方案是集中式管控，對於這種方案而言，責任就落到了DBA身上，讓DBA幫研發和運維人員查詢業務數據。另外一種方案就是鬆散式管控，也就是讓研發人員直接到數據庫上進行查詢。但是這兩種方案都會帶來一些問題，如果使用集中式管控，作爲DBA而言，可能各個業務團隊都有各種各樣的需求，而自身的工作能力是有限的，每天所能做的也就只是幾十次查詢，並且面對這些需求，對於DBA自身而言，也不會得到任何成長。而且這些需求也都是機械化的，並且還存在DBA的單點瓶頸，往來郵件的溝通成本非常高。而如果使用鬆散式管控，研發人員拿着一個賬號到數據庫上隨便查，這就可能因爲任意的查詢導致數據泄露，也可能因爲輸入了爛SQL將數據庫打掛或者將業務搞垮，也有可能因爲誤操作將數據弄錯了，這些風險可能會導致業務產品的迭代速度不可控。而無論對於研發Leader還是DBA而言，都需要儘量避免這些風險。
安全與效率:數據查詢
那麼，在DMS中是如何避免上述風險的呢？DMS提供了可控的SQL查詢操作，其包含了全局權限管控、風險識別、數據脫敏、操作審計以及安全規則引擎等。對於前面所提到的場景而言，研發、測試、運營發起一條SQL查詢之後，過程中會有三個攔截點，第一個攔截點是權限檢查，其會判斷是所執行的SQL語句否有相應數據庫和數據表的權限，進一步細化地判斷所查詢的機器是否是可授權的。DMS還會提供一些智能提示，並且能夠提供歷史SQL的保存、模板SQL以及格式化等功能。通過了第一個檢查點說明用戶本人的權限以及查詢SQL的權限沒有問題。
第二個檢查點會執行風險預警，也就是判斷用戶所發起的這條SQL是否存在風險，是否需要針對該條SQL實現主備分離，進而到備庫上去執行查詢。這部分還會生成執行計劃，來判斷該條SQL造成的影響是否會遠大於預期。如果預期的影響會遠大於預期，那麼執行計劃就會被攔截掉。
第三個檢查點會對於高風險語句進行攔截，比如在DBA設置的規範裏面不允許用戶直接執行沒有WHERE條件的SQL語句，可以直接攔截掉存在較高風險的SQL語句。在第三個檢查點還可以進行執行人限流，比如某人在一天之內已經查詢了兩萬條數據，如果他還需要繼續查詢就可能存在安全問題，因此也會對其請求進行攔截。
當風控引擎執行完成之後，DMS就認爲這條SQL可以丟到數據庫裏面執行，但這條SQL不一定就是安全的。爲了保證數據庫的安全和穩定，也需要一定的策略。比如設置超時機制，比如一條SQL只能執行60秒，超時自動中斷，這樣可以避免單條SQL執行超過60秒，進而產生不可控的影響。第二個策略就是使用全局連接池，可以避免DMS創建過多的連接。第三個策略就是限制結果行數，用戶一條SQL執行查詢，可能會返回幾萬條數據，但是這樣的數據量可能並不是他所預期的，用戶可能只想看一下這張表裏面有沒有數據，因此可以限制查詢結果的行數。此外，DMS還可以做實例性能實時探測，能夠實時地顯示在某條SQL在執行的過程中數據庫實例的性能表現。實例性能降低可能是因爲SQL影響，也可能是因爲正處於業務高峯期，而通過實例探測來發現異常，就可以實時中斷掉SQL的執行。
當結果查詢返回之後，還會存在一個攔截點，就是對結果風險的預警。數據返回之後需要進行數據安全上的檢查，分析返回的數據裏面是否存在敏感數據，如果存在，還需要對於敏感數據進行脫敏。此外，DMS還會分析某條SQL語句執行完成之後，影響了多少行數據，查出了多少行數據以及哪些列，並對於這些數據進行真實的審計。除了數據審計之外，DMS還會進行業務審計以及操作審計，也就是用戶發起的SQL是什麼，造成的影響如何都會審計下來。
DMS還擁有一個全局的安全規則引擎，整個過程中要不要做主備分流，執行語句的檢查粒度如何，比如執行計劃所需要攔截的閾值、高風險語句等都是在安全規則管控引擎裏面設置的。安全管控引擎進行攔截所依賴的經驗來自於DBA和實際的業務，不同的企業或者不同的團隊都可以在安全管控引擎上自己定義相應的經驗。經過了上述的各個步驟，數據查詢的整個過程就完成了，並將最終結果展示給了用戶，並且提前避掉了之前傳統數據庫研發模式所面臨的風險。
表結構變更要很小心!
在進行表結構變更時需要很小心。以一個具體的場景作爲例子，一個核心業務表負責的是24小時在線業務，這個表非常大並且沒有業務低峯期。在這種場景之下，研發同學要執行一個DDL，根據經驗來說，這樣一定會造成很高的IOPS，還會造成業務抖動。那麼，如何避免這樣的問題呢？此外，可能還會有其他的問題，比如業務同學說表的主鍵是int類型，而因爲數據量急速增長，馬上就要超出int類型所能表示的範圍了，再跑就查不到數據了，業務就會出現故障，此時該怎麼辦？對於這樣數據量又大，流量又高的數據表，在DMS中如何避免因爲表結構變更而造成的問題呢？
之所以造成上述問題，主要存在兩個原因，一者是這張表的主鍵使用了int類型，以爲一般而言應該使用bigint類型，二者需要考慮如何對於這樣的表做DDL而不影響業務。
安全與效率:表結構設計
那麼DMS是如何實現高效研發流程中的表結構設計的呢？首先，研發人員需要提交一個對於某張表進行變更的工單，而在表的設計階段則存在一些約束，比如索引、列以及命名的規範等，像上述場景中使用int作爲主鍵的數據類型在這個階段就會被攔截掉，必須要使用bigint作爲主鍵的類型。此外，在設計階段也可能存在這樣一種情況，同一個研發團隊的兩個人合作實現一個業務需求，每個人都需要做一個DDL，可能涉及到一張表，也可能是兩張表，如果是兩張表還可能存在業務交叉。這種情況下，在表結構設計中會強制他們參與到一個工單裏面進行協作，也就是進行表字段級別的協作。需要他們有一致的設計副本，發佈時間也要求必須一致，這樣才能跟上功能迭代的速度。設計階段完成以後，研發人員可以認爲現在設計的副本已經完成了，測試環節也驗證通過了，接下來可以發佈到線上去。而在發佈過程中不可避免地會出現業務需求的變動，或者領導認爲設計不合理等情況，此時就可以實現回退撤銷，並進行重新設計，這些都是在設計階段可以做的事情。
當確認表格設計沒有問題就到了發佈階段，這個階段需要爲TL或者DBA提供一些決策信息來判斷髮布是否合理。DMS會將一些風險數據，比如這張表有多大，有多少個索引，將會做什麼操作，會對數據庫造成什麼影響等收集起來並彙總給審批人，由審批人決定是否可以執行。即便研發人員因爲技術能力不夠，或者在提交表結構設計時沒有充分地考慮各種場景，在審批階段DBA或者TL都可以拒絕掉髮布請求。
發佈完成以後，就到了執行階段。在執行階段並不能保證一定是安全的，而DMS裏面有幾個策略能夠降低變更風險，比如保證所有變更都是不鎖表的，像前面提到了主鍵從int變爲bigint在MySQL中一定是鎖表的，而在DMS裏面提供了無鎖表結構變更功能，其能夠保證覆蓋到原生DDL覆蓋不到的地方，這樣不僅能夠保證表在變更時對業務不會產生影響，還能保證對於IOPS也不會產生影響。第二個策略就是DDL併發控制，DDL在執行過程中，可能會使得多條SQL在執行過程中會產生衝突，而在DMS裏面可以設併發控制，來設置在一個庫上或者一個實例上最多有幾條SQL同時執行，以此避免衝突。此外，還有鎖等待檢測功能，比如業務上有一個大的Update， DDL發上去之後，導致業務全部停止了，就會造成故障，而DMS會提供一個鎖等待來檢查現在的表上是否有鎖，如果幾秒鐘都等不到就放棄更新，以此來避免風險。此外的實例性能探測、變更中斷策略也都是爲了不影響業務。最終，表的變更就執行結束了。
在表結構設計方面，DMS同樣也提供了一個安全規則引擎，可以設置一定的閾值，設置哪些點開啓，哪些點關閉，這些都可以由DBA進行操作。
安全與效率:數據變更
數據變更的需求十分常見，比如往往需要更新、插入或者刪除一些業務數據，就需要實現數據變更。在傳統的數據庫研發模式下，需要提交一條SQL，之後還需要經過TL、DBA的層層審批，可能幾個小時甚至一兩天就過去了。
傳統數據庫研發模式下，實現數據變更的過程耗時比較久，而且最終還是需要DBA來執行。而DBA一天大約只能處理20個工單，這種方式使得溝通成本很高，也容易引發故障。而在DMS中，所有的工單都可以由研發人員自助提交，而DMS可以根據內置的DBA經驗進行風險決策，判斷是否需要上升到TL甚至DBA層級來確認。如果不需要上升風險等級，大約5分鐘左右就可以完成自動審批，之後研發人員直接執行SQL即可，完全不需要其他人員的參與，相比於原來的模式極大地提升了效率。
更多的功能
除了上述所分享的功能之外，DMS還提供了很多其他的功能。DMS在AnalyticDB、POLARDB、RDS for MySQL中都作爲工具進行了輸出。總體而言，DMS能夠幫助數據庫研發流程做到研發高效、變更穩定以及數據安全。在研發高效層面，DMS能夠提供高效的研發流程、全局的數據庫管理、便捷的數據查詢、易用的數據分析以及通暢的數據庫觸達；在變更穩定層面，DMS能夠提供智能的SQL風險審覈、不鎖表結構變更、不鎖表數據變更、可靠的SQL執行以及精準的數據回滾；在數據安全層面，DMS能夠提供統一的授權管理、可控的數據查詢、智能的數據脫敏、精確的操作審計以及定製的安全規則。
DMS實踐下的全生命週期
如下圖所示的是DMS實踐下的全生命週期。DMS能夠支持數據庫研發的全生命週期的各個部分，在混合雲實例管理方面，可以用戶通過DMS購買雲實例、同步混合雲實例並且
創建新數據庫。在分級權限管控方面，通過DMS可以設置變更、導出、查詢權限，可以針對庫、表、敏感列設置權限，並且能夠做到統一授權管理和個人賬號綁定。在表結構設計方面，DMS能夠幫助MySQL、PolarDB、DRDS、Oceanbase等數據庫設計表結構，並且能夠實現多套環境發佈、實現不鎖表的表結構變更以及變更窗口管控。在數據方案方面，DMS能夠實現不鎖表數據變更、歷史數據清理以及對於數據的訂正和導入、導出。在SQL查詢方面，DMS能夠實現數據脫敏、影響行數提醒、可控數據查詢、跨庫查詢以及數據分析。在SQL審覈方面，DMS實現了應用代碼審覈、SQL文本和規範約束檢查以及索引推薦。在性能診斷&優化方面，DMS能夠預測空間和性能的變化趨勢，進行SQL診斷優化，並且分析會話和實時性能。
本文作者：遊客be77vkb76molw
本文爲雲棲社區原創內容，未經允許不得轉載。