这是彭文华的第134篇原创
一般公司的大数据基本都是这个样子:底层是HDFS存储各种文件,上面架设Hive建设数仓,解决多维分析的需要。对于一些明细数据快速查询的需求,Hive其实非常不友好,慢的很。所以一般来说又会把Hive里处理好的明细数据倒一份到HBase里,解决明细数据查询的需求。
这下问题就来了,一套数据存两个地方,且不说浪费存储空间的事情,就单说让两套数据同步,就是个麻烦事。万一没同步了,还会出现两边数据不一样,运营拿着冲突的数据上来诘问的时候我们该咋弄?
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就是另外一种:散列存储,类似于链式存储。这俩天然一个擅长大批量操作,一个擅长快速查询。这玩意的毛病是从骨子里带出来的,这咋解?
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的解决方案,用雪花算法搞定主键。
设计的时候需要考虑分区策略,存储的时候规避热点存储问题,计算的时候也同样可以规避数据倾斜问题。之前分享过怎么解决数据倾斜,方法其实是一样的:
随机分区:每个区域的数据基本均衡,简单易用,偶尔出现倾斜,但是特征同样也会随机打散。
轮询分区:绝对不会倾斜,但是需要提前预知分成若干份,进行轮询。
hash散列:可以针对某个特征进行hash散列,保证相同特征的数据在一个区,但是极容易出现数据倾斜。
范围分区:需要排序,临近的数据会被分在同一个区,可以控制分区数据均匀。
不过Kudu只支持范围、Hash、多级三种分区方式。Kudu很有意思,他支持组合分区。比如这样:
Hash分区的优势在于超高写入吞吐量,预先设置的范围分区可避免 tablet 无限增长的问题;两者结合,那是强强联手,非常有意思。
Kudu毕竟还是一个存储系统,虽然提供了接口供我们使用,但是得用Java写啊!数仓同学是不是要哭了?
别着急!早就有解决方案了。那就是Kudu+Impala,双剑合并。kudu负责数据存储,Impala负责计算和SQL友好,你看,多棒啊~~~
最后用一个简单的架构演进图收尾吧:
扩展阅读:kudu的相关信息可以在Apache官网可以找到,我手上有一份网易大佬分享的实战经验,各位可以参考一下。“大数据架构师”公众号后台回复“kudu”即可下载。
配合以下文章享受更佳
剖析 | MapReduce全流程【附调优指南】
我需要你的转发,爱你哟