Kudu是Cloudera開(kāi)源的新型列式存儲(chǔ)系統(tǒng)，是Apache Hadoop生態(tài)圈的新成員之一（incubating），專門(mén)為了對(duì)快速變化的數(shù)據(jù)進(jìn)行快速的分析，填補(bǔ)了以往Hadoop存儲(chǔ)層的空缺。本文主要對(duì)Kudu的動(dòng)機(jī)、背景，以及架構(gòu)進(jìn)行簡(jiǎn)單介紹。

　　背景——功能上的空白

　　Hadoop生態(tài)系統(tǒng)有很多組件，每一個(gè)組件有不同的功能。在現(xiàn)實(shí)場(chǎng)景中，用戶往往需要同時(shí)部署很多Hadoop工具來(lái)解決同一個(gè)問(wèn)題，這種架構(gòu)稱為混合架構(gòu) (hybrid architecture)。比如，用戶需要利用Hbase的快速插入、快讀random access的特性來(lái)導(dǎo)入數(shù)據(jù)，HBase也允許用戶對(duì)數(shù)據(jù)進(jìn)行修改，HBase對(duì)于大量小規(guī)模查詢也非常迅速。同時(shí)，用戶使用HDFS/Parquet + Impala/Hive來(lái)對(duì)超大的數(shù)據(jù)集進(jìn)行查詢分析，對(duì)于這類場(chǎng)景， Parquet這種列式存儲(chǔ)文件格式具有極大的優(yōu)勢(shì)。

　　很多公司都成功地部署了HDFS/Parquet + HBase混合架構(gòu)，然而這種架構(gòu)較為復(fù)雜，而且在維護(hù)上也十分困難。首先，用戶用Flume或Kafka等數(shù)據(jù)Ingest工具將數(shù)據(jù)導(dǎo)入HBase，用戶可能在HBase上對(duì)數(shù)據(jù)做一些修改。然后每隔一段時(shí)間(每天或每周)將數(shù)據(jù)從Hbase中導(dǎo)入到Parquet文件，作為一個(gè)新的partition放在HDFS上，***使用Impala等計(jì)算引擎進(jìn)行查詢，生成最終報(bào)表。

　　這樣一條工具鏈繁瑣而復(fù)雜，而且還存在很多問(wèn)題，比如：

　　·?如何處理某一過(guò)程出現(xiàn)失??？

　　·?從HBase將數(shù)據(jù)導(dǎo)出到文件，多久的頻率比較合適？

　　·?當(dāng)生成最終報(bào)表時(shí)，最近的數(shù)據(jù)并無(wú)法體現(xiàn)在最終查詢結(jié)果上。

　　·?維護(hù)集群時(shí)，如何保證關(guān)鍵任務(wù)不失??？

　　·?Parquet是immutable，因此當(dāng)HBase中刪改某些歷史數(shù)據(jù)時(shí)，往往需要人工干預(yù)進(jìn)行同步。

　　這時(shí)候，用戶就希望能夠有一種優(yōu)雅的存儲(chǔ)解決方案，來(lái)應(yīng)付不同類型的工作流，并保持高性能的計(jì)算能力。Cloudera很早就意識(shí)到這個(gè)問(wèn)題，在2012年就開(kāi)始計(jì)劃開(kāi)發(fā)Kudu這個(gè)存儲(chǔ)系統(tǒng)，終于在2015年發(fā)布并開(kāi)源出來(lái)。Kudu是對(duì)HDFS和HBase功能上的補(bǔ)充，能提供快速的分析和實(shí)時(shí)計(jì)算能力，并且充分利用CPU和I/O資源，支持?jǐn)?shù)據(jù)原地修改，支持簡(jiǎn)單的、可擴(kuò)展的數(shù)據(jù)模型。

　　背景——新的硬件設(shè)備

