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分区后不可变（包括分区反思，和分区的拆封合并）
Kudu和HDFS的比较
- HDFS为分布式文件系统， Kudu 为非文件件系统，数据必须按表的形式结构化存 储;
- Kudu为原生的Hadoop存储引擎，通常也需要和HDFS并肩同部署;
Kudu和HBase的比较
相同点
- 内存部分差别不大，使 MemStore，MVCC等;
- 基本思想同样基于LSM架构，但Kudu的实现 复杂;
- 一条记录只在一个RowSet中;
- Kudu的事务性和HBase 样，只保证行级事务;
不同点
- Kudu预先定义数据Schema，主要面对结构化数据，HBase主要面向半结构化数据，可能有万以上的稀疏矩阵。因此Kudu能很好的支持SQL。据Cloudera说，Kudu变更为Schema，如改变column的效率还不错。
- Kudu除 partition还 持bucket，因此可以均衡查询并 (parallelism)和并发 (concurrency)。
- Kudu使列式存储，分析性能好于HBase;
4.存储和处理效率更高
- 由于有schema，因此 需要存储 名;
- update等使 offset表示位置，不是rowkey。
- 性能: Kudu的flush和compact更为复杂，因此write的性能(尤其是update) HBase差; 同时由于采列式存储，读取单条记录的性能(尤其是有很多 新时)也 HBase差。
- compaction:Kudu没有minor和major的区别，没有长时间stop-all的compaction，后台使用低IO级别的线程一直不停地compact;
- 副本一致性:每个数据块副本使 leader-follower 式服务，使用Raft(类似Zookeeper、 Paxos)consensus协议，能定义一致性，秒级MTTR(Mean Time To Recovery，平均恢复 时间)，每个follower都有WAL，能 持(n-1)/2台服务器的宕机。 同于HBase的单Region服务模式，HDFS能 持n-1台机 宕机，服务可靠性 ;
- Kudu中的Master 像是一个旁观者，提出建议，而HBase中Master直接管 哪块数据在哪被服务;
- 底层存储结构HBase使 HDFS， Kudu有自己的存储架构，直接存储本地磁盘，备份基于日志数据，适合跨数据中 的部署。
Kudu 和 Spark SQL集成后，能带来的好处:
- 带来和 Parquet 相似的扫描性能，但却不存在数据 新/插 的延迟，也就是说，对数据的实时更新/插入，对分析应用来说是即时可见的，无延迟。
- Spark对数据的过滤条件(基于判定的过滤条件，即 predicate)可以下推到 Kudu 这个存储层，能提高数据读取/扫描的性能
- 相对于Parquet，kudu基于主键索引的查询，性能更好
