1.时序数据的特点以及大数据背景下的可优化空间？
大数据时代已经到来了很多年，大数据解决方案基本成熟， Hadoop集群处理方案基本成为了一个处理大数据的最佳实践。他所处理的数据包含结构化，半结构化，非结构化的数据，通过Sqoop、Flume、kafka收集数据，通过hbase、hdfs存储数据、通过mapreduce、sparkstreaming等计算数据，最后通过hive作为数据仓库为应用层提供需要的数据。
这是一套通用的，综合的大数据解决方案。
那如果把数据类型细分一下，针对于大量的时序数据，我们应该怎么优化存储？
首先，什么是时序数据？
简单来说，时序数据就是按照时间维度索引的数据，比如车辆轨迹数据，传感器温度数据。随着物联网时代的到来，时序数据的数据量呈井喷式爆发，针对于这一数据细分的优化存储显得越来越重要。
那么时序数据有什么特点呢？针对于这些特点我们怎么去优化存储呢？
同样在浅谈数据存储文章中，我们简单并且不成熟的总结了一下时序数据库的特点以及解决方案，如下：
一般的时序数据都会有这几个属性：
度量的数据集，类似于关系型数据库中的 table；
一个数据点，类似于关系型数据库中的 row；
时间戳，表征采集到数据的时间点；
维度列，代表数据的归属、属性，表明是哪个设备/模块产生的，一般不随着时间变化，供查询使用；
指标列，代表数据的测量值，随时间平滑波动。
如下图所示的数据：
对于时序数据，我们总结了以下特点：
1.数据特点：数据量大，数据随着时间增长，相同维度重复取值，指标平滑变化（某辆车的某个设备上传上来平滑变化的轨迹坐标）。
2.写入特点：高并发写入，且不会更新（轨迹不会更新）。
3.查询特点：按不同维度对指标进行统计分析，存在明显的冷热数据，一般只会查询近期数据（一般我们只会关心近期的轨迹数据）。
针对特点可以有如下改进：
第一个特点，数据量大，相同维度重复取值，我们可以将这些相同的维度压缩存储（因为是重复的），减少存储成本，比如将重复的host和port只存储一份就好了。
第二个特点，高并发写入，和hbase一样，我们可以采用LSM代替B树
第三个特点，聚合以及冷热数据，我们可以对于冷数据降低精度存储，也就是对历史数据做聚合，节省存储空间。
乍一看是没有问题的，但是在我细细研究了时序数据库的原理之后，对此又有了新的理解。
首先对于第一个改进，我们完全可以将这些相同维度放到mysql等传统数据库中，然后每个维度生成一个唯一id，再将变化的指标数据和唯一id存储在hbase中，这样就不会存在相同维度重复存储的问题了，顶多是查询的时候多查一次mysql而已，在维度不多的情况下，完全是可以接受的①。
对于第二个改进就更不用说了，hbase完全满足。
第三个改进只是一个优化点，不能成为决定性因素。
那么时序数据库和传统的大数据存储解决方案到底有哪些本质区别呢？
我觉得最重要的区别就是结构化数据。
1.存储的是结构化数据。我们都知道传统的大数据方案要存储的数据包含结构化，半结构化，非结构化的数据，这样就决定了我们不能决定有哪些字段以及定义各个字段的数据类型，像hbase就是通过byte类型统一存储的，也就是说放到hbase中的数据都是byte数组，从普通类型转换成byte数组需要我们自己来做，我们并不知道怎样转换成byte它的存储效率会更高。但是时序数据产生的数据都是结构化的数据，我们可以事先定义好数据的字段以及类型，让数据库系统根据不同的字段类型选择最优的压缩方式，大大提高存储的利用率。
2.分析聚合的是结构化数据。既然分析聚合是结构化数据，那么我们就不需要使用mapreduce那种复杂的计算工具、一般也不需要hive那种数据仓库，而只需要在数据库存储层面内聚类似于sum、avg在这种计算工具就可以了，甚至还可以做一些简单的流式计算，为‘超融合’提供了基础（超融合就是说将类似于之前对于大数据处理方案的多个组件融合成一个组件，主要还是因为结构化数据太简单了，收集计算等都比较简单，这也是后续时序数据库的发展趋势，减少系统复杂度）。
