文 / 阿裡雲資料庫進階解決方案架構師王林平
摘要：在第十三屆中國資料庫技術大會（DTCC 2022）上，阿裡雲資料庫進階解決方案架構師王林平從上雲路徑、雲上資料庫使用實踐及使用進階等方案深入介紹了阿裡雲一站式資料庫上雲最佳實踐。
本文内容根據演講錄音以及PPT整理而成。
随着網際網路的持續快速發展，雲計算已經成為 IT 主流的基礎設施提供方式。雲計算支撐了城市大腦、冬奧會、天貓、淘寶、優酷等，與每一個人的生活息息相關。
阿裡集團的很多企業都已經将 IT 基礎設施搬到雲上，雲計算在國内得到了蓬勃發展，為企業帶來快捷的能力，實作了增效。
01 上雲路徑
DTS是幫助上雲的有力工具。它孵化自阿裡巴巴内部，最初被稱為DRC，用于做内部資料流轉，包括單元化、雙活、多活。2015-2016年，集團業務要上雲，面臨了一系列的問題，比如資料怎麼上雲、混合雲怎麼做災備和雙活等，怎麼分析上雲。為了解決問題，阿裡決定将 DRC 進行商業化，同時在雲上為企業客戶提供了豐富的能力。
技術上，DTS在某些方已經領先于國内外的友商，比如事務沖突、熱點模型的合并、網絡帶寬的優化、資料校驗、雙向複制等，擁有企業客戶10萬+。
上圖左側是某電商客戶搬站上雲的路徑，右側是實時分析。
該電商客戶希望将業務、會員、商城、購物車、計費系統、推薦算法等系統從 IDC 搬到雲上。在 IDC 使用的主要為MySQL、MongoDB、Redis，雲上提供了RDS、MySQL、MongoDB、PR 持久記憶體（自研的緩存），也有雲 Redis，可與 Redis 完全相容。整個上雲過程可以通過 DTS 實作資料的複制。
上圖可見上雲過程中存在兩條線，綠色線是雙向複制。目前從開源的 MongoDB、Redis 複制到雲上的MongoDB、Redis 依然是單向複制，而MySQL 支援雙向複制的，可以基于雙向複制建構無縫的切換方案。
比如某客戶的核心業務系統在 MySQL 上，客戶不希望 MySQL 在過程中有過多停機。我們為其建構了平滑的資料庫遷移上雲方案，通過全量和增量複制，将 IDC 機房的資料庫連到雲上的機房，得益于同城，其延遲較低。同時，在MySQL、 MongoDB和 Redis 上雲的過程中提供了資料一緻性的校驗。
同時，我們對網絡提供了較好的支援。得益于雙向同步，可以實作秒級、分鐘級的復原。雲上業務打開之後，MySQL依然可以回流到 IDC 繼續做複制。雲上業務正常後，可将 DTS 鍊路暫停。如果在觀察期發現業務出現問題，RDS、 MySQL 回流到IDC的 MySQL 鍊路依然存在，同時也可以支援過程中的DML，業務發現問題之後可以切回IDC。
總結來說，我們提供了資料平滑上雲的能力，也提供了復原能力，基于 MySQL 的鍊路可以實作秒級到分鐘級的復原和切換。
實時分析上雲方面，我們提供了與 MySQL 相容的實時分析資料庫ADB，經由 DTS 可以将 MySQL 資料庫的資料通過走專線、公網、 VPN 的方式同步到 ADB 做實時分析。
比如某客戶的業務裡有相對敏感的資訊，如果全部上雲，會面臨資料洩露風險與監管壓力。經過與客戶的溝通，最後我們決定将一部分不涉及敏感資訊的報表、資料分析等上雲，通過雲上的商業化、實時的分析引擎為業務提速。通過專線的方式走DTS，将多個業務庫的資料同步到 ADB ，在 ADB 上做資料分析。ADB 也支援通過SQL或定時任務的 ETL 對資料做處理，處理完後的資料還可通過專線再回流到IDC。
DTS雙向複制時，資料庫從 a 複制到b，複制過的資料再回環複制，會導緻一份資料雙寫，造成資料混亂。是以，我們實作了防循環寫，可以支援 MySQL 的雙向同步。同時也支援通過DTS将 Redis 和 MongoDB 同步到雲上做災備。DTS 目前與 Hbase 的耦合尚不成熟，是以雲上提供了 LTS 雙向複制的産品化能力，可以将 Hbase 同步到寬表裡做災備。
雲資料庫災備能夠為企業客戶提供資料備份的能力且延遲極低，網絡正常以及沒有其他阻礙的情況下可達秒級延遲。由于業務沒有做雙活，依然在IDC，是以RTO較長。假設IDC出現了網絡異常、自然災害等問題，會保留一份資料，業務需要在再建構一份業務伺服器以及相關的資源進而保證業務可恢複。
有了災備，還需要建構雙活。
某客戶希望 IDC 到雲上能夠支援雙活，需要在雲上再建構一份業務的服務，業務服務與 IDC 完全對等。資源出現異常後，可以将流量從 DTS 切到雲上。資料庫和應用伺服器都可以快速彈升，如果企業客戶使用了K8s，彈性能力會更好。
部分企業客戶存在備份低成本上雲的需求。傳統的方式大多為自己建構一個資料庫，将備份存儲到自己建構的伺服器上，過程中會涉及備份是否備援；如果沒有備援，是否需要選擇分布式存儲等。
而DTS能夠為備份提供低成本的上雲方案，同時它支援壓縮、加密、流控，可以保證資料上雲、備份上雲的安全性。它也可以将資料恢複給雲上的資料庫執行個體，若出現異常情況時可以将資料恢複，快速驗證備份是否可用。過程中提供了低成本的存儲，甚至未來可能會對接到自有存儲，能夠實作非常靈活的備份上雲和恢複。
02 雲上資料庫使用實踐
随着資料庫的量和研發人員越來越多，而DBA 人不夠多，無法随時支撐研發時，可能會影響工作。如果對研發人員管理的能力和權限放大，可能會出現資料安全性、可靠性和穩定性出現問題。
通過資料管理，可以為研發提效，也提高資料安全和效率。
首先，可以做資料資産管理，執行個體、資料庫和資料都可以通過 DMS 實作資料采集、安全管控、快速查找以及資料安全，資料安全包括脫敏、水印追溯等手段。
其次，對研發、技術團隊使用資料庫的過程做流程化的管理和規則。比如研發人員a希望将某主管owner的資料庫做變更。傳統的方式需要先找DBA， DBA 擷取到 DML 或DDL變更，上線之後再由 DBA 确認然後才會執行SQL，效率較低。
而如果使用 DMS ，則流程的效率可以得到大幅提高：研發人員a的權限為可以檢視，無法更新。發起流程的過程中會有安全規則攔截。研發人員a發起流程之後會發往主管審批，主管确認後發往 DBA 審批，可以由DMS 自動完成審批确認，确認後走 DMS 任務，版主研發完成本次 SQL 變更或DDL。
以上過程包含了SQL稽核、表結構設計規範，同時在 DMS 上提供了無鎖變更、研發規範、異常變更復原、變更優化等能力。
DMS 為研發和 DBA 提供了橋梁和平台。DBA的一些日常比較瑣碎但是又必須做的工作，可以通過流程化和規則的方式為研發提效。未來，我們将着眼于資産的治理、安全的體系化、邏輯數倉的建設以及場景化的方案等。
在雲上使用雲資料庫時，還需要做問題診斷和優化。DMS能夠做自動/半自動/人工的問題發現，可以通過監控、DAS的性能趨勢、巡檢、異常檢測、性能診斷、空間分析來發現問題。發現問題之後，提供了 DAS的診斷分析、會話管理、慢查詢、洞察和審計等進行問題的診斷。比如發現某個表沒有索引，DAS會給出索引建議。
如果是疑難雜症，則會轉交由阿裡雲的專家進行診斷。其他大部分問題可由DAS進行修複及優化，比如自動的 SQL 優化索引建立、限流等。如果性能診斷優化已經達到極緻，可能需要做擴縮容。雲資料庫擁有優秀的彈性能力，擴縮容十分平滑，尤其是PolarDB，可實作分鐘級的擴縮容。
未來，我們計劃在DAS上實作自發現、自優化、自修複的全面能力。
另外，我們正在從DAS入手建構批量的智能運維能力，包括執行個體監控、執行個體盯屏、異常發現、自動優化、自動修複、容量評估、安全審計。最近上線了複制延遲、OOM自修複、SQL Review輔助，未來也會提供異常根因分析、自動優化增強、自動修複、增強記憶體報警等能力。
自動SQL限流的流程如下：首先，會進行異常檢測，然後通過機器學習的能力擷取到全量SQL（目前僅支援雲資料庫，不支援IDC或雲上自建SQL），再進行根因分析、特征提取，如果發現該條SQL與某一類 SQL 比較一緻，則将其禁止，做自動限流。
完成自動限流之後， DAS會對某些 SQL 提出自動優化的建議。後續如果發現不再需要自動限流，則進行逾時設定，形成閉環。
資料庫的執行個體上會有控制台，而控制台的能力是由阿裡雲背後的DBaaS資料庫的資源管理平台提供支援，包括高可用、同城容災、監控報警。舉個例子，做跨機房的HA即由 DBaaS提供。
DBaaS是雲資料庫最底層的雲資料庫作業系統，雲資料庫的通用能力都由DBaaS提供，包括執行個體的資料安全、白名單加密、異常事件。DBaaS提供的能力會對雲資料庫生命周期裡的各個流程環節做打點，采集日志，以判斷資料庫在各個過程中是否出現異常。同時也提供了自愈能力。
跨機房切換時，可以通過 SLB 連到主節點，同時會有隐藏的備節點。出現問題之後，主備節點會做切換。切換完成後，暴露的SLB和域名不變。正常情況下，切換一般隻需20-30s，但不排除極端情況會對業務造成影響。
DBaaS背景的高可用切換HA元件在很多場景下夠将Fail Over變為Switch Over。
上圖左側的藍線代表機房出現問題後的切換線路，綠線為主機出現問題後的切換線路，紅線為執行個體以及資料庫本身出現問題後的切換線路。
技術人員不希望出現fail over，是以會盡量将 switch over 線擴大。通過 DAS和DBaaS的能力，做異常檢測、 SQL 限流，盡量地讓執行個體能夠主動切換，避免fail over。
03 雲資料庫使用進階
出現突發業務流量時，需要雲資料庫、DBaaS、核心、DAS配合來為企業提供自動彈伸的能力。目前，PolarDB MySQL和RDS MySQL 雲盤支援 auto-scaling。自動擴容提供了幾種不同的政策：其一，基于時間。比如某業務高峰一般為晚上10點，則可以在該時間節點開啟自動擴容，一般情況下可在十分鐘内完成；其二，自動擴容。基于自定義的規則進行擴容，比如cpu 達到某個門檻值即擴容，但該方式存在痛點，需要自行指定規格，規格未達到預期則無法擴容，不夠精準。
Auto-scaling在基于 CPU 使用率的場景已經卓有成效，CPU 使用率超過70%就增加讀節點也屬于 Auto-scaling 範圍内。如果 CPU 使用率超過70%，也可以彈升，進行垂直升配，隻需 5- 10 分鐘，業務不受損。
如上圖所示，最初業務較平穩，業務流量突然增加以後，業務發生了一次抖動。觸發了Auto-scaling自動彈升，自動升配并在分鐘級完成自動升配，彈升後盡管并發依然較高，但CPU使用率已經下降。
除了增效之外，阿裡雲資料庫團隊也希望能為客戶提供降本的能力，包括計算彈性降本、serverless、自動彈伸、分時彈性、資源超賣等。存儲層的降本包括支援冷熱分層、資料歸檔、高壓縮能力，同時也支援新硬體的紅利，比如持久記憶體的硬體。另外，我們也提供了架構優化的能力，雖然很多細節依然是未知數，但我們在持續努力嘗試微企業提供更高成本效益的方案。
同時，我們對PolarDB支援了多主叢集，通過多節點寫提升大叢集的寫能力。此前，出現寫瓶頸時隻能垂直擴容，擴容到極限後進行拆分，也包括水準拆分。多主叢集的能力更适合做垂直拆分，同時我們也提供了基于多主的水準拆分方案。
PolarDB Serverless已經公測，支援跨機的 scale up 和 scale out 了，針對實際需要将資源根據 QPS 進行彈升。如右圖所示，兩個曲線非常吻合，能夠大幅節約資源，支撐業務流量的抖動。
早期 AnalyticDB隻支援 MPP 引擎，無法應對多段 ETL 且中間被打斷的場景。如果 SQL 異常則需要重跑所有SQL。
AnalyticDB的湖倉版引入了spark引擎，可以做多段的 ETL 批處理，但底層共享一份資料，一份資料同時支援 MPP 的 OLAP 引擎，也支援批處理的引擎。比如基于 spark 的能力做完批處理後，資料存到底層存儲，實時分析的 MPP 引擎也可以讀取該份存儲。同時， MPP 和 spark 可以互動的，可以共享計算成果，并且提供了一體化的體驗，包括計費資料的通道、資料管理、資料通路等，為企業提供了更廣泛的實時分析場景，使用也更方面。
對于運維人員而言，用 SQL 處理資料比用資料庫處理資料更高效，而PolarDB4AI支援了算法的 SQL 态化，提供了三種特性：
第一，利用SQL語言高效模組化、訓練、評估、推理，友善使用者進行特征及模型全生命周期的操作和管理，縮短算法上線時間（2周降低至2天），降低人工智能門檻。
第二，實作了模型上傳和SQL态模型訓練推理平台，用算法模型在 PolarDb4AI 上運轉，進一步加速模型的上線速度。
第三，場景化資料智能解決方案。比如針對電商提供端到端的 PolarDB4AI 的 SQL 态的算法解決方案，實作大幅提效。
未來，我們期望資料庫上雲能夠更快、更穩、更安全。
其次，期望雲上資料庫方案變得更一站式、一體化。現有的将 MySQL 通過 DTS 同步到 ADB 的方式依然有些割裂，客戶更希望直接暴露一個service， 由service 直接從 MySQL 拉取資料，進行分析。
最後，希望資料上雲更智能，實作自動駕駛。
點選「連結」即可下載下傳演講PPT