Kudu 的架构概述

Kudu 的架构概述

---

目录

Kudu 的架构概述

体系结构概述

Kudu 的特点

Kudu 的概念和术语

---

体系结构概述

下图显示了一个Kudu集群，其中有三个主机和多个 tablet servers，每个tablet server 都服务于多个tablet 

Kudu 的特点

特点一：主从架构 主为master，从为 tablet server，通常为三主多从 

特点二：高可用性（High availability）

Tablet server 和 Master 使用 Raft Consensus Algorithm 来保证节点的高可用，确保只要有一半以上的副本可用，该 tablet 便可用于读写。例如，如果3个副本中有2个或5个副本中的3个可用，则该tablet可用。即使在 leader tablet 出现故障的情况下，读取功能也可以通过 read-only（只读的）follower tablets来进行服务，或者是leader宕掉的情况下，会根据raft机制重新选举leader

特点三：水平可扩展

特点四：OLAP 工作的快速处理。

特点五：与 MapReduce，Spark ，Impala和其他 Hadoop 生态系统组件集成

特点六：使用 Cloudera Manager 轻松维护和管理

特点七：底层存储完全是列式结构，每一列都可以自定义压缩

特点八：查询出来的数据是结构化模型，支持sql操作

Kudu 的概念和术语

•开发语言 C++

•Columnar Data Store（列式数据存储）

•Read Efficiency（高效读取）

对于分析查询，允许读取单个列或该列的一部分同时忽略其他列

•Data Compression（数据压缩）

由于给定的列只包含一种类型的数据，所以基于此模式的压缩会比压缩混合数据类型（在基于行的解决案中使用）时更有效几个数量级。结合从列读取数据的效率，压缩允许从磁盘读取更少的块时完成查询

•Table（表）

一张table是数据存储在 Kudu 的位置。表具有schema和全局有序的primary key（主键）。table被分成很多段，也就是称为tablets

•Tablet（段）

 一个tablet是一张table连续的segment，与其它数据存储引擎或关系型数据库partition（分区）相似。在一定的时间范围内，tablet的副本冗余到多个tserver服务器上，其中一个副本被认为是leader tablet。任何副本都可以对读取进行服务，并且写入时需要为tablet服务的一组tablet server之间达成一致性。一张表分成多个tablet，分布在不同的tablet server中，最大并行化操作，Tablet在Kudu中被切分为更小的单元，叫做RowSets，RowSets分为两种MemRowSets和DiskRowSet，MemRowSets每生成32M，就溢写到磁盘中，也就是DiskRowSet

•Tablet Server

tablet server是存储tablet和为tablet向client提供服务。对于给定的tablet，一个tablet server充当 leader，其他tablet server充当该tablet的follower副本。只有leader为每一个服务提供写请求，leader和followers为每个服务提供读请求。leader使用Raft协议来进行选举 。一个tablet server可以服务多个tablets，并且一个 tablet 可以被多个tablet servers服务着。

•Master

保持跟踪所有的tablets、tablet servers、catalog tables和其它与集群相关的metadata。在给定的时间点，只能有一个起作用的master（也就是 leader）。如果当前的leader消失，则选举出一个新的master，使用Raft协议来进行选举。master还协调客户端的metadata operations（元数据操作）。例如，当创建新表时，客户端内部将请求发送给master。 master将新表的元数据写入catalog table，并协调在tablet server上创建tablet的过程。所有master的元数据都存储在一个tablet中，可以复制到所有其他候选的master。tablet server以设定的间隔向master发出心跳（默认值为每秒一次）。master是以文件的形式存储在磁盘中。

•Raft Consensus Algorithm

Kudu 使用 Raft consensus algorithm 作为确保常规 tablet 和 master 数据的容错性和一致性的手段。通过 Raft协议，tablet 的多个副本选举出 leader，它负责接受请求和复制数据写入到其他follower副本。一旦写入的数据在大多数副本中持久化后，就会向客户确认。给定的一组N副本（通常为 3 或 5 个）能够接受最多(N - 1)/2 错误的副本的写入。

•Catalog Table（目录表）

catalog table是Kudu 的 metadata（元数据中）的中心位置。它存储有关tables和tablets的信息。该catalog table（目录表）可能不会被直接读取或写入。相反，它只能通过客户端 API中公开的元数据操作访问。catalog tables存储以下两类元数据。

•Tables  table schemas, locations, and states（表结构，位置和状态）

•Tablets

现有tablet 的列表，每个 tablet 的副本所在哪些tablet server，tablet的当前状态以及开始和结束的keys（键）

Logical Replication

Kudu复制操作，而不是磁盘上的数据。这称为逻辑复制，而不是物理复制。这有几个优点:

• 虽然插入和更新确实通过网络传输数据，但是删除不需要移动任何数据。删除操作被发送到每个tablet服务器，该服务器在本地执行删除操作。
• 物理操作(如压缩)不需要通过Kudu中的网络传输数据。这与使用HDFS的存储系统不同，HDFS需要通过网络传输块，以满足所需的副本数量。
• Tablets不需要在同一时间或同一时间表上执行压缩，或者在物理存储层上保持同步。这减少了所有 tablet servers 同时经历高延迟的机会，因为压缩或写负载过重。

参考：https://kudu.apache.org/docs/