特點：
High availability（高可用性）。Tablet server 和 Master 使用 Raft Consensus Algorithm 來保證節點的高可用，確保只要有一半以上的副本可用，該 tablet 便可用於讀寫。例如，如果3個副本中有2個或5個副本中的3個可用，則該tablet可用。即使在 leader tablet 出現故障的情況下，讀取功能也可以通過 read-only（只讀的）follower tablets 來進行服務，或者是leader宕掉的情況下，會根據raft機制重新選舉leader。
基礎概念：
開發語言：C++
Columnar Data Store（列式數據存儲）
Read Efficiency（高效讀取）
對於分析查詢，允許讀取單個列或該列的一部分同時忽略其他列
Data Compression（數據壓縮）
由於給定的列只包含一種類型的數據，基於模式的壓縮比壓縮混合數據類型（在基於行的解決案中使用）時更有效幾個數量級。結合從列讀取數據的效率，壓縮允許您在從磁盤讀取更少的塊時完成查詢
Table（表）
一張table是數據存儲在 Kudu 的位置。表具有schema和全局有序的primary key（主鍵）。table被分成很多段，也就是稱為tablets。
Tablet（段）
一個tablet是一張table連續的segment，與其它數據存儲引擎或關系型數據庫的partition（分區）相似。給定的tablet冗余到多個tablet服務器上，並且在任何給定的時間點，其中一個副本被認為是leader tablet。任何副本都可以對讀取進行服務，並且寫入時需要在為tablet服務的一組tablet server之間達成一致性。
一張表分成多個tablet，分布在不同的tablet server中，最大並行化操作
Tablet在Kudu中被切分為更小的單元，叫做RowSets，RowSets分為兩種MemRowSets和DiskRowSet，MemRowSets每生成32M，就溢寫到磁盤中，也就是DiskRowSet
Tablet Server
一個tablet server存儲tablet和為tablet向client提供服務。對於給定的tablet，一個tablet server充當 leader，其他tablet server充當該 tablet 的follower副本。只有leader服務寫請求，然而leader或followers為每個服務提供讀請求。leader使用Raft Consensus Algorithm來進行選舉 。一個tablet server可以服務多個tablets，並且一個 tablet 可以被多個tablet servers服務着。
Master
該master保持跟蹤所有的tablets，tablet servers，Catalog Table 和其它與集群相關的metadata。在給定的時間點，只能有一個起作用的master（也就是 leader）。如果當前的 leader 消失，則選舉出一個新的master，使用 Raft Consensus Algorithm來進行選舉。
master還協調客戶端的metadata operations（元數據操作）。例如，當創建新表時，客戶端內部將請求發送給master。 master將新表的元數據寫入catalog table，並協調在tablet server上創建 tablet 的過程。
所有master的數據都存儲在一個 tablet 中，可以復制到所有其他候選的 master。
tablet server以設定的間隔向master發出心跳（默認值為每秒一次）。
master是以文件的形式存儲在磁盤中，所以說，第一次初始化集群。需要設定好
Raft Consensus Algorithm
Kudu 使用 Raft consensus algorithm 作為確保常規 tablet 和 master 數據的容錯性和一致性的手段。通過 Raft，tablet 的多個副本選舉出 leader，它負責接受以及復制到 follower 副本的寫入。一旦寫入的數據在大多數副本中持久化后，就會向客戶確認。給定的一組 N 副本（通常為 3 或 5 個）能夠接受最多(N - 1)/2 錯誤的副本的寫入。
Catalog Table（目錄表）
catalog table是Kudu 的 metadata（元數據中）的中心位置。它存儲有關tables和tablets的信息。該catalog table（目錄表）可能不會被直接讀取或寫入。相反，它只能通過客戶端 API中公開的元數據操作訪問。catalog table 存儲兩類元數據。
Tables
table schemas, locations, and states（表結構，位置和狀態）
Tablets
現有tablet 的列表，每個 tablet 的副本所在哪些tablet server，tablet的當前狀態以及開始和結束的keys（鍵）。
注意：
1、建表的時候要求所有的tserver節點都活着
2、根據raft機制，允許（replication的副本數-）/ 2宕掉，集群還會正常運行，否則會報錯找不到ip:7050（7050是rpc的通信端口號），需要注意一個問題，第一次運行的時候要保證集群處於正常狀態下，也就是所有的服務都啟動，如果運行過程中，允許（replication的副本數-）/ 2宕掉
3、讀操作，只要有一台活着的情況下，就可以運行
上圖顯示了一個具有三個 master 和多個tablet server的Kudu集群，每個服務器都支持多個tablet。它說明了如何使用 Raft 共識來允許master和tablet server的leader和follow。此外，tablet server 可以成為某些 tablet 的 leader，也可以是其他 tablet follower。leader以金色顯示，而 follower 則顯示為藍色。
測試：
3個tablet server，單線程
50萬行數據，每行數據是120字節，時間： 1828行/s，14分鍾23秒，70M/s
總結：
1、KUDU分區數必須預先預定
2、在內存中對每個Tablet分區維護一個MemRowSet來管理最新更新的數據，當尺寸超過32M后Flush到磁盤上形成DiskRowSet，多個DiskRowSet在適當的時候進行歸並處理
3、和HBase采用的LSM（LogStructured Merge，很難對數據進行特殊編碼，所以處理效率不高）方案不同的是，Kudu對同一行的數據更新記錄的合並工作，不是在查詢的時候發生的（HBase會將多條更新記錄先后Flush到不同的Storefile中，所以讀取時需要掃描多個文件，比較rowkey，比較版本等，然后進行更新操作），而是在更新的時候進行，在Kudu中一行數據只會存在於一個DiskRowSet中，避免讀操作時的比較合並工作。那Kudu是怎么做到的呢？ 對於列式存儲的數據文件，要原地變更一行數據是很困難的，所以在Kudu中，對於Flush到磁盤上的DiskRowSet（DRS）數據，實際上是分兩種形式存在的，一種是Base的數據，按列式存儲格式存在，一旦生成，就不再修改，另一種是Delta文件，存儲Base數據中有變更的數據，一個Base文件可以對應多個Delta文件，這種方式意味着，插入數據時相比HBase，需要額外走一次檢索流程來判定對應主鍵的數據是否已經存在。因此，Kudu是犧牲了寫性能來換取讀取性能的提升。
更新、刪除操作需要記錄到特殊的數據結構里，保存在內存中的DeltaMemStore或磁盤上的DeltaFIle里面。DeltaMemStore是B-Tree實現的，因此速度快，而且可修改。磁盤上的DeltaFIle是二進制的列式的塊，和base數據一樣都是不可修改的。因此當數據頻繁刪改的時候，磁盤上會有大量的DeltaFiles文件，Kudu借鑒了Hbase的方式，會定期對這些文件進行合並。 
4、既然存在Delta數據，也就意味着數據查詢時需要同時檢索Base文件和Delta文件，這看起來和HBase的方案似乎又走到一起去了，不同的地方在於，Kudu的Delta文件與Base文件不同，不是按Key排序的，而是按被更新的行在Base文件中的位移來檢索的，號稱這樣做，在定位Delta內容的時候，不需要進行字符串比較工作，因此能大大加快定位速度，但是無論如何，Delta文件的存在對檢索速度的影響巨大。因此Delta文件的數量會需要控制，需要及時的和Base數據進行合並。由於Base文件是列式存儲的，所以Delta文件合並時，可以有選擇性的進行，比如只把變化頻繁的列進行合並，變化很少的列保留在Delta文件中暫不合並，這樣做也能減少不必要的IO開銷。
5、除了Delta文件合並，DRS自身也會需要合並，為了保障檢索延遲的可預測性（這一點是HBase的痛點之一，比如分區發生Major Compaction時，讀寫性能會受到很大影響），Kudu的compaction策略和HBase相比，有很大不同，kudu的DRS數據文件的compaction，本質上不是為了減少文件數量，實際上Kudu DRS默認是以32MB為單位進行拆分的，DRS的compaction並不減少文件數量，而是對內容進行排序重組，減少不同DRS之間key的overlap（重復），進而在檢索的時候減少需要參與檢索的DRS的數量。 
原文鏈接： http://blog.csdn.net/weixin_39478115/article/details/78470162