　　RAM的技術(shù)發(fā)展非?？?，它變得越來(lái)越便宜，容量也越來(lái)越大。Cloudera的客戶數(shù)據(jù)顯示，他們的客戶所部署的服務(wù)器，2012年每個(gè)節(jié)點(diǎn)僅有32GB RAM，現(xiàn)如今增長(zhǎng)到每個(gè)節(jié)點(diǎn)有128GB或256GB RAM。存儲(chǔ)設(shè)備上更新也非?？欤诤芏嗥胀ǚ?wù)器中部署SSD也是屢見(jiàn)不鮮。HBase、HDFS、以及其他的Hadoop工具都在不斷自我完善，從而適應(yīng)硬件上的升級(jí)換代。然而，從根本上，HDFS基于03年GFS，HBase基于05年BigTable，在當(dāng)時(shí)系統(tǒng)瓶頸主要取決于底層磁盤(pán)速度。當(dāng)磁盤(pán)速度較慢時(shí)，CPU利用率不足的根本原因是磁盤(pán)速度導(dǎo)致的瓶頸，當(dāng)磁盤(pán)速度提高了之后，CPU利用率提高，這時(shí)候CPU往往成為系統(tǒng)的瓶頸。HBase、HDFS由于年代久遠(yuǎn)，已經(jīng)很難從基本架構(gòu)上進(jìn)行修改，而Kudu是基于全新的設(shè)計(jì)，因此可以更充分地利用RAM、I/O資源，并優(yōu)化CPU利用率。我們可以理解為，Kudu相比與以往的系統(tǒng)，CPU使用降低了，I/O的使用提高了，RAM的利用更充分了。

　　簡(jiǎn)介

　　Kudu設(shè)計(jì)之初，是為了解決一下問(wèn)題：

　　·?對(duì)數(shù)據(jù)掃描(scan)和隨機(jī)訪問(wèn)(random access)同時(shí)具有高性能，簡(jiǎn)化用戶復(fù)雜的混合架構(gòu)

　　·?高CPU效率，使用戶購(gòu)買(mǎi)的先進(jìn)處理器的的花費(fèi)得到***回報(bào)

　　·?高IO性能，充分利用先進(jìn)存儲(chǔ)介質(zhì)

　　·?支持?jǐn)?shù)據(jù)的原地更新，避免額外的數(shù)據(jù)處理、數(shù)據(jù)移動(dòng)

　　·?支持跨數(shù)據(jù)中心replication

　　Kudu的很多特性跟HBase很像，它支持索引鍵的查詢和修改。Cloudera曾經(jīng)想過(guò)基于Hbase進(jìn)行修改，然而結(jié)論是對(duì)HBase的改動(dòng)非常大，Kudu的數(shù)據(jù)模型和磁盤(pán)存儲(chǔ)都與Hbase不同。HBase本身成功的適用于大量的其它場(chǎng)景，因此修改HBase很可能吃力不討好。***Cloudera決定開(kāi)發(fā)一個(gè)全新的存儲(chǔ)系統(tǒng)。

　　Kudu的定位是提供”fast analytics on fast data”，也就是在快速更新的數(shù)據(jù)上進(jìn)行快速的查詢。它定位OLAP和少量的OLTP工作流，如果有大量的random accesses，官方建議還是使用HBase最為合適。

　　架構(gòu)與設(shè)計(jì)

　　1.基本框架

　　Kudu是用于存儲(chǔ)結(jié)構(gòu)化（structured）的表（Table）。表有預(yù)定義的帶類型的列（Columns），每張表有一個(gè)主鍵（primary key）。主鍵帶有唯一性（uniqueness）限制，可作為索引用來(lái)支持快速的random access。

　　類似于BigTable，Kudu的表是由很多數(shù)據(jù)子集構(gòu)成的，表被水平拆分成多個(gè)Tablets. Kudu用以每個(gè)tablet為一個(gè)單元來(lái)實(shí)現(xiàn)數(shù)據(jù)的durability。Tablet有多個(gè)副本，同時(shí)在多個(gè)節(jié)點(diǎn)上進(jìn)行持久化。

