云+微服務+新硬件：下一代大規模并行數據庫架構風格
從上個世紀70年代開始，數據庫就成為計算機軟件中最重要的“中間件”。有了數據庫后，關于數據操作的原語可以從應用代碼中分離出 來，DBMS（數據庫管理系統）承擔了數據結構的管理、存取等任務，并維護了數據的可用性、一致性。這種專業化的分工，使得軟件開發效率和系統運行效率大 大提升。進入21世紀后，隨著軟件和硬件技術的發展、互聯網的興起，數據庫技術發展進入了一個百花齊放的新階段，其指導思想仍舊是專業化分工。為每一種數 據類型和應用訪問類型都有了其針對性的數據庫技術。本文主要描述其中一個細分市場——大規模并行數據庫的發展趨勢。
并行數據庫的定義和架構特點
在維基百科上，并行數據庫被定義為通過并行使用多個CPU和磁盤來將諸如裝載數據、建立索引、執行查詢等操作并行化以提升性能的數據庫系統。其中最重要的關鍵詞是并行。
在組成大規模計算機集群的時候，通常有兩種特性要考慮：并行和分布式。并行強調多節點同時執行，共同解決一個大問題，通常在嚴格的高性能網絡環境 中，有嚴格的執行要求和反饋時限。因此，并行和并發大多數時候是矛盾的兩面，你不應該指望并行數據庫能在極短的時間處理大量的請求，因為它是為了解決大問 題而設計的，而不是大量的小問題。分布式則是另外一個特性，它強調數據或計算分布在不同的節點，并對上提供透明性。
因為目的不一樣，通常設計運行在大規模集群的軟件時，不會同時追求這兩者。并行數據庫被設計為最求極致的并行，即使僅查詢一條數據的SQL，也會 被扔給所有的數據節點來執行；而HDFS則不是這樣，它不會要求一個文件塊完全分布在所有的數據節點上，并同時提供訪問，它只需要將一個文件按照順序分成 幾個塊分布在數個節點上即可，一個接一個地被訪問。因此一個HDFS數據節點失效影響不了全局；但是一個MPP的數據節點失效會影響全局。這是兩種特性的 典型差別。理解了這個“并行”的特點對理解并行數據庫的設計非常重要。
很明顯，因為并行數據庫的技術特點是為了某類需求設計的，因此它有自己的適用環境。首先因為它采用關系理論，因此它僅適合結構化數據。非結構化或 者某些半結構化數據，當然也可以在其中存和取，但是實際上有很多更好的解決方案可以選擇。其次還是因為它采用關系理論，關系代數和關系演算是其擅長的，因 此它在并行計算，特別是復雜的多表關聯、流水線等一系列操作中特別擅長，如果只是存入和取出的話，NoSQL會更加適合。再次，因為并行數據庫的SQL語 言是一種申明式的語言，甚至當初設計的目的并不是給程序員使用，而是給業務人員用的，因此處理日常重復性任務有更好的解決方案，比如MapReduce和 Spark。最后一點，因為并行數據庫需要在數據分布（計算Hash）和存儲格式（比如列存、壓縮、索引、頁面統計信息等）方面進行較多的處理以便為查詢 進行優化，因此裝載數據比較耗費精力，花費時間較長。所以入庫后只會被讀取少數次的任務，最好不要麻煩它來做。
并行數據庫目前的主要問題來自于它的設計目的，因為要實現完美的并行，因此它大多被設計為計算和存儲緊密耦合，這樣計算可以控制每行數據的存儲位 置和每個數據塊的存儲格式，這樣對大任務提供了很好的性能（類比于“魚”）。同時也使得系統魯棒性不高，這體現在一個節點退服后性能下降嚴重，兩個節點退 服有全庫停止的可能。另外系統擴展性也受到限制，一是規模不能太大，二是基本需要對等性能的機器，三是重新計算Hash并移動數據是非常麻煩和緩慢的（類 比于“熊掌”，目前是魚與熊掌不可兼得）。
并行數據庫技術要點分析
并行數據庫主要由執行引擎、存儲引擎和管理功能模塊組成。它們的不同技術風格形成了各個有特色的并行數據庫產品。
因為是大規模集群的數據庫，所以首要要面對的就是主、從節點的風格。主節點要承擔入口、元數據管理、SQL Parser、生成執行計劃和任務調度、管理兩階段提交等功能。目前有兩種方式：有專職Master和無專職Master。
從開源的PostgreSQL演變來的并行數據庫，多為有專職Master的。這種架構比較簡單，因此數據節點的對等性比較容易維護，不會形成性能短板。它們的Master形成了主備模式，切換的時候影響比較大，而且主節點的動態伸縮也是問題。
從頭設計的并行數據庫多為無專職Master的，比如Gbase 8a和Vertica。數據節點和Master節點代碼部署到一臺物理機，被連接上即充當此次連接的Master。其優點是足夠的擴展性和更好的高可用 性，但是缺點在于Master的進程可能拖慢數據節點，形成性能短板。而且Master之間的元數據同步也是一個負擔。
兩種方式各有優劣，在大規模集群下，無專職Master架構優勢更加明顯，其向“多Master”架構發展也很容易。我認為多Master是未來方向，這樣在提供良好的擴展性和高可用的同時，也保持了數據節點的對等性。
在存儲引擎中最為關鍵的就是數據分布。按行進行Hash分布是并行數據庫的重要特征。其它數據分布方式無法精確控制數據擺放，也無法提供足夠用于查詢優化的存儲信息。
就像之前說的那樣：這種緊密耦合的非透明的方式帶來了巨大的好處（同樣分布的表的高效關聯），同時也帶來了麻煩（擴展性、高可用等）。魚與熊掌不 可兼得。一些改進的SQL on Hadoop方案借用了這一點，比如HDFS Colocation、Pivotal HAWG、Vertica VIVE等。沒有解決Hash分布的解決方案，都難以處理多個大表關聯（Join）的問題，它們多通過預關聯的方式來規避這個問題，形成某種類似OLAP 多維立方體的解決方案（比如Google Dremel、Mesa，eBay Kylin等）；或通過shuffle實現重新分布（比如Hive或者SparkSQL）。
數據庫所用存儲設備歷經變遷，且當前面臨大變革。目前典型的并行數據庫多使用SAS磁盤，而HDFS使用容量更大、價格更便宜但性能和可靠性稍差 的SATA磁盤。使用這種慢速的磁盤是并行數據庫目前最大的瓶頸，使它無法實現效率和可擴展、高可用兼得，也就是魚與熊掌不可兼得的難題，主要來源就在于 此。磁盤IO的速度難以匹配摩爾定律要求的速度，但是電子盤和內存是可以的。隨著后兩者的價格快速下降、性能快速提高，并行數據庫可能又將面臨一次重大的 變革，并解決那個難題。
并行數據庫目前主要的數據存儲仍然使用磁盤，電子盤和內存盤最多只能作為緩存來使用。我認為接下來的1到2年，我們很快就將面對以SATA接口的 SSD替代SAS磁盤的過程。現在一些高端的并行數據庫一體機已經可以采用全SSD的配置了。目前的并行數據庫幾乎不用改動任何代碼，就可以運行在SSD 之上。
但是，因為硬件特性不一樣，只有全新設計一個并行數據庫系統，才能最佳發揮SSD的作用。因為現有的并行數據庫系統是為了旋轉磁盤的特性設計的， 為了將隨機的讀寫轉換為順序的讀寫，用了非常多復雜的機制和復雜的代碼。如果單個數據或者一小塊數據的隨機訪問速度和順序訪問相當，那么就沒有必要這樣 做，節省下的代碼將提高效率、系統的穩定性、可用性和擴展性。NoSQL數據庫AeroSprik就是專門為SSD來設計，而取得了很好的性能。
我認為未來是內存為王的時代，天下武功為快不破。內存是數據存儲的終極目標。目前柏睿Rapids DB和HANA等產品就是將內存作為數據的實際存儲地方，SSD只是拿來做快照和日志的存儲而已。這種方式，將解決MPP面臨的“魚與熊掌不可兼得”的問 題。在短期內，這種方案不能成為所有數據存儲的選擇，但是我堅信硬件的發展是持續的，用硬件來解決軟件的問題是最直接有效的方式。因為內存的易失性，并不 能簡單地將數據存儲從SSD轉移到內存中，這將面臨一次更多的、更徹底的并行數據庫軟件平臺的重新設計。
使用并行數據庫必須了解這樣一個事實，那就是單節點退服帶來的總體性能下降超出你的想象，如果碰巧遇到某些脆弱的數據庫和呵護不周到的DBA，還可能產生“雪崩”現象，即因為某一個節點下線導致整體異常繁忙而全庫崩潰。這事情出現可不是特例。
這是一個我們的測試結果。24個節點退服一個的情況下，不同產品讀的性能和寫的性能下降的情況。
圖1 24個節點退服情況對此測試結果
注意這不是滿負荷（CPU BOUND或IO BOUND）的情況，這不是一個成比例的下降。100個節點和1000個節點會面臨與此類似的情況，不能增加節點來解決這個問題。因此節點的退服影響很大，這和Hadoop非常不一樣。
簡單的說產生這個問題的原因就在于Hash分布。Hash分布帶來了極致的并行（魚），同時破壞了存儲和執行之間的透明性（熊掌），因此深度綁定導致出現問題的節點的任務無法分散在所有節點，只能由備機所在的節點承擔。
同樣影響的是線性擴展性，目前世界上最大的MPP生產集群是300個節點。而且大家都傾向用性能更好的胖節點來減少節點的數目。比如我們的設備就有24個SAS盤位。擴展的時候移動數據也是一個很大的開銷。
小結一下。目前我們可以看到三類典型的并行數據庫架構風格：
最左側是以Gbase8a、Vertica、GreenPlum為代表，典型的MPP數據庫。數據采用Hash分片，存儲引擎和執行引擎緊密耦合，數據完全的本地化，支持完整的SQL，基于成本進行SQL優化。
最右側是以Impala為代表的典型的SQL on HDFS。存儲引擎HDFS與查詢引擎完全透明，數據不是由查詢引擎寫入的，實際上它們就不叫執行引擎，大多只支持“查詢”。因為不能控制存儲，所以沒有統計信息，大部分只能實現基于規則的SQL優化。
圖2 三類典型的并行數據庫架構風格
存在一個中間的狀態，請允許我用MPP over HDFS來命名它。以GreenPlum HAWG和Vertica剛推出的VIVE為代表。雖然它也利用HDFS，但是寫入的數據均是通過它自己的存儲引擎寫入的，因此是要計算Hash的，有自 己的文件格式和壓縮格式，不同節點的文件寫到不同節點的目錄中，類似Hbase那樣。當然也有完整的統計信息，因此可以實現基于成本的SQL優化。它通過 HDFS的本地化機制部分實現了數據本地化。MPP節點（也就是執行節點）出現故障以后可以快速啟動一個新的執行節點，因為執行節點并不帶數據，當然這個 時候要損失掉數據本地化的收益。這種中間方案的性能和擴展性也處于中間。
比如HAWG。它基本上就是把GreenPlum DB的數據存儲從本地磁盤的文件系統遷移到HDFS上，使用了一個自己擴展的HDFS接口（gphdfs，Vertica的VIVE使用的是 webhdfs的接口）。典型的MPP性能肯定比中間方案的MPP over HDFS高。Vertica自己的一個測試，大概是高一倍左右。GreenPlum的測試結果與這個類似。
并行數據庫未來展望
如何既能充分發揮并行數據庫的特點，又避免其問題呢？當前云計算+微服務的新一代架構風格，配合當前的硬件發展讓我看到了一線曙光。
1. 云服務的模式，使得數據庫規模越來越大，經濟性越來越顯著
在我的實踐中，我感受到了云計算給IT帶來的顛覆，雖然云計算熱已經過了，但是它已經潤物細無聲地改變了業態。我認為數據庫也是這樣，以后以云的 方式提供的數據庫會越來越多。無論是企業內部的私有云還是對外的公有云。比如AWS RedShift和Openstack Trove (DBaaS)。這給數據庫軟件帶來的變化是它需要支持越來越大的集群，技術難度加大但經濟性更好，可以擁有更加專業的運營團隊來充分享受新技術的紅利。
70年代數據庫的出現實現了數據庫中間件和應用軟件的分工，因為分工而專業，而高效。同樣在當前情況下，云服務的模式使得數據庫的分工更加明顯， 并不需要每個應用都有一個數據庫集群為其服務，變擁有為租用，每個應用只需要訂購相應的數據庫服務即可。分工的細化帶來的效率的提升，使得數據庫的針對性 優化可以做到極致，出現問題后的解決方案也可以及時而迅速。
阿里云每一個數據庫首要的要求就是云化，比如OceanBase、內存分析型數據庫ADS等。多租戶、負載管理、資源隔離、配額和用量，這些原來數據庫并不看重的邊緣能力，在云服務的時代變得非常重要，成為新時代數據庫的標準配置。
2. 數據庫組件的分工細化，通過微服務實現高內聚，松耦合
并行數據庫的軟件模塊或者叫組件的分工會越來越細化。以前只有主節點和數據節點兩類，此外還有一些數據庫可以利用不帶數據的數據節點來作為裝載節 點。新一代架構風格會將接入節點、協調節點、元數據節點、日志節點、安全節點、SQL解析和優化節點、數據裝載和導出節點、數據節點全部分拆成可以并行， 可以靈活部署到任何位置的容器級服務。
這些組件按照容器的標準（比如Docker）進行封裝，并在微服務的框架下形成并行數據庫的管理系統（比如通過K8s或者Mesos）。服務發 現、配置管理、健康管理、鑒權管理由運行框架實現，從而達到各個組件高可用、松耦合、屏蔽內部細節的效果。同時Docker這樣的Build、Ship、 Run的方式為DevOps提供了便利的手段，使得數據庫軟件能像互聯網應用一般快速迭代升級。
不僅僅是數據庫功能組件的分工。對于數據庫最重要的能力，數據節點部分，還可以進行更加極致的分工。當前的數據庫設計模式下，數據節點承擔了整個 數據庫的一個分片，所管理的數據可能是上TB的量級。這樣龐大的數據量使得數據節點本身難以形成“微服務”。同時也是為什么需要能力對等的服務器的原因， 性能低下的服務器，或者出現故障的服務器會形成木桶效應從而拉低整個集群的性能。
為什么不讓數據節點管理更小的數據分片呢？無論是一個表，還是一個表的某個Hash值范圍，或者一個邏輯數據庫（數據沙盒）的某個Hash值范 圍。如果一個數據節點僅管理數MB的數據，那么這些數據節點不僅可以更加方便地管理在內存中，而且方便地在物理機器之前遷移，出現問題以后重新載入一個微 型的數據節點結束帶病工作狀態的速度也會很快。此外按照服務器的能力來分布這些數據節點也會變得很簡單，不再需要對等的服務器集群。
如果沒有Docker這樣的容器封裝標準，通過進程來實現這種大量的微數據節點可能會很復雜。但是Docker天生就是為這種單進程、微服務的任 務所設計。從Docker Hub中，一個Docker的Image可以很快獲取到一臺機器上，一個容器可以很快生成，其所需要負擔小的數據分片可以很快從其他副本分片獲取數據或者 直接從持久化存儲（File Server）中拉取數據，日志傳至專門的日志服務器，從而實現無狀態的服務。其初始化工作完成后，向“服務發現”進行注冊，這個數據分片就可以對外提供 訪問了。
這種微型數據節點設計將數據緩存在內存中，并使良好的資源管理成為可能。
3. 充分利用新型硬件的紅利
新一代的架構可以針對新型硬件進行特別優化，3D內存、Flash卡、硬件壓縮卡、Infiniband，這些硬件設備都是之前一代數據庫系統所未面對過的。如果進行針對性開發，不僅可以充分利用其性能優勢，還能延長硬件的生命周期。圖3是一個大致的示意。
圖3 新一代架構設計圖
總結幾點：
- 并行數據庫有其適用范圍；
- 所有數據庫設施都需要云化，實現專業分工；
- 組件的微服務和數據的微服務是新一代架構的主要特點；
- 硬件的變化將導致軟件形態極大地改變。
作者： 何鴻凌
簡介： 中國移動集團公司業務支撐系統部信息處副經理，高級工程師。工信部和人社部認證的高級程序員、系統分析師、網絡分析師。TDWI會員。主要精力放在大數據 技術以及大數據應用方面，主導引入Greenplum、Vertica、Gbase8a等MPP技術，以及Hadoop、流處理和Spark等技術來搭建 運營商的大數據平臺，并探索大數據對內和對外的商業應用。