kudu

Kudu 发展历史

2012年10月由Cloudera 公司发起

2014年9月小米加入开发

2015年10月对外公布

2015年12月进入Apache 孵化器，并迅速称为Apache 的顶级项目

Kudu最有名和最成功的应用案例—— 小米

 

 

KUDU的定位是

Fast Analytics on Fast Data，是一个既支持随机读写、又支持 OLAP(On Line Analysis Processing, 联机分析处理) 分析的大数据存储引擎。

 

 

Kudu 的设计目标

Kudu 最初的目标是成为一个新的存储引擎, 可以进行快速的数据分析, 又可以进行高效的数据随机

插入, 这样就能简化数据从源端到 Hadoop 中可以用于被分析的过程, 所以有如下的一些设计目标

- 尽可能快速的扫描, 达到 HDFS 中 Parquet 的二分之一速度

- 尽可能的支持随机读写, 达到 1ms 的响应时间

- 列式存储

- 支持NoSQL样式的API, 例如 put, get, delete, scan

 

 

 

Kudu 特点

Apache Kudu是由Cloudera开源的存储引擎（使用 C++ 开发），可以同时提供低延迟的随机

读写和高效的数据分析能力。它是一个融合HDFS和HBase的功能的新组件，具备介于两者之间的新存

储组件；

1）、Kudu是一种数据储存引擎，设计的时候借鉴了很多 Parquet（文件格式、列式存储） 和

HBase 的思想;

2）、kudu的数据模型类似关系型数据库, 是结构化的表；

3）、Kudu支持水平扩展，与Cloudera Impala 和 Apache Spark 等当前流行的大数据查询和

分析工具结合紧密；

适合场景

- 同时有顺序读写和随机读写需求的场景

- 需要高吞吐量的场景

- 对数据更新时效性要求比较高

Kudu特点：在频繁更新的数据之上做快速分析；

 

 

 

kudu

 

kudu是一种存储结构化数据表的存储系统,

kudu使用都额定的列类型,而不是类似于Nosql的"everything is byte"这可以带来两种好处:

1,确定的列类型使kudu可以进行类型特有的编码

2,可以提供SQL-like元数据给其他上层查询工具

 

KUDU 中存在两个角色：
Mater Server：负责集群管理、元数据管理等功能
Tablet Server：负责数据存储，并提供数据读写服务

 

 

Master

 

kudu的master节点负责整个集群的元数据管理个服务协议,它承担着一下功能:

1,作为catalog manager,master节点管理者集群中所有table和table的schema及一些其他的元数据

2,作为clster coordinator,master节点追踪着所有server节点是否存活,并且当server节点关掉后协调数据的重新分布

3,作为tablet directory,master跟踪每个tablet的位置

 

Catalog Manager

Kudu的master节点会持有一个单tablet的table——catalog table，但是用户是不能直接访问的。master将内部的catalog信息写入该tablet，并且将整个catalog的信息缓存到内存中。随着现在商用服务器上的内存越来越大，并且元数据信息占用的空间其实并不大，所以master不容易存在性能瓶颈。catalog table保存了所有table的schema的版本以及table的状态（创建、运行、删除等）。

 

Cluster Coordination

Kudu集群中的每个tablet server都需要配置master的主机名列表。当集群启动时，tablet server会向master注册，并发送所有tablet的信息。tablet server第一次向master发送信息时会发送所有tablet的全量信息，后续每次发送则只会发送增量信息，仅包含新创建、删除或修改的tablet的信息。

作为cluster coordination，master只是集群状态的观察者。对于tablet server中tablet的副本位置、Raft配置和schema版本等信息的控制和修改由tablet server自身完成。master只需要下发命令，tablet server执行成功后会自动上报处理的结果。

 

Tablet Directory

因为master上缓存了集群的元数据，所以client读写数据的时候，肯定是要通过master才能获取到tablet的位置等信息。但是如果每次读写都要通过master节点的话，那master就会变成这个集群的性能瓶颈，所以client会在本地缓存一份它需要访问的tablet的位置信息，这样就不用每次读写都从master中获取。

