1、kudu介绍

Kudu 是一个针对 Apache Hadoop 平台而开发的列式存储管理器。Kudu 共享 Hadoop 生态系统应用的常见技术特性: 它在 commodity hardware（商品硬件）上运行，horizontally scalable（水平可扩展），并支持 highly available（高可用）性操作。此外，Kudu 还有更多优化的特点：

1、OLAP 工作的快速处理。

2、与 MapReduce，Spark 和其他 Hadoop 生态系统组件集成。

3、与 Apache Impala（incubating）紧密集成，使其与 Apache Parquet 一起使用 HDFS 成为一个很好的可变的替代方案。强大而灵活的一致性模型，允许您根据每个 per-request（请求选择）一致性要求，包括 strict-serializable（严格可序列化）一致性的选项。​   

针对同时运行顺序和随机工作负载的情况性能很好。使用 Cloudera Manager 轻松维护和管理。High availability（高可用性）。Tablet server 和 Master 使用 Raft Consensus Algorithm 来保证节点的高可用，确保只要有一半以上的副本可用，该 tablet 便可用于读写。例如，如果 3 个副本中有 2 个或 5 个副本中的 3 个可用，则该 tablet 可用。即使在 leader tablet 出现故障的情况下，读取功能也可以通过 read-only（只读的）follower tablets 来进行服务。结构化数据模型。通过结合这些所有的特性，Kudu 的目标是支持应用家庭中那些难以在当前Hadoop 存储技术中实现的应用。​  

Kudu 常见的几个应用场景: ​   

1、实时更新的应用。刚刚到达的数据就马上要被终端用户使用访问到。​

2、根据海量历史数据查询。​   

3、非常快地返回关于单个实体的细粒度查询。​   

4、实时预测模型的应用，支持根据所有历史数据周期地更新模型。

2、kudu整体架构
Table（表）
　　一张 talbe 是数据存储在 Kudu 的位置。表具有 schema 和全局有序的 primary key（主键）。table 被分成称为 tablets 的 segments。
Tablet
　　一个 tablet 是一张 table 连续的 segment，与其它数据存储引擎或关系型数据库中的 partition（分区）相似。给定的 tablet 冗余到多个 tablet 服务器上，并且在任何给定的时间点，其中一个副本被认为是 leader tablet。任何副本都可以对读取进行服务，并且写入时需要在为 tablet 服务的一组 tablet server之间达成一致性。
Tablet Server
　　一个 tablet server 存储 tablet 和为 tablet 向 client 提供服务。对于给定的 tablet，一个 tablet server 充当 leader，其他 tablet server 充当该 tablet 的 follower 副本。只有 leader服务写请求，然而 leader 或 followers 为每个服务提供读请求。leader 使用 Raft Consunsus Algorithm来进行选举 。一个 tablet server 可以服务多个 tablets ，并且一个 tablet 可以被多个 tablet servers 服务着。
3、kudu底层原理

一张表会分成若干个tablet，每个tablet包括MetaData元信息及若干个RowSet，RowSet包含一个MemRowSet及
若干个DiskRowSet，DiskRowSet中包含一个BloomFile、Ad_hoc Index、BaseData、DeltaMem及若干个
RedoFile和UndoFile（UndoFile一般情况下只有一个）。
MemRowSet：用于新数据insert及已在MemRowSet中的数据的更新，一个MemRowSet写满后会将数据刷到磁盘形成若干个DiskRowSet。每次到达32M生成一个DiskRowSet。
DiskRowSet：用于老数据的变更（mutation），后台定期对DiskRowSet做compaction，以删除没用的数据及合并历史数据，减少查询过程中的IO开销。
BloomFile：根据一个DiskRowSet中的key生成一个bloom filter，用于快速模糊定位某个key是否在DiskRowSet中存在。
Ad_hocIndex：是主键的索引，用于定位key在DiskRowSet中的具体哪个偏移位置。
BaseData是MemRowSet flush下来的数据，按列存储，按主键有序。


