前言

Apache Kudu是由Cloudera開源的存儲引擎速勇，可以同時提供低延遲的隨機讀寫和高效的數(shù)據(jù)分析能力前痘。Kudu支持水平擴展凛捏，使用Raft協(xié)議進行一致性保證，并且與Cloudera Impala和Apache Spark等當前流行的大數(shù)據(jù)查詢和分析工具結合緊密芹缔。本文將為您介紹Kudu的一些基本概念和架構以及在企業(yè)中的應用坯癣，使您對Kudu有一個較為全面的了解。

一最欠、為什么需要Kudu

Kudu這個名字聽起來可能有些奇怪示罗，實際上，Kudu是一種非洲的大羚羊芝硬，中文名叫“捻角羚”蚜点，就是下圖這個樣子：

比較有意思的是，同為Cloudera公司開源的另一款產品Impala拌阴，是另一種非洲的羚羊禽额，叫做“黑斑羚”，也叫“高角羚”皮官。不知道Cloudera公司為什么這么喜歡羚羊，也許是因為羚羊的速度快吧实辑。
言歸正傳捺氢，現(xiàn)在提起大數(shù)據(jù)存儲，我們能想到的技術有很多剪撬，比如HDFS摄乒，以及在HDFS上的列式存儲技術Apache Parquet，Apache ORC残黑，還有以KV形式存儲半結構化數(shù)據(jù)的Apache HBase和Apache Cassandra等等馍佑。既然有了如此多的存儲技術，Cloudera公司為什么要開發(fā)出一款全新的存儲引擎Kudu呢梨水？
事實上拭荤，當前的這些存儲技術都存在著一定的局限性。對于會被用來進行分析的靜態(tài)數(shù)據(jù)集來說疫诽，使用Parquet或者ORC存儲是一種明智的選擇舅世。但是目前的列式存儲技術都不能更新數(shù)據(jù)旦委，而且隨機讀寫性能感人。而可以進行高效隨機讀寫的HBase雏亚、Cassandra等數(shù)據(jù)庫缨硝，卻并不適用于基于SQL的數(shù)據(jù)分析方向。所以現(xiàn)在的企業(yè)中罢低，經常會存儲兩套數(shù)據(jù)分別用于實時讀寫與數(shù)據(jù)分析查辩，先將數(shù)據(jù)寫入HBase中，再定期通過ETL到Parquet進行數(shù)據(jù)同步网持。但是這樣做有很多缺點：

• 用戶需要在兩套系統(tǒng)間編寫和維護復雜的ETL邏輯宜岛。
• 時效性較差。因為ETL通常是一個小時翎碑、幾個小時甚至是一天一次谬返，那么可供分析的數(shù)據(jù)就需要一個小時至一天的時間后才進入到可用狀態(tài)，也就是說從數(shù)據(jù)到達到可被分析之間是會存在一個較為明顯的“空檔期”的日杈。
• 更新需求難以滿足遣铝。在實際情況中可能會有一些對已經寫入的數(shù)據(jù)的更新需求，這種情況往往需要對歷史數(shù)據(jù)進行更新莉擒，而對Parquet這種靜態(tài)數(shù)據(jù)集的更新操作酿炸，代價是非常昂貴的。
• 存儲資源浪費涨冀。兩套存儲系統(tǒng)意味著占用的磁盤資源翻倍了填硕，造成了成本的提升。

我們知道鹿鳖，基于HDFS的存儲技術扁眯，比如Parquet状原，具有高吞吐量連續(xù)讀取數(shù)據(jù)的能力克懊；而HBase和Cassandra等技術適用于低延遲的隨機讀寫場景两曼，那么有沒有一種技術可以同時具備這兩種優(yōu)點呢芽偏？Kudu提供了一種“happy medium”的選擇：

Kudu不但提供了行級的插入蛹稍、更新踪蹬、刪除API搀暑，同時也提供了接近Parquet性能的批量掃描操作假褪。使用同一份存儲歼疮，既可以進行隨機讀寫杂抽，也可以滿足數(shù)據(jù)分析的要求。

二韩脏、Kudu總覽

Tables和Schemas

