一个 tablet server 存储 tablet 和为 tablet 向 client 提供服务。对于给定的 tablet，一个 tablet server 充当 leader，其他 tablet server 充当该 tablet 的 follower 副本。只有 leader 服务写请求，然而 leader 或 followers 为每个服务提供读请求。leader 使用 Raft Consensus Algorithm 来进行选举 。一个 tablet server 可以服务多个 tablets ，并且一个 tablet 可以被多个 tablet servers 服务着。
Master
该 master 保持跟踪所有的 tablets，tablet servers，Catalog Table 和其它与集群相关的 metadata。在给定的时间点，只能有一个起作用的 master（也就是 leader）。如果当前的 leader 消失，则选举出一个新的 master，使用 Raft Consensus Algorithm 来进行选举。master 还协调客户端的 metadata operations（元数据操作）。例如，当创建新表时，客户端内部将请求发送给 master。 master 将新表的元数据写入 catalog table，并协调在 tablet server 上创建 tablet 的过程。所有 master 的数据都存储在一个 tablet 中，可以复制到所有其他候选的 master。tablet server 以设定的间隔向 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 table 存储两类元数据:
Tables
table schemas, locations, and states（表结构，位置 和状态）
Tablets
现有 tablet 的列表，每个 tablet 的副本所在哪些 tablet server，tablet 的当前状态以及开始和结束的 keys（键）。
Logical Replication（逻辑复制）
Kudu 复制操作，不是磁盘上的数据。这被称为 logical replication（逻辑复制），而不是 physical replication（物理复制）。这有几个优点 :
虽然 insert（插入）和 update（更新）确实通过网络传输数据，deletes（删除）不需要移动任何数据。delete（删除）操作被发送到每个 tablet server，它在本地执行删除。
物理操作，如 compaction，不需要通过 Kudu 的网络传输数据。这与使用 HDFS 的存储系统不同，其中 blocks （块）需要通过网络传输以满足所需数量的副本。
tablet 不需要在同一时间或相同的时间表上执行压缩，或者在物理存储层上保持同步。这会减少由于压缩或大量写入负载而导致所有 tablet server 同时遇到高延迟的机会。
架构概述下图显示了一个具有三个 master 和多个 tablet server 的 Kudu 集群，每个服务器都支持多个 tablet。它说明了如何使用 Raft 共识来允许 master 和 tablet server 的 leader 和 follow。此外，tablet server 可以成为某些 tablet 的 leader，也可以是其他 tablet 的 follower。leader 以金色显示，而 follower 则显示为蓝色。
Streaming Input with Near Real Time Availability（具有近实时可用性的流输入）
数据分析中的一个共同挑战就是新数据快速而不断地到达，同样的数据需要靠近实时的读取，扫描和更新。Kudu 通过高效的列式扫描提供了快速插入和更新的强大组合，从而在单个存储层上实现了实时分析用例。
Time-series application with widely varying access patterns（具有广泛变化的访问模式的时间序列应用）
time-series（时间序列）模式是根据其发生时间组织和键入数据点的模式。这可以用于随着时间的推移调查指标的性能，或者根据过去的数据尝试预测未来的行为。例如，时间序列的客户数据可以用于存储购买点击流历史并预测未来的购买，或由客户支持代表使用。虽然这些不同类型的分析正在发生，插入和更换也可能单独和批量地发生，并且立即可用于读取工作负载。Kudu 可以用 scalable （可扩展）和 efficient （高效的）方式同时处理所有这些访问模式。由于一些原因，Kudu 非常适合时间序列的工作负载。随着 Kudu 对基于 hash 的分区的支持，结合其对复合 row keys（行键）的本地支持，将许多服务器上的表设置成很简单，而不会在使用范围分区时通常观察到“hotspotting（热点）”的风险。Kudu 的列式存储引擎在这种情况下也是有益的，因为许多时间序列工作负载只读取了几列，而不是整行。 过去，您可能需要使用多个数据存储来处理不同的数据访问模式。这种做法增加了应用程序和操作的复杂性，并重复了数据，使所需存储量增加了一倍（或更糟）。Kudu 可以本地和高效地处理所有这些访问模式，而无需将工作卸载到其他数据存储。
Predictive Modeling（预测建模）