前言
Apache Kudu是由Cloudera開源的存儲引擎，可以同時提供低延遲的隨機讀寫和高效的數據分析能力。Kudu支持水平擴展，使用Raft協議進行一致性保證，並且與Cloudera Impala和Apache Spark等當前流行的大數據查詢和分析工具結合緊密。本文將為您介紹Kudu的一些基本概念和架構以及在企業中的應用，使您對Kudu有一個較為全面的瞭解。
一、為什麼需要Kudu
Kudu這個名字聽起來可能有些奇怪，實際上，Kudu是一種非洲的大羚羊，中文名叫“捻角羚”，就是下圖這個樣子：
捻角羚，圖片來源見水印
比較有意思的是，同為Cloudera公司開源的另一款產品Impala，是另一種非洲的羚羊，叫做“黑斑羚”，也叫“高角羚”。不知道Cloudera公司為什麼這麼喜歡羚羊，也許是因為羚羊的速度快吧。
言歸正傳，現在提起大數據存儲，我們能想到的技術有很多，比如HDFS，以及在HDFS上的列式存儲技術Apache Parquet，Apache ORC，還有以KV形式存儲半結構化數據的Apache HBase和Apache Cassandra等等。既然有了如此多的存儲技術，Cloudera公司為什麼要開發出一款全新的存儲引擎Kudu呢？
事實上，當前的這些存儲技術都存在著一定的侷限性。對於會被用來進行分析的靜態數據集來說，使用Parquet或者ORC存儲是一種明智的選擇。但是目前的列式存儲技術都不能更新數據，而且隨機讀寫性能感人。而可以進行高效隨機讀寫的HBase、Cassandra等數據庫，卻並不適用於基於SQL的數據分析方向。所以現在的企業中，經常會存儲兩套數據分別用於實時讀寫與數據分析，先將數據寫入HBase中，再定期通過ETL到Parquet進行數據同步。但是這樣做有很多缺點：
- 用戶需要在兩套系統間編寫和維護複雜的ETL邏輯。
- 時效性較差。因為ETL通常是一個小時、幾個小時甚至是一天一次，那麼可供分析的數據就需要一個小時至一天的時間後才進入到可用狀態，也就是說從數據到達到可被分析之間是會存在一個較為明顯的“空檔期”的。
- 更新需求難以滿足。在實際情況中可能會有一些對已經寫入的數據的更新需求，這種情況往往需要對歷史數據進行更新，而對Parquet這種靜態數據集的更新操作，代價是非常昂貴的。
- 存儲資源浪費。兩套存儲系統意味著佔用的磁盤資源翻倍了，造成了成本的提升。
我們知道，基於HDFS的存儲技術，比如Parquet，具有高吞吐量連續讀取數據的能力；而HBase和Cassandra等技術適用於低延遲的隨機讀寫場景，那麼有沒有一種技術可以同時具備這兩種優點呢？Kudu提供了一種“happy medium”的選擇：
kudu的定位
Kudu不但提供了行級的插入、更新、刪除API，同時也提供了接近Parquet性能的批量掃描操作。使用同一份存儲，既可以進行隨機讀寫，也可以滿足數據分析的要求。
二、Kudu總覽
Tables和Schemas
從用戶角度來看，Kudu是一種存儲結構化數據表的存儲系統。在一個Kudu集群中可以定義任意數量的table，每個table都需要預先定義好schema。每個table的列數是確定的，每一列都需要有名字和類型，每個表中可以把其中一列或多列定義為主鍵。這麼看來，Kudu更像關係型數據庫，而不是像HBase、Cassandra和MongoDB這些NoSQL數據庫。不過Kudu目前還不能像關係型數據一樣支持二級索引。
Kudu使用確定的列類型，而不是類似於NoSQL的“everything is byte”。這可以帶來兩點好處：
- 確定的列類型使Kudu可以進行類型特有的編碼。
- 可以提供 SQL-like 元數據給其他上層查詢工具，比如BI工具。
讀寫操作
用戶可以使用 Insert，Update和Delete API對錶進行寫操作。不論使用哪種API，都必須指定主鍵。但批量的刪除和更新操作需要依賴更高層次的組件（比如Impala、Spark）。Kudu目前還不支持多行事務。
而在讀操作方面，Kudu只提供了Scan操作來獲取數據。用戶可以通過指定過濾條件來獲取自己想要讀取的數據，但目前只提供了兩種類型的過濾條件：主鍵範圍和列值與常數的比較。由於Kudu在硬盤中的數據採用列式存儲，所以只掃描需要的列將極大地提高讀取性能。
一致性模型
Kudu為用戶提供了兩種一致性模型。默認的一致性模型是snapshot consistency。這種一致性模型保證用戶每次讀取出來的都是一個可用的快照，但這種一致性模型只能保證單個client可以看到最新的數據，但不能保證多個client每次取出的都是最新的數據。另一種一致性模型external consistency可以在多個client之間保證每次取到的都是最新數據，但是Kudu沒有提供默認的實現，需要用戶做一些額外工作。
為了實現external consistency，Kudu提供了兩種方式：
- 在client之間傳播timestamp token。在一個client完成一次寫入後，會得到一個timestamp token，然後這個client把這個token傳播到其他client，這樣其他client就可以通過token取到最新數據了。不過這個方式的複雜度很高。
- 通過commit-wait方式，這有些類似於Google的Spanner。但是目前基於NTP的commit-wait方式延遲實在有點高。不過Kudu相信，隨著Spanner的出現，未來幾年內基於real-time clock的技術將會逐漸成熟。
三、Kudu的架構
與HDFS和HBase相似，Kudu使用單個的Master節點，用來管理集群的元數據，並且使用任意數量的Tablet Server節點用來存儲實際數據。可以部署多個Master節點來提高容錯性。
Master
Kudu的master節點負責整個集群的元數據管理和服務協調。它承擔著以下功能：
- 作為catalog manager，master節點管理著集群中所有table和tablet的schema及一些其他的元數據。
- 作為cluster coordinator，master節點追蹤著所有server節點是否存活，並且當server節點掛掉後協調數據的重新分佈。
- 作為tablet directory，master跟蹤每個tablet的位置。
Catalog Manager
Kudu的master節點會持有一個單tablet的table——catalog table，但是用戶是不能直接訪問的。master將內部的catalog信息寫入該tablet，並且將整個catalog的信息緩存到內存中。隨著現在商用服務器上的內存越來越大，並且元數據信息佔用的空間其實並不大，所以master不容易存在性能瓶頸。catalog table保存了所有table的schema的版本以及table的狀態（創建、運行、刪除等）。
Cluster Coordination
Kudu集群中的每個tablet server都需要配置master的主機名列表。當集群啟動時，tablet server會向master註冊，併發送所有tablet的信息。tablet server第一次向master發送信息時會發送所有tablet的全量信息，後續每次發送則只會發送增量信息，僅包含新創建、刪除或修改的tablet的信息。
作為cluster coordination，master只是集群狀態的觀察者。對於tablet server中tablet的副本位置、Raft配置和schema版本等信息的控制和修改由tablet server自身完成。master只需要下發命令，tablet server執行成功後會自動上報處理的結果。
Tablet Directory
因為master上緩存了集群的元數據，所以client讀寫數據的時候，肯定是要通過master才能獲取到tablet的位置等信息。但是如果每次讀寫都要通過master節點的話，那master就會變成這個集群的性能瓶頸，所以client會在本地緩存一份它需要訪問的tablet的位置信息，這樣就不用每次讀寫都從master中獲取。
因為tablet的位置可能也會發生變化（比如某個tablet server節點crash掉了），所以當tablet的位置發生變化的時候，client會收到相應的通知，然後再去master上獲取一份新的元數據信息。
Tablet存儲
在數據存儲方面，Kudu選擇完全由自己實現，而沒有藉助於已有的開源方案。tablet存儲主要想要實現的目標為：
- 快速的列掃描。
- 低延遲的隨機讀寫。
- 一致性的性能。
RowSets
在Kudu中，tablet被細分為更小的單元，叫做RowSets。一些RowSet僅存在於內存中，被稱為MemRowSets，而另一些則同時使用內存和硬盤，被稱為DiskRowSets。任何一行未被刪除的數據都只能存在於一個RowSet中。
無論任何時候，一個tablet僅有一個MemRowSet用來保存最新插入的數據，並且有一個後臺線程會定期把內存中的數據flush到硬盤上。
當一個MemRowSet被flush到硬盤上以後，一個新的MemRowSet會替代它。而原有的MemRowSet會變成一到多個DiskRowSet。flush操作是完全同步進行的，在進行flush時，client同樣可以進行讀寫操作。
MemRowSet
MemRowSets是一個可以被併發訪問並進行過鎖優化的B-tree，主要是基於MassTree來設計的，但存在幾點不同：
- Kudu並不支持直接刪除操作，由於使用了MVCC，所以在Kudu中刪除操作其實是插入一條標誌著刪除的數據，這樣就可以推遲刪除操作。
- 類似刪除操作，Kudu也不支持原地更新操作。
- 將tree的leaf鏈接起來，就像B+-tree。這一步關鍵的操作可以明顯地提升scan操作的性能。
- 沒有實現字典樹（trie樹），而是隻用了單個tree，因為Kudu並不適用於極高的隨機讀寫的場景。
與Kudu中其他模塊中的數據結構不同，MemRowSet中的數據使用行式存儲。因為數據都在內存中，所以性能也是可以接受的，而且Kudu對在MemRowSet中的數據結構進行了一定的優化。
DiskRowSet
當MemRowSet被flush到硬盤上，就變成了DiskRowSet。當MemRowSet被flush到硬盤的時候，每32M就會形成一個新的DiskRowSet，這主要是為了保證每個DiskRowSet不會太大，便於後續的增量compaction操作。Kudu通過將數據分為base data和delta data，來實現數據的更新操作。Kudu會將數據按列存儲，數據被切分成多個page，並使用B-tree進行索引。除了用戶寫入的數據，Kudu還會將主鍵索引存入一個列中，並且提供布隆過濾器來進行高效查找。
Compaction
為了提高查詢性能，Kudu會定期進行compaction操作，合併delta data與base data，對標記了刪除的數據進行刪除，並且會合並一些DiskRowSet。
分區
和許多分佈式存儲系統一樣，Kudu的table是水平分區的。BigTable只提供了range分區，Cassandra只提供hash分區，而Kudu提供了較為靈活的分區方式。當用戶創建一個table時，可以同時指定table的的partition schema，partition schema會將primary key映射為partition key。一個partition schema包括0到多個hash-partitioning規則和一個range-partitioning規則。通過靈活地組合各種partition規則，用戶可以創造適用於自己業務場景的分區方式。
四、Kudu的應用
Kudu的應用場景很廣泛，比如可以進行實時的數據分析，用於數據可能會存在變化的時序數據應用等，甚至還有人探討過使用Kudu替代Kafka的可行性（詳情請戳）。不過Kudu最有名和最成功的應用案例，還是國內的小米。小米公司不僅使用Kudu，還深度參與了Kudu的開發。Kudu項目在2012年10月由Cloudera公司發起，2015年10月對外公佈，2015年12月進入Apache孵化器，但是小米公司早在2014年9月就加入到Kudu的開發中了。
下面我們可以跟隨Cloudera在宣傳Kudu時使用的ppt來看一看Kudu在小米的使用。
小米 use case
從上圖中我們可以看到，Kudu在小米主要用來對手機app和後端服務的RPC調用事件進行追蹤，以及對服務進行監控。在小米的使用場景下，Kudu集群已經達到每天200億次寫入，並且還在增長。
Kudu除了優秀的性能，更為重要的是可以簡化數據處理的流程。在使用Kudu以前，小米的數據處理流程是這樣的：
before Kudu
可以看到，數據處理的流程很長。這種處理模式不但較為複雜，而且latency較高，通常需要等待較長的時間（1 hour - 1day）才能得到分析結果。下面再來看看使用Kudu以後的數據處理流程是怎樣的：
after Kudu
使用Kudu以後，數據處理的鏈路被簡化了，而且得益於Kudu對隨機讀寫和數據分析操作的支持都很好，可以直接對Kudu中的數據進行交互式分析，降低了系統複雜度，並且latency被大大縮短（0 ~ 10s）。
五、進一步學習
如果您看了本文的介紹後想進一步學習Kudu，以下途徑可以幫助您快速入門：
- 官方文檔永遠是學習開源項目的最好去處。
- Kudu的論文可以幫助您深入瞭解Kudu的設計思想。
- Raft協議，雖然不屬於Kudu的內容，但是Kudu的一致性協議使用了Raft協議，瞭解Raft協議可以幫助您更好地瞭解Kudu及其他分佈式開源系統。
- 這篇博客也許能對您在如何使用Kudu的問題上有一些啟發。
文章參考地址：https://www.jianshu.com/p/83290cd817ac
比較遺憾的是，由於Kudu還很年輕，所以並沒有比較好的相關書籍出版。計算機是一門實踐性較強的學科，所以動手實踐是成為Kudu專家的必經之路。
Apache Kudu主節點（Master）遷移
提前修改機器上kudu賬號可以登錄，（/etc/passwd），之後都是以kudu執行命令
1、將每個master的記錄下來
kudu fs dump uuid --fs_wal_dir=/home/data/kudu-master --fs_data_dirs=/home/data/kudu-master 2>/dev/null
2、存活的一個master上執行
kudu local_replica cmeta print_replica_uuids --fs_wal_dir=/home/data/kudu-master --fs_data_dirs=/home/data/kudu-master 00000000000000000000000000000000 2>/dev/null
3、根據前兩步確定dead master的uuid
4、在新master機器上執行,uuid為dead master的標識
kudu fs format --fs_wal_dir=/home/data/kudu-master --fs_data_dirs=/home/data/kudu-master --uuid=af4f6c30a3b04d86ae0172598d443a32
5、將一臺存活master的元數據拷貝過來,用kudu用戶執行，將目錄改為kudu擁有者
kudu local_replica copy_from_remote --fs_wal_dir=/home/data/kudu-master --fs_data_dirs=/home/data/kudu-master 00000000000000000000000000000000 10-12-7-14.testddw.sina.com:7051
6、新master和存活master上更新master list
kudu local_replica cmeta rewrite_raft_config --fs_wal_dir=/home/data/kudu-master --fs_data_dirs=/home/data/kudu-master 00000000000000000000000000000000 af4f6c30a3b04d86ae0172598d443a32:10-12-7-11.testddw.sina.com:7051 176a9a6dbc854614abd7940082270372:10-12-7-13.testddw.sina.com:7051
13b8832c228e4022b013fef555f5ae28:10-12-7-14.testddw.sina.com:7051
7、在CM界面將新master加入並啟動，刪除停掉待替換的master，然後新master和之前存活的master一臺臺重啟
8、檢查master狀態，需要在每個master管理頁面看到的master節點列表是一致的
9、執行健康檢查腳本
kudu cluster ksck 10.12.7.11,10.12.7.12,10.12.7.13,10.12.7.14,10.12.7.15
閱讀更多 大數據技術實戰 的文章
