https://cloud.tencent.com/developer/news/391226
https://zhuanlan.zhihu.com/p/36949867
本文主要简单介绍了一下Kudu，并在整体结构、数据存储结构和读写过程等方面上对HBase和Kudu这两款分布式存储系统进行大 体上的比较。Kudu通过要求完整的表结构设置，主键的设定，以列式存储作为数据在磁盘上的组织方式，更新和数据分开等技巧， 使得Kudu能够实现像HBase一样实现数据的随机读写之外，在HBase不太擅长的批量数据扫描（scan）具有较好的性能。而批量 读数据正是olap型应用所关注的重点，正如Kudu官网主页上描述的，Kudu实现的是既可以实现数据的快速插入与实时更新，也可以实现数据的快速分析。Kudu的定位不是取代HBase，而是以降低写的性能为代价，提高了批量读的性能，使其能够实现快速在线分析。
Kudu这东西估计很多同学都听过但是没用过，那么我们先从最基本的问题开始：kudu是什么？能做什么？
kudu是什么？
kudu和Hbase类似也是一个分布式数据库，据官方给它的定位是提供”fast analytics on fast data”（在更新更及时的数据上做更快的分析）。
据说Cloudera曾经想直接通过修改HBase来支持kudu现在的功能，但是Kudu的数据模型和磁盘存储都与Hbase不同，改造会非常大，所以Cloudera决定干脆开发一个全新的存储系统。
0.作为Hadoop生态圈的一部分，对接生态系统的其他组件方便，会有官方提供的接口
1.kudu自己存储数据不依赖与HDFS存储；不依赖于zookeeper，将它的功能集成进了自身的TMaster；
2.和HBase类似的LSM结构，用于支持数据的随机读写。
3.有表结构，需定义Schema信息
- 必须定义唯一键，这就造成了写数据时多了一个判断唯一的过程。
需在写入数据前定义好每一列的类型（方便做类似于parquet的列式存储）
可以像关系型数据库一样用Alter增删列，不具有HBase动态列的特性
4.支持行级别的ACID
5.目前不支持二级索引
6.目前不支持BloomFilter优化join
7.核心模块用的C++来实现，没有full gc的风险
kudu解决了什么问题？
HDFS和HBase是大数据最常用的两种存储方式，它们的优缺点非常明显：
HDFS，使用列式存储格式Apache Parquet，Apache ORC，适合离线分析，不支持单条记录级别的update操作，随机读写性能差。这个就不多说了，用过HDFS的同学应该都知道这个特点。
HBase，可以进行高效随机读写，却并不适用于基于SQL的数据分析方向，大批量数据获取时的性能较差。
那为什么HBase不适合做分析呢？
因为分析需要批量获取数据，而HBase本身的设计并不适合批量获取数据
1）都说HBase是列式数据库，其实从底层存储的角度来说它并不是列式的，获取指定列数据时是会读到其他列数据的。看过我之前文章的同学应该比较清楚就不多说了。相对而言Parquet格式针对分析场景就做了很多优化。
2）HBase是LSM-Tree架构的数据库，这导致了HBase读取数据路径比较长，从内存到磁盘，可能还需要读多个HFile文件做版本合并。
LSM 的中心思想就是将随机写转换为顺序写来大幅提高写入操作的性能，但是牺牲了部分读的性能。
随机读写是指对任意一个位置的读和写，磁盘随机读写慢是因为需要寻道，倒带才可以访问到指定存储点，而内存不需要，可以任意指定存储点
为了让数据平台同时具备随机读写和批量分析能力，传统的做法是采用混合架构(hybrid architecture)，也就是我们常说的T+1的方式，数据实时更新在HBase，第二天凌晨同步到HDFS做离线分析。这样的缺点很明显，时效性差，数据链路长，过程复杂，开发成本高。
这个时候Kudu出现了，它是介于HDFS和HBase两者之间的一个东西如下图所示，
它不及HDFS批处理快，也不及HBase随机读写能力强，但是反过来它比HBase批处理快（适用于OLAP的分析场景），而且比HDFS随机读写能力强（适用于实时写入或者更新的场景），这就是它能解决的问题。