2018-04-21

kudu提纲

• 整体技术架构
• 基本组件构成 限制&制约
• 原子性与事务机制
• 压缩与存储机制相关

image.png

● Master：负责集群table、tablet元数据管理，对table的crud，tablet分布，ts宕机后tablet转移。提供元数据信息的api接口；
● TabletServer：提供用户IO请求相应，负责本地磁盘系统的读写
● table ： 表
● tablet ： 分区表，分布在各个tabletserver上
● CatalogTable ： kudu的元数据表，tables、tablets的信息存储于catalog table中，可以通过api的方式访问

使用场景

● 近实时可用的流式数据输入
● 时序应用，以提供更广泛的访问
● 预测建模（更新操作，以改变文件中一个或多个数据集）
● impala可以多个数据源，很方便处理历史遗留问题（数据层面）

Schema的设计

比较合理的设计是什么样？
● 数据分布合理，提升读写的性能
● tablet间数据均匀，负载可以保持稳定
● 数据读取，尽可能涉及到较少的设计操作

以上取决于partition、primarykey的设计，最重要的就是对数据特征的了解。所以，在使用kudu的时候，对我们来说，schema设计是最重要的。

PrimaryKey

● kudu提供了组件索引
● 不支持范围update、delete
● 没有mysql那样的自动增长feature，需要用户自己指定

Partition

• PangePartition
• HashPartition
  前者可以自动分区（动态地增加、删除分区），在时序类应用中比较合适
  后者可以较好的解决热点问题和数据分布不均匀的问题

Comparison

image.png

MutiLevel Partition

Hash and Range Partitioning Example

image.png

Hash and Hash Partitioning Example

image.png

限制因素

• 数据类型不够丰富，数组、映射不支持；
• columns不超多300个，类型不可更改
• 每个数据不超过64KB
• 组件不可变（不可更新）
• 表创建后，Partition分区后不可变（包括分区反思，和分区的拆封合并）