有了 HBase 為什麼還要 Kudu？

Kudu這東西估計很多同學都聽過但是沒用過，那麼我們先從最基本的問題開始：kudu是什麼？能做什麼？

kudu是什麼？

kudu和Hbase類似也是一個分散式資料庫，據官方給它的定位是提供”fast analytics on fast data”（ 在更新更及時的資料上做更快的分析 ）。

據說Cloudera曾經想直接通過修改HBase來支援kudu現在的功能，但是Kudu的資料模型和磁碟儲存都與Hbase不同，改造會非常大，所以Cloudera決定乾脆開發一個全新的儲存系統。

0.作為Hadoop生態圈的一部分，對接生態系統的其他元件方便，會有官方提供的介面

1.kudu自己儲存資料不依賴與HDFS儲存；不依賴於zookeeper，將它的功能整合進了自身的TMaster；

2.和HBase類似的LSM結構，用於支援資料的隨機讀寫。

3.有表結構，需定義Schema資訊

- 必須定義唯一鍵，這就造成了寫資料時多了一個判斷唯一的過程。

• 需在寫入資料前定義好每一列的型別（方便做類似於parquet的列式儲存）

• 可以像關係型資料庫一樣用Alter增刪列，不具有HBase動態列的特性

4.支援行級別的ACID

5.目前不支援二級索引

6.目前不支援BloomFilter優化join

7.核心模組用的C++來實現，沒有full gc的風險

kudu解決了什麼問題？

HDFS和HBase是大資料最常用的兩種儲存方式，它們的優缺點非常明顯：

HDFS，使用列式儲存格式Apache Parquet，Apache ORC，適合離線分析， 不支援單條記錄級別的update操作，隨機讀寫效能差 。這個就不多說了，用過HDFS的同學應該都知道這個特點。

HBase，可以進行高效隨機讀寫， 卻並不適用於基於SQL的資料分析方向，大批量資料獲取時的效能較差 。

那為什麼HBase不適合做分析呢？

因為分析需要批量獲取資料，而HBase本身的設計並不適合批量獲取資料

1）都說HBase是列式資料庫，其實從底層儲存的角度來說它並不是列式的，獲取指定列資料時是會讀到其他列資料的。看過我之前文章的同學應該比較清楚就不多說了。相對而言Parquet格式針對分析場景就做了很多優化。

2）HBase是LSM-Tree架構的資料庫，這導致了HBase讀取資料路徑比較長，從記憶體到磁碟，可能還需要讀多個HFile檔案做版本合併。

LSM 的中心思想就是 將隨機寫轉換為順序寫來大幅提高寫入操作的效能 ，但是犧牲了部分讀的效能。

隨機讀寫是指對任意一個位置的讀和寫，磁碟隨機讀寫慢是因為需要尋道，倒帶才可以訪問到指定儲存點，而記憶體不需要，可以任意指定儲存點

為了讓資料平臺同時具備隨機讀寫和批量分析能力，傳統的做法是採用混合架構(hybrid architecture)，也就是我們常說的T+1的方式，資料實時更新在HBase，第二天凌晨同步到HDFS做離線分析。這樣的缺點很明顯，時效性差，資料鏈路長，過程複雜，開發成本高。

這個時候Kudu出現了，它是介於HDFS和HBase兩者之間的一個東西如下圖所示，

它不及HDFS批處理快，也不及HBase隨機讀寫能力強，但是反過來 它比HBase批處理快（適用於OLAP的分析場景），而且比HDFS隨機讀寫能力強（適用於實時寫入或者更新的場景） ，這就是它能解決的問題。

————————————————

最近真的忙，停更了接近一個月，抱歉，好多同學催更，感謝有那麼多同學的支援，這一篇先簡單地介紹了下kudu，接下來還會有一系列的文章，2019年將繼續輸出，感謝關注。