针对时间数据，还有一个最常见的处理——聚合，我们往往看的不仅仅是从一个数据源来的指标，如果我们要看北美地区某一个广告源在一段时间内产生的所有收入的总和，我们就需要把跟广告源标签对应的时间线全部挑出来，然后将广告收入时间点加和在一起，得到一个新的求和曲线，如图所示，我们找到了非常多的时间线，最后用某种聚合函数聚合在一起。每一种业务需要的聚合方式也是不一样的，比如广告数据算加和，或者按广告源作平均，也有可能找最大最小值，或者作统计性事情，比如99%值都在某个数值以上。
时间序列数据的特点
因此，我们得出时间序列特点包括以下几方面：
- 持续产生大量数据。不论是广告监控还是传感器、气温，它针对的情况很多。比如监控工业园区中灯的耗电量，每盏灯就会有传感器实时传输灯耗电量，如果采样间隔是一秒钟，每盏灯每一秒就会产生一个数据点，几万盏灯没秒就会有几万次写入，如果涉及楼宇多，就会产生每秒几百万上千万的写入。
- 数据产生率平稳，无明显的波峰谷。这带来了优化的好处和坏处，好处是不会产生明显的峰值，所以在做容量评估时会比较方便;坏处是没办法在闲暇时间做数据合并和补偿的工作。
- 近期的数据关注度更高。
- 时间久远的数据，极少被访问，甚至不再需要。所以时间序列数据一般需要数据回滚功能。
- 数据存在多个维度的标签。
- 展示或使用时往往需要对数据做聚合计算。
当传统数据库遇到时间序列数据
时间序列数据存到传统数据库中会遇到一些问题，例如时间序列数据直接保存到关系数据库中(例如MySQL 的InnoDB引擎)，使用SQL语句进行分析。这里就会遇到以下一些问题：
- tag重复存储，存储开销大，如果将模型变成MySQL的行时，每个数据点会产生独立的行，也就是标签会重复存储，在一个时间序列上每个数据点需要保存到标签重复存储一遍，这样才能用标签把这个序列上所有的数据点找出来。
- 可以用联合索引部分解决多维度的问题，但是进一步增加了存储的开销。
- B树索引在持续写入的时候产生大量随机IO，写性能迅速下降，多联合索引加剧了写入慢的问题，InnoDB是用B+Tree进行索引的，为了数据查询快，一般会根据标签不同组合建立不同索引，当写入数据时，不同标签写进去的数据排序是不一样的，大部分的标签在写进去时会在索引上产生随机插入。
- 数据量大导致索引/数据很容易超过内存容量，查找/聚合性能不高。查询时会导致大量的磁盘IO的开销。
- 降精度的SQL子查询很难被SQL优化器优化。
