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日志的作用是如果我们在做真正的操作之前，先将这件事记录下来，持久化到可靠存储中
