一文快速搞懂Kudu到底是什么

引言

大家好,我是ChinaManor,直譯過來就是中國碼農的意思,俺希望自己能成為國家復興道路的鋪路人,大資料領域的耕耘者,一個平凡而不平庸的人，

Kudu 介紹

近兩年， KUDU 在大資料平臺的應用越來越廣泛，在 阿里、小米、網易 等公司的大資料架構中，

KUDU 都有著不可替代的地位，

背景介紹

在 Kudu之前，大資料主要以兩種方式存盤：

? 靜態資料：

? 以 HDFS 引擎作為存盤引擎，適用于 高吞吐量的離線大資料分析 場景；

? 這類存盤的局限性是 資料無法進行隨機的讀寫；

? 動態資料：

? 以 HBase、 Cassandra 作為存盤引擎，適用于 大資料隨機讀寫 場景；

? 這類存盤的局限性是 批量讀取吞吐量遠不如 HDFS，不適用于批量資料分析的場景 ；

從上面分析可知，兩種資料在 存盤方式上 完全不同，進而導致使用場景完全不同，但在真實的場景

中，邊界可能沒有那么清晰，面對 既需要隨機讀寫，又需要批量分析的大資料場景，該如何選擇呢？

這個場景中，單種存盤引擎無法滿足業務需求，需要通過多種大資料工具組合來滿足這一需求，

如上圖所示， 資料實時寫入 HBase，實時的資料更新也在 HBase完成，為了應對 OLAP需求，

定時（通常是 T+1或者 T+H）將 HBase資料寫成靜態的檔案（如： Parquet）匯入到 OLAP引擎（如：

HDFS）， 這一架構能滿足既需要隨機讀寫，又可以支持 OLAP 分析的場景，但它有如下 缺點：

? 架構復雜 ，從架構上看，資料在 HBase、訊息佇列、 HDFS 間流轉，涉及環節太多，運維成本

很高，并且每個環節需要保證高可用，都需要維護多個副本，存盤空間也有一定的浪費，最后

資料在多個系統上，對資料安全策略、監控等都提出了挑戰，

? 時效性低 ，資料從 HBase匯出成靜態檔案是周期性的，一般這個周期是一天（或一小時），在

時效性上不是很高，

? 難以應對后續的更新， 真實場景中，總會有資料是延遲到達的，如果這些資料之前已經從 HBase

匯出到 HDFS，新到的變更資料就難以處理了，一個方案是把原有資料應用上新的變更后重寫

一遍，但這代價又很高，

為了解決上述架構的這些問題， Kudu應運而生， Kudu的定位是 Fast Analytics on Fast Data，

是一個 既支持隨機讀寫、又支持 OLAP 分析的大資料存盤引擎 ，

從上圖可以看出， KUDU 是一個 折中的產品 ，在 HDFS 和 HBase 這兩個偏科生中平衡了隨

機讀寫和批量分析的性能，從 KUDU 的誕生可以說明一 個觀點： 底層的技術發展很多時候都是上

層的業務推動的，脫離業務的技術很可能是空中樓閣 ，

新的硬體設備

記憶體（ 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的利用更充分了 ，

Kudu 是什么

Apache Kudu是由 Cloudera開源的 存盤引擎 ，可以同時提供 低延遲的隨機讀寫和高效的資料分

析能力 ，它是一個融合 HDFS和 HBase的功能的新組件，具備介于兩者之間的新存盤組件，

Kudu支持水平擴展，并且與 Cloudera Impala和 Apache Spark等當前流行的大資料查詢和分析

工具結合緊密，

Kudu 應用場景

Kudu的很多特性 跟 HBase很像，它支持索引鍵的查詢和修改 ， Cloudera曾經想過基于 HBase

進行修改，然而結論是對 HBase的改動非常大， Kudu的資料模型和磁盤存盤都與 Hbase不同， HBase

本身成功的適用于大量的其它場景，因此修改 HBase很可能吃力不討好，最后 Cloudera決定開發一

個全新的存盤系統，

1．Strong performance for both scan and random access to help customers simplify complex
hybrid architectures（ 適用于那些既有隨機訪問，也有批量資料 掃描的復合場景 ）

2．High CPU efficiency in order to maximize the return on investment that our customers are
making in modern processors（ 高計算量的場景 ）

3．High IO efficiency in order to leverage modern persistent storage（ 使用了高性能的存盤設

備，包括使用更多的記憶體 ）

4．The ability to upDATE data in place, to avoid extraneous processing and data movement
（ 支持資料更新，避免資料反復遷移 ）

5．The ability to support active-active replicated clusters that span multiple data centers
in geographically distant locations（ 支持跨地域的實時資料備份和查詢 ）

Kudu 架構

