文章目录
一、kudu是什么？
Kudu和Hbase类似也是一个分布式数据库，据官方给它的定位是提供”fast analytics on fast data”（在更新更及时的数据上做更快的分析）。
据说Cloudera曾经想直接通过修改HBase来支持Kudu现在的功能，但是Kudu的数据模型和磁盘存储都与Hbase不同，改造会非常大，所以Cloudera决定干脆开发一个全新的存储系统。
- 作为Hadoop生态圈的一部分，对接生态系统的其他组件方便，会有官方提供的接口。
- kudu自己存储数据不依赖与HDFS存储；不依赖于zookeeper，将它的功能集成进了自身的TMaster。
- 和HBase类似的LSM结构，用于支持数据的随机读写。
- 有表结构，需定义Schema信息。必须定义唯一键，这就造成了写数据时多了一个判断唯一的过程。需在写入数据前定义好每一列的类型（方便做类似于parquet的列式存储）。可以像关系型数据库一样用Alter增删列，不具有HBase动态列的特性。
- 支持行级别的ACID。
- 目前不支持二级索引。
- 目前不支持BloomFilter优化join。
- 核心模块用的C++来实现，没有full gc的风险。
二、kudu解决了什么问题？
HDFS和HBase是大数据最常用的两种存储方式，它们的优缺点非常明显：
- HDFS，使用列式存储格式Apache Parquet，Apache ORC，适合离线分析，不支持单条记录级别的update操作，随机读写性能差。
- HBase，可以进行高效随机读写，却并不适用于基于SQL的数据分析方向，大批量数据获取时的性能较差。
那为什么HBase不适合做分析呢？
因为分析需要批量获取数据，而HBase本身的设计并不适合批量获取数据
- HBase是列式数据库，其实从底层存储的角度来说它并不是列式的，获取指定列数据时是会读到其他列数据的。
- HBase是LSM-Tree架构的数据库，这导致了HBase读取数据路径比较长，从内存到磁盘，可能还需要读多个HFile文件做版本合并。
- LSM 的中心思想就是将随机写转换为顺序写来大幅提高写入操作的性能，但是牺牲了部分读的性能。
为了让数据平台同时具备随机读写和批量分析能力，传统的做法是采用混合架构(hybrid architecture)，也就是我们常说的T+1的方式，数据实时更新在HBase，第二天凌晨同步到HDFS做离线分析。这样的缺点很明显，时效性差，数据链路长，过程复杂，开发成本高。
这个时候Kudu出现了
它是介于HDFS和HBase两者之间的一个东西如下图所示
它不及HDFS批处理快，也不及HBase随机读写能力强，但是反过来它比HBase批处理快（适用于OLAP的分析场景），而且比HDFS随机读写能力强（适用于实时写入或者更新的场景），这就是它能解决的问题。
