kudu-列式存储管理器-第四篇（原理篇）

1、简介

Kudu自身的架构，部分借鉴了Bigtable/HBase/Spanner的设计思想。论文的作者列表中，有几位是HBase社区的Committer/PBC成员，因此，在论文中也能很深刻的感受到HBase对Kudu设计的一些影响

2、表与Schema

Kudu设计是面向结构化存储的，因此，Kudu的表，需要用户在建表时定义它的Schema信息，这些Schema信息包含：列定义（含类型），Primary Key定义（用户指定的若干个列的有序组合）。

数据的唯一性，依赖于用户所提供的Primary Key中的Column组合的值的唯一性。 Kudu提供了Alter命令来增删列，但位于Primary Key中的列是不允许删除的。

Kudu当前并不支持二级索引。

从用户角度来看，Kudu是一种存储结构化数据表的存储系统。

在一个Kudu集群中可以定义任意数量的table，每个table都需要预先定义好schema。

每个table的列数是确定的，每一列都需要有名字和类型，每个表中可以把其中一列或多列定义为主键。

这么看来，Kudu更像关系型数据库，而不是像HBase、Cassandra和MongoDB这些NoSQL数据库。不过Kudu目前还不能像关系型数据一样支持二级索引。

Kudu使用确定的列类型，而不是类似于NoSQL的“everything is byte”。这可以带来两点好处： 确定的列类型使Kudu可以进行类型特有的编码。 可以提供 SQL-like 元数据给其他上层查询工具，比如BI工具

3、kudu的底层数据模型

Kudu的底层数据文件的存储，未采用HDFS这样的较高抽象层次的分布式文件系统，而是自行开发了一套可基于Table/Tablet/Replica视图级别的底层存储系统。这套实现基于如下的几个设计目标：

• 可提供快速的列式查询。

• 可支持快速的随机更新

• 可提供更为稳定的查询性能保障。

一张表会分成若干个tablet，每个tablet包括MetaData元信息及若干个RowSet，RowSet包含一个MemRowSet及若干个DiskRowSet，DiskRowSet中包含一个BloomFile、Ad_hoc Index、BaseData、DeltaMem及若干个RedoFile和UndoFile（UndoFile一般情况下只有一个）。

注意事项：

MemRowSet：用于新数据insert及已在MemRowSet中的数据的更新，一个MemRowSet写满后会将数据刷到磁盘形成若干个DiskRowSet。(默认是1G或者或者120S)

DiskRowSet用于老数据的变更（mutation），后台定期对DiskRowSet做compaction，以删除没用的数据及合并历史数据，减少查询过程中的IO开销。 

BloomFile根据一个DiskRowSet中的key生成一个bloom filter，