不多說，直接上干貨！
Cloudera Kudu是什么？
kudu是cloudera在2012開始秘密研發的一款介於hdfs和hbase之間的高速分布式列式存儲數據庫。兼具了hbase的實時性、hdfs的高吞吐，以及傳統數據庫的sql支持。作為一款實時、離線之間的存儲系統。定位和spark在計算系統中的地位非常相似。如果把mr+hdfs作為離線計算標配，storm+hbase作為實時計算標配。spark+kudu有可能成為未來最有競爭力的一種架構。
也就是kafka -> spark -> kudu這種架構，未來此架構是否會風靡，暫且不言論。讓我們拭目以待吧！
Kudu是Cloudera開源的新型列式存儲系統，是Apache Hadoop生態圈的新成員之一（incubating），專門為了對快速變化的數據進行快速的分析，填補了以往Hadoop存儲層的空缺。
Kudu是Todd Lipcon@Cloudera帶頭開發的存儲系統，其整體應用模式和HBase比較接近，即支持行級別的隨機讀寫，並支持批量順序檢索功能。
Kudu 是一個針對 Apache Hadoop 平台而開發的列式存儲管理器。Kudu 共享 Hadoop 生態系統應用的常見技術特性:它在commodity hardware（商品硬件）上運行，horizontally scalable（水平可擴展），並支持 highly available（高可用）性操作。
Kudu的目標是：提供快速的全量數據分析與實時處理功能；充分利用先進CPU與IO資源；支持數據更新；簡單、可擴展的數據模型。
Kudu的官網
http://kudu.apache.org/
A new addition to the open source Apache Hadoop ecosystem, Apache Kudu completes Hadoop's storage layer to enablefast analytics on fast data.
背景——功能上的空白
Hadoop 生態系統有很多組件，每一個組件有不同的功能。在現實場景中，用戶往往需要同時部署很多 Hadoop 工具來解決同一個問題，這種架構稱為 混合架構 (hybrid architecture) 。 比如，用戶需要利用 Hbase 的快速插入、快讀 random access 的特性來導入數據， HBase 也允許用戶對數據進行修改， HBase 對於大量小規模查詢也非常迅速。同時，用戶使用 HDFS/Parquet + Impala/Hive 來對超大的數據集進行查詢分析，對於這類場景， Parquet 這種列式存儲文件格式具有極大的優勢。
很多公司都成功地部署了 HDFS/Parquet + HBase 混合架構，然而這種架構較為復雜，而且在維護上也十分困難。首先，用戶用 Flume 或 Kafka 等數據 Ingest 工具將數據導入 HBase ，用戶可能在 HBase 上對數據做一些修改。然后每隔一段時間 ( 每天或每周 ) 將數據從 Hbase 中導入到 Parquet 文件，作為一個新的 partition 放在 HDFS 上，最后使用 Impala 等計算引擎進行查詢，生成最終報表。
這樣一條工具鏈繁瑣而復雜，而且還存在很多問題，比如：
（1）如何處理某一過程出現失敗？
（2）從 HBase 將數據導出到文件，多久的頻率比較合適？
（3）當生成最終報表時，最近的數據並無法體現在最終查詢結果上。
（4）維護集群時，如何保證關鍵任務不失敗？
（5）Parquet 是 immutable ，因此當 HBase 中刪改某些歷史數據時，往往需要人工干預進行同步。
這時候，用戶就希望能夠有一種優雅的存儲解決方案，來應付不同類型的工作流，並保持高性能的計算能力。 Cloudera 很早就意識到這個問題，在 2012 年就開始計划開發 Kudu 這個存儲系統，終於在 2015 年發布並開源出來。 Kudu 是對 HDFS 和 HBase 功能上的補充，能提供快速的分析和實時計算能力，並且充分利用 CPU 和 I/O 資源，支持數據原地修改，支持簡單的、可擴展的數據模型。
背景——新的硬件設備
RAM 的技術發展非常快，它變得越來越便宜，容量也越來越大。 Cloudera 的客戶數據顯示，他們的客戶所部署的服務器， 2012 年每個節點僅有 32GB RAM ，現如今增長到每個節點有 128GB 或 256GB RAM 。存儲設備上更新也非常快， 在很多普通服務器中部署 SSD 也是屢見不鮮。 HBase 、 HDFS 、以及其他的 Hadoop 工具都在不斷自我完善，從而適應硬件上的升級換代。然而，從根本上， HDFS 基於 03 年 GFS ， HBase 基於 05 年 BigTable ，在當時系統瓶頸主要取決於底層磁盤速度。當磁盤速度較慢時， CPU 利用率不足的根本原因是磁盤速度導致的瓶頸，當磁盤速度提高了之后， CPU 利用率提高，這時候 CPU 往往成為系統的瓶頸。 HBase 、 HDFS 由於年代久遠，已經很難從基本架構上進行修改，而 Kudu 是基於全新的設計，因此可以更充分地利用 RAM 、 I/O 資源，並優化 CPU 利用率。我們可以理解為， Kudu 相比與以往的系統， CPU 使用降低了， I/O 的使用提高了， RAM 的利用更充分了。
1. Kudu的簡介
Kudu 設計之初，是為了解決一下問題：
- 對數據掃描 (scan) 和隨機訪問 (random access) 同時具有高性能，簡化用戶復雜的混合架構；
- 高 CPU 效率，使用戶購買的先進處理器的的花費得到最大回報；
- 高 IO 性能，充分利用先進存儲介質；
- 支持數據的原地更新，避免額外的數據處理、數據移動。
2. Kudu支持跨數據中心 replication
Kudu 的很多特性跟 HBase 很像，它支持索引鍵的查詢和修改。 Cloudera 曾經想過基於 Hbase 進行修改，然而結論是對 HBase 的改動非常大， Kudu 的數據模型和磁盤存儲都與 Hbase 不同。 HBase 本身成功的適用於大量的其它場景，因此修改 HBase 很可能吃力不討好。最后 Cloudera 決定開發一個全新的存儲系統。
3. Kudu的對外接口
Kudu 提供 C++ 和 JAVA API ，可以進行單條或批量的數據讀寫， schema 的創建修改。除此之外， Kudu 還將與 hadoop 生態圈的其它工具進行整合。目前， kudu beta 版本對 Impala 支持較為完善，支持用 Impala 進行創建表、刪改數據等大部分操作。 Kudu 還實現了 KuduTableInputFormat 和 KuduTableOutputFormat ，從而支持 Mapreduce 的讀寫操作。同時支持數據的 locality（本地性） 。目前對 spark 的支持還不夠完善， spark 只能進行數據的讀操作。
4. 節點
Kudu-master：主節點，維護存儲表元數據，跟蹤協調所有的tserver的狀態和數據，安裝奇數節點(最少三個)。
Kudu-tserver：從節點，存儲具體表數據的節點，一個表數據可以有多個副本，但只有一個leader才能負責寫請求，leader和follower都可以負責讀請求。安裝最少三個節點。
使用案例——小米
為什么這里用小米來作為案例，是因為小米在Kudu走在前列。
小米是Hbase的重度用戶，他們每天有約50億條用戶記錄。小米目前使用的也是HDFS + HBase這樣的混合架構。可見該流水線相對比較復雜，其數據存儲分為SequenceFile，Hbase和Parquet。
在使用Kudu以后，Kudu作為統一的數據倉庫，可以同時支持離線分析和實時交互分析。如下：