從用戶角度來看缩麸，Kudu是一種存儲結構化數(shù)據(jù)表的存儲系統(tǒng)。在一個Kudu集群中可以定義任意數(shù)量的table赡矢，每個table都需要預先定義好schema匙睹。每個table的列數(shù)是確定的愚屁，每一列都需要有名字和類型，每個表中可以把其中一列或多列定義為主鍵痕檬。這么看來霎槐，Kudu更像關系型數(shù)據(jù)庫，而不是像HBase梦谜、Cassandra和MongoDB這些NoSQL數(shù)據(jù)庫丘跌。不過Kudu目前還不能像關系型數(shù)據(jù)一樣支持二級索引。
Kudu使用確定的列類型唁桩，而不是類似于NoSQL的“everything is byte”闭树。這可以帶來兩點好處：

• 確定的列類型使Kudu可以進行類型特有的編碼。
• 可以提供 SQL-like 元數(shù)據(jù)給其他上層查詢工具荒澡，比如BI工具报辱。

讀寫操作

用戶可以使用 Insert，Update和Delete API對表進行寫操作单山。不論使用哪種API碍现，都必須指定主鍵。但批量的刪除和更新操作需要依賴更高層次的組件（比如Impala米奸、Spark）昼接。Kudu目前還不支持多行事務。
而在讀操作方面悴晰，Kudu只提供了Scan操作來獲取數(shù)據(jù)慢睡。用戶可以通過指定過濾條件來獲取自己想要讀取的數(shù)據(jù)，但目前只提供了兩種類型的過濾條件：主鍵范圍和列值與常數(shù)的比較铡溪。由于Kudu在硬盤中的數(shù)據(jù)采用列式存儲漂辐，所以只掃描需要的列將極大地提高讀取性能。

一致性模型

Kudu為用戶提供了兩種一致性模型棕硫。默認的一致性模型是snapshot consistency髓涯。這種一致性模型保證用戶每次讀取出來的都是一個可用的快照，但這種一致性模型只能保證單個client可以看到最新的數(shù)據(jù)饲帅，但不能保證多個client每次取出的都是最新的數(shù)據(jù)。另一種一致性模型external consistency可以在多個client之間保證每次取到的都是最新數(shù)據(jù)瘤泪，但是Kudu沒有提供默認的實現(xiàn)灶泵，需要用戶做一些額外工作。
為了實現(xiàn)external consistency对途，Kudu提供了兩種方式：

• 在client之間傳播timestamp token赦邻。在一個client完成一次寫入后，會得到一個timestamp token实檀，然后這個client把這個token傳播到其他client惶洲，這樣其他client就可以通過token取到最新數(shù)據(jù)了按声。不過這個方式的復雜度很高。
• 通過commit-wait方式恬吕，這有些類似于Google的Spanner签则。但是目前基于NTP的commit-wait方式延遲實在有點高。不過Kudu相信铐料，隨著Spanner的出現(xiàn)渐裂，未來幾年內基于real-time clock的技術將會逐漸成熟。

三钠惩、Kudu的架構

與HDFS和HBase相似柒凉，Kudu使用單個的Master節(jié)點，用來管理集群的元數(shù)據(jù)篓跛，并且使用任意數(shù)量的Tablet Server節(jié)點用來存儲實際數(shù)據(jù)膝捞。可以部署多個Master節(jié)點來提高容錯性愧沟。

Master

Kudu的master節(jié)點負責整個集群的元數(shù)據(jù)管理和服務協(xié)調蔬咬。它承擔著以下功能：

• 作為catalog manager，master節(jié)點管理著集群中所有table和tablet的schema及一些其他的元數(shù)據(jù)央渣。
• 作為cluster coordinator计盒，master節(jié)點追蹤著所有server節(jié)點是否存活，并且當server節(jié)點掛掉后協(xié)調數(shù)據(jù)的重新分布芽丹。
• 作為tablet directory北启，master跟蹤每個tablet的位置。

Catalog Manager

Kudu的master節(jié)點會持有一個單tablet的table——catalog table拔第，但是用戶是不能直接訪問的咕村。master將內部的catalog信息寫入該tablet，并且將整個catalog的信息緩存到內存中蚊俺。隨著現(xiàn)在商用服務器上的內存越來越大懈涛，并且元數(shù)據(jù)信息占用的空間其實并不大，所以master不容易存在性能瓶頸泳猬。catalog table保存了所有table的schema的版本以及table的狀態(tài)（創(chuàng)建批钠、運行、刪除等）得封。

