这是彭文华的第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友好，你看，多棒啊~~~
最后用一个简单的架构演进图收尾吧：
