Kudu原理

一、表与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工具。

二、kudu的底层数据模型

Kudu的底层数据文件的存储，未采用HDFS这样的较高抽象层次的分布式文件系统，而是自行开发了一套可基于Table/Tablet/Replica视图级别的底层存储系统

这套实现基于如下的几个设计目标：

• 可提供快速的列式查询
• 可支持快速的随机更新
• 可提供更为稳定的查询性能保障

• 一个Table会被分成若干个tablet，其中Tablet的数量是根据hash或者是range进行设置的
• 一个Tablet中包含MetaData信息和多个RowSet信息，其中MetaData信息是block和block在data中的位置。
• 一个RowSet包含一个MemRowSet和多个DiskRowSet，其中MemRowSet用于存储insert数据和update后的数据，写满后会刷新到磁盘中也就是多个DiskRowSet中，默认是1G刷新一次或者是2分钟。
• DiskRowSet用于老数据的mutation（改变），比如说数据的更新操作，后台定期对DiskRowSet进行合并操作，删除历史数据和没有的数据，减少查询过程中的IO开销。
• 一个DiskRowSet包含1个BloomFilter，1个Ad_hoc Index，多个UndoFile、RedoFile、BaseData、DeltaMem
  • BloomFile：根据一个DiskRowSet中的key生成一个bloom filter，用于快速模糊定位某个key是否在DiskRowSet中存在。
  • Ad_hoc Index：是主键的索引，用于定位主键在DiskRowSet中的具体偏移位置。
  • BaseData：是MemRowSet flush下来的数据，按列存储，按主键有序。
  • UndoFile：是基于BaseData之前时间（上次flush之前）的历史数据，可以获得历史数据，类似mysql中的回滚日志。
  • RedoFile：是基于BaseData之后时间（上次flush之后）的变更记录，可以获得新的数据，类似mysql中的重做日志。
  • DeltaMem：在内存中存储DiskRowSet中数据的更新，写满后flush到磁盘，形成deltafile文件。

注意：

• 这里有两个在内存中处理的数据集，区别如下：
  • MemRowSet：存储新增的数据，对该内存数据集中还未flush的数据的更新；
  • DeltaMem：对已flush到磁盘内的数据的更新；

• MemRowSets可以对比理解成HBase中的MemStore, 而DiskRowSets可理解成HBase中的HFile。MemRowSets中的数据按照行视图进行存储，数据结构为B-Tree。
• MemRowSets中的数据被Flush到磁盘之后，形成DiskRowSets。
• DiskRowSets中的数据，按照32MB大小为单位，按序划分为一个个的DiskRowSet。 DiskRowSet中的数据按照Column进行组织，与Parquet类似。

这是Kudu可支持一些分析性查询的基础。每一个Column的数据被存储在一个相邻的数据区域，而这个数据区域进一步被细分成一个个的小的Page单元，与HBase File中的Block类似，对每一个Column Page可采用一些Encoding算法，以及一些通用的Compression算法。 既然可对Column Page可采用Encoding以及Compression算法，那么，对单条记录的更改就会比较困难了。

前面提到了Kudu可支持单条记录级别的更新/删除，是如何做到的？

与HBase类似，也是通过增加一条新的记录来描述这次更新/删除操作的。DiskRowSet是不可修改了，那么 KUDU 要如何应对数据的更新呢？在KUDU中，把DiskRowSet分为了两部分：

• base data： 负责存储基础数据
• delta stores：delta stores负责存储 base data 中的变更数据.

如上图所示，数据从 MemRowSet 刷到磁盘后就形成了一份 DiskRowSet（只包含 base data），每份 DiskRowSet 在内存中都会有一个对应的 DeltaMemStore，负责记录此 DiskRowSet 后续的数据变更（更新、删除）。DeltaMemStore 内部维护一个 B-树索引，映射到每个 row_offset 对应的数据变更。DeltaMemStore 数据增长到一定程度后转化成二进制文件存储到磁盘，形成一个 DeltaFile，随着 base data 对应数据的不断变更，DeltaFile 逐渐增长。