海量数据存储解决方案

技术选型

数据存储

    考虑到数据量较大，采用传统的关系型数据库已经不太合适，需要做大量的分库分表操作。因此考虑nosql的方式，常见的nosql数据库包括hbase，mongodb，cassandra，redis，solr，elasticsearch等。

    redis虽然可以做存储，但常用于缓存，其存储和持久化能力稍弱。

    solr和elasticsearch虽然可以存储数据，但他们常用于搜索，大量的数据存储及索引建立会影响他们的效率，通样影响查询速度，对硬件资源的要求也更高。

    mongodb对于亿级别的数据存储还是可以的，十亿百亿之后存储和查询能力会出现性能瓶颈。对于位置索引mongodb支持是很好的。

    hbase是hadoop生态圈的一员，具有较高的吞吐量和较好的平行扩展能力，能应对百亿以上的数据存储，缺点是查询不够灵活，不按其rowkey查询的方式性能极差，而rowkey查询也只能按照其组成顺序查询，无法满足各种维度的查询需求。

    cassandra类似hbase，性能也比较接近，但基于我们对hbase的使用积累，以及hbase对mapreduce的良好支持，我们选用hbase作为数据存储介质。

数据查询

    由于我们采用hbase作为原始数据存储介质，导致查询很不灵活，因此需要做额外的索引。建立索引的方式有几种：

1．将原数据按不同的索引维度，存多次hbase。这样会造成原始数据存储多次。

2．使用hbase自带的协处理器，对需要建索引的字段构造索引后再存入hbase，查询的时候先查索引表，再查元数据表。这样实际上也会存储多次hbase，且复杂度较高。

3． 利用elasticsearch和solr等搜索工具做二级索引。

    假设以elasticsearch作为我们的搜索引擎，加上其聚合特性还可以满足一定时间范围的聚合（数据量不太大的情况下），实现灵活的即时统计。

整体框架

    假设我们的数据来自于用户app或者其他物联网设备，这里统称为设备（device）。设备通过网络上报的网关，然后通过消息队列分发后进行数据处理，流程如下图所示：

    为了实现平台化，设备数据进过我们的网关上报后，会先进行数据的标准化，变成平台统一定义的设备数据格式，然后通过mq分发到各个业务处理单元。

    DATA-SNAPSHOT：设备快照（每个设备的最后一次状态），这部分主要保存各个metric的最新一次状态，不会关注历史状态，可以满足app，web网站快速查询设备的最新状态，由于每个设备只有一条数据，可以支持多种条件过滤查询以及一些简单的统计。

    DATA-BACKUP：数据备份（历史数据存储），这部分主要是存储通过设备上报上来的所有数据，可以满足按设备主要属性查找最新上报的数据和分页查找历史数据以及作为数据统计的数据源。

    DATA-INDEXING：数据索引（一段时间内的全量设备数据，一般设计为6-12个月），这部分主要存储设备最近一段时间上报上来的全量数据，全量（部分）索引，以满足不同维度不同组合的查询及简单统计。