不多說，直接上干貨！
那既然有了HBase，為什么還需要Kudu呢？
簡單的說，就是嫌棄HBase在OLAP（聯機分析處理）場合，SQL／MR類的批量檢索場景中，性能不夠好。通常這種海量數據OLAP場景，要不走預處理的路，比如像EBAY麒麟這樣走Cube管理的，或者像谷歌Mesa這樣按業務需求走預定義聚合操作。再有就是自己構建數據通道，串接實時和批量處理兩種系統，發揮各自的特長。
但是OLAP是個復雜的問題，場景眾多，必然不可能有完美的通用解決方案，Kudu定位於應對快速變化數據的快速分析型數據倉庫，希望靠系統自身能力，支撐起同時需要高吞吐率的順序和隨機讀寫的應用場景（可能的場景，比如時間序列數據分析，日志數據實時監控分析），提供一個介於HDFS和HBase的性能特點之間的一個系統，在隨機讀寫和批量掃描之間找到一個平衡點，並保障穩定可預測的響應延遲。
結構化數據存儲系統在 Hadoop 生態系統里面，通常分為兩類：
- 靜態數據，數據通常都是使用二進制格式存放到 HDFS 上面，譬如 Apache Avro，Apache Parquet。但無論是 HDFS 還是相關的系統，都是為高吞吐連續訪問數據這些場景設計的，都沒有很好的支持單獨 record 的更新，或者是提供好的隨機訪問的能力。
- 動態數據，數據通常都是使用半結構化的方式存儲，譬如 Apache HBase，Apache Cassandra。這些系統都能低延遲的讀寫單獨的 record，但是對於一些像 SQL 分析這樣需要連續大量讀取數據的場景，顯得有點捉緊見拙。
上面的兩種系統，各有自己的側重點，一類是低延遲的隨機訪問特定數據，而另一類就是高吞吐的分析大量數據。之前，我們並沒有這樣的系統可以融合上面兩種情況，所以通常的做法就是使用 pipeline，譬如我們非常熟悉的 Kafka，通常我們會將數據快速寫到 HBase 等系統里面，然后通過 pipeline，在導出給其它分析系統。雖然我們在一定層面上面，我們其實通過 pipeline 來對整個系統進行了解耦，但總歸要維護多套系統。而且數據更新之后，並不能直接實時的進行分析處理，有延遲的開銷。所以在某些層面上面，並不是一個很好的解決方案。
Kudu 致力於解決上面的問題，它提供了簡單的來處理數據的插入，更新和刪除，同時提供了 table scan 來處理數據分析。通常如果一個系統要融合兩個特性，很有可能就會陷入兩邊都做，兩邊都沒做好的窘境，但 Kudu 很好的在融合上面取得了平衡。
那為什么不能想辦法改進HBase呢？
Kudu 的很多特性跟 HBase 很像，它支持索引鍵的查詢和修改。 Cloudera 曾經想過基於 Hbase 進行修改，然而結論是對 HBase 的改動非常大， Kudu 的數據模型和磁盤存儲都與 Hbase 不同。 HBase 本身成功的適用於大量的其它場景，因此修改 HBase 很可能吃力不討好。最后 Cloudera 決定開發一個全新的存儲系統。