因为tablet的位置可能也会发生变化（比如某个tablet server节点crash掉了），所以当tablet的位置发生变化的时候，client会收到相应的通知，然后再去master上获取一份新的元数据信息。

 

Tablet存储

在数据存储方面，Kudu选择完全由自己实现，而没有借助于已有的开源方案。tablet存储主要想要实现的目标为：

1. 快速的列扫描。
2. 低延迟的随机读写。
3. 一致性的性能。

 

RowSets

在Kudu中，tablet被细分为更小的单元，叫做RowSets。一些RowSet仅存在于内存中，被称为MemRowSets，而另一些则同时使用内存和硬盘，被称为DiskRowSets。任何一行未被删除的数据都只能存在于一个RowSet中。

无论任何时候，一个tablet仅有一个MemRowSet用来保存最新插入的数据，并且有一个后台线程会定期把内存中的数据flush到硬盘上。

当一个MemRowSet被flush到硬盘上以后，一个新的MemRowSet会替代它。而原有的MemRowSet会变成一到多个DiskRowSet。flush操作是完全同步进行的，在进行flush时，client同样可以进行读写操作。

 

MemRowSet

MemRowSets是一个可以被并发访问并进行过锁优化的B-tree，主要是基于MassTree来设计的，但存在几点不同：

1. Kudu并不支持直接删除操作，由于使用了MVCC，所以在Kudu中删除操作其实是插入一条标志着删除的数据，这样就可以推迟删除操作。
2. 类似删除操作，Kudu也不支持原地更新操作。
3. 将tree的leaf链接起来，就像B+-tree。这一步关键的操作可以明显地提升scan操作的性能。
4. 没有实现字典树（trie树），而是只用了单个tree，因为Kudu并不适用于极高的随机读写的场景。

与Kudu中其他模块中的数据结构不同，MemRowSet中的数据使用行式存储。因为数据都在内存中，所以性能也是可以接受的，而且Kudu对在MemRowSet中的数据结构进行了一定的优化。

 

DiskRowSet

当MemRowSet被flush到硬盘上，就变成了DiskRowSet。当MemRowSet被flush到硬盘的时候，每32M就会形成一个新的DiskRowSet，这主要是为了保证每个DiskRowSet不会太大，便于后续的增量compaction操作。Kudu通过将数据分为base data和delta data，来实现数据的更新操作。Kudu会将数据按列存储，数据被切分成多个page，并使用B-tree进行索引。除了用户写入的数据，Kudu还会将主键索引存入一个列中，并且提供布隆过滤器来进行高效查找。

 

Compaction

为了提高查询性能，Kudu会定期进行compaction操作，合并delta data与base data，对标记了删除的数据进行删除，并且会合并一些DiskRowSet。

分区

和许多分布式存储系统一样，Kudu的table是水平分区的。BigTable只提供了range分区，Cassandra只提供hash分区，而Kudu提供了较为灵活的分区方式。当用户创建一个table时，可以同时指定table的的partition schema，partition schema会将primary key映射为partition key。一个partition schema包括0到多个hash-partitioning规则和一个range-partitioning规则。通过灵活地组合各种partition规则，用户可以创造适用于自己业务场景的分区方式。

Kudu的应用

Kudu的应用场景很广泛，比如可以进行实时的数据分析，用于数据可能会存在变化的时序数据应用等，甚至还有人探讨过使用Kudu替代Kafka的可行性（详情请戳这里）。不过Kudu最有名和最成功的应用案例，还是国内的小米。小米公司不仅使用Kudu，还深度参与了Kudu的开发。Kudu项目在2012年10月由Cloudera公司发起，2015年10月对外公布，2015年12月进入Apache孵化器，但是小米公司早在2014年9月就加入到Kudu的开发中了。

 

Kudu 在小米应用

典型的大数据平台数据存储流程与分析

 

基于Kudu的大数据平台数据存储流程与分析

 

使用Kudu相比较优势

提高了数据时效性

简化了系统架构（所有的数据存储都集中到的 KUDU 上）

Kudu把analytics 和 online两个应用场景进行了整合，将分散的大数据生态圈组件进

行融合，这也是未来大数据生态圈急需解决的一个问题，也是一个趋势。