Apache Kudu架构

1. Kudu架构

下图显示了一个具有三个master和多个tablet server的Kudu集群

Kudu采用Raft一致性算法，当写入一条数据，被至少一半replica保存，就可以让客户端访问该条数据。但所有的replica的数据会最终一致

Table：表具有schema和全局有序的primary key。table被分成多个tablets

Tablet：在任何给定的时间点，其中一个副本被认为是leader tablet。只有 leader tablet处理写请求，任何tablet都可以对读取进行服务

Tablet Server：一个tablet server可以服务多个tablets ，并且一个tablet可以被多个tablet servers服务。tablet server以设定的时间间隔向Master发送心跳

Master：master保持跟踪所有的tablets、tablet servers、Catalog Table和其它与集群相关的metadata。在给定的时间点，只有一个leader master起作用，且Master只有一个tablet

master还协调客户端的metadata operations。例如，当创建新表时，客户端内部将请求发送给master。 master将新表的元数据写入catalog table，并协调在tablet server上创建tablet

Catalog Table：它存储有关tables和tablets的信息。该catalog table不会被直接读取或写入。只能通过客户端API进行访问。catalog table存储两类元数据：

1. table schemas, locations, and states
2. tablet的列表，以及每个tablet的副本所在哪些tablet server，tablet的当前状态以及开始和结束的key

Logical Replication逻辑复制

Kudu replica之间的复制，不是磁盘上的复制，而是逻辑上的复制。这有几个优点

1. insert和update通过网络传输数据。delete操作被发送到每个tablet server，在本地执行删除
2. 物理操作。如compaction，不需要通过网络传输数据，只在当前tablet server上进行compaction
3. tablet的多个replica不需要在同一时间或同一任务执行压缩，或者在物理存储层上保持同步。这会减少所有tablet server同时遇到高延迟的频率