李敏　虞金中

摘要：針對快速變化的數據，目前的數據庫還無法做到快速處理。對于這樣的現(xiàn)狀，客戶希望有一種數據庫不僅能夠對數據快速地分析，而且能夠對數據快速地修改、刪除和隨機讀取。為此，Cloudera參考了Google發(fā)表的介紹其分布式數據庫[1]（Spanner）的論文，在2012年開始秘密研發(fā)的一款介于HDFS[2]和HBase[3]之間的高速分布式存儲數據庫Kudu[4]。Kudu不僅有效地兼具了HBase的實時性，HDFS的高吞吐，以及傳統(tǒng)數據庫的SQL支持，而且它更有效地利用了現(xiàn)代硬件的CPU和IO資源，降低了混合架構系統(tǒng)的復雜性。Kudu作為一款實時、離線之間的存儲系統(tǒng)被譽為下一代分析平臺的重要組成部分，填補了HDFS和HBase之間的空白，并將進一步把Hadoop[5]市場向傳統(tǒng)數據倉庫市場靠攏。

關鍵詞：Kudu;快速實時處理;分布式存儲數據庫;大數據

中圖分類號：TP392? ? ? 文獻標識碼：A

文章編號：1009-3044（2019）25-0008-03

Abstract： For fast-changing data， current databases cannot be processed quickly. For such a status quo， customers want a database that not only can quickly analyze data， but also can quickly modify， delete and randomize data. To this end， Cloudera refers to a paper published by Google on its distributed database [1] （wrench）， and in 2012 began a secret high-speed distribution between HDFS [2] and HBase[3]. Storage database [4]. Kudu not only effectively combines the real-time nature of HBase， the high throughput of HDFS， and the SQL support of traditional databases， but it also makes more efficient use of the CPU and IO resources of modern hardware， reducing the mix. The complexity of the architecture system. Kudu as a real-time， offline storage system is hailed as an important part of the next-generation analytics platform， filling the gap between HDFS and HBase， and will further put Hadoop [5] The market is moving closer to the traditional data warehouse market.

Key words： Kudu; fast real-time processing; distributed storage database; big Data

1引言

近幾年來，隨著物聯(lián)網、移動互聯(lián)網、社會化網絡的快速發(fā)展，企業(yè)的數據增長迅速，半結構化及非結構化的行業(yè)應用數據規(guī)模將成幾何倍數增長。隨著時間的推移，越來越多的人會意識到數據對于一個人甚至企業(yè)的重要性，它有可能重塑生產力格局，甚至有可能決定著企業(yè)的未來發(fā)展方向。

基于分布式存儲和并行計算的大數據技術和平臺不斷發(fā)展成熟，并逐步得到推廣。國內外已形成普遍共識：大數據[6]技術平臺在各個重大行業(yè)的推廣應用已成為一個急迫的需求和必然的發(fā)展趨勢。在現(xiàn)有的各種大數據技術平臺中，目前比較穩(wěn)定成熟和廣為業(yè)界使用的主流大數據平臺當數Apache Hadoop系統(tǒng)，而且它是開源的。Hadoop存儲層主要由HDFS和HBase 兩個系統(tǒng)把持著，一直沒有太大突破。在追求高吞吐的批處理場景下，我們選用HDFS，在追求低延遲，有隨機讀寫需求的場景下，我們選用HBase。那么是否存在一種系統(tǒng)，既能結合兩個系統(tǒng)優(yōu)點，也能支持高吞吐率和低延遲呢？為了解決此問題，進一步提高大數據處理的性能，Cloundera在2012年秘密研究實現(xiàn)數據快速實時處理的Kudu數據庫。

2 Kudu設計的背景

Hadoop 系統(tǒng)有很多組件，每一個組件有不同的功能，在現(xiàn)實場景中，用戶往往需要同時部署很多 Hadoop工具來解決同一個問題，這種架構稱為混合架構。近幾年來，很多公司都成功地部署了HDFS/Parquet + HBase 混合架構。這樣的一條工具鏈不僅煩瑣而復雜，而且還存在很多問題，并且維護上也十分困難。雖然一些重大行業(yè)能夠成功地部署、維護這樣的混合架構，但是在這些行業(yè)內更希望能有一個存儲系統(tǒng)能夠為多種不同類型的工作負載提供高性能的處理能力，來應付不同類型的工作流，并保持高性能的計算能力。Kudu于2015年相應而生，它專門針對實時變化的數據進行快速分析，彌補了在線事務處理（OLTP）和在線分析（OLAP[7]）之前的空白。

3 Apache Kudu

3.1 Kudu 簡介

Kudu是一個彌補HDFS和HBase 之間的缺口的新型的存儲，它能夠更有效地利用現(xiàn)代硬件的CPU和IO資源，既能夠支持數據分析，又能夠支持數據更新、刪除和實時查詢。

在當前的Hadoop生態(tài)系統(tǒng)下，客戶使用的都是一個混合的架構，而Kudu則是主要針對這個混合架構的需求所設計開發(fā)的一個存儲系統(tǒng)，希望能夠降低這種混合架構系統(tǒng)的復雜性，同時能夠滿足客戶類似的需求。

Kudu是Cloudera開源的列式存儲引擎，是一個新的數據高速列式存儲系統(tǒng)。Kudu在Hadoop生態(tài)系統(tǒng)中扮演的角色打破了HBase和HDFS之間的不足，如圖1所示：

從上圖可知，Kudu既能夠滿足分析的需求（快速的數據吞吐量），也能夠滿足查詢的需求（快速的隨機訪問）。

3.2 Kudu設計與架構

