如何同时兼顾多维分析和快速查询的需求？Kudu来帮忙！彭文华国有企业法

这是彭文华的第134篇原创

一般公司的大数据基本都是这个样子：底层是HDFS存储各种文件，上面架设Hive建设数仓，解决多维分析的需要。对于一些明细数据快速查询的需求，Hive其实非常不友好，慢的很。所以一般来说又会把Hive里处理好的明细数据倒一份到Hbase里，解决明细数据查询的需求。

这下问题就来了，一套数据存两个地方，且不说浪费存储空间的事情，就单说让两套数据同步，就是个麻烦事。万一没同步了，还会出现两边数据不一样，运营拿着冲突的数据上来诘问的时候我们该咋弄？

我们知道Hive是基于HDFS的一种数据仓库工具，做了很多易用性的优化，把复杂的MapReduce简化成了对数据工程师非常友好的SQL。但是玩过HDFS的同学都知道，这是一个文件系统啊。文件系统就意味着要查一条记录得把某个文件打开，然后顺序往下读，这速度可想而知。Hive是直接映射HDFS的文件做成表，那就得按照HDFS的套路来。所以不是Hive不想支持实时查询的功能，实在是臣妾做不到啊！

而且，仍然是由于基于HDFS，Hive想对某条数据进行修改，也就成为不太可能了。所以Hive天然是一个面向历史、擅长批数据处理的数据仓库工具。所以Hive的应用场景其实非常有限。

Hbase虽然也是基于HDFS的，但是Hbase实质是是一个KV数据库。它在底层设计的时候就做了大量的查询优化设计。比如Trailer、布隆过滤器、三级索引的设置。

这个Trailer的设计很有意思，他是用来找数据用的。里面存储了总偏移量、每个kv的大小、第一个数据块的偏移量和最后一个偏移量。这就可以用来快速寻址，找到数据所在的存储地址。配合索引和布隆过滤器，就能超快速锁定Data Block中的kv值。

所以我们回头看一下，Hive的存储方式，其实就是数据结构中四大存储方式中的顺序存储，而Hbase就是另外一种：散列存储，类似于链式存储。这俩天然一个擅长大批量操作，一个擅长快速查询。这玩意的毛病是从骨子里带出来的，这咋解？

其实还是有解的。经验丰富的你应该知道这个方法。既然Hbase和Hive都是基于HDFS的，只不过Hbase的存储结构比较巧妙，那能不能把数据放在Hbase的表里，然后Hive引用Hbase的表作为外表呢？这样既不影响Hbase的快速查询，又能让Hive基于同一个表进行批量数据的操作？这当然可以！

这个解决方案很好的解决了两个问题：

1、数据冗余问题，原来要存两份，现在一份就行了；

2、高时延问题，原来数据到Hbase和到Hive得需要分别跑，现在不需要了；

同时，也顺带解决了两份数据带来的运维复杂、数据不一致等一系列问题，这也就成为了大数据平台的通用架构之一。

但是这毕竟是两个组件融合起来，仍然存在各种乱七八糟的问题。比如上来就会遇到版本兼容的问题，烦死个人。

但是这还好解决，不行就换个版本吧。但是你看看上面那个图，Hive的数据源变成Hbase了，相当于Hbase不仅要承担本身查询的任务，还要面对Hive过来的N多批处理的请求，增加了非常多的压力。每个Hive的MapReduce任务都会启动N个Handler去连接Hbase，Hbase还不被烦死了。而且这势必又会降低Hbase原有的高速查询的效率。

另外，Hbase毕竟是列式存储，在表设计的时候，就跟Hive不一样，所以表映射的时候会有非常多的限制。数据仓库工程师会非常不习惯这种转来转去的感觉，让人非常难受。

所以，有没有更好的解决方案呢？

Cloudera公司发现了这个巨大的问题，发现这是一个打造一个好产品的巨大潜在机会啊！于是在其他人都在研究怎么用Hbase和Hive融合的时候，他们就在悄**的搞研发。他们的定位就是“Fast Analytics on Fast Data。一帮牛人搞了多久呢？3年，就出来了这么个玩意。

”

一个兼具Hbase和Hive长处的Kudu！

不过，想要兼具二者的长处，规避二者的短处，可不是那么简单的事情！因为二者的缺陷是与生俱来的。也就是说，想要规避一个不能快速查询，一个不能批量操作，那就不能基于HDFS和Hbase的任何一种数据存储形式，得另起一个。所以Kudu就自己整了一套：

玩数仓或者数据库的同学看到这个就会亲切不少。因为里面很多单词是非常熟悉的，比如table、Undo、Redo等。这些都是从关系型数据库中沿用过来的。因为有这些设计，所以Kudu是能够支持数据的删改操作的。

这里有个小细节，Table下面是Tablet，这其实是Kudu为了适应分布式而专门设计的，一个表会拆成N个tablet，散放在各个节点中。

既然底子类似于关系型数据库，那么与Hive类似的数据批处理肯定就没问题了。

但是查询咋办？

注意看上图最左侧第一行，叫“BloomFile”，第二行是“AdhocIndex”。第一个其实就是布隆过滤器的应用，第二个就是查询索引了。同时，在每个tablet的metaData里也会布隆过滤器和索引。这样就能快速判断某个数据是否在这个tablet、DiskRowSet中了。查询也是嗷嗷快的。

Kudu貌似看上去很好，但是千万不要迷信哈。也有几个不太好的地方：

1、查询不如Hbase，官方自己都说，如果要追求快速查询还得用Hbase；

2、应对数据更新，Kudu需要额外投入资源，所以装Kudu的机器时不时会抽风；

3、必须要有且走主键，非主键超级吃CPU；

4、设计的时候需要同时考虑更多。

因为没有自增主键，所以建议用类似UUID的解决方案，用雪花算法搞定主键。

设计的时候需要考虑分区策略，存储的时候规避热点存储问题，计算的时候也同样可以规避数据倾斜问题。之前分享过怎么解决数据倾斜，方法其实是一样的：

• 随机分区：每个区域的数据基本均衡，简单易用，偶尔出现倾斜，但是特征同样也会随机打散。

• 轮询分区：绝对不会倾斜，但是需要提前预知分成若干份，进行轮询。

• hash散列：可以针对某个特征进行hash散列，保证相同特征的数据在一个区，但是极容易出现数据倾斜。

• 范围分区：需要排序，临近的数据会被分在同一个区，可以控制分区数据均匀。

不过Kudu只支持范围、Hash、多级三种分区方式。Kudu很有意思，他支持组合分区。比如这样：

Hash分区的优势在于超高写入吞吐量，预先设置的范围分区可避免 tablet 无限增长的问题；两者结合，那是强强联手，非常有意思。

Kudu毕竟还是一个存储系统，虽然提供了接口供我们使用，但是得用Java写啊！数仓同学是不是要哭了？

别着急！早就有解决方案了。那就是Kudu+Impala，双剑合并。kudu负责数据存储，Impala负责计算和SQL友好，你看，多棒啊~~~

最后用一个简单的架构演进图收尾吧：

扩展阅读：kudu的相关信息可以在Apache官网可以找到，我手上有一份网易大佬分享的实战经验，各位可以参考一下。“大数据架构师”公众号后台回复“kudu”即可下载。

配合以下文章享受更佳

干货 |12种方法，彻底搞定数据倾斜！

干货|布隆过滤器-抖音不重复推荐的秘密

干货 |传统数据仓库转型最佳利器：Kylin！

剖析 |MapReduce全流程【附调优指南】

干货 |ZooKeeper的ZAB、Watch详解

我需要你的转发，爱你哟