　　Kudu有兩種類型的組件，Master Server和Tablet Server。Master負(fù)責(zé)管理元數(shù)據(jù)。這些元數(shù)據(jù)包括talbet的基本信息，位置信息。Master還作為負(fù)載均衡服務(wù)器，監(jiān)聽(tīng)Tablet Server的健康狀態(tài)。對(duì)于副本數(shù)過(guò)低的Tablet，Master會(huì)在起replication任務(wù)來(lái)提高其副本數(shù)。Master的所有信息都在內(nèi)存中cache，因此速度非常快。每次查詢都在百毫秒級(jí)別。Kudu支持多個(gè)Master，不過(guò)只有一個(gè)active Master，其余只是作為災(zāi)備，不提供服務(wù)。

　　Tablet Server上存了10~100個(gè)Tablets，每個(gè)Tablet有3（或5）個(gè)副本存放在不同的Tablet Server上，每個(gè)Tablet同時(shí)只有一個(gè)leader副本，這個(gè)副本對(duì)用戶提供修改操作，然后將修改結(jié)果同步給follower。Follower只提供讀服務(wù)，不提供修改服務(wù)。副本之間使用raft協(xié)議來(lái)實(shí)現(xiàn)High Availability，當(dāng)leader所在的節(jié)點(diǎn)發(fā)生故障時(shí)，followers會(huì)重新選舉leader。根據(jù)官方的數(shù)據(jù)，其MTTR約為5秒，對(duì)client端幾乎沒(méi)有影響。Raft協(xié)議的另一個(gè)作用是實(shí)現(xiàn)Consistency。Client對(duì)leader的修改操作，需要同步到N/2+1個(gè)節(jié)點(diǎn)上，該操作才算成功。

　　Kudu采用了類似log-structured存儲(chǔ)系統(tǒng)的方式，增刪改操作都放在內(nèi)存中的buffer，然后才merge到持久化的列式存儲(chǔ)中。Kudu還是用了WALs來(lái)對(duì)內(nèi)存中的buffer進(jìn)行災(zāi)備。

　　2.列式存儲(chǔ)

　　持久化的列式存儲(chǔ)存儲(chǔ)，與HBase完全不同，而是使用了類似Parquet的方式，同一個(gè)列在磁盤(pán)上是作為一個(gè)連續(xù)的塊進(jìn)行存放的。例如，圖中左邊是twitter保存推文的一張表，而圖中的右邊表示了表在磁盤(pán)中的的存儲(chǔ)方式，也就是將同一個(gè)列放在一起存放。這樣做的***個(gè)好處是，對(duì)于一些聚合和join語(yǔ)句，我們可以盡可能地減少磁盤(pán)的訪問(wèn)。例如，我們要用戶名為newsycbot

　　的推文數(shù)量，使用查詢語(yǔ)句：

　　SELECT COUNT(*) FROM tweets WHERE user_name = ‘newsycbot’;

　　我們只需要查詢User_name這個(gè)block即可。同一個(gè)列的數(shù)據(jù)是集中的，而且是相同格式的，Kudu可以對(duì)數(shù)據(jù)進(jìn)行編碼，例如字典編碼，行長(zhǎng)編碼，bitshuffle等。通過(guò)這種方式可以很大的減少數(shù)據(jù)在磁盤(pán)上的大小，提高吞吐率。除此之外，用戶可以選擇使用通用的壓縮格式對(duì)數(shù)據(jù)進(jìn)行壓縮，如LZ4, gzip, 或bzip2。這是可選的，用戶可以根據(jù)業(yè)務(wù)場(chǎng)景，在數(shù)據(jù)大小和CPU效率上進(jìn)行權(quán)衡。這一部分的實(shí)現(xiàn)上，Kudu很大部分借鑒了Parquet的代碼。

