1、简介
背景：
大数据主要存储的两种方式：
①静态数据（HDFS）：
优点：
吞吐量大
缺点：
随机读写差
不支持更新操作 //单条数据无法实现更新
②动态数据（HBase）:
优点：
随机读写良好
支持更新操作
缺点：
数据分析的吞吐量小 //HBase读取数据路径比较长，从内存到磁盘，可能还需要读多个HFile文件做版本合并。所以存储在HBase的数据，当我们用
//HBase做数据分析的时候，效率低
注：随机读写是指对任意一个位置的读和写，磁盘随机读写慢是因为需要寻道，倒带才可以访问到指定存储点。
eg：比如今天12点的数据13才到，那么我想写到12点的那个位置上去，利用HBase中的RowKey的有序性可以解决
传统解决方案:
混合架构（T+1）：
数据实时更新在HBase，第二天凌晨同步到HDFS做离线分析。
①数据链长，维护不易
②时效性低，一般的周期都是一天/小时，不能做实时的分析
③如果数据已经同步到了HDFS，那么数据延迟问题得不到解决
kudu :
定义：是一个既支持随机读写、又支持实时sql查询、数据更新插入的大数据存储引擎
kudu在HDFS和HBase中平衡了随机读写和批量分析的性能，完美的和impala集成，既支持了SQL实时查询，也支持了数据更新插入操作
2、架构
Table：
table 是数据存储在 Kudu 的位置，具有 schema 和全局有序的 primary key。
Tablets：
① 一个Tablets是一张Table连续的segment
②Tablets是存在副本的，副本存在于不同的Tablet Server上，副本提供读服务，只有leader提供写服务
Tablet Server：
一个Tablet Server包含多个不同Tablets //最大并行化操作
Master Server:
kudu的整体架构包含两部分：
Tablet Server集群、Master Server集群
Master Server为了保证高可用，一般设置为3台以上，一个为leader，其余为followers。一般只会有一个master起作用（也就是 leader）
作用：
①存储跟踪所有的 tablets，tablet servers，Catalog Table 等 metadata。
②协调客户端的 metadata operations（元数据操作）
例如：
当创建新表时，客户端内部将请求发送给 master。 master 将新表的元数据写入 catalog table，并协调在 tablet server 上创建 tablet 的过程。
注：tablet server 以设定的间隔向 master 发出心跳（默认值为每秒一次）
Raft （类似于zk）：
①tablet、Master的副本选举
②tablet、Master的副本数据写入 //接受以及复制到 follower 副本数据的写入
③tablet、Master的数据迁移 //在节点宕机之后的数据迁移
Catalog Table（目录表）：
存储有关 tables 和 tablets 的信息，只能通过客户端 API 中公开的元数据操作访问
Tables ：
table schemas, locations, and states（表结构，位置和状态）
Tablets
现有tablet 的列表，每个 tablet 的副本所在哪些tablet server，tablet的当前状态以及开始和结束的keys（键）
Logical Replicationa（复制逻辑）：
HDFS操作的是磁盘上的数据。
Kudu：
insert（插入）和 update（更新）确实通过网络传输数据
delete（删除）操作被发送到每个 tablet server，它在本地执行删除。
3、kudu底层存储原理
参考网址：https://blog.csdn.net/lingbo229/article/details/80359987
①1个Table包含多个Tablet，其中Tablet的数量是根据hash或者是range进行设置的
②1个Tablet中包含MetaData信息和多个RowSet信息 //MetaData就是保存的Tablet Server上的位置信息等
③1个RowSet包含一个MemRowSet和多个DiskRowSet
其中MemRowSet用于存储insert数据和update后的数据，写满后会刷新到磁盘中也就是多个DiskRowSet中，默认是1G刷新一次或者是2分钟 //1G数据刷新到众多的DiskRowSet
DiskRowSet会定期的刷新，进行合并操作，删除更新数据之前的历史数据
④1个DiskRowSet包含1个BloomFilter，1个Ad_hoc Index，一个BaseData，多个Delta file文件（UndoFile、RedoFile)，一个Delta MemStore
BloomFile：根据DiskRowSet中key生成一个bloom filter，用于快速模糊的定位某一个key是否在DiskRowSet中
Ad_hoc Index：是主键的索引，用于定位key在DiskRowSet中具体哪个偏移位置
BaseData：是MemRowSet flush下来的数据，按照列存储，按照主键有序 //也就是CFile文件
Deltafile：
UndoFile：是BaseData之前的数据历史数据 //更新数据之前的数据
RedoFile：是BaseData之后的mutation记录，可以获得较新的数据 //最新的更新数据
DeltaMemStore：
Delta Memstore达到一定程度后会在内存中合并数据，然后生成Redo data到磁盘
合并策略：
①多个DeltaFile进行合并生成一个大的DeltaFile。默认是1000个DeltaFile进行合并一次
②DeltaFile文件的大小和Base data的文件的比例为0.1的时候，会进行合并操作，生成Undo data
4、kudu读写流程
读流程：
1、客户端连接TMaster获取表的位置信息
2、客户端找到TServer，Kudu接受读请求，并记录timestamp信息，如果没有显式指定，那么表示使用当前时间
3、从内存中读取数据，也就是MemRowSet和DeltaMemStore中读取数据，根据timestamp来找到对应的mutation链表
//DeltaMemStore是合并数据的缓冲区中，如果都找不到，说明数据在磁盘
4、从磁盘中读取数据，由boom filter快速定位含有此key的DiskRowSet。
5、由index来判断rowId在Data中的偏移
6、根据读操作中包含的timestamp信息判断是否需要将base data进行回滚操作从而获取数据
写流程：
1、客户端连接TMaster获取表的位置信息
2、客户端找到TServer。
3、Kudu在Tablet中的所有rowset（memrowset,diskrowset）中进行查找，看是否存在与待插入数据相同主键的数据，如果存在就返回错误，否则继续
4、写入操作先被提交到tablet的预写日志(WAL)，并根据Raft一致性算法取得追随节点的同意，然后才会被添加到其中一个tablet的内存中，
插入会被添加到tablet的MemRowSet中
更新和删除操作将被追加到MemRowSet中的原始行之后以生成redo记录的列表
5、Kudu在MemRowset中写入一行新数据，在MemRowset（1G或者是120s）数据达到一定大小时
MemRowset将数据落盘，并生成一个diskrowset用于持久化数据还生成一个memrowset继续接收新数据的请求
数据更新流程：
1、客户端连接TMaster获取表的位置信息
2、客户端找到TServer。
3、因为待更新数数据可能位于memrowset中，也可能已经flush到磁盘上，形成diskrowset。
a. 当待更新数据位于memrowset时：
找到待更新数据所在行，然后将更新操作记录在所在行中一个mutation链表中，与插入数据不同的位置上，
在memrowset将数据落盘时，Kudu会将更新合并到base data，并生成UNDO records用于查看历史版本的数据
b. 当待更新数据位于DiskRowset时：
找到待更新数据所在的DiskRowset，每个DiskRowset都会在内存中设置一个DeltaMemStore，将更新操作记录在DeltaMemStore中，
在DeltaMemStore达到一定大小时，flush在磁盘，形成DeltaFile中
注：wal日志的作用是如果我们在做真正的操作之前，先将这件事记录下来，持久化到可靠存储中