Kudu是一个分布式的,具有可扩展性的列式存储管理器,可以对快速变化的数据进行快速分析。
使用场景
- 近实时计算场景
- 时间序列数据的场景
- 预测建模
- 与存量数据共存
- 既有随机读写/访问,又有批量扫描分析的场景(OLAP)
- HTAP混合事务分析处理场景
- Kudu作为持久层与Impala紧密集成的场景
架构
Kudu包含两种类型的组件:
- Master Server:负责管理元数据
元数据包括Tablet Server的服务器信息以及Tablet信息,Master Server通过Raft协议提供高可用性。
- Tablet Server:用来存储Tablets
每个Tablet存在多个副本,副本之间通过Raft协议提供高可用性。
基本概念
名称 | 描述 |
Master Server | Master Server存储了其他服务的所有元信息,在同一时刻,最多有一个master作为leader提供服务,leader宕机之后会按Raft一致性算法进行重新选举。Master Server会协调Client传来的元信息读写操作。Master Server本身不存储数据,数据存储在一个tablet之中,并会按照正常的tablet进行副本备份。 |
Tablet Server | 简称TServer,负责为客户端存储和提供Tablets,仅Leader Tablet可以写入请求,其他的Tablet只能执行请求。 |
列式存储 | 列式存储相比于行式存储,列式存储把相同列的数据放在一起,因为相同列的数据重复度更高,所以在存储上可以提供更高的压缩比。又因为大部分BI分析只读取部分列,相比行式存储,列式存储只需要扫描需要的列,读取的数据更少,因此可以提供更快速的查询 |
Table | Kudu中所有的数据均存储在Table中,每张表有其对应的表结构和主键,数据按主键有序存储,因为Kudu设计为支持超大规模数据量,Table中的数据会被分割为片段,称之为Tablet。 |
Tablet | 一个Tablet把相邻的数据放在一起,跟其他分布式存储服务类似,一个Tablet会有多个副本放置在不同的服务器上面,在同一个时刻,仅有一个Tablet作为leader存在,每个副本均可单独提供读操作,写操作则需要一致性同步写入(Raft)。 |
Raft | Kudu使用Raft一致性算法,该算法将节点分为leader,follow和candidate三种角色,当leader节点宕机时,follower会成为candidate并且通过多数选举原则成为一个新的leader,因为有多数选举原则,所以在任意时刻,最多有一个leader角色。leader接收client上传的数据修改指令并且分发给follower,当多数follower写入时,leader会认为写入成功并告知client。 |
Catalog Table | Kudu的MetaData的中心位置,存储Table和Tablet的信息。 |
优缺点
优点
- 基于列式存储
- 快速顺序读写
- 使用LSM树以支持高效随机读写
- 查询性能和耗时较稳定
- 不依赖Zookeeper
- 有表结构,需要定义Schema,需要定义唯一键,支持SQL分析(依赖Impala和Spark等引擎)
- 支持增删列,单行级ACID(不支持多行事务,不满足原子性)
- 查询时先查询内存再查询磁盘
- 数据存储在Linux文件系统,不依赖HDFS存储
缺点
- 暂不支持除PK外的二级索引和唯一性限制
- 不支持多行事务
- 不支持BloomFilter优化Join
- 不支持数据回滚
- 不能修改PK,不支持自增 PK
- 每表最多不能超过300列,每个tserver数据压缩后不超过8TB
- 数据类型少,不支持Map,Array和Struct等复杂类型
存储引擎对比
特性 | Kudu | Hudi | DeltaLake |
---|---|---|---|
行级别更新 | 支持 | 支持 | 支持 |
schema修改 | 支持 | 支持 | 支持 |
批流共享 | 支持 | 支持 | 支持 |
可用索引 | 是 | 是 | 否 |
多并发写 | 支持 | 不支持 | 支持 |
版本回滚 | 不支持 | 支持 | 支持 |
实时性 | 高 | 近实时 | 差 |
使用HDFS | 不支持 | 支持 | 支持 |
空值处理 | 默认null | error | 默认null |
多并发读 | 支持 | 支持 | 支持 |
云存储 | 不支持 | 支持 | 支持 |
兼容性 | Spark,Impala,Presto | Spark,Presto,Hive,MR较好 | 依赖Spark,有限支持Hive,Presto |