KUDU是一個分布式主從架構的存儲系統(tǒng)，這意味者它有Master-Slave的架構，不過實際上，它的Slave組件叫做Tablet Server,存儲著KUDU中的數據。KUDU的架構圖如下：

KUDU整體是高可用的，無論是Master還是Tablet Server都有多臺，它們內部采用Raft選舉機制來保障誰是Leader,誰是Follower。

對于KUDU Master來說，它主要存儲Catalog Table, Tablet Server以及Tablets的元數據信息。Catalog Table存儲KUDU中Table的Metadata信息。KUDU Master使用采用Raft機制，為保證選舉的成功性，通常Master需要為奇數個，一般是3個，在集群規(guī)模比較大時可設置為5個。

對于Tablet Server, 它主要存儲Tablets以及向外部Client提供服務。

Tablet的不同副本會存儲在不同的Tablet Server上，它們也通過Raft機制保障誰是Leader,誰是Follower。對于一個特定的Tablet, 只有Leader可以被寫入，而Follower只能被讀取。這樣大大提升了讀的效率。然而當數據寫入過大時，如果有Leader Tablet所在的Tablet Server宕機，那將會造成大量的寫失敗，而在Raft機制中，Leader只允許提交當前時間片的數據，因為當新的Leader選舉產生后，之前寫失敗的數據也不會再次寫入，只能繼續(xù)寫當前時間片以后的新數據。這也是為什么Tablet Server節(jié)點宕機后，有可能造成數據一致性的問題。

那么對于一個特定的數據表, KUDU里是怎么存儲的呢？參見下圖：

對于一個表，KUDU中會將其若干個Tablet, 每個Tablet又包含Metadata以及RowSet。其中Metadata存放Tablets的元數據信息，RowSet存儲具體的數據。

RowSet是把Tablet切片成更小的單元。RowSet分為兩種，一種在內存里，叫MemRowSet,一種flush落地到磁盤上，叫DiskRowSet。

這兩種RowSet有些區(qū)別，首先，一個表只有一個MemRowSet,但是會有很多個DiskRowSet。當MemRowSet達到大小時(一般是32M)，才會刷新到磁盤上形成DiskRowSet。因為32M的大小并不大，所以不會造成HBase中Major Compaction的性能問題。

另外，MemRowSet中數據是行式存儲，實現(xiàn)形式是B+tree，它的存儲樣式為：

而DiskRowSet為列式存儲，它的存儲樣式為：

對于每一個DiskRowSet，它包含六個部分：BloomFile，AdhocIndex，UndoFile，RedoFile，BaseData，DeltaMem。

BloomFile是根據主鍵生成的一個Bloom Filter，用于模糊定位數據是否在DiskRowSet存在；

AdhocIndex則是主鍵的索引，用于定位主鍵在DiskRowSet的偏移量；

BaseData是上次Flush到磁盤的數據；

RedoFile是上次Flush到磁盤以后發(fā)生的數據變化；

UndoFile是上次Flush到磁盤之前的數據；

DeltaMem則是RedoFile生成之前的在內存和磁盤交互時的存儲格式。

DiskRowSet在磁盤上具體存儲為一個個的CFile文件, 需要注意的是，DiskRowSet這六部分并不是存在一個CFile中，而是獨立在多個CFile中的，每一部分都會形成單獨的CFile。

但實際上，無論是在KUDU Master還是KUDU Tablet Server上，我們見到實際存儲的都是都是.metadata文件和.data文件，像這種：

CFile文件在哪？和.data還有.metadata文件有什么關系？他們的關系像這樣：

.metadata文件記錄的是一個DiskRowSet中幾部分對應CFile的位置以及映射關系，而大量的CFile又被Container合并寫到一個.data文件中，因此對于一個DiskRowSet的正常讀寫，.metadata文件和.data文件缺一不可。

對于HDFS來說，無論讀還是寫，實際操作的是底層一個個數據文件，由于設計之初并不對文件中的內容做要求，因此只支持整個數據文件的新增，刪除或者向其中追加新的數據。而無法實現(xiàn)單條數據的更新和刪除，因為HDFS根本沒有辦法定位這條數據在哪里，而即便定位了，也需要把整個數據文件刪掉再重建才能把操作完成，這個代價太過昂貴。而如果是離線分析，HDFS倒是很有優(yōu)勢，雖然它不知道某條數據在哪里，但是它知道分析用到的整張表在哪里存儲并進行快速定位。

對于HBase來說，它底層仍然依賴于HDFS的文件塊存儲，但是它需要實現(xiàn)快速數據快速插入，更新和刪除。那它怎么實現(xiàn)呢？和KUDU一樣，HBase借用了內存來進行處理，在內存中有MemStore,所有寫入HBase的數據都變成一個Key-Value的鍵值對，當然這個Key不只是一個字段，而是Rowkey+Column Family+Column Qualifier+Timestamp+Type的組成，而Value是Column Qualifier所對應的值。當MemStore到達一定大小后，會Flush到磁盤行程HFile，而HFile對應一個個HDFS的BLOCK文件，MemStore以及HFile中要求Key必須是高度有序的，因此可以快速定位數據，HBase對表的所有的插入和更新都轉換成對HDFS的HFile文件的創(chuàng)建。這樣一來數據更新和刪除的問題解決了，但是要做離線分析就復雜了，因為除了Key以外的其他數據無法定位，而且將HDFS數據文件經過一次轉換，在最差情況下可能需要SCAN全表才能找到分析需要的數據。

KUDU的數據處理流程和HBase有些類似，但是為了滿足更高要求的數據一致性以及數據分析能力，KUDU的數據寫入過程比HBase更加復雜，因此KUDU的隨機讀寫效率是要比HBase差一些的。但是它又有一些新的特性比HBase更優(yōu)秀，例如：

● KUDU的數據分區(qū)方式多樣化，而HBase單一化；

● KUDU底層采用本地文件系統(tǒng)，而HBase底層采用HDFS；

● KUDU本身就有Catalog Table的機制，因此和Impala集成時運作效率很高，而HBase這點基本上；

● KUDU的Compaction產生的IO量非常小，不會產生性能問題，而HBase大表的Major Compaction很容易誘發(fā)性能問題。

KUDU與HDFS相比，它雖然實現(xiàn)了數據的快速更新，刪除等需求，但是它也有以下不足的地方：

● KUDU的穩(wěn)定性較差，節(jié)點故障或者磁盤損壞都會導致數據一致性風險；

● KUDU Compaction的文件小但是數量多，因此系統(tǒng)的打開文件數限制需要設置的比較大；

● KUDU運行時需要較多的內存。

KUDU目前版本已經發(fā)展到1.11.1。除上述情況外，仍然存在一些使用上的限制：

◆ 表創(chuàng)建后，主鍵不能修改；

◆ 主鍵列大小不能大于16K，且必須在非主鍵列之前；

◆ KUDU中的表只能支持300列；

◆ 不能使用Alter Table改變現(xiàn)有列的類型和屬性；

◆ 副本數在建表時，后續(xù)無法修改；

◆ 表名和列名必須為有效的UTF-8字符串，256字符，且不支持其他編碼類型；

◆ 刪除部分數據不會立刻釋放存儲空間，必須等待KUDU內部執(zhí)行Compaction后才會釋放，但如果刪除整張表，存儲空間會立即釋放。