Cluster Coordination

Kudu集群中的每個tablet server都需要配置master的主機名列表埋心。當集群啟動時，tablet server會向master注冊忙上，并發(fā)送所有tablet的信息拷呆。tablet server第一次向master發(fā)送信息時會發(fā)送所有tablet的全量信息，后續(xù)每次發(fā)送則只會發(fā)送增量信息，僅包含新創(chuàng)建茬斧、刪除或修改的tablet的信息腰懂。
作為cluster coordination，master只是集群狀態(tài)的觀察者项秉。對于tablet server中tablet的副本位置绣溜、Raft配置和schema版本等信息的控制和修改由tablet server自身完成。master只需要下發(fā)命令伙狐，tablet server執(zhí)行成功后會自動上報處理的結果涮毫。

Tablet Directory

因為master上緩存了集群的元數(shù)據(jù)，所以client讀寫數(shù)據(jù)的時候贷屎，肯定是要通過master才能獲取到tablet的位置等信息罢防。但是如果每次讀寫都要通過master節(jié)點的話，那master就會變成這個集群的性能瓶頸唉侄，所以client會在本地緩存一份它需要訪問的tablet的位置信息咒吐，這樣就不用每次讀寫都從master中獲取。
因為tablet的位置可能也會發(fā)生變化（比如某個tablet server節(jié)點crash掉了）属划，所以當tablet的位置發(fā)生變化的時候恬叹，client會收到相應的通知，然后再去master上獲取一份新的元數(shù)據(jù)信息同眯。

Tablet存儲

在數(shù)據(jù)存儲方面绽昼，Kudu選擇完全由自己實現(xiàn)，而沒有借助于已有的開源方案须蜗。tablet存儲主要想要實現(xiàn)的目標為：

• 快速的列掃描硅确。
• 低延遲的隨機讀寫。
• 一致性的性能明肮。

RowSets

在Kudu中菱农，tablet被細分為更小的單元，叫做RowSets柿估。一些RowSet僅存在于內存中循未，被稱為MemRowSets，而另一些則同時使用內存和硬盤秫舌，被稱為DiskRowSets的妖。任何一行未被刪除的數(shù)據(jù)都只能存在于一個RowSet中。
無論任何時候足陨，一個tablet僅有一個MemRowSet用來保存最新插入的數(shù)據(jù)嫂粟，并且有一個后臺線程會定期把內存中的數(shù)據(jù)flush到硬盤上。
當一個MemRowSet被flush到硬盤上以后钠右，一個新的MemRowSet會替代它赋元。而原有的MemRowSet會變成一到多個DiskRowSet忘蟹。flush操作是完全同步進行的飒房，在進行flush時搁凸，client同樣可以進行讀寫操作。

MemRowSet

MemRowSets是一個可以被并發(fā)訪問并進行過鎖優(yōu)化的B-tree狠毯，主要是基于MassTree來設計的护糖，但存在幾點不同：

• Kudu并不支持直接刪除操作，由于使用了MVCC嚼松，所以在Kudu中刪除操作其實是插入一條標志著刪除的數(shù)據(jù)嫡良，這樣就可以推遲刪除操作。
  類似刪除操作献酗，Kudu也不支持原地更新操作寝受。
• 將tree的leaf鏈接起來，就像B±tree罕偎。這一步關鍵的操作可以明顯地提升scan操作的性能很澄。
• 沒有實現(xiàn)字典樹（trie樹），而是只用了單個tree颜及，因為Kudu并不適用于極高的隨機讀寫的場景甩苛。
• 與Kudu中其他模塊中的數(shù)據(jù)結構不同，MemRowSet中的數(shù)據(jù)使用行式存儲俏站。因為數(shù)據(jù)都在內存中讯蒲，所以性能也是可以接受的，而且Kudu對在MemRowSet中的數(shù)據(jù)結構進行了一定的優(yōu)化肄扎。

DiskRowSet

當MemRowSet被flush到硬盤上墨林，就變成了DiskRowSet。當MemRowSet被flush到硬盤的時候反浓，每32M就會形成一個新的DiskRowSet萌丈，這主要是為了保證每個DiskRowSet不會太大，便于后續(xù)的增量compaction操作雷则。Kudu通過將數(shù)據(jù)分為base data和delta data辆雾，來實現(xiàn)數(shù)據(jù)的更新操作。Kudu會將數(shù)據(jù)按列存儲月劈，數(shù)據(jù)被切分成多個page度迂，并使用B-tree進行索引。除了用戶寫入的數(shù)據(jù)猜揪，Kudu還會將主鍵索引存入一個列中惭墓，并且提供布隆過濾器來進行高效查找。

