附PPT下載｜DTCC演講：降本增效，阿里雲一站式資料庫上雲實踐

　　本文內容根據演講錄音以及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 拉取資料，進行分析。

　　最後，希望資料上雲更智慧，實現自動駕駛。