有了HBase为什么还要Kudu？

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随机读写能力强（适用于实时写入或者更新的场景），这就是它能解决的问题。

————————————————

最近真的忙，停更了接近一个月，抱歉，好多同学催更，感谢有那么多同学的支持，这一篇先简单地介绍了下kudu，接下来还会有一系列的文章，2019年将继续输出，感谢关注。

觉得有价值请关注 ▼