kudu基础 读写操作

kudu基础

kafka

• 消息队列
• 高吞吐量低开销
• 将追踪已读取消息的任务交给了读取器

kudu

• kafka的替代者
• 是与hbase相似的列式存储分布式数据库
• 提供给结构化数据的储存引擎
• 使用水平分区分配数据
• 使用raft共识复制分区

结构化数据：
静态数据集：储存在HDFS中（高吞吐量 ）
半结构化数据：储存在HBase和Cassandra。可适应于低延迟的记录级读写，但是在对ML和基于SQL的分析等应用上连续读吞吐量上远远落后于静态文件格式

为什么需要kudu?
HDFS ：吞吐量高，列式存储，不支持record-level操作，随机读写性差
HBase： 高效随机读写，获取大批量数据时性能差，不适用于数据分析
kudu同时拥有 HDFS的扫描性能和HBase的随机读写性能

table: 包含schema和primary key
tablet：段，是在一张table连续的segment。存在副本机制

一个table->n个tablet->m*n个metaData信息+RowSet信息
RowSet=一个memrowset和0到多个diskRowset
ps: 区别每条数据之间的唯一标识
ACID: 原子性，一致性，隔离性，持久性

主要角色：master和tserver
master：管理元数据信息，监听server，当server宕机之后负责tablet的重分配
tserver: tablet的储存与数据的增删改查

kudu操作流程

读流程

1. client连接到tmaster（获取表的相关信息），找到需要读取数据的tablet所在的tserver（把信息发送给master的过程）
2. master校验后返回元数据给client（把tserver信息返回），client和tserver建立连接，并记录timestamp（若没有显式指定则使用当前时间）
3. 内存：从MemRowSet和DeltaMemStore中读取数据，根据timestamp找到对应的mutation链表
4. 磁盘：通过metaData找到数据所在的rowSet。（先加载内存里面的数据再加载磁盘里面的数据），最后把数据返回给client

插入流程（写流程）

1. client连接tmaster获取元数据信息(tablet信息)，
2. 找到并连接tserver，
3. kudu在所有的rowset中进行查找（在MemRowSet和DiskRowSet中是否存在相同的primary key）。若存在，则返回错误。若不存在，则把待插入的数据写入Wal 日志（预写日志），并根据raft一致性算法获得追随节点同意之后，才会插入到其中一个tablet的内存中（写入的是tablet的MemRowSet）
4. 在MemRowSet中的数据达到一定大小时，MemRowSet会将数据落盘然后生成一个diskrowset用于持久化数据，并生成一个MemRowSet来继续接收新数据请求

更新流程

1. client连接tmaster获取元数据(tablet)，再连接tserver。
2. 根据数据位置不同，执行不同的操作
   • 若数据在MemRowSet中，将更新信息写入数据所在行的mutation链表中。(该MemRowSet落盘之后会合并到base data中，并且生成用于查看历史版本的数据的records)
   • 若数据在磁盘（DiskRowSet）中，将更新信息写在DeltMemStore中。DeltaMemStore达到一定大小会落盘。

ps: wal日志会在真正操作之前把这件事记录下来并持久化到可靠存储中。所以出错的时候很容易就可以通过该日志检查并重做。

参考：

1. 如何评价kudu?
2. kudu和kafka对比的blog
3. kudu的一篇论文
4. kudu架构原理(我写完之后才发现这一篇，说实话写的比我的全面很多，推荐看看)