技術(shù)干貨 | 說說KUDU的小秘密

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BaseData是上次Flush到磁盤的數(shù)據(jù)；

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

UndoFile是上次Flush到磁盤之前的數(shù)據(jù)；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

● KUDU運行時需要較多的內(nèi)存。

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

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

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

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

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

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

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

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