KUDU 學習筆記
Kudu
現存系統針對結構化數據存儲與查詢的一些痛點問題，結構化數據的存儲，通常包含如下兩種方式：
- 靜態數據通常以Parquet/Carbon/Avro形式直接存放在HDFS中，吞吐能力大，適合離線分析，隨機讀寫能力差，難以支持單條記錄級別的更新。
- 可變數據的存儲通常選擇面向列族的HBase或者Cassandra，高效隨機讀寫，吞吐能力小，不適合離線分析場景。
Kudu的設計是結合了Hbase的高效隨機讀寫和HDFS高吞吐能力一種折中處理，既能支持OLTP型實時讀寫能力又能支持OLAP型分析。另外一個初衷Kudu作為一個新的分佈式存儲系統期望有效提升CPU的使用率，而低CPU使用率恰是HBase/Cassandra等系統的最大問題。
Kudu架構
Kudu採用了Master-Slave主從架構，一個table表會按照主鍵進行hash/或者range（分區）劃分出多個小的tablet（相當於Hbase里的Region），每個小的tablet會對應多個副本（其中1個Leader tablet用於讀寫，其他的副本為Follower tablet用於只讀），這個小的tablet會分到各個Tablet Server 中，這些tablet相關信息存儲在Master Server中（1個Leader多個Follower）。
Master Server
1用來存放一些表的Schema信息，且負責處理建表等請求，管理元數據(元數據存儲在只有一個tablet的Catalog table中)，即tablet與表的基本信息。
2. 跟蹤管理集群中的所有的Tablet Server，並且在Tablet Server異常之後協調數據的重部署。
3. 存放Tablet到Tablet Server的部署信息。
其中Catalog Table元數據表，用來存儲table(schema、locations、states)與tablet（現有的tablet列表，每個tablet及其副本所處Tablet Server，tablet當前狀態以及開始和結束鍵）的信息。
Tablet Server
存儲tablet和為tablet向client提供服務。對於給定的tablet，一個Tablet Server充當leader，其他Tablet Server充當該tablet的follower副本。只有leader服務寫請求，leader與follower為每個服務提供讀請求。
Tablet與HBase中的Region大致相似，但存在如下一些明顯的區別點：
分區策略不一樣
Tablet包含兩種分區策略，一種是基於Hash Partition方式，在這種分區方式下用戶數據可較均勻的分佈在各個Tablet中，但原來的數據排序特點已被打亂。另外一種是基於Range Partition（分區）方式，數據將按照用戶數據指定的有序的分區鍵的組合String的順序進行分區。而HBase中僅僅提供了一種按用戶數據RowKey的Range Partition方式。
多副本機制不一樣
一個Tablet可以被部署到了多個Tablet Server中，由自己系統管理，不依賴HDFS。在HBase最初的架構中，一個Region只能被部署在一個RegionServer中，它的數據多副本交由HDFS來保障。
數據文件存儲結構
具體結構如下
數據的讀寫更操作
不管數據的讀寫，還是更新操作，其大致都需要先查找我們要的數據的主鍵所對應的位置，比如下面的寫操作
寫流程
Client首先連接Master，獲取元數據信息。然後連接Tablet Server，查找MemRowSet與DeltMemStore中是否存在相同primary key，如果存在，則報錯;如果不存在，則將待插入的數據寫入WAL日誌，然後將數據寫入MemRowSet。
1、client向Master請求預寫表的元數據信息
2、Master會進行一定的校驗，表是否存在，字段是否存在等
3、如果Master校驗通過，則返回表的分區、tablet與其對應的Tablet Server給client；如果校驗失敗則報錯給client。
4、client根據Master返回的元數據信息，將請求發送給tablet對應的Tablet Server.
5、Tablet Server首先會查詢內存中MemRowSet與DeltMemStore中是否存在與待插入數據主鍵相同的數據，如果存在則報錯。
6、Tablet Server會講寫請求預寫到WAL日誌，用來server宕機後的恢復操作
7、將數據寫入內存中的MemRowSet中，一旦MemRowSet的大小達到1G或120s後，MemRowSet會flush成一個或DiskRowSet,用來將數據持久化
8、返回client數據處理完畢
更新流程
Client首先向Master請求元數據，然後根據元數據提供的tablet信息，連接Tablet Server，根據數據所處位置的不同，有不同的操作:在內存MemRowSet中的數據，會將更新信息寫入數據所在行的mutation鏈表中；在磁盤中的數據，會將更新信息寫入DeltMemStore中。
1、client向Master請求預更新表的元數據，首先Master會校驗表是否存在，字段是否存在，如果校驗通過則會返回給client表的分區、tablet、tablet所在Tablet Server信息
2、client向Tablet Server發起更新請求
3、將更新操作預寫如WAL日誌，用來在server宕機後的數據恢復
4、根據Tablet Server中待更新的數據所處位置的不同，有不同的處理方式:
如果數據在內存中，則從MemRowSet中找到數據所處的行，然後在改行的mutation鏈表中寫入更新信息，在MemRowSet flush的時候，將更新合併到baseData中
如果數據在DiskRowSet中，則將更新信息寫入DeltMemStore中，DeltMemStore達到一定大小後會flush成DeltFile。
5、更新完畢後返回消息給client。
讀流程
客戶端將要讀取的數據信息發送給Master，Master對其進行一定的校驗，比如表是否存在，字段是否存在。Master返回元數據信息給client，然後client與Tablet Server建立連接，通過metaData找到數據所在的RowSet，首先加載內存裏面的數據(MemRowSet與DeltMemStore),然後加載磁盤裏面的數據，最後返回最終數據給client.
1、客戶端Master請求查詢表指定數據
2、Master對請求進行校驗，校驗表是否存在，schema中是否存在指定查詢的字段，主鍵是否存在
3、Master通過查詢Catalog Table返回表，將tablet對應的Tablet Server信息、Tablet Server狀態等元數據信息返回給client
4、client與Tablet Server建立連接，通過metaData找到primary key對應的RowSet。
5、首先加載RowSet內存中MemRowSet與DeltMemStore中的數據
6、然後加載磁盤中的數據，也就是DiskRowSet中的BaseData與DeltFile中的數據
7、返回數據給Client
8、繼續4-7步驟，直到拿到所有數據返回給client
參考
//blog.csdn.net/nosqlnotes/article/details/79496002
//blog.csdn.net/a376554764/article/details/89445319
