云+微服務+新硬件：下一代大規(guī)模并行數(shù)據(jù)庫架構風格

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