這些年大家都在談分散式資料庫，各大企業也紛紛開始做資料庫的分散式改造。那麼，所謂的分散式資料庫到底是什麼？採用什麼架構？優勢在哪？為什麼越來越多企業選擇它？分散式資料庫技術會向什麼方向發展？帶著這些疑問，一探究竟吧！參與文末的話題互動，更有機會贏取精美獎品~
分散式資料庫的架構演進
隨著資料量的爆發增長，傳統集中式資料庫面臨極大的挑戰：
- 效能瓶頸：資料規模爆發增長，傳統集中式資料庫難以維持資料量大時的效能，而分散式資料庫的效能可以水平擴充套件；
- 缺失混合負載能力：資料量爆發增長帶來對資料分析（OLAP）需求的增長。企業需要使用兩套系統分別支撐事務交易（OLTP）和資料分析（OLAP），不僅造成了大量的資料冗餘，同時增加了系統的複雜度和運維難度。而分散式資料庫的混合負載能力可大幅度提升分析的時效性，減少資料冗餘，並大大提高靈活性；
- 高昂成本：集中式資料庫水平擴充套件難，可靠性需要付出高昂的成本。而分散式資料庫的架構支援靈活擴充套件，實現高可用方案的成本較低。
分散式資料庫與單機資料庫的不同在於其可以將核心功能擴充套件到多臺節點，甚至多個地域，包括事務管理、資料儲存和資料查詢等。從實現方式上看，分散式資料庫主要有3種不同的技術路線：
1. 分散式中介軟體 + 單機資料庫。
這條路線本質上是分散式系統由兩部分組成：
a) 上層是分散式中介軟體：維護一套統一的分片規則，提供SQL 解析，請求轉發和結果合併的能力。
b) 底層單機資料庫：開源MySQL或PG單機資料庫，提供資料儲存和執行能力。
這種方式主要使用比較成熟的核心來解決擴充套件性的問題，所以生態友好、成本較低，也比較容易實現。
不過，缺點也顯而易見。比如功能降級、在全域性事務能力和高可用等方面存在短板，需要有針對性增強，導致整個方案的複雜度高、機器冗餘多。最重要的是，因為使用的是開源產品的核心，資料庫會始終受制於開原始碼修改、專利、發行方式等很多方面的風險，這種形式顯然無法滿足當前國內金融、政企客戶的需求。
2. 基於分散式儲存的分散式資料庫。
這種形態基於分散式儲存，再疊加資料庫能力。大部分公有云資料庫採用這條技術路線。華為雲GaussDB(for MySQL)就是這種形態的典型代表。
這條路線有限地解決了擴充套件性問題，資料一致性主要依賴分散式儲存引擎。上層的計算節點無狀態，共享儲存提供跨節點讀寫。這種架構充分利用分散式儲存提供的高階特性，更容易形成技術競爭力。但是這種架構的擴充套件性有限，尤其是寫節點。
另外，這種架構對底座（分散式儲存）有比較重的依賴，線下實現的成本高。
3. 原生分散式資料庫。
這種形態是基於分散式資料庫理論實現的分散式資料庫。這條路線是根據分散式一致性協議做底層設計。原生分散式資料庫將分散式儲存、事務和計算結合在一起，資料由系統自動打散並儲存多個副本，透過一致性協議保證多個副本和事務的一致性。
這種形態更容易在資料庫本身所擅長的領域發揮優勢，比如說效能、複雜SQL處理能力、企業級能力。叢集的擴充套件和收縮對應用透明，按需擴充套件，支援大規模部署限制；資料一致性由事務層一致性協議保護，安全性更高；靈活部署，多活架構，對硬體的依賴低，可以透過普通伺服器實現叢集和高可用。
因為金融政企客戶在使用分散式技術之前，往往已經有分庫分表、使用分散式中介軟體產品的經驗，所以對原生分散式架構的認可度更高，學習成本也相對較低，因此，這種形態也是國內當前被採用較多的一種。
華為雲GaussDB分散式資料庫就是這種形態的典型代表。GaussDB基於華為在資料庫領域20多年的戰略投入，已經在金融行業積累了非常豐富的實踐經驗，是企業數字化轉型、核心資料上雲、分散式改造的信賴之選。
原生分散式資料庫的挑戰和關鍵技術
原生分散式資料庫基於分散式資料庫理論，是一款對於使用者應用透明的分散式資料庫。不過，實現分散式關聯式資料庫有幾個關鍵挑戰：
第一，安全可信。
分散式、雲化環境的複雜性增加了安全風險，比如資料洩露和丟失的風險增加，身份認證和訪問控制以及資料傳輸、儲存安全的控制難度提升。
第二，事務系統的正確性及效能。
分散式資料庫中經常有一次操作涉及多臺資料庫的場景，需要一種方案來維護整個資料庫叢集事務的ACID特性，避免出現部分成功部分失敗等無法接受的情況。
另外，在大併發場景下事務管理器容易成為效能的單點瓶頸，比如獲取事務唯一標識、全域性快照、頻繁互動導致大量的網路通訊和鎖等待等。
第三，分散式查詢能力。
在分散式系統中，需要在最短時間內獲取準確的查詢結果，提升查詢效能。
第四，高可用能力。
分散式資料庫需要確保異常場景下（如：節點硬體故障或者Bug當機等）資料庫系統的連續可用。
分散式資料庫的挑戰和關鍵技術
GaussDB分散式資料庫研發了一系列高效能、高可用、安全特性迎接上述四大挑戰，下面挑選幾個有代表性的特性加以說明。
全密態
傳統的加密方式在服務端加密，金鑰管理員是可以獲取的。而全密態資料庫的金鑰掌握在使用者自己手上，資料庫管理員無法獲取，加解密過程僅在客戶側完成，資料在儲存、傳輸、查詢整個生命週期過程中均以密文形態存在，避免管理員惡意獲取金鑰解密資料。
全密態資料庫
分散式事務GTM-Lite
如下圖所示，GaussDB沒有采用傳統的事務列表的管理方式，而是提供了一個CSN（提交系列號），透過對比CSN的大小來實現事務可見性判斷。
GTM-Lite技術示意
當事務開始時，根據事務隔離級別的不同，從GTM-Lite獲取一個CSN值，作為這個事務的查詢快照點（如果是可重複讀，只需要在事務開始時獲取一次CSN值，如果是讀已提交，每次SELECT時都需要重新取一次CSN值）。
當事務提交時，向GTM-Lite申請一個新的CSN值，作為這個事務提交CSN值，並記錄到事務提交記錄中。
GTM-Lite技術透過CSN提交序列號進行可見性判斷，無需耗費大量計算資源來遍歷列表；無鎖化原子操作提供CSN序列號，無需鎖等待；節點間事務互動僅需要一個CSN，網路開銷跟事務規模無關。在保證事務全域性強一致的同時，提供高效能的事務處理能力，避免了單GTM的效能瓶頸。
分散式查詢最佳化
1. 分散式執行
GaussDB是如何處理分散式資料庫叢集中的業務應用SQL的呢？
1）業務應用的SQL會下發給CN節點；
2）CN利用資料庫的最佳化器生成分散式的執行計劃，每個DN會按照執行計劃的要求處理資料；
3）資料基於一致性Hash演算法分佈在每個DN，因此DN在處理資料的過程中，可能需要從其他DN獲取資料，GaussDB提供三種stream流（廣播流broadcast、聚合流gather和重分佈流redistribute）實現資料在DN間的流動；
4）DN將結果集返回給CN進行彙總；
5）CN將彙總的結果返回給業務應用。
分散式查詢示意
讓我們展開看一下節點間的資料交換。比如某條SQL的執行邏輯如下圖所示：
SQL執行邏輯
以兩個DN為例， 在執行過程中，DN會按照redistribute鍵將資料傳送到對應的節點。
Redistribute運算元接收到C/D兩表join的資料之後，根據重分佈鍵計算將資料發給DN1還是DN2，Redistribute Collector收集到重分佈之後的資料之後發給上層的Join運算元再做Join計算。
CN、DN間的資料流動
另外，GaussDB的最佳化器會根據統計資訊選取針對當前SQL效能最優的Stream流運算元完成CN、DN間的資料流動。
2. 全並行架構
GaussDB採用全並行架構，從MPP節點並行、SMP執行緒並行、到SIMD指令並行，到LLVM CodeGen技術，全面挖掘系統計算資源的潛力，提升查詢效能。
高可用
1. GaussDB重做日誌
重做日誌在如下場景可以發揮作用，提升系統的可用性
1）當資料庫發生故障，如當機，可以透過重做日誌檔案恢復資料。
2）HA架構下，主備透過重做日誌檔案進行資料同步。
3）備份恢復時，透過歸檔重做日誌檔案實現PITR。
GaussDB使用WAL (Write Ahead Log) 機制實現重做日誌，在提升可用性的同時兼顧效能，即在資料修改時遵循 no-force-at-commit 策略，在提交時並不強制寫。為了保證資料在資料庫發生故障時可以恢復，透過Redo 機制，用連續的、順序的日誌條目的寫出將隨機的、分散的資料塊的寫出推延，這個推延使得資料的寫出可以獲得批次效應的效能提升。
2. 分散式部署
GaussDB支援多種高可用部署形態，保證系統的穩定性和可靠性。下面我們看兩個典型案例。
1）兩地三中心。
同城有兩個雙活資料中心，兩個資料中心同時承載業務，異地一個容災資料中心；同城可實現節點級、AZ級、資料中心級等故障高可用，同時提供跨城的異地容災能力。
GaussDB兩地三中心高可用部署
2）同城3AZ高可用+異地容災。
同城採用邏輯3AZ、3副本部署，異地採用單AZ、3副本部署，提供了同城抵禦節點級故障和AZ級故障的能力，跨城的Region級容災的能力。
GaussDB同城3AZ高可用+異地容災
分散式資料庫技術的發展方向
基於新需求、新場景、以及全池化架構、新網路和大模型等新技術的出現，我們認為分散式資料庫技術主要向以下六個方向發展。
分散式資料庫技術的發展方向
高可用能力的持續提升
高可用是目前大多數金融政企客戶首要關注的問題，特別是對於多地、多中心容災有要求的客戶。針對這樣的客戶，華為雲GaussDB已經提供了多種解決方案，如支援同城雙活、異地容災、兩地三中心的解決方案，支援同城雙活強同步的解決方案，支援非同步資料複製、多地多活的高可用解決方案。
面向未來，分散式資料庫將具備真正全球部署能力的多活架構。
軟硬體深度協同
硬體和軟體兩者之間相輔相成，互相促進。利用新型硬體（GPU、FPGA、高速網路）和華為在晶片、伺服器、儲存、網路、作業系統、資料庫的全棧軟硬體能力，提升效能和高可用能力。
首先，資料庫的持久化邏輯，深度整合到了計算與儲存分離的技術底座中，分散式資料庫可以獲得在容量、彈性、擴充套件性方面的巨大提升，同時能提供給客戶一致的體驗。
其次，從計算節點解除安裝下推到儲存中，特別是對一些複雜的查詢處理，同時疊加並行處理能力，使得這些計算邏輯能充分利用下面整個儲存池的能力，同時最關鍵的是能做到對業務透明。
最後，就是高效能。高效能的實現除了I/O聚合之外，單條交易的本質就是網路的時延和處理的時延。所以，網路對於分散式資料庫的時延（效能）影響是巨大的。
總而言之，軟硬協同帶給我們的不僅僅是效能擴充套件方面的優勢，更是可以透過軟硬協同打造真正企業級的可靠性。
企業級混合負載 （HTAP）
近年來企業級混合負載（HTAP）的興起，旨在打破事務處理（TP）和分析（AP）之間的壁壘。分散式資料庫都應具備混合負載能力，即在支援高併發、事務性請求的同時，對分析型的複雜查詢提供了良好的支援，從而大幅度降低成本，同時提高企業決策的效率。
HTAP架構的核心技術：
第一，透明路由。透過自動選擇行存引擎、列存引擎以及行列組合，提供查詢的準確性和實時性，增加客戶的易用性，提升HTAP產品的商用價值。
第二，效能提升。TP要求的是低時延、高吞吐，而AP要求的是複雜查詢的能力。常規執行最佳化技術包括並行執行、編譯執行、向量化執行等，在這些技術的基礎上進一步加速複雜查詢，支撐企業級混合負載。
第三，資料新鮮度。保證資料高新鮮度、高效能，保證HTAP架構能夠具備更多應對使用者的能力。
第四，資源隔離。使用者對TP效能要求比較高，在引入實時AP的同時，不能影響TP的能力和效能，需要在資源隔離、資料新鮮度以及效能的提升方面做好權衡。
雲原生多主
單一架構其實並不能解決今天行業碰到的所有問題，但云原生多主架構可以幫助解決兩類問題：
第一個，是高可用的問題，希望能基於多主架構，解決切換時業務中斷的問題。
第二個，是擴充套件性的問題，基於多主架構，融合軟硬協同的進展，真正能在計算節點以下，持續提升產品的效能和彈性。
資料安全可信
當今世界，每個國家、組織和個人都在關注安全、合規和隱私的問題，幾年前資料無保護隨意獲取並使用的便利不再，這也促進了技術的進步和落地。未來，全行業都會面臨越來越嚴格的對於可信安全方面的要求。
全密態是華為雲資料庫為了提升隱私保護能力研製的一項關鍵技術，全密態支援資料在整個計算過程中同樣是以密文形式存在，實現了讓整個敏感資料在全生命週期當中都得到保護。因此，無論資料處於何種狀態，攻擊者都無法獲取到有效資訊，從而保障了企業資料全生命週期的隱私安全。
AI-Native
機器學習已被廣泛用於最佳化資料管理問題，如資料清理、資料分析、查詢重寫、資料庫診斷等。然而，傳統的機器學習演算法無法解決泛化和推理問題。幸運的是，大模型（LLM）可以幫助解決這些限制，為智慧化資料管理提供了很好的機會。
藉助AI/LLM，未來分散式資料庫將朝著全流程、全鏈路、高效易用的智慧化資料庫的方向發展，在資料庫諮詢、開發、運維等關鍵階段，構建相應的自動化能力：
第一，諮詢階段，提供專家式輔助，制定精細化方案。
- HLD助手，結合專家經驗，自動生成資料庫HLD；
- DB知識庫，透過積累運維工單、答疑、文件手冊等，形成資料庫行業知識庫；
- 問答助手，透過提供ChatBot，實現互動式運維。
第二，開發階段，提供開發輔助，提升SQL開發效率。
- 透過構建NL2SQL轉換能力，讓自然語言轉換為SQL語句；
- 同時，增強的SQL轉換能力提升異構資料庫間的SQL語句轉換自動化率。
第三，運維階段，實現預測性維護，提升系統可靠性。
- 智慧巡檢，可以構築Schema/SQL、中介軟體/告警等全鏈路可觀測可跟蹤能力；
- 智慧故障處理，透過全鏈路感知編排，提供精準分析，快速定位故障並給出建議；
- SQL質量提升能力，可以快速找出問題SQL，診斷根因，提供全域性分析。
綜上，分散式資料庫效能卓越，憑藉高可用、高可擴充套件性、高價效比等優勢，已經被對資料庫要求最嚴苛的金融行業所認可，並逐漸被應用在更廣闊的領域。不過，從總體發展狀態來看，目前還處於早期，但發展方向明朗，上升空間很大。
參與有獎
GaussTech技術專欄第一期話題討論：
對於分散式資料庫的未來發展，你怎麼看？
1.你認為分散式是資料庫未來的發展趨勢嗎？
2.哪種架構會得到更多企業的青睞？
3.分散式資料庫技術又會向什麼方向發展？
點選連結，即可參與“GaussTech技術專欄第一期”話題討論，就有機會獲得HUAWEI mini藍芽音響 _綺境森林、《華為資料之道》書籍、新貴族系列中性筆、平裝套芯筆記本、GaussDB字母筆、炫彩馬卡龍指甲刀等好禮，快來參與吧！
點選關注，第一時間瞭解華為雲新鮮技術~