Kudu是一种完全的列式存储引擎，表中的每一列数据都是存放在一起，列与列之间都是分开的。
为了能够保存一部分历史数据，并实现MVCC，Kudu将数据分为三个部分。一个部分叫做base data，是当前的数据；第二个部分叫做UNDO records，存储的是从插入数据时到形成base data所进行的所有修改操作，修改操作以一定形式进行组织，实现快速查看历史数据；第三个部分是REDO records，存储的是还未merge到当前数据中的更新操作。下图中表示的是在Kudu中插入一条数据、更新数据两个操作的做法，当然做法不唯一，不唯一的原因是Kudu可以选择先不将更新操作合并到base data中。
4、MemRowSet
以B+Tree方式实现，用于新数据insert及已在MemRowSet中的数据的更新，一个MemRowSet写满后会将数据刷到磁盘形成若干个DiskRowSet。每次到达32M生成一个DiskRowSet。
5、DiskRowSet
以二叉平衡树的方式实现，用于老数据的变更（mutation），后台定期对DiskRowSet做compaction，以删除没用的数据及合并历史数据，减少查询过程中的IO开销。
磁盘上每一个DiskRowSet有若干.metadata和.data文件，metadata文件记录的是DiskRowSet的元信息，主要包括哪些block和block在data中的位置，上图为block和DiskRowSet中各部分的映射关系，在写磁盘时是通过container来写入，每个container可以写很大的一块连续的磁盘空间，用于给某一个CFile写数据，当一个CFile写完后会将container归还给BlockManager，这时container就可以用于下一个CFile写数据了，当BlockManager中没有container可用是会创建一个新的container给新的CFile使用。

对应新建block先看看是否有container可用，若没有，目前默认的是在所在的配置中的data_dir中随机选取一个dir建一个新的metadata和data文件。先写data，block落盘后再写metadata。
6、MVCC
表的主键排序,受益于MVCC（Multi-Version Concurrency Control 多版本并发控制，一旦数据写入到MemRowSet，后续的reader能立马查询到。
7、kudu的写流程
1、客户端连接到TMaster获取表的相关信息（分区和tablet信息）；
2、找到负责写请求的tablet 所在的TServer，kudu接受客户端的请求，检查本次写操作是否符合要求；
3、kudu在 tablet 中所有RowSet 中，查找是否存在与待插入数据相同主键的记录，如果存在，返回错误？否则继续；
4、写入操作先被提交到tablet 的预写日志（WAL）上，然后根据Raft 一致性算法取得追随节点的同意后，才会被添加到其中一个tablet 的内存中，插入到MenRowSet中。（因为在MemRowSet 中支持了多版本并发控制（mvcc） ，对最近插入的行（未刷新到磁盘上的新的行）的更新和删除操作将被追加到MemRowSet中的原始行之后以生成Redo 记录的列表）。
5、kudu在MemRowSet 中写入新数据，在MemRowSet 达到一定大小或者时间限制（1G 或者 120s），MemRowSet 会将数据落盘，生成一个DiskRowSet 用于持久化数据 和 一个 MemRowSet 继续接受新数据的请求。

8、kudu的读流程
1、客户端连接TMaster 获取表的相关信息，包括分区和表中的tablet 的信息；
2、客户端找到 tablet 所在的TServer 以后，kudu接受读请求，并记录timestamp（没有显示指定就使用当前时间）信息；
3、从内存中读取数据，即是从MemRowSet 和 DeltaRowSet中读取数据，根据timestamp来找到对应的mutation链表；
4、从磁盘中读取数据，从metadata文件中使用boom

9、kudu的更新操作
1、客户端连接到TMaster获取表的相关信息（分区和tablet信息）；
2、找到负责写请求的tablet 所在的TServer，kudu接受客户端的请求，检查本次写操作是否符合要求；
3、因为待更新的数据可能位于MemRowSet ，也可能位于DiskRowSet 中，所以根据待更新的数据所处的位置，kudu有不同的做法：
a） 当待更新的数据位于MemRowSet时，找到它所在的行，然后将跟新操作记录在所在行中的一个mutation的链表中，在MemRowSet 数据落地的时候，kudu会将更新合并到base data，并生成undo records 用于查看历史版本的数据和MVCC， undo records 实际上也是以 DeltaFile 的形式存放；
b）当待跟新的数据位于DiskRowSet时，找到待跟新数据所在的DiskRowSet ，每个DiskRowSet 都会在内存中设置一个DeltaMemStore，将更新操作记录在DeltaMemStore中，在DeltaMemStore达到一定大小时，flush 在磁盘，形成Delta并存放在DeltaFile中。

参考来自：https://blog.csdn.net/Apache_Jerry/article/details/88669885
参考来自：https://blog.csdn.net/weixin_39478115/article/details/78470294参考来自：https://blog.csdn.net/lingbo229/article/details/80359987

