Kudu是由Todd Lipcon@Cloudera带头开发出存储系统，整体应用模式与HBase很相似，也就是能够支持行级别的随机读写，对于批量顺序检索功能也能支持。

一、Kudu的必要性

大家不禁要问了?既然与HBase相似，那为什么有了HBase，还需要Kudu呢?

Kudu的定位是 「Fast Analytics on Fast Data」，也就是在更新更及时的基础上实现更快的数据分析。

目前数据存储有了HDFS和Hbase，但两者都存在这明显的缺点，这才需要Kudu。

HDFS:使用列式存储格式Apache Parquet，Apache ORC，适合离线分析，不支持单条纪录级别的update操作，无法进行随机读写

HBASE:可以进行高效随机读写，却并不适用于基于SQL的数据分析方向，不适用于批量数据分析的场景。

二、Kudu整体架构

Table（表）：一张table是数据存储在kudu的位置。Table具有schema和全局有序的primary key(主键)。Table被分为很多段，也就是tablets.

Tablet (段)：一个tablet是一张table连续的segment，与其他数据存储引擎或关系型数据的partition类似。Tablet存在副本机制，其中一个副本为leader tablet。任何副本都能够对服务读取，而且写入时需要在所有副本对应的tablet server之间达成一致性。

Tablet server：主要是存储tablet和为tablet向client提供服务。对于给定的tablet，一个tablet server充当leader，其他tablet server充当该tablet的follower副本。只有leader服务写请求，leader与follower为每个服务提供读请求。

Master：主要负责管理元数据(元数据存储在只有一个tablet的catalog table中)，即tablet与表的基本信息，监听tserver的状态

Catalog Table: 元数据表，用来存储table(schema、locations、states)与tablet（现有的tablet列表，每个tablet及其副本所处tserver，tablet当前状态以及开始和结束键）的信息。

三、Kudu优缺点

1.优点：

1)一个table由多个tablet组成，能够很好地支持分区查看、扩容和数据高可用。

2)可以支持update和upsert操作。

3)与imapla集成或spark集成后(dataframe)可通过标准的sql操作，使用起来很便捷

4)可与spark系统集成

2.缺点：

1)只有主键可以设置range分区。

2)如果是pyspark连接kudu，则不能对kudu进行额外的操作。

3)kudu的shell客户端不提供表schema查看。