其他分享
首页 > 其他分享> > 如何同时兼顾多维分析和快速查询的需求?Kudu来帮忙!彭文华

如何同时兼顾多维分析和快速查询的需求?Kudu来帮忙!彭文华

作者:互联网

我们知道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就是另外一种:散列存储,类似于链式存储。这俩天然一个擅长大批量操作,一个擅长快速查询。这玩意的毛病是从骨子里带出来的,这咋解?




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?


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

1、查询不如HBase,官方自己都说,如果要追求快速查询还得用HBase;

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

3、必须要有且走主键,非主键超级吃CPU;

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


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

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


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

图片

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


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

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

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

图片


标签:存储,兼顾,多维分析,Hive,查询,Kudu,HBase,数据
来源: https://blog.51cto.com/15127541/2664797