## 问题
> 对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用使用什么数据库？答案是什么，如果我们使用的传统数据库，肯定留有多余的字段，10个不行，20个，但是这个严重影响了质量。并且如果面对大数据库，pt级别的数据，这种浪费更是严重的，那么我们该使用是什么数据库？hbase数个不错的选择.
> https://blog.csdn.net/a519781181/article/details/79423512
> Row key 行主键， HBase不支持条件查询和Order by等查询，读取记录只能按Row key（及其range）或全表扫描，因此Row key需要根据业务来设计以利用其存储排序特性（Table按Row key字典序排序如1,10,100,11,2）提高性能。
## HBase的优点：
- 列可以动态增加，并且列为空就不存储数据，节省存储空间。
- Hbase自动切分数据，使得数据存储自动具有水平scalability。
- Hbase可以提供高并发读写操作的支持。
## HBase的缺点：
- 不能支持条件查询，只支持按照Row key来查询。（就只有一张表，没有聚合、分组操作？）
- HBase并不适合传统的事物处理程序或关联分析，不支持复杂查询，一定程度上限制了它的使用，但是用它做数据存储的优势也同样非常明显。
> 作者：唐小新
链接：https://www.zhihu.com/question/19716897/answer/15601976
目前来说，我认为hbase版本还不稳定，使用起来还是会出现很多潜在的bug，你看看淘宝的使用经验就知道了，所以使用hbase的限制：
- 要有比较强大的IT团队，且有一定的nosq 库表的设计经验，否则你无法发挥hbase的性能优势
- hbase的 有效性还存在一定的问题(nosql CAP理论中的A），因为只要集群中的一个节点宕机了，这个节点上的数据暂时就不能访问了，需要等待一定的时间，进行同步处理，查询数据时，你会发现有部分缺失。当然，也有处理方法，淘宝就是找人专门盯着这些集群，以最快的速度恢复这些宕机的机器
- 监控做的不好，目前hbase版本的监控粒度太粗，基本上不能给出什么有价值的信息，监控不行的话，你运维得被搞死。淘宝用hbase，它是专门做了一个针对hbase的监控的，但目前没开源.
- 查询简单，只能根据key,扫描一条记录，或全表扫描，或根据key范围性扫描，不支持复杂的sql处理，也不会具有关系型数据库的ACID特性. - - hbase基本上是采用hdfs作为存储，你使用hdfs,就得考虑它的 单几点问题，也就是HA问题，当然，目前版本好像提供了HA机制，但好不好用，还待验证 ....
> 总之，hbase目前还是存在很多问题的，想要用好它，你得自己考虑这些问题，且做增强，它还不算一个非常成熟的数据库，我猜想，后期版本会有大改.
> 系统依赖复杂，部署维护难度大。要深度玩转HBase，给业务提供高效的存储服务，除了HBase自身，必须得精通JVM、HDFS、ZOOKEEPER。
表结构、Rowkey的设计和应用开发门槛较高，不同实践经验带来的业务效果差别会比较大。
服务单点可用、GC、IO抖动规避等因素，使得实时性、可用性还有待进一步提高。产品化体验及配套仍不够完善，监控报警、Trouble Shooting、上下游数据链路、容灾备份、数据管理等方面，相对于关系数据库而言还是不够丰富.
> 因为HBase存储的是松散的数据，所以如果你的应用程序中，数据表每一行的结构是有差别的，那么可以考虑使用HBase。因为HBase的列可以动态增加，并且列为空就不存储数据，所以如果你需要经常追加字段，且大部分字段是NULL值的，那可以考虑HBase。因为HBase可以根据Rowkey提供高效的查询，所以如果你的数据（包括元数据、消息、二进制数据等）都有着同一个主键，或者你需要通过键来访问和修改数据，使用HBase是一个很好地选择。
#### CSV文件数据源：
- 表结构常变
- 对于百亿条数据量
> MongoDB有点吃力,除非搞集群，做了集群也仅仅是存储了数据，对分析没有作用；HBase容易扩展。
- 对于分析应用
> Hbase也可以介入MapReduce。
#### Mysql数据源
考虑采用MongoDB存储，然后转移至Hive数据仓库做应用分析。
MongoDB往Hive导数据 https://blog.csdn.net/dr_guo/article/details/51698757
- PS：博文中的链接为原有博主的作品，本文仅作转接分享，请知悉。