與 HDFS和 HBase相似， Kudu使用單個的 Master節點，用來管理集群的元資料，并且使用任意

數量的 Tablet Server（可對比理解 HBase中的 RegionServer角色）節點用來存盤實際資料， 可以 部

署多個 Master節點來提高容錯性 ， 一個 table表的資料，被分割成 1個或多個 Tablet， Tablet被部署

在 Tablet Server來提供資料讀寫服務 ，

資料模型

KUDU 的資料模型與傳統的 關系型資料庫 類似， 一個 KUDU 集群由多個 表 組成，每個表由多

個 欄位 組成，一個表必須指定一個由若干個（ >=1）欄位組成的 主鍵 ，如下圖：

KUDU 表中的每個欄位是強型別的 ，而不是 HBase 那樣所有欄位都認為是 bytes，好處是可

以 對不同型別資料進行不同的編碼，節省空間 ，同時，因為 KUDU 的使用場景是 OLAP 分析，

有一個資料型別對下游的分析工具也更加友好，

? Table（表） ： 一張表 table是資料存盤在 Kudu的從節點 tablet server中，表具有 schema 和全

局有序的 primary key（主鍵）， table 被分成稱為 tablets 的 segments，

? Tablet：

? 1）、一個 tablet 是一張 table連續的 segment， tablet是 Kudu表的水平磁區，類似于 google

Bigtable的 tablet，或者 HBase的 region，

? 2）、每個 tablet存盤著一定連續 range的資料（ key），且 tablet兩兩間的 range不會重疊，

一張表的所有 tablet包含了這張表的所有 key空間，與其它資料存盤引擎或關系型資料庫中

的 partition（磁區）相似，

? 3）、給定的 tablet 冗余到多個 tablet server 服務器上，并且在任何給定的時間點，其中

一個副本是 leader tablet，其他的副本為 follower tablet，

? 4）、每個 Tablet同時只有一個 leader副本，這個副本對用戶提供修改操作，然后將修改結

果同步給 follower，

? 5）、 Follower只提供讀服務，不提供修改服務，副本之間使用 raft協議來實作 High

Availability，當 leader所在的節點發生故障時， followers會重新選舉 leader， Raft協議的另

一個作用是實作 Consistency， Client對 leader的修改操作，需要同步到 N/2+1個節點上，

該 操作才算成功，

磁區策略

與大多數大資料存盤引擎類似， KUDU 對表進行橫向磁區， KUDU 表會被橫向切分存盤在多

個 tablets 中，不過相比與其他存盤引擎， KUDU 提供了更加豐富靈活的資料磁區策略，

? Range Partitioning，按照欄位值范圍進行磁區， HBase 就采用了這種方式，

? Example 1：沒有邊界，用 20150101和 20160101分割資料，將資料分成了三塊

? Example 2：有邊界 [(2014-01-01), (2017-01-01)]，在 2015-01-01 and 2016-01-01處分割

Range Partitioning的優勢是 在資料進行批量讀的時候，可以把大部分的讀變成同一個 tablet

中的順序讀，能夠提升資料讀取的吞吐量 ，并且按照范圍進行磁區，可以很方便的進行磁區擴展，

其劣勢是同一個范圍內的資料寫入都會落在單個 tablet 上，寫的壓力大，速度慢，

? Hash Partitioning，按照欄位的 Hash 值進行磁區， Cassandra 采用了這個方式，

? 下 面的案例中， metric表按照 host， metric散列磁區，把資料寫入到四個 bucket中，

與 Range Partitioning 相反，由于是 Hash 磁區，資料的寫入會被均勻的分散到各個 tablet

中，寫入速度快，但是對于順序讀的場景這一策略就不太適用了，因為資料分散，一次順序讀需要

將各個 tablet 中的資料分別讀取并組合，吞吐量低，并且 Hash 磁區無法應對磁區擴展的情況，

KUDU 支持用戶對一個表指定一個范圍磁區規則和多個 Hash 磁區規則，如下圖：

多級散列磁區組合，如下圖所示：

列式存盤

KUDU 是一個列式存盤的存盤引擎 ，其資料存盤方式如下：

列式存盤的資料庫很適合于 OLAP 場景，其特點如下：

? 優勢： 查詢少量列時 IO 少，速度快；資料壓縮比高；便于查詢引擎性能優化：延遲物化、直
接操作壓縮資料、向量化執行，

? 劣勢： 查詢列太多時性能下降（ KUDU 建議列數不超過 300）；不適合 OLTP 場景

整體架構

KUDU 中存在兩個角色：

? Mater Server：負責集群管理、元資料管理等功能

? Tablet Server：負責資料存盤，并提供資料讀寫服務

