实现快速实时处理的一种新数据库Kudu

李敏　虞金中

摘要：针对快速变化的数据，目前的数据库还无法做到快速处理。对于这样的现状，客户希望有一种数据库不仅能够对数据快速地分析，而且能够对数据快速地修改、删除和随机读取。为此，Cloudera参考了Google发表的介绍其分布式数据库[1]（Spanner）的论文，在2012年开始秘密研发的一款介于HDFS[2]和HBase[3]之间的高速分布式存储数据库Kudu[4]。Kudu不仅有效地兼具了HBase的实时性，HDFS的高吞吐，以及传统数据库的SQL支持，而且它更有效地利用了现代硬件的CPU和IO资源，降低了混合架构系统的复杂性。Kudu作为一款实时、离线之间的存储系统被誉为下一代分析平台的重要组成部分，填补了HDFS和HBase之间的空白，并将进一步把Hadoop[5]市场向传统数据仓库市场靠拢。

关键词：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引言

近幾年来，随着物联网、移动互联网、社会化网络的快速发展，企业的数据增长迅速，半结构化及非结构化的行业应用数据规模将成几何倍数增长。随着时间的推移，越来越多的人会意识到数据对于一个人甚至企业的重要性，它有可能重塑生产力格局，甚至有可能决定着企业的未来发展方向。

基于分布式存储和并行计算的大数据技术和平台不断发展成熟，并逐步得到推广。国内外已形成普遍共识：大数据[6]技术平台在各个重大行业的推广应用已成为一个急迫的需求和必然的发展趋势。在现有的各种大数据技术平台中，目前比较稳定成熟和广为业界使用的主流大数据平台当数Apache Hadoop系统，而且它是开源的。Hadoop存储层主要由HDFS和HBase 两个系统把持着，一直没有太大突破。在追求高吞吐的批处理场景下，我们选用HDFS，在追求低延迟，有随机读写需求的场景下，我们选用HBase。那么是否存在一种系统，既能结合两个系统优点，也能支持高吞吐率和低延迟呢？为了解决此问题，进一步提高大数据处理的性能，Cloundera在2012年秘密研究实现数据快速实时处理的Kudu数据库。

2 Kudu设计的背景

Hadoop 系统有很多组件，每一个组件有不同的功能，在现实场景中，用户往往需要同时部署很多 Hadoop工具来解决同一个问题，这种架构称为混合架构。近几年来，很多公司都成功地部署了HDFS/Parquet + HBase 混合架构。这样的一条工具链不仅烦琐而复杂，而且还存在很多问题，并且维护上也十分困难。虽然一些重大行业能够成功地部署、维护这样的混合架构，但是在这些行业内更希望能有一个存储系统能够为多种不同类型的工作负载提供高性能的处理能力，来应付不同类型的工作流，并保持高性能的计算能力。Kudu于2015年相应而生，它专门针对实时变化的数据进行快速分析，弥补了在线事务处理（OLTP）和在线分析（OLAP[7]）之前的空白。

3 Apache Kudu

3.1 Kudu 简介

Kudu是一个弥补HDFS和HBase 之间的缺口的新型的存储，它能够更有效地利用现代硬件的CPU和IO资源，既能够支持数据分析，又能够支持数据更新、删除和实时查询。

在当前的Hadoop生态系统下，客户使用的都是一个混合的架构，而Kudu则是主要针对这个混合架构的需求所设计开发的一个存储系统，希望能够降低这种混合架构系统的复杂性，同时能够满足客户类似的需求。

Kudu是Cloudera开源的列式存储引擎，是一个新的数据高速列式存储系统。Kudu在Hadoop生态系统中扮演的角色打破了HBase和HDFS之间的不足，如图1所示：

从上图可知，Kudu既能够满足分析的需求（快速的数据吞吐量），也能够满足查询的需求（快速的随机访问）。

3.2 Kudu设计与架构

3.2.1 Kudu的基本框架

Kudu是以表的形式进行结构数据存储的存储系统。一个Kudu集群有多个表，每个表都是由schema进行定义，包含有限列，每列有一个名字和类型，并且可以选择是否支持空值;这些列中的一些有序的列可以定义为表的主键，主键有唯一性约束，不仅可以作为删除和更新的索引，而且可以用来支持快速的随机访问的索引;这些特性与传统的关系型数据库相似，但是与Cassandra ， MongoDB ，Riak ， BigTable等分布式数据存储却非常不同。

Kudu 采用了类似 log-structured 存储系统的方式，增删改等操作都放在内存的 buffer中（Kudu 使用 WALS 对内存中的 buffer 进行灾备），随后通过归并排序才能持久化到列式存储中。

3.2.2列式存储

持久化的列式存储，与HBase 完全不同，Kudu使用了类似 Parquet[8] 的方式，同一个列在磁盘上是作为一个连续的块进行存放的。例如下图2所示，图2中左边twitter是保存数据的一张表，而图2中的右边表示表在磁盘中的存储方式，就是将同一个列放在一起存放。这样做的好处是：对于一些聚合和join语句，我们可以尽可能地减少磁盘的访问。例如，我们要用户名为 newsycbot 的数量，使用查询语句：SELECT COUNT（*） FROM tweets WHERE user_name = ‘newsycbot‘，我們只需要查询User_name这个 block 即可。

同一个列的数据是集中的，而且是相同格式的，Kudu 可以对数据进行编码，例如字典编码，行长编码，bitshuffle 等。它通过这种方式可以很大的减少数据在磁盘上的大小，提高吞吐率。Kudu的Tablet存储设计包括：快速的列扫描，能够达到可以媲美Parquet和ORCFile[9]的类似的性能，从而可以支撑分析业务;低延时的随机更新，在随机访问时，希望达到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的计算速度。从上图中我们可以发现，Kudu的速度和Parquet的速度差距不大，甚至有些Query比Parquet还快。这是由于这些数据都是在内存缓存过的。

对比Kudu和HBase的性能比较，官方给出的测试结果如下图4：

从图中我们可以看出，在scan和range查询上，Kudu 和Parquet 比 HBase快很多，而随机访问（random access）则比HBase稍慢。然而数据集仅只有60 亿行数据，所以很可能这些数据也是可以全部缓存在内存的。对于从内存查询，除了随机访问（random access）比HBase慢之外，Kudu的速度基本上要优于HBase。

5结论

Kudu的本质是将性能的优化建立在列式存储的基础上，提高存储的效率和较快投影字段过滤的效率，降低查询时CPU的开销。然而其他大多数设计，都是为解决在列式存储的基础上支持随机读写的问题而存在的。

为应对BI领域少量更新和大量扫描分析场景，Kudu借鉴了很多传统数据仓库等技术。在这个领域目前是Impala+ Kudu/Hive/Spark SQL/Green plum MPP数据库[10]在混合使用，传统的MPP数据库将会是一个过渡产品，不同的数据库优良性能未来将趋向融合。与大多数关系型数据库不同的是：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]. 计算机系统应用，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]. 现代计算机（专业版），2013（29）：12-15.

[6] 张东霞，苗新，刘丽平，等. 智能电网大数据技术发展研究[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.

【通联编辑：光文玲】