1、kudu介绍

Kudu 是一个针对 Apache Hadoop 平台而开发的列式存储管理器。Kudu 共享 Hadoop 生态系统应用的常见技术特性: 它在 commodity hardware（商品硬件）上运行，horizontally scalable（水平可扩展），并支持 highly available（高可用）性操作。此外，Kudu 还有更多优化的特点：

1、OLAP 工作的快速处理。

2、与 MapReduce，Spark 和其他 Hadoop 生态系统组件集成。

3、与 Apache Impala（incubating）紧密集成，使其与 Apache Parquet 一起使用 HDFS 成为一个很好的可变的替代方案。强大而灵活的一致性模型，允许您根据每个 per-request（请求选择）一致性要求，包括 strict-serializable（严格可序列化）一致性的选项。​   

针对同时运行顺序和随机工作负载的情况性能很好。使用 Cloudera Manager 轻松维护和管理。High availability（高可用性）。Tablet server 和 Master 使用 Raft Consensus Algorithm 来保证节点的高可用，确保只要有一半以上的副本可用，该 tablet 便可用于读写。例如，如果 3 个副本中有 2 个或 5 个副本中的 3 个可用，则该 tablet 可用。即使在 leader tablet 出现故障的情况下，读取功能也可以通过 read-only（只读的）follower tablets 来进行服务。结构化数据模型。通过结合这些所有的特性，Kudu 的目标是支持应用家庭中那些难以在当前Hadoop 存储技术中实现的应用。​  

Kudu 常见的几个应用场景: ​   

1、实时更新的应用。刚刚到达的数据就马上要被终端用户使用访问到。​

2、根据海量历史数据查询。​   

3、非常快地返回关于单个实体的细粒度查询。​   

4、实时预测模型的应用，支持根据所有历史数据周期地更新模型。

2、kudu整体架构
Table（表）
　　一张 talbe 是数据存储在 Kudu 的位置。表具有 schema 和全局有序的 primary key（主键）。table 被分成称为 tablets 的 segments。
Tablet
　　一个 tablet 是一张 table 连续的 segment，与其它数据存储引擎或关系型数据库中的 partition（分区）相似。给定的 tablet 冗余到多个 tablet 服务器上，并且在任何给定的时间点，其中一个副本被认为是 leader tablet。任何副本都可以对读取进行服务，并且写入时需要在为 tablet 服务的一组 tablet server之间达成一致性。
Tablet Server
　　一个 tablet server 存储 tablet 和为 tablet 向 client 提供服务。对于给定的 tablet，一个 tablet server 充当 leader，其他 tablet server 充当该 tablet 的 follower 副本。只有 leader服务写请求，然而 leader 或 followers 为每个服务提供读请求。leader 使用 Raft Consunsus Algorithm来进行选举 。一个 tablet server 可以服务多个 tablets ，并且一个 tablet 可以被多个 tablet servers 服务着。
3、kudu底层原理

一张表会分成若干个tablet，每个tablet包括MetaData元信息及若干个RowSet，RowSet包含一个MemRowSet及
若干个DiskRowSet，DiskRowSet中包含一个BloomFile、Ad_hoc Index、BaseData、DeltaMem及若干个
RedoFile和UndoFile（UndoFile一般情况下只有一个）。
MemRowSet：用于新数据insert及已在MemRowSet中的数据的更新，一个MemRowSet写满后会将数据刷到磁盘形成若干个DiskRowSet。每次到达32M生成一个DiskRowSet。
DiskRowSet：用于老数据的变更（mutation），后台定期对DiskRowSet做compaction，以删除没用的数据及合并历史数据，减少查询过程中的IO开销。
BloomFile：根据一个DiskRowSet中的key生成一个bloom filter，用于快速模糊定位某个key是否在DiskRowSet中存在。
Ad_hocIndex：是主键的索引，用于定位key在DiskRowSet中的具体哪个偏移位置。
BaseData是MemRowSet flush下来的数据，按列存储，按主键有序。


