vehicle time series data analysis

以HADOOP为代表的云计算提供的只是一个算法运行环境，为大数据的并行计算提供了在现有软硬件水平下最好的（近似）方法，并不能解决大数据应用中的所有问题。从具体应用而言，通过物联网方式接入IT圈的数据供应商(Data Provider)所面临的首要问题是数据分析的算法，其次才是算法的并行计算。

以汽车厂商(OEM,Tire1,Vendor,TSP)为例，所面临的大数据问题在 4V(Volume,Velocity,Variety,Veracity/Value)中，最突出的差异是Velocity，即实时性(Real Time)，有些信号的更新周期达到10ms。当然从应用采样和算法处理角度而言，可能并不需要这么密的数据，这就涉及到系统架构的区别，哪些功能放在终 端上运行，哪些功能在后台服务器上运行。以发动机转速信号为例，总线上这个信号的周期一般是10ms±5%，如果整个车联网系统要做的只是驾驶员行为分析 （反映车辆运行状态），根本就用不上这么高频度的采样周期，完全可以10s往后台打包发一次数据。但是如果整个车联网的应用是发动机故障诊断或防盗报警， 需要的精度就不一样了，正常启动转速低于500rpm几乎可以肯定发动机异常，如果等到30s后驾驶员才得到提示，发动机就该冒烟了。而对于一些事件触发 信号，如锁车状态下发动机异常启动，后台服务器判断车辆被盗的时间要求则更高。

IT行业在评估系统采用NoSQL还是SQL的时候，汽车上数据处理首先面临的是如何搜索。不同于传统互联网行业的文本数据，物联网或车辆网面对的都是时间序列数据(Time Series Data)，在这一点上，看股市走势图上各种眼花缭乱的曲线就知道了。当某个信号样本被定义为故障模式后，历史数据里面是否还存在类似的曲线，这在时间序列里被成为相似度搜索(Similarity Search)的问题。如果某个信号曲线总是周期重复，并呈现一定上升或下降趋势，未来能否能对这个信号做出预测，这就是数据预测(Data Prediction)的问题。其它数据相关分析、数据聚类等被统称为数据挖掘(Data Mining)的技术则建立在结构化数据的基础上，目的在于降低数据维度(Variety)，目前在汽车控制和分析领域的应用实在有限。

遗 憾的是时间序列的分析和处理在车联网领域几乎没有成熟的工具和方法，即使Matlab、R、Python这类专业的数学工具，提供的算法库也很少。这一方 面是因为物联网行业积累的数据还不够丰富，应用前景不清晰；另有一些如股市数据、视频流数据、语音数据等，与传感网络数据性质类似，虽然受到重视，但涉及 安全与机密，难以开放成果；更重要的是，时间序列数据的处理涉及各专业应用领域的技术和方法，处理难度很大。以汽车速度这一数据为例，机械工业时代大家关心的单位是小时，电子和信息工业时代单位是秒，在物联网行业中全过程、大样本的场景下讨论的则是毫秒，数据量和处理速度的要求超出现有普通计算机能力。移动终端上速度来源于GPS或 MEMS（Velocity和Veracity较低，但获取容易），车载终端上可能来自轮速和发动机转速（Velocity和Veracity相对较高， 但获取困难），在进数据库之前，不同数据源的解析要求也不一样。但无论如何，对数据的模式匹配或相似度搜索的要求都是共同的，因此在这一研究方向亟待可工程化的计算方法。

Similarity Search最早提出似乎是在1993年(Agrawal)，那时的数据还称不上海量，对“相似度”的定义更理论化一些。数学上对相同的定义是很容易的，比如欧式距离(Euclidean Disatance)和动态时间弯曲(Dynamic Time Warping)，但“相似”就会牵涉到程度的问题，不是简单设定一个容差或排序就能解决的。从算法工程化的角度来说，牺牲精确性来提升算法的时间和空间效率是很有必要的。数据比较理想情况下也可以用模型相似(线性、多项式、指数)，如果周期性比较明显也可以转换成频域方式用压缩相似来度量，但最直观的还是形态相似(上升、下降)，普遍的做法是将时间曲线分段，这方面已经有一些可用的算法，但效果很难达到大规模应用的要求。

* PAA(Piecewise Aggregate Approximation)，分段累积近似

* PLA(Piecewise Linear Representation)，分段线性表示

* SAX(Symbolic Aggregate Approximation)，符号集合近似

* LM(Landmark Model)，界标模型

相似度的定义本质上是描述数据的基本特征，通过特征空间的定义来降低数据维度。维度建立起来后就能对进入数据库的数据建立索引，压缩搜索的空间，为搜索算法的开发提供基础。