| Hive | Hbase |
| 数据处理和计算问题 | 实时数据查询问题 |
| 不是数据库 | NoSQL数据库 |
| 清洗数据 | 海量数据查询接口 |
| OLAP | OLTP（严格讲只是OLP,不包含T） |
| 逻辑表，不存储实际数据 | 物理表 |
| 行模式 | 列模式 |
| 不提供row-level的更新 | 支持row-level的更新 |
| 完整的SQL实现 | 不适用于有join，多级索引，表关系复杂 |
| HDFS文件的视图，HDFS文件的SQL接口 | 建了索引的key-value表 |
| 批处理 | 事务处理(例如和web开发结合) |
| 单次Hive查询都需要耗费分钟级以上的时间（哪怕一个再小的表），因此无法作为web后端的数据库使用。 | HBase可以替代MySQL使用，至少淘宝就是这么做了。
HBase是建造在HDFS基础上的分布式数据库，可以支持海量数据（比MySQL高一到两个量级）的存储和查询。 |
| DataGrip | Phoenix |
| hive可以挂接hbase，即针对hbase开放出SQL的接口 | 不用Hive，也能操作HBase |
| Hive是建立在Hadoop之上为了减少MapReduce jobs编写工作的批处理系统 | HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。 |
| 蜜蜂 | 蜂蜜 |
| Hive支持标准SQL查询 | HBase不支持SQL，有自己的语法规则 |
| 一种客户端工具 | 一种db |
从上面的表格可以看出,hbase可以替换hive吗？不行，因为hbase支持不了复杂的sql
比起单机的Oracle和MySQL，好处就是伸缩性好啊
劣势就是分布式带来的可用性，一致性，分区容忍性~等问题，以及分布式事务难以实现。
Hbase，主要用于明细查询，即席查询，因为他快啊，但是不适合多条件查询
hive更像是hadoop客户端，可以将SQL任务转化为mapreduce任务操作hdfs中的数据。
hbase则是支持大数据存储和查询的数据仓库，在CAP理论中，选择了CA，保留了一致性，舍弃了可用性，简单直白理解就是不容易丢数据。是noSQL典型代表。
使用关系 源数据生产者 -Flume/Kafka-> Flume/消费者 -write-> HDFS -Hive.load-> Hive -ETL/Analyze.result-> HBase 源数据生产者 -Kafka-> SparkStreaming/消费者 -write-> HDFS [-SparkSQL-> Hive] && [-SparkSQL-> HBase]
类比于单机系统。hdfs就是linux的文件系统，hbase就是资源管理器，hive就是图形化界面，GUI再快，不可能快过命令行
个人理解:
hive的优势是在于对于集群文件HDFS的查询功能。
HBase早期在国内被很多大型互联网公司大规模使用，促进了国内的生态发展，而Cassandra似乎在国外发展得更好
Hbase，主要用于明细查询，即席查询，因为他快啊，但是不适合多条件查询
hbase适合写密集型应用，每天写入量巨大，而相对读数量较小的应用，比如IM的历史消息，游戏的日志等等
HBase是根据谷歌的BigTable设计的。典型的应用场景就是不断插入新的信息（谷歌的情况下就是互联网上新生成的网页），而不怎么修改。比如现在Facebook的messenger就是用HBase实现的。
这里要提到HBase是按行存储的，所以特点就是插入（ingest）快。但是做分析的时候经常是要按列扫描（scan）的。比如算一个公司员工的平均工资。
Cloudera在推出新的列存储引擎Kudu的时候讨论过HDFS，HBase，和Kudu的应用场景。
根据[2]其实Cassandra的写入性能比Hbase更胜一筹，并且读取性能也优于hbase
下面是商用的公司：
| 数据库 | 公司 |
| Hbase | 美团，淘宝 |
| Cassandra | 苹果 |
注意，无论是国内的前程无忧还是国外的indeed,目前hbase的岗位需求都高于cassandra十倍以上。
