Hadoop生态圈之Kudu（一）

Apache Kudu

​        Apache Kudu 是由 Cloudera 开源的存储引擎，可以同时提供低延迟的随机读写和高效的数据分析能力。它是一个融合 HDFS 和 HBase 的功能的新组件，具备介于两者之间的新存储组件。

​        Kudu 支持水平扩展，并且与 Cloudera Impala 和 Apache Spark 等当前流行的大数据查询和分析工具结合紧密。

 

Kudu 应用场景

• 适用于那些既有随机访问，也有批量数据扫描的复合场景

• 高计算量的场景

• 使用了高性能的存储设备，包括使用更多的内存

• 支持数据更新，避免数据反复迁移

• 支持跨地域的实时数据备份和查询

• 国内使用的 kudu 一些案例可以查看《构建近实时分析系统.pdf》文档。

 

Kudu 架构

​        与 HDFS 和 HBase 相似， Kudu 使用单个的 Master 节点，用来管理集群的元数据，并且使用任意数量的 Tablet Server（类似 HBase 中的 RegionServer 角 色）节点用来存储实际数据。可以部署多个 Master 节点来提高容错性。

 

• Table

  ​ 表（Table）是数据库中用来存储数据的对象，是有结构的数据集合。kudu 中的表具有 schema（纲要） 和全局有序的 primary key（主键）。 kudu 中一个 table 会被水平分成多个被称之为 tablet 的片段

• Tablet

  ​ 一个 tablet 是一张 table 连续的片段， tablet 是 kudu 表的水平分区， 类似于 HBase 的 region。每个 tablet 存储着一定连续 range 的数据（key）， 且 tablet 两两间的 range 不会重叠。一张表的所有 tablet 包含了这张表的所有 key 空间

  ​ tablet 会冗余存储。 放置到多个 tablet server 上，并且在任何给定的时间点，其中一个副本被认为是 leader tablet,其余的被认之为 follower tablet。 每个 tablet 都可以进行数据的读请求，但只有 Leader tablet 负责写数据请求。

• Tablet Server

  ​ tablet server 集群中的小弟， 负责数据存储，并提供数据读写服务

  ​ 一个 tablet server 存储了 table 表的 tablet， 向 kudu client 提供读 取数据服务。对于给定的 tablet，一个 tablet server 充当 leader，其他 tablet server 充当该 tablet 的 follower 副本。

  ​ 只有 leader 服务写请求，然而 leader 或 followers 为每个服务提供读 请求 。一个 tablet server 可以服务多个 tablets ，并且一个 tablet 可以被多个 tablet servers 服务着

• Master Server

  负责集群管理、元数据管理等功能。

 

Kudu 原理

• table 与 schema

  ​         Kudu 设计是面向结构化存储的，因此， Kudu 的表需要用户在建表时定义它 的 Schema 信息，这些 Schema 信息包含： 列定义（含类型）， Primary Key 定义 （用户指定的若干个列的有序组合）。数据的唯一性，依赖于用户所提供的 Primary Key 中的 Column 组合的值的唯一性。Kudu 提供了 Alter 命令来增删列， 但位于 Primary Key 中的列是不允许删除的。

  ​         从用户角度来看， Kudu 是一种存储结构化数据表的存储系统。在一个 Kudu 集群中可以定义任意数量的 table，每个 table 都需要预先定义好 schema。每个 table 的列数是确定的，每一列都需要有名字和类型，每个表中可以把其中一列 或多列定义为主键。这么看来， Kudu 更像关系型数据库，而不是像 HBase、 Cassandra 和 MongoDB 这些 NoSQL 数据库。不过 Kudu 目前还不能像关系型数据 一样支持二级索引。

  ​         Kudu 使用确定的列类型，而不是类似于 NoSQL 的“everything is byte”。 带来好处：确定的列类型使 Kudu 可以进行类型特有的编码,可以提供元数据给其他上层查询工具。