　　HBase支持snappy存儲(chǔ)，然而因?yàn)樗腖SM的數(shù)據(jù)存儲(chǔ)方式，使得它很難對(duì)數(shù)據(jù)進(jìn)行特殊編碼，這也是Kudu聲稱具有很快的scan速度的一個(gè)很重要的原因。不過(guò)，因?yàn)榱惺骄幋a后的數(shù)據(jù)很難再進(jìn)行修改，因此當(dāng)這寫(xiě)數(shù)據(jù)寫(xiě)入磁盤(pán)后，是不可變的，這部分?jǐn)?shù)據(jù)稱之為base數(shù)據(jù)。Kudu用MVCC（多版本并發(fā)控制）來(lái)實(shí)現(xiàn)數(shù)據(jù)的刪改功能。更新、刪除操作需要記錄到特殊的數(shù)據(jù)結(jié)構(gòu)里，保存在內(nèi)存中的DeltaMemStore或磁盤(pán)上的DeltaFIle里面。DeltaMemStore是B-Tree實(shí)現(xiàn)的，因此速度快，而且可修改。磁盤(pán)上的DeltaFIle是二進(jìn)制的列式的塊，和base數(shù)據(jù)一樣都是不可修改的。因此當(dāng)數(shù)據(jù)頻繁刪改的時(shí)候，磁盤(pán)上會(huì)有大量的DeltaFiles文件，Kudu借鑒了Hbase的方式，會(huì)定期對(duì)這些文件進(jìn)行合并。

　　3.對(duì)外接口

　　Kudu提供C++和JAVA API，可以進(jìn)行單條或批量的數(shù)據(jù)讀寫(xiě)，schema的創(chuàng)建修改。除此之外，Kudu還將與hadoop生態(tài)圈的其它工具進(jìn)行整合。目前，kudu beta版本對(duì)Impala支持較為完善，支持用Impala進(jìn)行創(chuàng)建表、刪改數(shù)據(jù)等大部分操作。Kudu還實(shí)現(xiàn)了KuduTableInputFormat和KuduTableOutputFormat，從而支持Mapreduce的讀寫(xiě)操作。同時(shí)支持?jǐn)?shù)據(jù)的locality。目前對(duì)spark的支持還不夠完善，spark只能進(jìn)行數(shù)據(jù)的讀操作。

　　使用案例——小米

　　小米是Hbase的重度用戶，他們每天有約50億條用戶記錄。小米目前使用的也是HDFS + HBase這樣的混合架構(gòu)?？梢?jiàn)該流水線相對(duì)比較復(fù)雜，其數(shù)據(jù)存儲(chǔ)分為SequenceFile，Hbase和Parquet。

　　在使用Kudu以后，Kudu作為統(tǒng)一的數(shù)據(jù)倉(cāng)庫(kù)，可以同時(shí)支持離線分析和實(shí)時(shí)交互分析。

　　性能測(cè)試

　　1. 和parquet的比較

　　圖是官方給出的用Impala跑TPC-H的測(cè)試，對(duì)比Parquet和Kudu的計(jì)算速度。從圖中我們可以發(fā)現(xiàn)，Kudu的速度和parquet的速度差距不大，甚至有些Query比parquet還快。然而，由于這些數(shù)據(jù)都是在內(nèi)存緩存過(guò)的，因此該測(cè)試結(jié)果不具備參考價(jià)值。

　　2.和Hbase的比較

　　圖是官方給出的另一組測(cè)試結(jié)果，從圖中我們可以看出，在scan和range查詢上，kudu和parquet比HBase快很多，而random access則比HBase稍慢。然而數(shù)據(jù)集只有60億行數(shù)據(jù)，所以很可能這些數(shù)據(jù)也是可以全部緩存在內(nèi)存的。對(duì)于從內(nèi)存查詢，除了random access比HBase慢之外，kudu的速度基本要優(yōu)于HBase。

　　3.超大數(shù)據(jù)集的查詢性能

　　Kudu的定位不是in-memory database。因?yàn)樗Ｍ鸋DFS/Parquet這種存儲(chǔ)，因此大量的數(shù)據(jù)都是存儲(chǔ)在磁盤(pán)上。如果我們想要拿它代替HDFS/Parquet + HBase，那么超大數(shù)據(jù)集的查詢性能就至關(guān)重要，這也是Kudu的最初目的。然而，官方?jīng)]有給出這方面的相關(guān)數(shù)據(jù)。由于條件限制，網(wǎng)易暫時(shí)未能完成該測(cè)試。下一步，我們將計(jì)劃搭建10臺(tái)Kudu + Impala服務(wù)器，并用tpc-ds生成超大數(shù)據(jù)，來(lái)完成該對(duì)比測(cè)驗(yàn)。