KUDU学习总结
KUDU学习总结
题记：了解KUDU的相关技术，对其技术产生的背景、数据模型、架构和存储进行知识梳理。
1. 技术产生的背景
在 KUDU 之前，大数据主要以两种方式存储：
- 静态数据：以HDFS为存储引擎
- 优势：适用于高吞吐量的离线大数据分析场景
- 局限：数据无法进行随机的读写
- 动态数据：HBase和Cassandra 作为存储引擎
- 优势：适用于大数据随机读写场景
- 局限：批量读取吞吐量远不如 HDFS，不适用于批量数据分析的场景
KUDU进行了折中处理：
2. 数据模型
2.1 核心API
KUDU 的对外 API 主要分为写跟读两部分。其中写包括：Insert、Update、Delete，所有写操作都必须指定主键；读 KUDU 对外只提供了 Scan 操作，Scan 时用户可以指定一个或多个过滤器，用于过滤数据。
2.2 一致性模型
跟大多数关系型数据库一样，KUDU 也是通过 MVCC（Multi-Version Concurrency Control）来实现内部的事务隔离。
3. 架构
3.1 两个角色
- Mater Server：负责集群管理、元数据管理等功能
- Tablet Server：负责数据存储，并提供数据读写服务
KUDU Client 在与服务端交互时，先从 Master Server 获取元数据信息，然后去 Tablet Server 读写数据，如下图：
3.2 数据分区策略
一般数据分区策略主要有两种：
- Range Partitioning：按照字段值范围进行分区，HBase
- 优势：数据进行批量读的时候，可以把大部分的读变成同一个 tablet 中的顺序读，能够提升数据读取的吞吐量。并且按照范围进行分区，我们可以很方便的进行分区扩展。
- 局限：是同一个范围内的数据写入都会落在单个 tablet 上，写的压力大，速度慢
- Hash Partitioning: 按照字段的 Hash 值进行分区，Cassandra
- 优势：数据的写入会被均匀的分散到各个 tablet 中，写入速度快
- 局限：对于顺序读的场景这一策略就不太适用了，因为数据分散，一次顺序读需要将各个 tablet 中的数据分别读取并组合，吞吐量低。并且 Hash 分区无法应对分区扩展的情况。
KUDU将不同分区策略进行组合，取长补短。
4.存储
4.1 设计目标
- 快速的列扫描
- 低延迟的随机更新
- 稳定的性能表现
4.2 存储方式
列式存储
优势
- 查询少量列时 IO 少，速度快
- 数据压缩比高
- 便于查询引擎性能优化：延迟物化、直接操作压缩数据、向量化执行
劣势
- 查询列太多时性能下降（KUDU 建议列数不超过 300 ）
- 不适合 OLTP 场景
4.3 存储实现
与其他大数据存储引擎类似，KUDU 的存储也是通过 LSM 树（Log-Structured Merge Tree）来实现的。KUDU 的最小存储单元是 RowSets，KUDU 中存在两种 RowSets：MemRowSets、DiskRowSets，数据先写内存中的 MemRowSet，MemRowSet 满了后刷到磁盘成为一个 DiskRowSet，DiskRowSet 一经写入，就无法修改了。见下图：
4.4 应对数据变更
DiskRowSet 是不可修改了，那么 KUDU 要如何应对数据的更新呢？在 KUDU 中，把 DiskRowSet 分为了两部分：
- base data： 负责存储基础数据
- delta stores：负责存储 base data 中的变更数据
如上图所示，数据从 MemRowSet 刷到磁盘后就形成了一份 DiskRowSet（只包含 base data），每份 DiskRowSet 在内存中都会有一个对应的 DeltaMemStore，负责记录此 DiskRowSet 后续的数据变更（更新、删除）。DeltaMemStore 内部维护一个 B-树索引，映射到每个 row_offset 对应的数据变更。DeltaMemStore 数据增长到一定程度后转化成二进制文件存储到磁盘，形成一个 DeltaFile，随着 base data 对应数据的不断变更，DeltaFile 逐渐增长。
4.5 优化读写性能
在具体的数据（列数据、变更记录）上，KUDU 都做了 B- 树索引，以提高随机读写的性能。在 base data 中，KUDU 还针对主键做了好几类索引（实际上由于 delta store 只记录变更数据，base data 中对主键的索引即本 DiskRowSet 中全局的主键索引)：
- 主键范围索引：记录本 DiskRowSet 中主键的范围，用于粗粒度过滤一些主键范围
- 布隆过滤器：通过主键的布隆过滤器来实现不存在数据的过滤
- 主键索引：要精确定位一个主键是否存在，以及具体在 DiskRowSet 中的位置（即：row_offset），通过以 B-树为数据结构的主键索引来快速查找。
随着时间的推移，KUDU 中的小文件会越来越多，主要包括各个 DiskRowSet 中的 base data，还有每个 base data 对应的若干份 DeltaFile。小文件的增多会影响 KUDU 的性能，特别是 DeltaFile 中还有很多重复的数据。为了提高性能，KUDU 会进行定期 compaction，compaction 主要包括两部分：
- DeltaFile compaction：过多的 DeltaFile 影响读性能，定期将 DeltaFile 合并回 base data 可以提升性能。在通常情况下，会发生频繁变更的字段是集中在少数几个字段中的，而 KUDU 是列式存储的，因此 KUDU 还在 DeltaFile compaction 时做了优化，文件合并时只合并部分变更列到 base data 中对应的列。
- DiskRowSet compaction：除了 DeltaFile，定期将 DiskRowSet 合并也能提升性能，一个原因是合并时我们可以将被删除的数据彻底的删除，而且可以减少同样 key 范围内数据的文件数，提升索引的效率。
4.6 数据写过程
4.7 数据更新过程
4.8 数据读过程
