CC00002.kudu——|Hadoop&OLAP_Kudu.V02|——|kudu.v02|架构|Master|Table|

一、Kudu的架构

### --- Kudu架构

~~~     与HDFS和HBase相似，Kudu使用单个的Master节点，用来管理集群的元数据，
~~~     并且使用任意数量的Tablet Server节点用来存储实际数据。可以部署多个Master节点来提高容错性。

二、Master：Kudu.Master架构

### --- Kudu的master节点负责整个集群的元数据管理和服务协调。它承担着以下功能：

~~~     作为catalog manager，master节点管理着集群中所有table和tablet的schema及一些其他的元数据。
~~~     作为cluster coordinator，master节点追踪着所有server节点是否存活，
~~~     并且当server节点挂掉后协调数据的重新分布。
~~~     作为tablet directory，master跟踪每个tablet的位置。

~~~     # Catalog Manager

~~~     Kudu的master节点会持有一个单tablet的table——catalog table，但是用户是不能直接访问的。
~~~     master将内部的catalog信息写入该tablet，并且将整个catalog的信息缓存到内存中。
~~~     随着现在商用服务器上的内存越来越大，并且元数据信息占用的空间其实并不大，
~~~     所以master不容易存在性能瓶颈。
~~~     catalog table保存了所有table的schema的版本以及table的状态(创建、运行、删除等)。

~~~     # Cluster Coordination

~~~     Kudu集群中的每个tablet server都需要配置master的主机名列表。
~~~     当集群启动时，tablet server会向master注册，并发送所有tablet的信息。
~~~     tablet server第一次向master发送信息时会发送所有tablet的全量信息，
~~~     后续每次发送则只会发送增量信息，仅包含新创建、删除或修改的tablet的信息。 
~~~     作为cluster coordination，master只是集群状态的观察者。
~~~     对于tablet server中tablet的副本位置、
~~~     Raft配置和schema版本等信息的控制和修改由tablet server自身完成。
~~~     master只需要下发命令，tablet server执行成功后会自动上报处理的结果。

~~~     # Tablet Directory

~~~     因为master上缓存了集群的元数据，所以client读写数据的时候，
~~~     肯定是要通过master才能获取到tablet的位置等信息。
~~~     但是如果每次读写都要通过master节点的话，那master就会变成这个集群的性能瓶颈，
~~~     所以client会在本地缓存一份它需要访问的tablet的位置信息，
~~~     这样就不用每次读写都从master中获取。 
~~~     因为tablet的位置可能也会发生变化(比如某个tablet server节点crash掉了)，
~~~     所以当tablet的位置发生变化的时候，client会收到相应的通知，
~~~     然后再去master上获取一份新的元数据信息。

三、Table

### --- Table

~~~     在数据存储方面，Kudu选择完全由自己实现，而没有借助于已有的开源方案。

~~~     # tablet存储主要想要实现的目标为：

~~~     快速的列扫描
~~~     低延迟的随机读写
~~~     一致性的性能

~~~     # RowSets

~~~     在Kudu中，tablet被细分为更小的单元，叫做RowSets。
~~~     一些RowSet仅存在于内存中，被称为MemRowSets，
~~~     而另一些则同时使用内存和硬盘，被称为DiskRowSets。
~~~     任何一行未被删除的数据都只能存在于一个RowSet中。 
~~~     无论任何时候，一个tablet仅有一个MemRowSet用来保存最新插入的数据，
~~~     并且有一个后台线程会定期把内存中的数据flush到硬盘上。 
~~~     当一个MemRowSet被flush到硬盘上以后，一个新的MemRowSet会替代它。
~~~     而原有的MemRowSet会变成一到多个DiskRowSet。flush操作是完全同步进行的，
~~~     在进行flush时，client同样可以进行读写操作。

~~~     # MemRowSet

~~~     MemRowSets是一个可以被并发访问并进行过锁优化的B-tree，
~~~     主要是基于MassTree来设计的，但存在几点不同：
~~~     Kudu并不支持直接删除操作，由于使用了MVCC，
~~~     所以在Kudu中删除操作其实是插入一条标志着删除的数据，这样就可以推迟删除操作。
~~~     类似删除操作，Kudu也不支持原地更新操作。
~~~     将tree的leaf链接起来，就像B+-tree。这一步关键的操作可以明显地提升scan操作的性能。
~~~     没有实现字典树(trie树)，而是只用了单个tree，因为Kudu并不适用于极高的随机读写的场景。
~~~     与Kudu中其他模块中的数据结构不同，MemRowSet中的数据使用行式存储。
~~~     因为数据都在内存中，所以性能也是可以接受的，
~~~     而且Kudu对在MemRowSet中的数据结构进行了一定的优化。

~~~     # DiskRowSet

~~~     当MemRowSet被flush到硬盘上，就变成了DiskRowSet。
~~~     当MemRowSet被flush到硬盘的时候，每32M就会形成一个新的DiskRowSet，
~~~     这主要是为了保证每个DiskRowSet不会太大，便于后续的增量compaction操作。
~~~     Kudu通过将数据分为base data和delta data，来实现数据的更新操作。
~~~     Kudu会将数据按列存储，数据被切分成多个page，并使用B-tree进行索引。
~~~     除了用户写入的数据，Kudu还会将主键索引存入一个列中，并且提供布隆过滤器来进行高效查找。

~~~     # Compaction

~~~     为了提高查询性能，Kudu会定期进行compaction操作，合并delta data与base data，
~~~     对标记了删除的数据进行删除，并且会合并一些DiskRowSet。

### --- 分区

~~~     # 选择分区策略需要理解数据模型和表的预期工作负载:
~~~     对于写量大的工作负载，重要的是要设计分区，使写分散在各个tablet上，以避免单个tablet超载。
~~~     对于涉及许多短扫描的工作负载(其中联系远程服务器的开销占主导地位)，
~~~     如果扫描的所有数据都位于同一块tablet上，则可以提高性能。
~~~     理解这些基本的权衡是设计有效分区模式的核心。
~~~     没有默认分区 在创建表时，Kudu不提供默认的分区策略。
~~~     建议预期具有繁重读写工作负载的新表至少拥有与tablet服务器相同的tablet。
~~~     和许多分布式存储系统一样，Kudu的table是水平分区的。
~~~     BigTable只提供了range分区，Cassandra只提供hash分区，
~~~     而Kudu同时提供了这两种分区方式，使分区较为灵活。
~~~     当用户创建一个table时，
~~~     可以同时指定table的的partition schema，partition schema会将primary key映射为partition key。
~~~     一个partition schema包括0到多个hash-partitioning规则和一个range-partitioning规则。
~~~     通过灵活地组合各种partition规则，用户可以创造适用于自己业务场景的分区方式。