目录
Kudu是一个列式数据存储。列式数据存储把数据存储在强类型列中。结合适当的数据模型设计，列式存储可以更好地用于平常数据分析或数据仓库分析任务，具体原因如下:
读取效率
对于分析查询，您可以读取单个列或该列的一部分，而忽略其他列。这意味着系统可以通过读取磁盘上最小的块数量来满足请求。对于基于行的存储，系统需要读取整个行的数据，即使系统只从行数据中返回一些列的数据。
数据压缩
因为给定的列只包含一种数据类型，基于模式的压缩比压缩混合数据类型的效率要高得多，基于行的解决方案使用的是混合数据压缩方式。与列式读取数据的方式相结合，压缩可以让系统通过读取磁盘上更少的数据块来实现查询。
Raft 一致性算法
raft一致性算法提供了一种方法，可以从潜在的领导者池中选出一个分布式集群的领导者。如果一个跟随者不能到达当前的领导者，它就会转变成一个候选人。考虑到法定人数，一名候选人被选为新领导人，而另一名候选人则重新成为追随者。对raft一致性算法讨论超出了这个文档的范围，但它是一个健壮的算法，信任它，使用它即可。
Kudu使用了大量的协商一致算法来选择作为主节点服务器（master）和作为领导者（leader）的平板服务器，最终确定一个给定的写操作的成功与否也应用了这些协商一致算法。
数据表是数据存储在Kudu中的位置。一个表有一个设计好的模式（数据模型）和一个完全有序的主键。系统将一个表按主键拆分为片块。
平板（tablet）
平板是表的连续数据段，类似于其他数据存储引擎或关系数据库中的分区。一个给定的平板在多个平板服务器上被复制，在任何一个特定的时间点，只有其中一个副本被认为是领导者的平板服务器。任何副本都可以提供读取服务。写入则是需要在平板服务器的集合中达成一致。
平板服务器（tablet
server）
平板服务器群集，为客户端提供需要访问的平板服务器。对于一个给定的平板，一台平板服务器作为领导者，而其他的则作为追随者平板服务器，是领导者平板服务器的复制品。只有领导者服务写请求，而领导者或追随者每个服务都处理读取请求。领导人是协商一致通过的。一台平板服务器可以服务于多个平板，一个平板也可以由多个平板服务器来共同提供服务。
主节点（master）
主节点跟踪所有的平板、平板服务器、目录表和与集群相关的其他元数据。在特定的时间点，只能有一个主节点(领导者)。如果现任领导者消失了，一个新的主节点将会由raft一致性算法从候选主节点中挑选出来。
主节点还为客户机协调元数据操作。例如，在创建新表时，客户端内部向主节点发送请求。主节点将新表的元数据写入编目表，并协调在平板服务器上创建平板的过程。
所有的主数据都存储在一个平板中，它可以被复制到其他所有的候选主节点。
平板服务器在一个设置的时间间隔内发送心跳到主节点服务器(默认为每秒一次)。
目录表
目录表是Kudu元数据中心。它存储有关数据表和平板的信息。通过使用客户端API，可以通过主节点服务器访问目录表。目录表不能直接读或写。相反，它只能通过在客户端API中公开的元数据操作来访问。目录表存储了两类元数据:
目录表存储的内容
数据表数据表的模式，位置，状态
平板现有平板的名单，平板副本，状态，开始和结束键
逻辑复制
Kudu复制的是操作，而不是磁盘上的数据。这被称为逻辑复制，而不是物理复制。它有以下几个好处:
[if !supportLists]· [endif]尽管插入和更新需要通过网络传输数据，删除不需要移动任何数据。删除操作被发送到每个平板服务器，在本地执行删除操作。
[if !supportLists]· [endif]物理操作，例如压缩，不需要在Kudu的网络上传输数据。这与使用HDFS的存储系统不同，在这些系统中，块需要通过网络传输，以满足所需的副本数量。
[if !supportLists]· [endif]平板不需要在同一时间或同一任务内执行压缩。它们甚至不需要在物理存储层上保持同步。这降低了所有的平板服务器在同一时间出现因为压缩或大量写的负载而导致高延迟的机会 。
架构图概述
下图显示了一个Kudu集群，有三个主节点服务器和多个平板服务器，每个服务器都有多个平板。它说明了如何使用“raft共识”来决策主节点服务器和平板服务器的领导者和追随者角色。此外，平板服务器可以成为某些平板的领导者，也可以成为其他平板的追随者。领导者在下图中以黄色表现，而追随者则以灰色表示。
kudu体系结构概述
[if !vml]
[endif]
