Kudu概述

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