ADAS数据平台实践总结

        随着汽车智能化发展,adas数据分析变得越来越重要,此处根据个人认知对adas数据平台进行分析。

  • 概述

        adas数据一般来自于汽车厂商发布新车的前的 实际道路测试(路试),相对于其他数据,具有如下特征:

1.数据全面,有准备的录制数据,分析数据要求多方面,如宏观、微观、问题分析、场景分析,及基于数据的模型训练

2.数据量大,通常一轮路试周期在 2周-1个月左右 

3.数据格式多样化,大部分会基于autosar协议,但可演变出多种数据格式,且如有现场融合或特斯拉类,不遵守该协议的情况。

4.全为数字格式

5.具有时序性

6.可进行切割

        基于以上分析,首先要对数据进行统一格式化,制定数据分析的输入标准。其次因具有不同维度的分析,采取的分析方案或知识域也不一样,所以尽量采用跨知识域存储及数据处理方案。最后,对分析结果能进行快速回溯验证。

  • 统一输入标准

        将不同的原始文件(路试数据)通过自有规则,转换为统一格式,该部分可以在数据分析前完成,从而和汽车路试领域解耦,该部分我们叫做“预解析”。那预解析完以怎样的格式存储呢,这是数据平台最重要的点。

        举一个业务用例图:

        用户 ---- 上传路试数据 ---- 转换为标准数据 ---- 标准数据再处理(运行各种模型)---- 切片(筛选出关键事件、场景,统计宏观数据)----  对场景、关键事件进行回溯验证 ---- 出具报告。该流程是数据分析人员的基本作业流程,包含“3进3出”

进 
1 原始文件录入 原始文件转标准格式前  获取原始数据
2 标准格式存储 运行模型前 获取标准格式数据
3 回写标准数据格式 切片场景前 获取标准格式数据

 可以看到 第1个进出 是没有选择的,本身就是统一输入标准。第2、3个进出就比较有讲究,相当于数据的回写,这不就是我们日常使用的数据库吗?初期我也是这么认为的,并且找了一个iotdb(时序库)作为存储,运行时从中存取数据,但很快发现问题:运行模型会将几乎所有数据运行一次,且有的模型还是“数据顺序”要求。不仅如此,切片逻辑也需全量扫描,比如定位一个场景,总不能让路试工程师哪个小本本记录,xx秒开始泊车,xx秒开始上坡,xx秒开始S弯吧。。。除此之外,还会通过数据进行相关预测,甚至做模型回灌和训练,可以看到这其中已经不仅仅是传统的数据分析,还有大量的 “数据挖掘”概念。由此得出一个结论,我们的数据是用于多方面应用的,应当具有很好的开放性。

综合以上得出两点:1.数据运行过程会进行近全量处理 2.数据访问应具有很好的开放性。

  • 存储及数据处理方案

         基于以上总结,处理全量数据,采用“存取一体”的lambda架构是最合适的。数据开放性上主要在于 支持不用语言高效访问,访问包含访问 时序数据、结果数据、以及中间数据。

实际应用中,我们最终基于3种方案进行了对比与选择,在此分享。分别是:基于arrow文件+spark(或等价的)、基于iotdb时序库、基于TDengine时序库。以下对三种方案做对比,分别是:全量处理方案、开放性、潜在风险

        基于arrow文件+spark(或等价的)方案:

                全量处理。采用 lambda架构。批处理层:数据参数,将arrow从云存储下载到本地;加速层:从本地load数据,进行自定义处理,回写arrow,回传云存储;服务层:按需下载云存储arrow文件,读取展示

                开放性。原始文件访问---云端下载;过程文件---加速层程序控制;结果文件---下载访问。由于arrow支持多语言快速存取,访问速度会很快。

                潜在风险。该方案采取使用时下载文件,非常依赖云存储,对云存储和宽带稳定性有较高要求。其次由于未像传统spark使用方式,将实际原始数据传输,增加了一层映射,代码难度增加。

        基于iotdb时序库的方案:

                全量处理。由数据库架构完成存入操作,但由于提供了TSfile挂载,可在外部写完TSfile后,挂载到数据库。相对数据库直接入库,省略了wal缓冲及记录,索引文件构建等操作,极大增加了插入速度。数据取出:java或C等只能将数据按一列一列取出,但python可直接传输numpy数据结构,传输量大大减少。非外部模型(simulink模型等)下可以采用数据库内置引擎。

                开放性:原始文件访问---通过sql查询访问,除python外,速度较慢;过程文件---如取出操作则程序可控,采用内置引擎则无法提供;结果文件---通过sql访问,除python外,速度较慢。

                潜在风险:全量处理时,需要控制数据总量,毕竟机器的空间是有限的,可以通过卸载存储组(类似mysql 的某个db)的方式,达到基于存储组的 “无限量”的云数据库,但恢复时需要等待较长时间(实际1-5分钟)。当需要大批量数据查询时,查询时长会增加,比如某个路试一天数据360亿个数据点,200多G,要传输多久??

        基于TDengine时序库方案:

                全量处理。和iotdb一样,由数据库架构完成存入操作。主要采取批量写入增加吞吐量,但wal缓冲,索引构建等基本操作是不可避免的,相对iotdb挂载文件,性能要低。可以通过集群节点增加吞吐量,但对于汇聚查询来说,需要将不同机器数据传到一台,网络资源是有限的,所以和iotdb没有区别,且在python端使用不支持numpy格式传输,在python端使用时,iotdb更优。以上情况是将数据取出来运算的评估,如果不是运行simulin等外部模型,则可采取内部引擎,无需传输直接执行回写即可,C语言特性是内存自主管控,相同数据不必拷贝多份,但在全量处理情况下,最少也得加载200多G的数据。

                开放性:原始文件访问---通过sql查询访问,速度较慢;过程文件---如取出操作则程序可控,采用内置引擎则无法提供;结果文件---通过sql访问,速度较慢。

                潜在风险:全量处理时,需要控制数据总量,可通过taosdump 导出数据,进行云存储,达到基于数据库的 “无限量”的云数据库。导入则必须按 库级别 进行导入,不能像iotdb一样,先挂载需要用到的tsfile,快速投入使用。当外部需要大批量数据时,查询时长会增加。

        综合以上,可以看出,时序数据库具有 “重分析引擎”的特点,对于数据吞吐(存储特性)不够重视。因此如果是大批量数据迅速录入,或 具有自有分析引擎时,采用时序库是不明智的。反之,数据量较少或持续缓慢输入(如20m/s数据)时,需要依赖数据库函数及分析引擎时,选择时序库是明智的。以下是吞吐量和引擎分析表:

arrow iotdb tdengine
数据吞吐

存:高,基于文件传输及快速内存映射 

取:高,基于文件传输及快速内存映射

存:一般,先写Tsfile后挂载

取:较弱,除python外,取数较慢

存:弱,批量写入

取:弱,  列表取出

分析引擎 很弱:本身支持基本筛选功能,基本依赖外部引擎 一般,基于java不如基于C有性能优势 较好,内置引擎优秀,但udf扩展等问题严重拉低性能

        最后,软件要实现一些功能或性能要求,通过不断演变肯定能实现,比如时序库通过优化UDF,把外部模型转换为UDF函数,再优化执行UDF的传输格式,甚至集群模式下进行 基于本地化的“分区”等,当然这是时序库本身的工作,不是使用者的工作。

你可能感兴趣的:(数据挖掘,人工智能)