一、kudu是什麼？
Kudu和Hbase類似也是一個分佈式數據庫，據官方給它的定位是提供”fast analytics on fast data”（在更新更及時的數據上做更快的分析）。
據說Cloudera曾經想直接通過修改HBase來支持Kudu現在的功能，但是Kudu的數據模型和磁盤存儲都與Hbase不同，改造會非常大，所以Cloudera決定乾脆開發一個全新的存儲系統。
- 作爲Hadoop生態圈的一部分，對接生態系統的其他組件方便，會有官方提供的接口。
- kudu自己存儲數據不依賴與HDFS存儲；不依賴於zookeeper，將它的功能集成進了自身的TMaster。
- 和HBase類似的LSM結構，用於支持數據的隨機讀寫。
- 有表結構，需定義Schema信息。必須定義唯一鍵，這就造成了寫數據時多了一個判斷唯一的過程。需在寫入數據前定義好每一列的類型（方便做類似於parquet的列式存儲）。可以像關係型數據庫一樣用Alter增刪列，不具有HBase動態列的特性。
- 支持行級別的ACID。
- 目前不支持二級索引。
- 目前不支持BloomFilter優化join。
- 核心模塊用的C++來實現，沒有full gc的風險。
二、kudu解決了什麼問題？
HDFS和HBase是大數據最常用的兩種存儲方式，它們的優缺點非常明顯：
- HDFS，使用列式存儲格式Apache Parquet，Apache ORC，適合離線分析，不支持單條記錄級別的update操作，隨機讀寫性能差。
- HBase，可以進行高效隨機讀寫，卻並不適用於基於SQL的數據分析方向，大批量數據獲取時的性能較差。
那爲什麼HBase不適合做分析呢？
因爲分析需要批量獲取數據，而HBase本身的設計並不適合批量獲取數據
- HBase是列式數據庫，其實從底層存儲的角度來說它並不是列式的，獲取指定列數據時是會讀到其他列數據的。
- HBase是LSM-Tree架構的數據庫，這導致了HBase讀取數據路徑比較長，從內存到磁盤，可能還需要讀多個HFile文件做版本合併。
- LSM 的中心思想就是將隨機寫轉換爲順序寫來大幅提高寫入操作的性能，但是犧牲了部分讀的性能。
爲了讓數據平臺同時具備隨機讀寫和批量分析能力，傳統的做法是採用混合架構(hybrid architecture)，也就是我們常說的T+1的方式，數據實時更新在HBase，第二天凌晨同步到HDFS做離線分析。這樣的缺點很明顯，時效性差，數據鏈路長，過程複雜，開發成本高。
這個時候Kudu出現了
它是介於HDFS和HBase兩者之間的一個東西如下圖所示
它不及HDFS批處理快，也不及HBase隨機讀寫能力強，但是反過來它比HBase批處理快（適用於OLAP的分析場景），而且比HDFS隨機讀寫能力強（適用於實時寫入或者更新的場景），這就是它能解決的問題。