Kudu是一种完全的列式存储引擎，表中的每一列数据都是存放在一起，列与列之间都是分开的。
为了能够保存一部分历史数据，并实现MVCC，Kudu将数据分为三个部分。一个部分叫做base data，是当前的数据；第二个部分叫做UNDO records，存储的是从插入数据时到形成base data所进行的所有修改操作，修改操作以一定形式进行组织，实现快速查看历史数据；第三个部分是REDO records，存储的是还未merge到当前数据中的更新操作。下图中表示的是在Kudu中插入一条数据、更新数据两个操作的做法，当然做法不唯一，不唯一的原因是Kudu可以选择先不将更新操作合并到base data中。
4、MemRowSet
以B+Tree方式实现，用于新数据insert及已在MemRowSet中的数据的更新，一个MemRowSet写满后会将数据刷到磁盘形成若干个DiskRowSet。每次到达32M生成一个DiskRowSet。
5、DiskRowSet
以二叉平衡树的方式实现，用于老数据的变更（mutation），后台定期对DiskRowSet做compaction，以删除没用的数据及合并历史数据，减少查询过程中的IO开销。
磁盘上每一个DiskRowSet有若干.metadata和.data文件，metadata文件记录的是DiskRowSet的元信息，主要包括哪些block和block在data中的位置，上图为block和DiskRowSet中各部分的映射关系，在写磁盘时是通过container来写入，每个container可以写很大的一块连续的磁盘空间，用于给某一个CFile写数据，当一个CFile写完后会将container归还给BlockManager，这时container就可以用于下一个CFile写数据了，当BlockManager中没有container可用是会创建一个新的container给新的CFile使用。

对应新建block先看看是否有container可用，若没有，目前默认的是在所在的配置中的data_dir中随机选取一个dir建一个新的metadata和data文件。先写data，block落盘后再写metadata。
6、MVCC
表的主键排序,受益于MVCC（Multi-Version Concurrency Control 多版本并发控制，一旦数据写入到MemRowSet，后续的reader能立马查询到。
7、kudu的写流程
1、客户端连接到TMaster获取表的相关信息（分区和tablet信息）；
2、找到负责写请求的tablet 所在的TServer，kudu接受客户端的请求，检查本次写操作是否符合要求；
3、kudu在 tablet 中所有RowSet 中，查找是否存在与待插入数据相同主键的记录，如果存在，返回错误？否则继续；
4、写入操作先被提交到tablet 的预写日志（WAL）上，然后根据Raft 一致性算法取得追随节点的同意后，才会被添加到其中一个tablet 的内存中，插入到MenRowSet中。（因为在MemRowSet 中支持了多版本并发控制（mvcc） ，对最近插入的行（未刷新到磁盘上的新的行）的更新和删除操作将被追加到MemRowSet中的原始行之后以生成Redo 记录的列表）。
5、kudu在MemRowSet 中写入新数据，在MemRowSet 达到一定大小或者时间限制（1G 或者 120s），MemRowSet 会将数据落盘，生成一个DiskRowSet 用于持久化数据 和 一个 MemRowSet 继续接受新数据的请求。

8、kudu的读流程
1、客户端连接TMaster 获取表的相关信息，包括分区和表中的tablet 的信息；
2、客户端找到 tablet 所在的TServer 以后，kudu接受读请求，并记录timestamp（没有显示指定就使用当前时间）信息；
3、从内存中读取数据，即是从MemRowSet 和 DeltaRowSet中读取数据，根据timestamp来找到对应的mutation链表；
4、从磁盘中读取数据，从metadata文件中使用boom

9、kudu的更新操作
1、客户端连接到TMaster获取表的相关信息（分区和tablet信息）；
2、找到负责写请求的tablet 所在的TServer，kudu接受客户端的请求，检查本次写操作是否符合要求；
3、因为待更新的数据可能位于MemRowSet ，也可能位于DiskRowSet 中，所以根据待更新的数据所处的位置，kudu有不同的做法：
a） 当待更新的数据位于MemRowSet时，找到它所在的行，然后将跟新操作记录在所在行中的一个mutation的链表中，在MemRowSet 数据落地的时候，kudu会将更新合并到base data，并生成undo records 用于查看历史版本的数据和MVCC， undo records 实际上也是以 DeltaFile 的形式存放；
b）当待跟新的数据位于DiskRowSet时，找到待跟新数据所在的DiskRowSet ，每个DiskRowSet 都会在内存中设置一个DeltaMemStore，将更新操作记录在DeltaMemStore中，在DeltaMemStore达到一定大小时，flush 在磁盘，形成Delta并存放在DeltaFile中。

参考来自：https://blog.csdn.net/Apache_Jerry/article/details/88669885
参考来自：https://blog.csdn.net/weixin_39478115/article/details/78470294参考来自：https://blog.csdn.net/lingbo229/article/details/80359987