企業級數據庫新型研發模式——數據管理DMS實踐

2019阿里雲峯會·上海開發者大會於7月24日盛大開幕，本次峯會與將來世界的開發者們分享開源大數據、IT基礎設施雲化、數據庫、雲原生、物聯網等領域的技術乾貨，共同探討前沿科技趨勢。本文整理自數據庫專場中阿里雲智能技術專家王天振 (爲知)的精彩演講，傳統數據庫研發模式不只困難重重，而且效率低下，而基於DMS的企業級數據庫新型研發模式卻可以作到研發高效，變動穩定和數據安全，本文就爲你們介紹阿里巴巴根據自身經驗沉澱下來的企業級數據庫新型研發模式。

數據庫專場PPT下載

本文內容整理自演講視頻以及PPT。

本次分享的內容是企業級數據庫新型研發模式，這種研發模式在阿里巴巴集團內部已經應用了將近十年的時間。阿里巴巴內部有大約數十萬的研發人員，而這數十萬研發人員天天都會產生不少數據庫變動、查詢以及數據導出的需求。而在阿里內部，僅經過兩位數的DBA就可以知足數十萬研發人員所有的數據庫操做需求，這背後所依靠的正是企業級數據庫新型研發模式。

本次分享將主要圍繞如下三個方面：
1、雲時代數據庫的研發挑戰
2、新型研發模式概述
3、數據管理DMS最佳實踐

1、雲時代數據庫的研發挑戰

數據庫研發的全生命週期
數據庫研發的全生命週期以下圖所示。這裏的數據庫研發指的是一款產品在其創做與迭代過程當中，研發人員所須要參與的涉及到數據庫的相關工做，這些工做就叫作數據庫研發。數據庫研發的全生命週期主要劃分紅了7個部分，分別是實例管理、權限管控、表結構設計、數據階段、SQL查詢、SQL審覈以及性能診斷&優化，這些都須要研發人員、DBA、運維人員以及項目的負責人蔘與進來。

傳統數據庫研發面臨的挑戰

傳統數據庫研發方式須要面對三個主要的挑戰，即研發效低、數據安全無保障、變動風險大。

研發效率低：傳統數據庫研發模式下，研發人員、運維人員甚至測試人員等產品中涉及到的全部相關人員可能都須要接觸數據庫，在這個過程當中須要與DBA進行溝通，好比研發人員告知DBA今晚8點想要發佈一個表結構。然而，在晚上8點的時候可能忽然出現了業務高峯，就須要取消表結構的發佈，這樣的過程須要研發人員與DBA以及項目Leader反覆溝通，使得溝通成本變得很是高。此外，這種方式也使得研發規範難以落實，研發規範每每是根據DBA的經驗總結而成的，可能推薦了主鍵的使用方式以及索引和列的類型等。可是，因爲研發人員的能力良莠不齊，想要讓整個研發團隊的全體成員都可以遵照研發規範，每每很難落實。若是經過文本或者培訓來落實，不只成本比較高，並且難度也比較大。並且多環境研發也是一個難題。對於產品研發而言，可能有測試環境、開發環境，若是處在金融領域，可能有更加複雜的環境。針對不一樣的環境，研發方式也各有不一樣，若是仍是須要和人進行溝通，就會使得溝通成本、研發時間以及功能上線時間都沒法控制，進而形成研發效率的低下。
數據安全無保障：傳統數據庫研發模式下，DBA會給研發人員一個數據庫帳號，或者團隊共用一個帳號。這些帳號能夠實時地獲取數據庫信息，若是數據庫中存儲了業務敏感信息，還有可能在不知情的狀況下發生信息泄露。而傳統數據庫研發模式下，每每沒有審計或者審計比較弱，研發人員到底查了多少條數據，返回了哪些數據，DBA可能也不清楚。此外，當有人員離職或者轉崗的時候，對於數據庫帳號的處理問題，都是數據安全須要考慮的範圍。
變動風險大：首先，表結構變動鎖表會影響業務，好比在傳統數據庫研發中作了一個DDL，直接把線上的IOPS打上去了或者直接鎖表，使得業務沒法讀取數據。這種狀況下，若是比較嚴重就會形成故障，若是不嚴重可能使得業務出現抖動。其次，變動誤操做沒法實現快速恢復，原本只須要更新10條數據，可是遺漏了WHERE條件就將所有的數據都修改了，這樣該怎麼辦？最後，業務高峯期的變動更加難以防範，研發人員提出在8點進行變動，而DBA可能由於負責多條業務線不清楚每條業務線的高峯期，而在8點作變動時遇到業務高峯期，產生了故障。所以，如何從研發層面攔截高峯期的變動也都是傳統數據庫研發模式所須要面對的挑戰。

2、新型研發模式概述

阿里巴巴擁有數十萬的研發人員，若是不去解決在數據庫研發生命週期中的這三個問題，就會使得業務受到嚴重受影響。所以，阿里巴巴在使用DMS的過程當中，提出了一種新型的數據庫研發模式。阿里巴巴所提出的新型數據庫研發模式須要多種角色參與進來，技術負責人須要把控全部數據庫，可能由CTO或者數據庫團隊的Leader承擔；還有就是DBA或者運維人員；再有安全管理人員，最後還有產品研發團隊的成員。

數據庫新型研發模式主要分爲兩個階段。第一階段從技術負責人開始，會先把DBA、業務Leader以及研發等的角色劃分出來，而且制定安全規則，好比每一個人能查多少數據，天天能夠查多少次，以及變動時間範圍等，還須要進行資源採購，這些就是技術負責人須要作的事情。DBA和運維人員須要制定一些規範，好比每一個表裏面不能超過幾個索引，必須有什麼樣的主鍵和UK，表名或者列名必需要加有什麼樣的業務屬性等。此外，還須要設置必定的變動規範，好比幾點能夠變動，同時能夠變動幾張表，以及表的大小限制等，這些規範都須要由DBA來落實。下一個步驟就到研發、測試和運營人員了，此時資源、規範以及業務線都已經準備好了，所須要作的就是申請數據庫的權限，進而執行數據查詢、導出以及對於表結構的變動和性能的查詢等，這些研發人員經常使用的需求在研發流程中均可以實現全自助。

在第二階段，研發人員發起一個申請工單提交上去，DMS會將DBA的經驗和建議提供給研發人員，幫助研發人員優化自身的SQL。若是由於某些緣由或者需求必需要違背必定的規範，就須要上升到另一級進行審批把控。在這個部分，DMS會將風險收集起來提供給審批人，而整個審批過程能夠實現自定義，也就是說企業能夠根據自身的業務屬性決定誰來審批。審批把控經過以後，則直接由發起人進行SQL的落地執行。最後一點就是全局風險掌控，技術負責人能夠在產品裏面查看今天業務被查詢了多少次，有幾個張表發生了變動，業務增加狀況如何，哪些人員查詢了哪些庫，返回了多少數據，而且能夠看到一些數據庫風險報告和數據安全報告，包括安全管理人員提供的數據審計報告，這大體就是整個新型數據庫研發流程。

3、數據管理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診斷優化，而且分析會話和實時性能。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。