不多說，直接上干貨！
Kudu的架構
1、kudu的 基本框架
Kudu 是用於存儲結構化（ structured ）的表（ Table ）。表有預定義的帶類型的列（ Columns ），每張表有一個主鍵（ primary key ）。主鍵帶有唯一性（ uniqueness ）限制，可作為索引用來支持快速的 random access 。
類似於 BigTable ， Kudu 的表是由很多數據子集構成的，表（Table）被水平拆分成多個 Tablets（片）。Kudu 用以每個 tablet 為一個單元來實現數據的 durability （持久化）。 Tablet（片） 有多個副本，同時在多個節點上進行持久化。
Kudu 有兩種類型的組件， Master Server 和 Tablet Server 。
（1） Master Server 負責管理元數據。這些元數據包括 talbet 的基本信息，位置信息。 Master 還作為負載均衡服務器，監聽 Tablet Server 的健康狀態。對於副本數過低的 Tablet ， Master 會在起 replication 任務來提高其副本數。 Master 的所有信息都在內存中 cache ，因此速度非常快。每次查詢都在百毫秒級別。 Kudu 支持多個 Master ，不過只有一個 active Master ，其余只是作為災備，不提供服務。
（2） Tablet Server 上存了 10~100 個 Tablets ，每個 Tablet 有 3 （或 5 ）個副本存放在不同的 Tablet Server 上，每個 Tablet 同時只有一個 leader 副本，這個副本對用戶提供修改操作，然后將修改結果同步給 follower 。 Follower 只提供讀服務，不提供修改服務。副本之間使用 raft 協議來實現 High Availability ，當 leader 所在的節點發生故障時， followers 會重新選舉 leader 。根據官方的數據，其 MTTR 約為 5 秒，對 client 端幾乎沒有影響。 Raft 協議的另一個作用是實現 Consistency 。 Client 對 leader 的修改操作，需要同步到 N/2+1 個節點上，該操作才算成功。
Kudu 采用了類似 log-structured 存儲系統的方式，增刪改操作都放在內存中的 buffer ，然后才 merge 到持久化的列式存儲中。 Kudu 還是用了 WALs 來對內存中的 buffer 進行災備。
2. 列式存儲
持久化的列式存儲存儲，與 HBase 完全不同，而是使用了類似 Parquet 的方式，同一個列在磁盤上是作為一個連續的塊進行存放的。例如，圖中左邊是 twitter 保存推文的一張表，而圖中的右邊表示了表在磁盤中的的存儲方式，也就是將同一個列放在一起存放。這樣做的第一個好處是，對於一些聚合和 join 語句，我們可以盡可能地減少磁盤的訪問。
例如，我們要用戶名為 newsycbot的推文數量，使用查詢語句：
SELECT COUNT(*) FROM tweets WHERE user_name = ‘newsycbot’;
我們只需要查詢 User_name 這個 block（塊） 即可。同一個列的數據是集中的，而且是相同格式的， Kudu 可以對數據進行編碼，例如字典編碼，行長編碼， bitshuffle 等。通過這種方式可以很大的減少數據在磁盤上的大小，提高吞吐率。除此之外，用戶可以選擇使用通用的壓縮格式對數據進行壓縮，如 LZ4, gzip, 或 bzip2 。這是可選的，用戶可以根據業務場景，在數據大小和 CPU 效率上進行權衡。這一部分的實現上， Kudu 很大部分借鑒了 Parquet 的代碼。
HBase 支持 snappy 存儲，然而因為它的 LSM 的數據存儲方式，使得它很難對數據進行特殊編碼，這也是 Kudu 聲稱具有很快的 scan 速度的一個很重要的原因。不過，因為列式編碼后的數據很難再進行修改，因此當這寫數據寫入磁盤后，是不可變的，這部分數據稱之為 base 數據。 Kudu 用 MVCC （多版本並發控制）來實現數據的刪改功能。更新、刪除操作需要記錄到特殊的數據結構里，保存在內存中的 DeltaMemStore 或磁盤上的 DeltaFIle 里面。 DeltaMemStore 是 B-Tree 實現的，因此速度快，而且可修改。磁盤上的 DeltaFIle 是二進制的列式的塊，和 base 數據一樣都是不可修改的。因此當數據頻繁刪改的時候，磁盤上會有大量的 DeltaFiles 文件， Kudu 借鑒了 Hbase 的方式，會定期對這些文件進行合並。
下圖顯示了一個具有三個 master 和多個 tablet server 的 Kudu 集群，每個服務器都支持多個 tablet。它說明了如何使用 Raft 共識來允許 master 和 tablet server 的 leader 和 follow。此外，tablet server 可以成為某些 tablet 的 leader，也可以是其他 tablet 的 follower。leader 以金色顯示，而 follower 則顯示為藍色。
