Hbase hive kudu的区别和使用场景

Hive

一句话描述Hive：基于Hadoop的一个一个数据仓库工具；可以将结构化的数据文件映射为一张数据表，并提供完整的sql查询功能，可以将sql语句转化为mapreduce任务运行；也正是由于这种机制，导致Hive最大的缺点就是慢，Map/Reduce本身只适合批量、长周期任务，类似查询这种短、平、快的业务，代价太高。

Hbase

HBase 的核心是将数据抽象成表，表中只有rowkey 和columnfamily。rowkey 是记录的主键，
过Key/Value 很容易找到；columfamily 中存储实际的数据。仅能通过主键（rowkey）和主键的rar
来检索数据，仅支持单行事务（可通过 Hive 支持来实现多表 Join 等复杂操作)。主要用来存储非
构化和半结构化的松散数据
正是由于 HBase 的这种结构，应对查询中带了主键（useid）的应用非常有效，查询结果返回
度非常快。而对于没有带主键且通过多个维度水查询时，就非常困难。为了解决这个问题，在 HBas
上实现了一些技术方案，效果也基木差强人意。
二级素引，核心思路仿照数据库建素引方式对需要查询的列建素引，带来的问题是影响加载速
度、数据膨账率大。二级索引不能建太多，最多1~2个。
HBase 自身的协处理器，遇到不带rowkey 的查询，由协处理器通过线程并行扫描。
HBase 不支持 SQL 语法，使用非常不便，所以诞生丁 Phoenix。 Phoenix 是通过一个嵌人的 JDBC
驱动存储在HBase 中的数据的查询。Phoenix 可以让龙发者在 HBase数据集上使用 SQL 查询。Phoenix
查询引擎会将 SQL 查询转换为一个或多个HBase 的扫描操作，并合并执行以生成标准的 JDBC 结果
集。对于简单查询来说，Phoenix 的性能甚至胜过 Hive。

Kudu

由于 HBase、Parquet 不能兼顾分析和更新的需求，所以需要一个新的存储引擎可以同
吞吐的分析应用及少量更新的应用，Kudu 存储引擎应运而生。Cloudera 的设计目标如下"：
•在扫描和随机访问两种场景下都有很强的性能，帮助客户简化混合架构。
•高 CPU 利用率
•高V0效率，充分利用现代存储。
•支持数据原地更新。
•支持双活集群。
Kudu 的核心机制如下：
(1）模仿数据库，以二维表的形式组织数据，创建表的时候需要指定 Schema，所以只
化数据
(2）每张表指定一个或多个主键
(3）支持 insert、update、delete 操作，这些修改操作都要指定主键

(4）read 操作，只支特 scan 原语

(5)-—致性模型，默认支特 snapshot
(6） Cluster 类似 HBase 简单的主备结构
(7）单张表支持水平分割

(8）使用 Raf 协议，可以根据 SLA 指定备份块数量
(9）列式存储
(10）数据先更新到内存中，最后再合并到最终存储中，有专门的后台进程负责
(11）延迟物化，好处是代码实际执行时，对于一些选择性条件的查询，可以直接跳过不必要的
数据
（12）支持和 MR、 Spark、Impala 等集成，支持 Locality、 Columnar Projection、Predicate
Pushdown 等

选取

Kudu项目的初衷是在hive的批量处理和hbase的随机读写之间找一个平衡点。
kudu的批量处理性能优于hbase，随机读写优于hive。
hive的一般用于构建数据仓库，kudu一般用于做近实时的查询分析。
hive一般要配合impala或者presto或者kylin等做交互式查询
kudu一般配合impala做交互式查询，也可以配合其他的做数据查询。
hbase一般可以配合apache Phoenix提供查询功能。
使用hive、kudu、hbase还要看需求：

如果是建立数据仓库，做T+1天的BI系统，还是要选择Hive。
如果希望数据是分钟级别的延时，希望尽量快的看到结果，而且是结构数据，选kudu是没错的。
如果需求是大量快速的写，经常单条的读，那必须是hbase，kudu和hive都不行。

它们三个各有所长，没有谁能取代谁，一般在企业中也都是互相配合使用来应对多种需求场景

文献参考

1.kudu会取代hive吗？ - 知乎

2.书籍：大数据架构详解：从数据获取到深度学习