列族数据组织方式的缺点：
1）在需要读取整条记录的时候，需要访问多个列族组合数据，效率会降低，可以通过字段冗余来解决一些问题。
2）只能提供Key值和全表扫描两种访问方式，很多情况下需要自己建耳机索引。
3）数据是非结构化，或者说是半结构化的，应用在处理数据时要费点心，不像关系数据库那么省心。

在数据完全结构化，很少变动，需要事务的场景使用Mysql等关系数据库比较合适。

1，什么是HBASE？
Google三驾马车之BigTable的开源实现，配合HDFS，实现了数据的分布式海量存储。
2，为什么会出现HBASE？
传统关系型数据库，关系模型绑架对象模型、僵硬的约束设计及设计范式使得存储数据包含了一部分业务逻辑，而且糟糕的海量数据处理能力引出了各种NoSql设计，HBASE简单粗暴，数据库就是存储数据，业务由应用去处理。
3，HBASE设计特点？
a，可伸缩
HBASE以key的区域进行分片形成HRegion（HBASE数据管理的基本单位），一个HRegion中数据量超过阈值，会一分为二，并在集群中进行负载均衡。
数据读写：application Zookeeper HMaster HRegionServer HRegion HFile
b，可扩展数据模型
列族设计，具体字段（column）在写入时指定，轻松支持百万字段的扩展
c，高性能存储
数据写入时通过log连续写入，异步与磁盘上的多个LSM树进行合并。
数据写操作（i，u，d）都在内存中进行（也是一颗排序树），超过内存阈值，与磁盘上最新的LSM树合并

批处理是对历史大量数据的离线计算处理，而流计算则是对实时流入的数据进行实时响应。

Storm模仿消息队列的处理方式，并进行了也许和技术的抽象，使得业务和技术分离，这是一种典型的架构设计方式。而且，storm 也采用了主从架构默契，很好的贯彻了分布式的典型思路。

Spark Stream 主要是使用了Spark Stream 的数据分段作用，如果在分片的时间足够短，那么数据就不会太大，然后将分段分片后的少量数据，提交给Spark 处理，就会在毫秒级得到结果。

Flink的主要思想则跟Spark 反过来，也就是说，在Flink的世界里，流是一等公民，而批处理只能退而其次。