1.车联网数据的收集

因为车辆的监控数据非常大，传统关系型数据库（如Mysql、pg等）已经无法胜任存储工作，所以需要选用一种分布式数据库用于存储车辆实时数据。在市场上能够找到分布式数据库有 HBase就是一个很好得选择。

因为HBase底层存储基于HDFS的面向列数据库，其核心思想来源于谷歌三大论文内的bigtable。在谷歌和开源界均拥有丰富的应用实践经验。
除此之外，HBase还有以下特点：

（1）、支持PB级别的数据量；（2）、压缩效率非常高；（3）、支持亿级别的QPS；（4）、在国内外很多大型互联网公司使用；（5）、HBase添加节点及扩容比较方便，无需DBA任何干预。

车联网系统是利用车载设备收集车辆运行时产生的各项数据，通过网络实时上传，在平台进行动态分析和利用。

我们可以发现，车联网系统所面对的数据特点是大量车辆终端高并发的不间断写入TB级甚至PB级的数据，而且对于实时分析来说，为了保证分析结果的时效性，又要求查询的低时延响应。

HBase采用LSM存储模型，可以从容应对高并发写入的场景，同时也能保证读时延在可接受的范围内。同时HBase具有良好的水平扩展能力。通过增减RegionServer来实现对存储容量动态调整，满足对使用成本的要求。

2.用户画像,标签数据的存储

标签数据是稀疏矩阵的代表，描述了实体的各类属性，主要应用于智能推荐、商务智能或营销引擎等领域。

三个不同的用户在同一公司旗下的不同APP中留下了大量的行为数据，这些数据中包含了直接填写的用户资料、使用APP的具体行为以及领域专家对某些现象的标记，通过后台的标签算法可以得到这样的数据：

这样的特点对于MySQL是灾难性的，这是因为在MySQL建表时就必须定义表结构，属性的动态增删是巨大的工作量，同时大量NULL值的存储会导致存储成本变得难以接受。但是使用HBase存储时，未指定value的列不会占用任何的存储空间，因而可以将有限的资源高效利用，且HBase表在创建时只需指定ColumnFamily，而对于Column的增删极为容易，有利于应对未来属性的扩张。

3.消息/订单等交易系统的保存:

HBase基于底层的HDFS作为存储系统，HDFS实现了三副本策略，按照一定的规则将副本放在不同的节点或机架中，本身具有较高的容灾能力。

在电信领域、银行领域，不少的订单查询底层的存储，另外不少通信、消息同步的应用构建在HBase之上。

例如:来自淘宝/天猫的使用场景：
1 瞬间写入量很大，数据库不好支撑或需要很高成本支撑的场景。
2 数据需要长久保存，且量会持久增长到比较大的场景
3 HBase不适用与有join，多级索引，表关系复杂的数据模型
4 合理设计rowkey，非常重要
5 数据最好是可恢复的
6 生产环境关闭split，region数不要太多。

4.对象存储

比如一些app的海量的图片、网页、新闻等对象，可以存储在HBase中，有些病毒公司的病毒库也可以存储在HBase中。

5.Feed流-微信/微博盆友圈,头条,百度信息流等

Feed流，是RSS中用来接收该信息来源更新的接口，简单的说就是持续更新并呈现给用户的内容。比如微信朋友圈中看到的好友的一条条状态，微博看到的你关注的人更新的内容，App收到的一篇篇新文章的推送，都算是feed流。简单说来，就是一种信息单元格，你也可以理解为某一个卡片啊，一段文字啊，一段视频啊，一段音频啊，等等的信息单元，可能包含，这是谁的，有多少人看，什么类型消息等等，一个feed 就是一个信息单元，一个用户想看的有用信息单元，一个满足用户需求的信息单元，完全根据个人喜好来进行信息获取，所以你会觉得抖音有毒，短视频有毒。他们目前的主流算法就是通过feed方式进行喜好推荐，进而长时间吸引的眼球，提高平台的用户时长。