• kudu 底层数据模型

  ​         Kudu 的底层数据文件的存储，未采用 HDFS 这样的较高抽象层次的分布式文件系统，而是自行开发了一套可基于 Table/Tablet/Replica 视图级别的底层存储系统。

 

​         一张 table 会分成若干个 tablet，每个 tablet 包括 MetaData 元信息及若 干个 RowSet。

​        RowSet 包含一个 MemRowSet 及若干个 DiskRowSet， DiskRowSet 中包含一个 BloomFile、Ad_hoc Index、BaseData、DeltaMem 及若干个 RedoFile 和 UndoFile。

• MemRowSet：用于新数据 insert 及已在 MemRowSet 中的数据的更新，一个 MemRowSet 写满后会将数据刷到磁盘形成若干个 DiskRowSet。 默认是 1G 或者或 者 120S。

• DiskRowSet：用于老数据的变更，后台定期对 DiskRowSet 做 compaction， 以删除没用的数据及合并历史数据，减少查询过程中的 IO 开销。

• BloomFile：根据一个 DiskRowSet 中的 key 生成一个 bloom filter，用 快速模糊定位某个 key 是否在 DiskRowSet 中。

• Ad_hocIndex：是主键的索引，用于定位 key 在 DiskRowSet 中的具体哪个偏移位置。

• BaseData 是 MemRowSet flush 下来的数据，按列存储，按主键有序。

• UndoFile 是基于 BaseData 之前时间的历史数据，通过在 BaseData 上 apply UndoFile 中的记录，可以获得历史数据。

• RedoFile 是基于 BaseData 之后时间的变更记录，通过在 BaseData 上 apply RedoFile 中的记录，可获得较新的数据。

• DeltaMem 用于 DiskRowSet 中数据的变更，先写到内存中，写满后 flush 到 磁盘形成 RedoFile。

  在 KUDU 中， 把 DiskRowSet 分为了两部分： base data、 delta stores。 base data 负责存储 基础数据， delta stores 负责存储 base data 中的变更数据

• tablet 发现过程

  ​ 当创建 Kudu 客户端时，其会从主服务器上获取 tablet 位置信息，然后直接与服务于该 tablet 的服务器进行交谈。 为了优化读取和写入路径， 客户端将保留该信息的本地缓存，以防止他们在 每个请求时需要查询主机的 tablet 位置信息。随着时间的推移，客户端的缓存可能会变得过时，并且当写入被发送到不再是 tablet 领导者的 tablet 服务器 时，则将被拒绝。然后客户端将通过查询主服务器发现新领导者的位置来更新其缓存。

 

Kudu 写流程

1. 当 Client 请求写数据时， 先根据主键从 Master Server 中获取要访问的目标 Tablets，然后到依次对应的 Tablet 获取数据。

2. 因为 KUDU 表存在主键约束，所以需要进行主键是否已经存在的判断，这里就涉及到之前说的索引结构对读写的优化了。一个 Tablet 中存在很多个 RowSets， 为了提升性能，我们要尽可能地减少要扫描的 RowSets 数量。

3. 首先，我们先通过每个 RowSet 中记录的主键的（最大最小）范围，过滤掉一批不存在目标主键的 RowSets，然后在根据 RowSet 中的布隆过滤器，过滤掉确定不存在目标主键的 RowSets，最后再通过 RowSets 中的 B-树索引，精确定位目标主键是否存在。

4. 如果主键已经存在，则报错（主键重复），否则就进行写数据（写 MemRowSet）。

 

Kudu 读流程

1. 数据读取过程大致如下： 先根据要扫描数据的主键范围，定位到目标的 Tablets，然后读取 Tablets 中的 RowSets。

2. 在读取每个 RowSet 时，先根据主键过滤要 scan 范围，然后加载范围内的 base data，再找到对应的 delta stores，应用所有变更，最后 union 上 MemRowSet 中的内容，返回数据给 Client。

 

Kudu 更新过程

​        数据更新的核心是定位到待更新数据的位置，这块与写入的时候类似，就不展开了，等定位到具体位置后，然后将变更写到对应的 delta store 中