有了 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年將繼續輸出,感謝關注。
覺得有價值請關注 ▼