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

語言: CN / TW / HK

theme: fancy

引言

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

一文快速搞懂系列講究快速入門掌握一個新的大資料元件,幫助新手瞭解大資料技術,以下是系列文章:

文章傳送門:

一文快速搞懂系列__一文快速搞懂SuperSet[實戰案例]

一文快速瞭解Elastic Search 開源搜尋引擎(技術選型+啟動命令)

一文快速瞭解ClickHouse 戰鬥民族的開源搜尋引擎(超詳細解讀+快速入門)

一篇文章讓你快速入門Docker

Hbase快速入門(安裝部署)

這是一文快速搞懂系列的第二篇:一文快速搞懂Kudu到底是什麼 在這裡插入圖片描述

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的全部內容,如果對你有幫助,不妨點個關注~

在這裡插入圖片描述