3.2.1 Kudu的基本框架

Kudu是以表的形式進行結構數據存儲的存儲系統(tǒng)。一個Kudu集群有多個表，每個表都是由schema進行定義，包含有限列，每列有一個名字和類型，并且可以選擇是否支持空值;這些列中的一些有序的列可以定義為表的主鍵，主鍵有唯一性約束，不僅可以作為刪除和更新的索引，而且可以用來支持快速的隨機訪問的索引;這些特性與傳統(tǒng)的關系型數據庫相似，但是與Cassandra ， MongoDB ，Riak ， BigTable等分布式數據存儲卻非常不同。

Kudu 采用了類似 log-structured 存儲系統(tǒng)的方式，增刪改等操作都放在內存的 buffer中（Kudu 使用 WALS 對內存中的 buffer 進行災備），隨后通過歸并排序才能持久化到列式存儲中。

3.2.2列式存儲

持久化的列式存儲，與HBase 完全不同，Kudu使用了類似 Parquet[8] 的方式，同一個列在磁盤上是作為一個連續(xù)的塊進行存放的。例如下圖2所示，圖2中左邊twitter是保存數據的一張表，而圖2中的右邊表示表在磁盤中的存儲方式，就是將同一個列放在一起存放。這樣做的好處是：對于一些聚合和join語句，我們可以盡可能地減少磁盤的訪問。例如，我們要用戶名為 newsycbot 的數量，使用查詢語句：SELECT COUNT（*） FROM tweets WHERE user_name = ‘newsycbot‘，我們只需要查詢User_name這個 block 即可。

同一個列的數據是集中的，而且是相同格式的，Kudu 可以對數據進行編碼，例如字典編碼，行長編碼，bitshuffle 等。它通過這種方式可以很大的減少數據在磁盤上的大小，提高吞吐率。Kudu的Tablet存儲設計包括：快速的列掃描，能夠達到可以媲美Parquet和ORCFile[9]的類似的性能，從而可以支撐分析業(yè)務;低延時的隨機更新，在隨機訪問時，希望達到O（log（n））的時間復雜度;性能的一致性。

4性能評測

1）Kudu與Parquet的性能進行對比，同樣都是采用Impala集成，Kudu性能比Parquet提高31%。

Cloudera利用TPC-H對Impala-Kudu和Impala-Parquet進行了性能的比較，結果如下圖3所示：

圖3是官方給出用Impala跑TPC-H的測試，對比Parquet和Kudu的計算速度。從上圖中我們可以發(fā)現(xiàn)，Kudu的速度和Parquet的速度差距不大，甚至有些Query比Parquet還快。這是由于這些數據都是在內存緩存過的。

對比Kudu和HBase的性能比較，官方給出的測試結果如下圖4：

從圖中我們可以看出，在scan和range查詢上，Kudu 和Parquet 比 HBase快很多，而隨機訪問（random access）則比HBase稍慢。然而數據集僅只有60 億行數據，所以很可能這些數據也是可以全部緩存在內存的。對于從內存查詢，除了隨機訪問（random access）比HBase慢之外，Kudu的速度基本上要優(yōu)于HBase。

5結論

Kudu的本質是將性能的優(yōu)化建立在列式存儲的基礎上，提高存儲的效率和較快投影字段過濾的效率，降低查詢時CPU的開銷。然而其他大多數設計，都是為解決在列式存儲的基礎上支持隨機讀寫的問題而存在的。

為應對BI領域少量更新和大量掃描分析場景，Kudu借鑒了很多傳統(tǒng)數據倉庫等技術。在這個領域目前是Impala+ Kudu/Hive/Spark SQL/Green plum MPP數據庫[10]在混合使用，傳統(tǒng)的MPP數據庫將會是一個過渡產品，不同的數據庫優(yōu)良性能未來將趨向融合。與大多數關系型數據庫不同的是：Kudu當前并不支持二級索引，除primary key外，其他列并沒有提供唯一性限制。目前，Kudu要求每個table有一個primary key，當然我們期望將來的版本能夠自動產生迭代的keys.

參考文獻：

[1] James C. Corbett， Jeffrey Dean， Michael Epstein，etal.Spanner： Google's globally distributed database.Published： AUG 2013

[2] 郝樹魁. HadoopHDFS和MapReduce架構淺析[J]. 郵電設計技術，2012（07）：37-42.

[3] 唐長城，楊峰，代棟，等. 一種基于HBase的數據持久性和可用性研究[J]. 計算機系統(tǒng)應用，2013（10）：175-180.

[4] Lipcon T， Alves D，Burkert D，et al. Kudu ： Storage for fast analytics on fast data. Draft ，2015.

[5] 黃素萍，葛萌. Hadoop平臺在大數據處理中的應用研究[J]. 現(xiàn)代計算機（專業(yè)版），2013（29）：12-15.

[6] 張東霞，苗新，劉麗平，等. 智能電網大數據技術發(fā)展研究[J]. 中國電機工程學報，2015（01）：2-12.

[7] 常冰琳：使用Kudu搭建OLAP云服務[EB/OL]. http：//www.docin.com/p-1635604338.html.

[8] 新一代列式存儲格式Parquet[EB/OL]. http：//www.2cto.com/database/201603/495571.html.

[9] Hive： ORC File Format存儲格式詳解[EB/OL].https：//www.iteblog.com/archives/1014.html

[10]薛志云，何軍，張丹陽，等. Hadoop和Spark在實驗室中部署與性能評估[J]. 實驗室研究與探索，2015（11）：77-81.

【通聯(lián)編輯：光文玲】