從架構特點到功能缺陷，重新認識分析型分散式資料庫
本文是分散式資料庫的總綱文章的第一部分，主要探討分析性分散式資料庫的發展和技術差異；第二部分則是交易性資料庫的一些關鍵特性分析。Ivan開始計劃的分散式資料庫是不含分析場景的，所以嚴格來說本篇算是番外篇，後續待條件具備將以獨立主題的方式展開。
隨著大規模網際網路應用的廣泛出現，分散式資料庫成為近兩年的一個熱門話題。同樣，在銀行業主推X86限制主機與小型機的背景下，傳統的單機資料庫逐漸出現了一些瓶頸，馬上會面臨是否引入分散式資料庫的問題。
近期，Ivan在個人公眾號就“銀行引入分散式資料庫的必要性”做過一些展望，並收到了一些朋友的反饋，除了對分散式資料庫具體技術探討外，還有一類很有趣的建議，“能不能也講講Teradata、Greenplum這類MPP，這些也是分散式資料庫，但老闆總是認為OLTP場景下的才算數”。
的確，為了解決OLAP場景需求，其實很早就出現了分散式架構的產品和解決方案，其與目前的OLTP方案有很多共通的地方。而且Ivan相信，今後OLAP和OLTP兩個分支技術的發展也必然是交錯前行，可以相互借鑑的。
鑑於此，本文會將OLAP類場景的分散式資料也納入進來，從兩個維度對“分散式資料庫”進行拆解，第一部分會橫向談談不同的“分散式資料庫”，把它們分為五類並對其中OLAP場景的三類做概要分析；第二部分結合NoSQL與NewSQL的差異，縱向來談談OLTP場景“分散式資料庫”實現方案的關鍵技術要點，是前文的延伸，也是分散式資料庫專題文章的一個總綱，其中的要點也都會單獨撰文闡述。
首先，Ivan們從橫向談談不同的“分散式資料庫”：
一、萬法同宗RDBMS
1990年代開始，關係型資料庫（RDBMS）成為主流，典型的產品包括Sybase、Oracle、DB2等，同期大約也是國內IT產業的起步階段。RDBMS的基本特徵已有學術上的定義，這裡不再贅述。
但從實際應用的角度看，Ivan認為有兩點最受關注：
內部以關係模型儲存資料，對外支援ANSI SQL介面；
支援事務管理ACID特性，尤其是強一致性（指事務內的修改要麼全部失敗要麼全部成功，不會出現中間狀態）。
而後出現的各種“分散式資料庫”，大多都是在這兩點上做權衡以交換其他方面的能力。
“資料庫”雖然有經典定義，但很多大資料產品或許是為了標榜對傳統資料庫部分功能的替代作用，也借用了“資料庫”的名號，導致在實踐中這個概念被不斷放大，邊界越來越模糊。本文一個目標是要釐清這些產品與經典資料庫的差異與傳承，所以不妨先弱化“資料庫”，將其放大為“資料儲存”。
那麼怎樣才算是“分散式資料儲存”系統？
“分散式”是一種架構風格，用其實現“資料儲存”，最現實的目的是為了開啟資料庫產品的效能天花板，並保證系統的高可靠，進一步展開，“分散式資料庫”的必要條件有兩點：
支援水平擴充套件，保證高效能
通過增加機器節點的方式提升系統整體處理能力，擺脫對專用裝置的依賴，並且突破專用裝置方案的效能上限。這裡的機器節點，通常是要支援X86伺服器。
廉價裝置+軟體，保證高可靠
在單機可靠性較低的前提下，依靠軟體保證系統整體的高可靠，又可以細分為“資料儲存的高可靠”和“服務的高可靠”。總之，任何單點的故障，可能會帶來短時間、區域性的服務水平下降，但不會影響系統整體的正常運轉。
將這兩點作為“分散式資料庫”的必要條件，Ivan大致歸納了一下，至少有五種不同的“分散式資料庫”：
NoSQL
NewSQL
MPP
Hadoop技術生態
Like-Mesa
注：也許有些同學會提到Kafka、Zookeeper等，這些雖然也是分散式資料儲存，但因為具有鮮明的特點和適用場景，無需再納入“資料庫”概念進行探討。
這五類中，前兩類以支援OLTP場景為主，後三類則以OLAP場景為主。Ivan將按照時間線，主要對OLAP場景下的三類進行概要分析。
二、OLAP場景下的分散式資料庫
1990-2000年代，隨著應用系統廣泛建設與深入使用，資料規模越來越大，國內銀行業的“全國大集中”基本都是在這個階段完成。這期間，RDBMS得到了廣泛運用，Oracle也擊敗Sybase成為資料庫領域的王者。
在滿足了基本的交易場景後，資料得到了累積，進一步的分析性需求自然就湧現了出來。單一資料庫內同時支援聯機交易和分析需求存在很多問題，往往會造成對聯機交易的干擾，因此需要新的解決方案。這就為MPP崛起提供了機會。
1. MPP
MPP（Massively Parallel Processing）是指多個處理器（或獨立的計算機）並行處理一組協同計算[1]。
為了保證各節點的獨立計算能力，MPP資料庫通常採用ShareNothing架構，最為典型的產品是Teradata（簡稱TD），後來也出現Greenplum（簡稱GPDB）、Vertica、Netezza等競爭者。
架構特點：
MPP是多機可水平擴充套件的架構，符合“分散式”的基本要求，其中TD採用外接集中儲存而GPDB直接使用本地磁碟，從這點來說GPDB是更徹底的Share Nothing架構。
考慮到TD商業策略上採用一體機方案，不具有開放性，而GPDB具有較高的開源程度，下文中通過分析後者架構特點來分析MPP工作機制。
GPDB屬於主從架構[2]，Slave稱為Segment是主要的資料加工節點，是在PostgreSQL基礎上的封裝和修改，天然具備事務處理的能力，可進行水平擴充套件；叢集內有唯一Active狀態的Master節點，除了元資料儲存和排程功能外，同時承擔一定的工作負載，即所有外部對叢集的資料聯機訪問都要經過Master節點。
在高可靠設計方面，首先設定了Standby Master節點，在Master節點宕機時接管其任務，其次將Segment節點則細分為兩類不同角色Primary和Mirror，後者是前者的備節點，資料提交時在兩者間進行強同步，以此保證Primary宕機時，Mirror可以被排程起來接替前者的任務。
資料分析性需求對IT能力的要求包括：
複雜查詢能力；
批量資料處理；
一定的併發訪問能力。
MPP較好的實現了對上述能力的支撐，在前大資料時代得到了廣泛的應用，但這個時期的資料總量相對仍然有限，普遍在TB級別，對應的叢集規模也通常在單叢集百節點以下。
隨著資料價值關注度的不斷提升，越來越多的資料被納入企業分析範圍；同時實際應用中考慮到資料儲存和傳輸成本，往往傾向於將資料集中在一個或少數幾個叢集中，這樣推動了叢集規模的快速增長。
在大規模叢集（幾百至上千）的使用上，MPP從批處理和聯機訪問兩個方面都顯現了一些不足。以下內容主要借鑑了Pivotal（GPDB原廠）的一篇官方部落格[3]。
注：有位同學給出的譯文也具有較好的質量，推薦閱讀[4]。
缺陷：
批處理
MPP架構下，工作負載節點（對GPDB而言是Segment節點）是完全對稱的，資料均勻的儲存在這些節點，處理過程中每個節點（即該節點上的Executor）使用本地的CPU、記憶體和磁碟等資源完成本地的資料加工。這個架構雖然提供了較好的擴充套件性，但隱藏了極大的問題——Straggler，即當某個節點出現問題導致速度比其他節點慢時，該節點會成為Straggler。
此時，無論叢集規模多大，批處理的整體執行速度都由Straggler決定，其他節點上的任務執行完畢後則進入空閒狀態等待Straggler，而無法分擔其工作。導致節點處理速度降低的原因多數是磁碟等硬體損壞，考慮到磁碟本身的一定故障率（根據Google統計前三個月內2%損壞率，第二年時達到8%）當叢集規模達到一定程度時，故障會頻繁出現使straggler成為一個常規問題。
併發
由於MPP的“完全對稱性”，即當查詢開始執行時，每個節點都在並行的執行完全相同的任務，這意味著MPP支援的併發數和叢集的節點數完全無關。根據該文中的測試資料，4個節點的叢集和400個節點的叢集支援的併發查詢數是相同的，隨著併發數增加，這二者幾乎在相同的時點出現效能驟降。
傳統MPP的聯機查詢主要面向企業管理層的少數使用者，對併發能力的要求較低。而在大資料時代，資料的使用者從戰略管理層轉向戰術執行層乃至一線人員，從孤立的分析場景轉向與業務交易場景的融合。對於聯機查詢的併發能力已經遠超MPP時代，成為OLAP場景分散式資料庫要考慮的一個重要問題。
除上述兩點以外，GPDB架構中的Master節點承擔了一定的工作負載，所有聯機查詢的資料流都要經過該節點，這樣Master也存在一定的效能瓶頸。同時，在實踐中GPDB對資料庫連線數量的管理也是非常謹慎的。在Ivan曾參與的專案中，Pivotal專家給出了一個建議的最大值且不會隨著叢集規模擴大而增大。
綜上，大致可以得出結論，MPP（至少是GPDB）在叢集規模上是存在一定限制的。
2000-2010年代，大多數股份制以上銀行和少部分城商行都建立了資料倉庫或ODS系統，主要採用了MPP產品。可以說，這十餘年是MPP產品最輝煌的時代。到目前為止，MPP仍然是銀行業建設資料倉庫和資料集市類系統的主要技術選擇。為了規避MPP併發訪問上的缺陷以及批量任務對聯機查詢的影響，通常會將資料按照應用粒度拆分到不同的單體OLTP資料庫中以支援聯機查詢。
2. Hadoop生態體系
MPP在相當長的一段時期內等同於一體機方案（以TD為代表），其價格高昂到普通企業無法承受，多數在銀行、電信等行業的頭部企業中使用。2010年代，隨著大資料時代的開啟，Hadoop生態體系以開源優勢，獲得了蓬勃發展和快速普及。
Hadoop技術體系大大降低了資料分析類系統的建設成本，資料分析挖掘等工作由此步入“資料民主化”時代。在Hadoop生態體系中，分析需求所需要的能力被拆分為批量加工和聯機訪問，通過不同的元件搭配實現。批量加工以MapReduce、Tez、Spark等為執行引擎，為了獲得友好的語義支援，又增加了Hive、SparkSQL等元件提供SQL訪問介面。
聯機訪問部分，則從早期Hive過渡到Impala、Hawk以及Kylin、Presto等方案逐漸降低了訪問延時。
架構特點：
Hadoop生態體系下HDFS、Spark、Hive等元件已經有很多文章介紹，本文不再贅述。總的來說，其架構的著力點在於資料高吞吐處理能力，在事務方面相較MPP更簡化，僅提供粗粒度的事務管理。
缺陷：
Hadoop也有其明顯的缺陷，主要是三點：
批量加工效率較低
MPP的擁護者往往會詬病Hadoop計算引擎執行效率低。的確，在同等規模的叢集執行相同的資料加工邏輯，即使與Spark對比，MPP所耗費的時間也會明顯更少些[3]，其主要的原因在於兩者對於資料在磁碟和記憶體中的組織形式不同。
MPP從RDBMS而來（例如Vertica和GPDB都是基於PostgreSQL開發），對資料的組織形式更貼近傳統方式，按區、段、塊等單位組織，對資料進行了預處理工作以提升使用時的效率；Hadoop生態體系以HDFS檔案儲存為基礎，HDFS並不像傳統資料庫那樣獨立管理一塊連續的磁碟空間，而是將資料表直接對映成不同的資料檔案，甚至表分割槽也以目錄、檔案等方式體現。
HDFS最簡單的txt格式乾脆就是平鋪的資料檔案，處理過程難免要簡單粗暴一些，但隨著Avro、ORCFile、Parquet等很多新的儲存格式相繼被引入，基於HDFS的批處理也更加精細。從整體架構來看，Hadoop更加看重大資料量批量處理的吞吐能力。
同時，Hadoop具備MPP所缺失的批量任務調整能力，資料的多副本儲存使其具有更多“本地化”資料加工的備選節點，而且資料加工處理與資料儲存並不繫結，可以根據節點的執行效率動態調整任務分佈，從而在大規模部署的情況下具有整體上更穩定的效率。相比之下，MPP在相對較小的資料量下具有更好的執行效率。
不能無縫銜接EDW實施方法論
在長期的實踐中，企業級市場的主流整合商針對EDW專案沉澱了一套固定的實施方法，與MPP特性相匹配，但Hadoop並不能與之無縫對接。一個最典型的例子是歷史資料的儲存，傳統方法是採用“拉鍊表”的形式，即對於當前有效的資料會記錄其生效的起始時間，在資料被更改或刪除後，在該行記錄的另外一列記錄失效時間。這樣，當前資料即變更為歷史資料，通過這種增量的表述方式，節省了大量的儲存空間和磁碟IO。
可以看出，拉鍊表的設計思想其實與基於時間戳的MVCC機制是相同的。
HDFS作為Hadoop的儲存基礎，其本身不提供Update操作，這樣所有在資料操作層面的Update最終會被轉換為檔案層面的Delete和Insert操作，效率上顯著降低。據Ivan所知，在很多企業實踐中會將這種增量儲存轉換為全量儲存，帶來大量資料冗餘的同時，也造成實施方法上的變更。
聯機查詢併發能力不足
對於聯機查詢場景，最常見的是SQL on Hadoop方案，將Impala、HAWQ等MPP引擎架設在HDFS基礎上，批量資料與聯機查詢共用一份資料。MPP引擎借鑑了MPP資料庫的設計經驗，相對Hive等元件提供了更低的延遲。但存在一個與MPP相同的問題，即併發能力不足。
通過一些專案測試中，Ivan發現在大體相同的資料量和查詢邏輯情況下， Impala併發會低於GPDB。其原因可能是多方面的，不排除存在一些調優空間，但在系統架構層面也有值得探討的內容。例如在元資料讀取上，Impala複用了Hive MetaStore，但後者提供的訪問服務延時相對較長，這也限制了Impala的併發能力[7]。
3. Like-Mesa
Mesa是Google開發的近實時分析型資料倉庫，2014年釋出了論文披露其設計思想[5]，其通過預聚合合併Delta檔案等方式減少查詢的計算量，提升了併發能力。
Mesa充分利用了現有的Google技術元件，使用BigTable來儲存所有持久化的元資料，使用了Colossus (Google的分散式檔案系統)來儲存資料檔案，使用MapReduce來處理連續的資料。
Mesa相關的開源產品為Clickhouse[6]（2016年Yandex開源）和Palo[7]（2017年百度開源）。
架構特點：
目前ClickHouse的資料仍以俄語社群為主，為便於大家理解和進一步研究，下面主要以Palo為例進行說明。
Palo沒有完全照搬Mesa的架構設計的思路，其藉助了Hadoop的批量處理能力，但將加工結果匯入到了Palo自身儲存，專注於聯機查詢場景，在聯機查詢部分主要借鑑了Impala技術。同時Palo沒有複用已有的分散式檔案系統和類BigTable系統，而是設計了獨立的分散式儲存引擎。雖然資料儲存上付出了一定的冗餘，但在聯機查詢的低延遲、高併發兩方面都得到了很大的改善。
Palo在事務管理上與Hadoop體系類似，資料更新的原子粒度最小為一個數據載入批次，可以保證多表資料更新的一致性。
整體架構由Frontend和Backend兩部分組成，查詢編譯、查詢執行協調器和儲存引擎目錄管理被整合到Frontend；查詢執行器和資料儲存被整合到Backend。Frontend負載較輕，通常配置下，幾個節點即可滿足要求；而Backend作為工作負載節點會大幅擴充套件到幾十至上百節點。資料處理部分與Mesa相同採用了物化Rollup（上卷表）的方式實現預計算。
Palo和ClickHouse都宣稱實現了MPP Data Warehouse，但從架構上看已經與傳統的MPP發生很大的變化，幾乎完全捨棄了批量處理，專注於聯機部分。
ClickHouse和Palo作為較晚出現的開源專案，還在進一步發展過程中，設定的使用場景以廣告業務時序資料分析為主，存在一定侷限性，但值得持續關注。