Kudu是由Todd Lipcon@Cloudera帶頭開發出存儲系統，整體應用模式與HBase很相似，也就是能夠支持行級別的隨機讀寫，對于批量順序檢索功能也能支持。

一、Kudu的必要性

大家不禁要問了?既然與HBase相似，那為什么有了HBase，還需要Kudu呢?

Kudu的定位是 「Fast Analytics on Fast Data」，也就是在更新更及時的基礎上實現更快的數據分析。

目前數據存儲有了HDFS和Hbase，但兩者都存在這明顯的缺點，這才需要Kudu。

HDFS:使用列式存儲格式Apache Parquet，Apache ORC，適合離線分析，不支持單條紀錄級別的update操作，無法進行隨機讀寫

HBASE:可以進行高效隨機讀寫，卻并不適用于基于SQL的數據分析方向，不適用于批量數據分析的場景。

二、Kudu整體架構

Table（表）：一張table是數據存儲在kudu的位置。Table具有schema和全局有序的primary key(主鍵)。Table被分為很多段，也就是tablets.

Tablet (段)：一個tablet是一張table連續的segment，與其他數據存儲引擎或關系型數據的partition類似。Tablet存在副本機制，其中一個副本為leader tablet。任何副本都能夠對服務讀取，而且寫入時需要在所有副本對應的tablet server之間達成一致性。

Tablet server：主要是存儲tablet和為tablet向client提供服務。對于給定的tablet，一個tablet server充當leader，其他tablet server充當該tablet的follower副本。只有leader服務寫請求，leader與follower為每個服務提供讀請求。

Master：主要負責管理元數據(元數據存儲在只有一個tablet的catalog table中)，即tablet與表的基本信息，監聽tserver的狀態

Catalog Table: 元數據表，用來存儲table(schema、locations、states)與tablet（現有的tablet列表，每個tablet及其副本所處tserver，tablet當前狀態以及開始和結束鍵）的信息。

三、Kudu優缺點

1.優點：

1)一個table由多個tablet組成，能夠很好地支持分區查看、擴容和數據高可用。

2)可以支持update和upsert操作。

3)與imapla集成或spark集成后(dataframe)可通過標準的sql操作，使用起來很便捷

4)可與spark系統集成

2.缺點：

1)只有主鍵可以設置range分區。

2)如果是pyspark連接kudu，則不能對kudu進行額外的操作。

3)kudu的shell客戶端不提供表schema查看。