Kudu的架构

　　不多说，直接上干货！

 Kudu的架构

1、kudu的 基本框架

Kudu 是用于存储结构化（ structured ）的表（ Table ）。表有预定义的带类型的列（ Columns ），每张表有一个主键（ primary key ）。主键带有唯一性（ uniqueness ）限制，可作为索引用来支持快速的 random access 。

　　类似于 BigTable ， Kudu 的表是由很多数据子集构成的，表（Table）被水平拆分成多个 Tablets（片）。Kudu 用以每个 tablet 为一个单元来实现数据的 durability （持久化）。 Tablet（片） 有多个副本，同时在多个节点上进行持久化。

  Kudu 有两种类型的组件， Master Server 和 Tablet Server 。

　　（1） Master Server 负责管理元数据。这些元数据包括 talbet 的基本信息，位置信息。 Master 还作为负载均衡服务器，监听 Tablet Server 的健康状态。对于副本数过低的 Tablet ， Master 会在起 replication 任务来提高其副本数。 Master 的所有信息都在内存中 cache ，因此速度非常快。每次查询都在百毫秒级别。 Kudu 支持多个 Master ，不过只有一个 active Master ，其余只是作为灾备，不提供服务。

（2） Tablet Server 上存了 10~100 个 Tablets ，每个 Tablet 有 3 （或 5 ）个副本存放在不同的 Tablet Server 上，每个 Tablet 同时只有一个 leader 副本，这个副本对用户提供修改操作，然后将修改结果同步给 follower 。 Follower 只提供读服务，不提供修改服务。副本之间使用 raft 协议来实现 High Availability ，当 leader 所在的节点发生故障时， followers 会重新选举 leader 。根据官方的数据，其 MTTR 约为 5 秒，对 client 端几乎没有影响。 Raft 协议的另一个作用是实现 Consistency 。 Client 对 leader 的修改操作，需要同步到 N/2+1 个节点上，该操作才算成功。

　　　　　　　　　　　　　　　　　　 

　　Kudu 采用了类似 log-structured 存储系统的方式，增删改操作都放在内存中的 buffer ，然后才 merge 到持久化的列式存储中。 Kudu 还是用了 WALs 来对内存中的 buffer 进行灾备。

2. 列式存储

持久化的列式存储存储，与 HBase 完全不同，而是使用了类似 Parquet 的方式，同一个列在磁盘上是作为一个连续的块进行存放的。例如，图中左边是 twitter 保存推文的一张表，而图中的右边表示了表在磁盘中的的存储方式，也就是将同一个列放在一起存放。这样做的第一个好处是，对于一些聚合和 join 语句，我们可以尽可能地减少磁盘的访问。

　　例如，我们要用户名为 newsycbot的推文数量，使用查询语句：

SELECT COUNT(*) FROM tweets WHERE user_name = ‘newsycbot’;

　　　　　　　　　　　　

我们只需要查询 User_name 这个 block（块） 即可。同一个列的数据是集中的，而且是相同格式的， Kudu 可以对数据进行编码，例如字典编码，行长编码， bitshuffle 等。通过这种方式可以很大的减少数据在磁盘上的大小，提高吞吐率。除此之外，用户可以选择使用通用的压缩格式对数据进行压缩，如 LZ4, gzip, 或 bzip2 。这是可选的，用户可以根据业务场景，在数据大小和 CPU 效率上进行权衡。这一部分的实现上， Kudu 很大部分借鉴了 Parquet 的代码。

　　　　　　　　　　 

　　HBase 支持 snappy 存储，然而因为它的 LSM 的数据存储方式，使得它很难对数据进行特殊编码，这也是 Kudu 声称具有很快的 scan 速度的一个很重要的原因。不过，因为列式编码后的数据很难再进行修改，因此当这写数据写入磁盘后，是不可变的，这部分数据称之为 base 数据。 Kudu 用 MVCC （多版本并发控制）来实现数据的删改功能。更新、删除操作需要记录到特殊的数据结构里，保存在内存中的 DeltaMemStore 或磁盘上的 DeltaFIle 里面。 DeltaMemStore 是 B-Tree 实现的，因此速度快，而且可修改。磁盘上的 DeltaFIle 是二进制的列式的块，和 base 数据一样都是不可修改的。因此当数据频繁删改的时候，磁盘上会有大量的 DeltaFiles 文件， Kudu 借鉴了 Hbase 的方式，会定期对这些文件进行合并。

　　下图显示了一个具有三个 master 和多个 tablet server 的 Kudu 集群，每个服务器都支持多个 tablet。它说明了如何使用 Raft 共识来允许 master 和 tablet server 的 leader 和 follow。此外，tablet server 可以成为某些 tablet 的 leader，也可以是其他 tablet 的 follower。leader 以金色显示，而 follower 则显示为蓝色。