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

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