时间维度的数据分析案例
维度是用于在不同角度描述事物特征的概念，比如在时间维度上分析数据就是一种常见的方法。时间维度一般包含年、月、日等多个层次，每个层次都有与任务相关的属性。
在实际的案例中，数据源是由监控PaaS产品的监控工具产生，会产生两类数据：一类是性能指标（metrics），以固定时间间隔监控平台组件的性能指数（比如http server的latency）；另一类是警报数据（alerts），当指标超过人为设定的阈值时就会产生警报数据。这种方法会在产生警报的一段时间内产生大量，导致警报风暴。并且很难找到警报产生的真正原因和预测警报的产生。如下图所示，在这样的监控环境下，SRE（运维人员）的工作负担会很大。所以，我们依据时间维度上的警报和性能指标数据尝试减少警报数据的产生，并定位警报进而预测警报。
我们首先将数据存储到Hadoop上，并依据dt字段（字符串类型，记录日期信息）对数据进行partition。partition的好书在于缩小查询范围，从而提高查询速度。在下图表示的数据schema中，（customer, env, component, item）是记录环境信息的字段，以下我都称为环境四元组。collect_time是在划分时间维度的时间字段。recover_alert是标识故障是否修复的布尔值。value是性能指标值，值为数值或者状态描述字符串。
下面我将分别介绍怎么分析这两类数据。
警报分析
首先使用贝叶斯概率来分析警报数据之间的相关性。
我们发现：产生的警报数据量大，但警报数据之间有很多冗余。这些冗余数据会干扰运维人员进行问题的定位和修复，所以我们要建立警报数据之间的关联关系，来降低冗余的警报数据产生的影响。
我们首先将警报数据依据环境四元组进行分类，将每类警报的第一次发出时间记为警报时间的开始时间，并修复的时间记为该警报的结束时间。如果这次警报没有修复或者修复时间超过一天则将结束时间记为系统最大值（sys.maxint）。这样我们就将这段时间的重复报警数据过滤掉。
接下来只记录固定时间窗口（默认16分钟）内的一个警报数据的起止时间，当另一个警报的开始时间落在这个警报的时间窗口内时，则将这两个警报统计为一个组合（events_pair）。
我们通过这个组合出现的次数和这类警报出现的总次数之比\(r=\frac{c(alert2 | alert1)}{c(alert1)}\)，来衡量这两类警报关联程度。即值越高，这该两类警报的关系越大。比如在一个环境下的缓存redis出现故障，随后mysql集群也出现警报。那么在下次redis出现故障时，可能mysql集群中的实例也会先后发出报警。这时，我们的方法就能衡量这种关系的可能性。
性能指标分析
我们使用相关系数衡量指标之间的相关性。由于目前我们对于两个指数之间的关系是未知的，所以采用两种计算相关性的方法（pearson, spearman相关系数）来计算相关系数，系数的取值范围如下图。其绝对值越大表示两者的相关性越强。
当一个变量增大，另一个变量也增大时，表明它们之间是正相关的，相关系数大于0；如果一个变量增大，另一个变量却减小，表明它们之间是负相关的，相关系数小于0；如果相关系数等于0，表明它们之间不存在线性相关关系。
由于相关系数描述的是两组数据一同变化移动的趋势。所以在进行系数计算前，需要进行预处理工作，将两组性能指标的数据处理成有序离散值（相同时间单位内的数据）。首先统计指定时间周期内的性能指标，将非数值类指标转换为数值。这一步骤称之为数值化（Numeralization）。然后再标准化（Normalize）为同一时间单位内的数据。
比如下图例子所表示的预处理流程。在数值化中，将app的状态值依据映射关系转化为数值。在标准化中过滤掉不同时间单位的指标数据。
正如前面所说，求出的相关系数范围在-1到1之间。系数绝对值越大，则表示两者的相关性越高。比如这个环境下的网络io与应用运行状态的相关系数表现出强正相关性。那么在下次应用出现故障时就可以先去检查网络环境来快速定位问题可能产生的原因。
总结
依据时间维度来分析数据还有很多方法，我这次介绍的只是分析数据关系性的方法。虽然我们在实际开发过程中获得了监控平台同事的肯定。但是我们不能将时间上的先后次序，简单地定义为逻辑上的因果。这因为这种弱相关性判断，我们开发的分析工具，目前还只能够辅助运维人员的工作。想要添加到整个PaaS产品的自动化流程中，我们还要继续在这方面下功夫。
##参考