為了實作磁區容錯性，跟其他大資料產品一樣，對于每個角色， 在 KUDU 中都可以設定特定
數量（ 3 或 5）的副本， 各副本間通過 Raft 協議來保證資料一致性， Raft 協議與 ZAB 類似，都
是 Paxos 協議的工程簡化版本，

上圖顯示了一個具有 三個 master 和 多個 tablet server 的 Kudu 集群 ，每個服務器都支持多

個 tablet，它說明了如何使用 Raft 共識來 允許 master 和 tablet server 的 leader 和 follow，

檔案： https://kudu.apache.org/docs/index.html#_architectural_overview

此外， tablet server 可以成為某些 tablet 的 leader，也可以是其他 tablet 的 follower， leader 以

金色顯示，而 follower 則顯示為藍色，下面是一些基本概念：

角色 作用

Master 集群中的老大，負責集群管理、元資料管理等功能

Tablet Server 集群中的小弟，負責資料存盤，并提供資料讀寫服務

一個 tablet server 存盤了 table表的 tablet 和為 tablet 向 client 提供服務，

對于給定的 tablet，一個 tablet server 充當 leader，其他 tablet server 充當

該 tablet 的 follower 副本，

只有 leader服務寫請求，然而 leader 或 followers 為每個服務提供讀請求 ，

一個 tablet server 可以服務多個 tablets ，并且一個 tablet 可以被多個

tablet servers 服務著，

Table（表） 一張 table是資料存盤在 Kudu的 tablet server中，表具有 schema 和全域有序

的 primary key（主鍵）， table 被分成稱為 tablets 的 segments，

Tablet 一個 tablet 是一張 table連續的 segment， tablet是 kudu表的水平磁區，類似

于 google Bigtable的 tablet，或者 HBase的 region，每個 tablet存盤著一定連續

range的資料（ key），且 tablet兩兩間的 range不會重疊，一張表的所有 tablet

包含了這張表的所有 key空間，與其它資料存盤引擎或關系型資料庫中的

partition（磁區）相似，給定的 tablet 冗余到多個 tablet 服務器上，并且在任

何給定的時間點，其中一個副本被認為是 leader tablet，任何副本都 可以對讀

取進行服務，并且寫入時需要在為 tablet 服務的一組 tablet server之間達成

一致性，

Tablet server 的任務非常繁重 , 其負責和資料相關的所有操作 , 包括存盤 , 訪問 , 壓縮 , 其還

負責將資料復制到其它機器， 因為 Tablet server`特殊的結構 , 其任務過于繁重 , 所以有如下限制：

? Kudu 最多支持 300個服務器 , 建議 Tablet server最多不超過 100 個

? 建議每個 Tablet server 至多包含 2000 個 tablet(包含 Follower)

? 建議每個表在每個 Tablet server中至多包含 60個 tablet(包含 Follower)

? 每個 Tablet server至多管理 8TB資料

? 理想環境下 , 一個 tablet leader應該對應一個 CPU`核心 , 以保證最優的掃描性能

Kudu Client 互動

KUDU Client 在與服務端互動時，先從 Master Server 獲取元資料資訊，然后去 Tablet Server

讀寫資料，如下圖：

Kudu 可視化工具

Kudu 使用方法 ： https://kudu.apache.org/docs/developing.html

? 方式一：可 通過 Java client、 C++ client、 Python client操作 Kudu表 ，但要構建 Client并撰寫應

用程式；

? 方式二：可 通過 Kudu-Spark包集成 Kudu與 Spark，并撰寫 Spark應用程式來操作 Kudu表；

? KuduContext，集成 Kudu背景關系實體物件，封裝數 據為 RDD

? SparkSession ，讀取 Kudu表的資料，封裝為 DataFrame

? 方式三：可 通過 Impala的 shell對 Kudu表進行互動式的操作 ，因為 Impala2.8及以上的版本已經

集成了對 Kudu的操作，

? 直 接定義 Impala表資料存盤在 Kudu中，內部集成

Kudu 框架本身提供命令 kudu管理 Kudu集群，位于 $KUDU_HOME/bin目錄

Kudu-Plus一款針對 Kudu可視化工具， GitHub地址： https://github.com/Xchunguang/kudu-plus

Kudu-plus是可視化管理 Kudu的工具，由于 Kudu雖然是列式資料庫，但是可以表達成關系數

據庫類似的表和欄位等資訊，某種情況下通過可視化管理更加輕松， KuduPlus包括對表和資料的操

作約束，可以幫助更好的理解 Kudu，目前版本的功能如下所列：

下載地址： 鏈接： https://pan.baidu.com/s/1_VX0wwAIh60-Mnus8r8uqQ 提取碼： 7ltk

總結

以上就是大資料框架Kudu的全部內容,如果對你有幫助,不妨點個關注~