公司网站公司新闻,建站重庆,手机商城网站案例,中装建设集团有限公司董事长是谁随着汽车智能化发展#xff0c;adas数据分析变得越来越重要#xff0c;此处根据个人认知对adas数据平台进行分析。
概述 adas数据一般来自于汽车厂商发布新车的前的 实际道路测试#xff08;路试#xff09;#xff0c;相对于其他数据#xff0c;具有如下特征#xff1… 随着汽车智能化发展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数据时需要依赖数据库函数及分析引擎时选择时序库是明智的。以下是吞吐量和引擎分析表
arrowiotdbtdengine数据吞吐 存高基于文件传输及快速内存映射 取高基于文件传输及快速内存映射 存一般先写Tsfile后挂载 取较弱除python外取数较慢 存弱批量写入 取弱, 列表取出 分析引擎很弱本身支持基本筛选功能基本依赖外部引擎一般基于java不如基于C有性能优势较好内置引擎优秀但udf扩展等问题严重拉低性能 最后软件要实现一些功能或性能要求通过不断演变肯定能实现比如时序库通过优化UDF把外部模型转换为UDF函数再优化执行UDF的传输格式甚至集群模式下进行 基于本地化的“分区”等当然这是时序库本身的工作不是使用者的工作。
