Flume、Kafka、Hbase、Hive适用场景

@Author  : Spinach | GHB
@Link    : http://blog.csdn.net/bocai8058

---

Flume、Kafka适用场景

Kafka、Flume都可以实现数据的传输，但它们的侧重点不同。

Kafka追求的是高吞吐量、高负载（topic下可以有多个partition）

Flume追求的是数据的多样性：数据来源的多样性、数据流向的多样性

如果数据来源很单一、想要高吞吐的话可以使用Kafka

如果数据来源很多、数据流向很多的话可以使用Flume

也可以将Kafka和Flume结合起来使用。

【请看链接详细内容】
引用：https://blog.csdn.net/helloxiaozhe/article/details/79481319

Hbase适用场景

Hbase适合需对数据进行随机读操作或者随机写操作、大数据上高并发操作，比如每秒对PB级数据进行上千次操作以及读写访问均是非常简单的操作。

• 半结构化或非结构化数据

对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用HBase。以上面的例子为例，当业务发展需要存储author的email，phone，address信息时RDBMS需要停机维护，而HBase支持动态增加.

• 记录非常稀疏

RDBMS的行有多少列是固定的，为null的列浪费了存储空间。而如上文提到的，HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。

• 多版本数据

根据Row key和Column key定位到的Value可以有任意数量的版本值，因此对于需要存储变动历史记录的数据，用HBase就非常方便。

• 超大数据量

当数据量越来越大，RDBMS数据库撑不住了，就出现了读写分离策略，通过一个Master专门负责写操作，多个Slave负责读操作，服务器成本倍增。随着压力增加，Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了，需要借助中间层。随着数据量的进一步增加，一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按ID取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。采用HBase就简单了，只需要加机器即可，HBase会自动水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）。

Hive适用场景

起源于FaceBook,Hive在Hadoop中扮演数据仓库的角色。建立在Hadoop集群的最顶层，对存储在Hadoop群上的数据提供类SQL的接口进行操作。你可以用 HiveQL进行select,join,等等操作。

如果你有数据仓库的需求并且你擅长写SQL并且不想写MapReduce jobs就可以用Hive代替。

注意：Hive现在适合在离线下进行数据的操作，就是说不适合在挂在真实的生产环境中进行实时的在线查询或操作，因为一个字“慢”。

---