Compaction

為了提高查詢性能而姐，Kudu會定期進行compaction操作腊凶，合并delta data與base data，對標記了刪除的數(shù)據(jù)進行刪除，并且會合并一些DiskRowSet钧萍。

分區(qū)

和許多分布式存儲系統(tǒng)一樣褐缠，Kudu的table是水平分區(qū)的。BigTable只提供了range分區(qū)风瘦，Cassandra只提供hash分區(qū)队魏，而Kudu提供了較為靈活的分區(qū)方式。當用戶創(chuàng)建一個table時万搔，可以同時指定table的的partition schema胡桨，partition schema會將primary key映射為partition key。一個partition schema包括0到多個hash-partitioning規(guī)則和一個range-partitioning規(guī)則瞬雹。通過靈活地組合各種partition規(guī)則昧谊，用戶可以創(chuàng)造適用于自己業(yè)務場景的分區(qū)方式。

四酗捌、Kudu的應用

Kudu的應用場景很廣泛揽浙，比如可以進行實時的數(shù)據(jù)分析，用于數(shù)據(jù)可能會存在變化的時序數(shù)據(jù)應用等意敛，甚至還有人探討過使用Kudu替代Kafka的可行性（詳情請戳這里）馅巷。不過Kudu最有名和最成功的應用案例，還是國內的小米草姻。小米公司不僅使用Kudu钓猬，還深度參與了Kudu的開發(fā)。Kudu項目在2012年10月由Cloudera公司發(fā)起撩独，2015年10月對外公布敞曹，2015年12月進入Apache孵化器，但是小米公司早在2014年9月就加入到Kudu的開發(fā)中了综膀。
下面我們可以跟隨Cloudera在宣傳Kudu時使用的ppt來看一看Kudu在小米的使用澳迫。

從上圖中我們可以看到，Kudu在小米主要用來對手機app和后端服務的RPC調用事件進行追蹤剧劝，以及對服務進行監(jiān)控橄登。在小米的使用場景下，Kudu集群已經達到每天200億次寫入讥此，并且還在增長拢锹。
Kudu除了優(yōu)秀的性能，更為重要的是可以簡化數(shù)據(jù)處理的流程萄喳。在使用Kudu以前卒稳，小米的數(shù)據(jù)處理流程是這樣的：

可以看到，數(shù)據(jù)處理的流程很長他巨。這種處理模式不但較為復雜充坑，而且latency較高减江，通常需要等待較長的時間（1 hour - 1day）才能得到分析結果。下面再來看看使用Kudu以后的數(shù)據(jù)處理流程是怎樣的：

使用Kudu以后捻爷，數(shù)據(jù)處理的鏈路被簡化了您市，而且得益于Kudu對隨機讀寫和數(shù)據(jù)分析操作的支持都很好，可以直接對Kudu中的數(shù)據(jù)進行交互式分析役衡，降低了系統(tǒng)復雜度，并且latency被大大縮短（0 ~ 10s）薪棒。

五手蝎、進一步學習

如果您看了本文的介紹后想進一步學習Kudu，以下途徑可以幫助您快速入門：

• Documentation俐芯，官方文檔永遠是學習開源項目的最好去處棵介。
• Paper，Kudu的論文可以幫助您深入了解Kudu的設計思想吧史。
• Raft協(xié)議邮辽，雖然不屬于Kudu的內容，但是Kudu的一致性協(xié)議使用了Raft協(xié)議贸营，了解Raft協(xié)議可以幫助您更好地了解Kudu及其他分布式開源系統(tǒng)吨述。
• Apache Kudu as a More Flexible And Reliable Kafka-style Queue，這篇博客也許能對您在如何使用Kudu的問題上有一些啟發(fā)钞脂。

比較遺憾的是揣云，由于Kudu還很年輕，所以并沒有比較好的相關書籍出版冰啃。計算機是一門實踐性較強的學科邓夕，所以動手實踐是成為Kudu專家的必經之路：github地址。