一文详尽如何破解车联网数据采集存储难题

 

一、车联网市场及趋势浅析

（一）什么是车联网

未来智能互联化是一个不可逆转的趋势，生活中常用的物品都在逐渐联网化，例如洗衣机、电视、智能家居等设备，通过联网可以用手机控制，甚至于智能穿戴的设备，衣服、眼镜、鞋都有逐渐联网的趋势。

 

手机作为第一个智能终端，它已经从简单的通话工具演变成了可以社交，查看新闻，甚至办公的工具。汽车也是一样，现在汽车正在逐渐联网，成为第二个智能终端。汽车作为智能终端接入网络之后，利用车载设备实现智能化交通、移动金融服务、购物、车家互控等场景逐渐成为现实。这些场景下会产生越来越多的数据，比如，现在可以从手机端直接连接汽车4S店的服务。甚至汽车跟手机的终端打通，已经可以互联互通互动。也可以从汽车端直接控制家电，比如在汽车上有些高端车，可以直接车家互动，在车里面控制家里的空调、洗衣机等。

 

除了这些，未来娱乐内容等方面的数据，以及车上产生的状态轨迹数据都会逐渐向云端存储，而5G的发展无疑加速了进程。

 

（二）市场趋势

 

随着5G网络的建设，传统的移动互联网市场已经饱和，一部分企业开始瞄准5G带来的汽车互联网机遇，探索5G所驱动的汽车革命；同时，汽车企业在过去几年时间提升了认识，逐步开始实践数字化转型，部分企业已经初见成效。之所以5G可以给汽车互联网带来发展机遇，主要原因5G支撑了云计算在汽车上的应用，这使得云语音等服务成为可能。

 

与其他设备的移动互联网应用不同，汽车互联网的应用有一定难度，主要是汽车企业主动性不强，完全外部安装的设备不容易发挥作用，利用5G带来的云平台接入，给汽车企业带来了主动数字化转型的动力，那么汽车互联网的发展会大大加快。

• 汽车联网可以划分4个阶段：
  第一阶段：2G/3G/4G联网的时候，主要是解决“通”的问题，能看到汽车的状态，比如现在租车或网约车汽车的状态与位置，用2G/3G/4G数据传就足够了。

第二阶段：带宽逐渐增加之后，就可以拿到更多车上产生的数据，做大联网的数据。但车联网的大数据分析，能够为保险行业或者其他金融行业提供车主驾驶行为的数据判断。

第三阶段：V2X、5G、云端互联，带宽已经越来越高的情况下，可以实现更多车和其他系统的对接，更多更丰富的功能。

第四阶段：可以借助于云端无穷无尽的计算能力，去做一些智能化的计算和判断，实现智能驾驶远程连接系统，对接第三方系统，对接车车的互联，车和路测终端，更紧密的互联等更大场景下的智能化应用。

 

中国车联网用户规模不断攀升，5G/V2X技术应用有望实现强劲增长，2022年用户总规模将超过5100万。短期，中国车联网市场规模的增长主要依赖软硬件装载量的提升。中长期，随着车联网生态的丰富，广告、CP/SP等以车联云为核心的车内增值服务将带来更广阔的增长空间。

早在2017年，国家就推出了车联网行业的新四化：“网联化”、“智能化”、“共享化”、“电动化”。无论从国家规划还是从科技发展趋势来看，这四化都将成为未来汽车行业的发展方向。未来，所有汽车行业都会从传统的汽车制造企业向出行服务方向进行转型。随着国内汽车保有量和人均收入的快速增长，给客户提供更加可靠、安全、优质的出行服务，将变成车企的主要目标。针对这个目标，阿里云存储产品需要给车企提供可信赖的数据支撑，便于车企对自身进行优化、改进。

图源见水印，侵删

据前瞻产业研究院发布的《车联网行业市场前瞻与投资占率规划分析报告》数据显示，2020年中国汽车保有量约为2.5~3亿辆，按照15%的渗透率，具备联网能力的车辆将达到4000万辆左右。以每辆1000元的硬件产品价格来估算，单是硬件市场就有400亿元规模。而随着产品功能的丰富，单辆车的硬件产值也会翻倍提高，加之互联网服务，车联网市场的空间可以在5~10年内达到千亿甚至万亿规模。

 

二、车联网海量监控数据怎么存？

 

（一）车联网系统数据存储

 

汽车企业在生产系统中采用云战略实现上云上平台，一方面可以解决过去难以解决的各个系统互联互通问题，另外一方面，可以通过推进产业互联网平台，为各地域的工厂（不一定是同一家公司）之间共享信息提供基础条件。

上图左右放的是智能互联系统的云端架构图，从左边这个逻辑架构图可以看到，从下面产品通过网络接入云端，首先连接底层的是产品的数据库，云端在资源池化之后，让用户以更贴近业务的方式去定义业务相关的一些应用和产品。

 

所以说，从第一层把数据对接上来，就要进入云端的数据库集中的存储，有了集中的数据存储层之后，才需要往上去建立应用层应用平台，或者是智能化的规则引擎，数据来驱动平台。根据不同的业务互动场景，去建设相关的应用。

 

右端是数据架构图，表示数据首先从车企端采集以后，不单纯是车上的各个指标数据，还有它的位置信息以及其他更丰富的数据，比如智能后视镜，采集的视频数据、语音的数据和云端服务交互的数据。这些数据是多样化的，无结构的，半结构的或者结构化的数据都会有。所以需要有一个Delegate池化的大数据云端存储平台，能够支撑多模、异构的数据的存储、查询和解析。

 

这些数据不光是车产生的，还有可能第三方系统的，比如车跟支付宝平台对接，微信对接，第三方国家银联的平台，或者是内容提供商的平台对接，服务提供商的平台对接，这些数据源也都可以作为我们数据库全景数据的补充。

 

有了全景数据，未来才能支撑更多更丰富的场景。

 

大致的部署结构如下所示：

首先车企端在一般情况下使用OBD、OBU把数据导出来。TBox是车集中的计算平台，就像我们的电脑似的，它把数据从OBD、OBU平台拿到之后上传，通过SIM卡跟云端发生交互。云端拿到数据之后，通过数据解析，一致化之后，再融入第三方数据源，实现不同场景下数据的应用，比如，车载应用：IVI新功能规划、新的交互模式、智能座舱体验；TSP服务：加油充电、道路求援、交通信息、停车服务；正常导向：国家标准（国VI、EV）、第三方数据输入、安全体现等，都可以基于云端的数据，去搭建需求应用系统。

 

（二）车联网典型数据场景–新能源汽车监控

 

BEV新能源汽车监控场景主要是为了满足GB/T32960国标和地标的需求，以便车厂能够获得平台符合性及车辆符合性认证。整个车厂建设过程中，出于日常运营需求，往往在国标基础上建设额外服务，例如：通知、告警、监控、追迹、调度服务、系统报表、数据转发等功能。

• 主要建立能力
  调度服务：可选服务，可用于车辆运营。

报警信息：可选服务，可通知车主、4S店等定制化报警服务。

统计报表：可选服务，基于OEM要求进行定制。

数据存储：实施接受（10S频率），北京区域要求存储1年，上海地区存储3年。

数据查询：各个数据（实时数据/历史数据）的查询显示接口，需求提供报警新展示，单体蓄电池电压数据展示；动力蓄电池包温度数据展示；整车数据展示；极值数据展示。

 

（三）车联网典型数据场景–Telematics

 

Telematics是指应用无线通信技术的车载计算机，新一代Telematics将以公有云为核心，实现车辆远程控制、远程读取信息和智能赋能。目前有内置和OBD接头两种实现的方式，其本质都是对于汽车各系统ECU的远程监控，已经实现的功能有远程检测，远程控制，呼叫中心等，比较成熟的有bluelink, 安吉星on-star，美国的snap-on，还有delphi出的Verizon Wireless等。

（四）车联网典型数据场景–智能后视镜监控

 

为贯彻交警“便捷高效，互联互通，共享共治”的互联+思维理念，充分发挥智能行车记录仪在交警执法中的积极作用，运营商积极配合深圳市交警局打造“车联网生态系统平台”，建立中国智能交通产业联盟上下游企业生态圈，支持车联网生态圈等相关企业发展，实现星级用户车主“一人一车一设备”的愿景，为车主提供多样化的车联网平台管理方案，以提高交警对车辆管理的效率。

（五）车联网典型数据场景–车载娱乐系统

 

车载信息娱乐系统（IVI）是智能驾驶舱信息交互的重要载体，基于车身总线系统和互联网服务，形成车载综合信息处理系统，可提供导航定位、车体控制、无线通信、车内娱乐和汽车移动等多种服务内容。产业链中，中控厂商凭借对硬件和软件的整合的产品优势和技术累积，占据了座舱电子产业链的制高点，未来，中控系统将成为人机交互的核心驱动，具备广阔的应用前景。目前，IVI能够实现包括三维导航、实时路况、IPTV、辅助驾驶、故障检测、车身控制、移动办公、无线通讯、基于在线的娱乐功能及TSP服务等一系列应用，车辆电子化，网络化和智能化水平强依赖云端能力。

云端和车机端的数据的交互量会大幅的提升，不光是服务能力赋能汽车，同时视频和音频汽车车主驾驶的时候操作的数字路径，都需要从云端去获取，这些数据也需要在云端去集中的存储，就是现在的一个场景和海量数据存储的一个现状。

 

三、云原生多模数据库Lindorm怎么解？

 

（一）什么是云原生多模数据库Lindorm？

 

云原生多模数据库Lindorm适用于任何规模、多种规模的云原生数据库服务，支持海量数据的低成本存储处理和弹性按需付费，兼容HBase、Solr、SQL、OpenTSDB等多种开源标准接口，是互联网IoT、车联网、广告、社交、监控、游戏、风控等场景首选数据库。

未来，车联网场景将会是数据量大，数据类型多。不同场景下产生的数据类型多种多样，会有视频、文本、代码链路、用户数字轨迹等方面的数据，以及在车机端点击应用的操作行为。这些都会使得云端数据库建设对应的存储模型，以及查询能力，因此云端多模的存储能力是必选项。

 

同时，需要考虑对现有系统和第三方平台的对接能力，多模的数据库需要有一个开放的标准和协议支持，支撑更大范围的数据生态。

 

Lindorm主要有以下四个特点：

 

1.极致性价比

 

当遇到数据量激增的场景，如果没有很好的数据压缩存储或者冷热数据自动转存的方案，数据成本也会激增。大部分的监控数据是机架式密度数据，有一些运维数据在不出故障的时候就没有什么价值。只有出了故障，在回溯分析定位的时候，它才会发挥价值。像这种数据，如果用传统的关系数据库或者是自建的数据库存储，运维和数据授权的成本非常高昂，是不经济的存储方式。

 

因此，未来需要极致性价比的物联网存储，能够提供PB级甚至EB级存储能力的存储平台，才能有效支撑这种场景。

 

2.云原生弹性

 

未来，我们需要云端提供随时进行池化资源的使用方式，没有业务的时候可以收缩资源占用量，节约成本。业务并发量大的时候，在保证性能的前提下满足成本控制的需求。

 

因此，弹性伸缩数据库的存储，是云原生场景下很关键的能力。

 

3.企业级稳定性

 

支撑如此庞大数量在线运行车辆的场景，稳定性至关重要。

 

例如汽车OTA场景，当发生故障或网络中断、数据丢失的情况，汽车升级可能发生中断，导致了车机端的故障或是智能化控制指令丢失，执行失败等。

 

4.数据生态融合

 

对接更广泛的生态，无疑可以支撑我们更大场景下的这个数据应用，这个也是非常关键的。

 

目标行业：工业物联网、 车联网、APM运维、NPM运维……

 

这些场景都有一个共同的特点，就是产生海量、带持续指标的监控数据，而这些数据的价值密度非常低，它需要一种经济且友好的数据库进行存储。

上方为Lindorm数据库体系图。

 

目前Lindorm的核心能力除了能够对接广泛的数据生态等，在数据库内部也有多模数据转存的通道，能够在宽表、时序、全文检索、文件检索引擎之间做数据的协同。

 

上层除了支持SDK等接口之外，还支持其他应用比较广泛的大数据生态接口查询语言。

 

（二）Lindorm产品策略

上方为产品发展策略，未来演进方向是云原生多模超融合数据库。

 

首先在金字塔底层的第一阶段，要具备海量多模数据的存储能力，把结构化、半结构化、无结构化的数据以较为经济的方式存储下来，对这些数据做云化的处理，称为数据云。

 

在此基础上，再建设跨数据库引擎的横向融合能力，如宽表、时序、图、关系等模型数据，实现数据库协同查询能力。

 

在Lindorm数据库内部，用户可以通过一致的查询语句，透明查询多种数据库，拿到所需要的信息。无论这个信息是从宽表、时序还是从文本检索引擎来的，均对用户透明化处理，从而更友好地支撑未来数据应用的开发。

 

再往上层的纵向融合指的除了数据库引擎、上层数据交换、ETF流数据处理以及计算引擎，可以在上层搭建数据库内部的运行，例如异常检测、趋势预测、关联性分析、相关性分析等，纵向地将数据库的能力进一步融合，进而达到超融合，实现统一的查询语言、数据视图，数据访问。

 

在车联网的一些具体场景下，比如新能源汽车当前电池包的健康状态监控，或者是公共场景下带业务特征的计算，都可以做成数据库内计算的算子，或是以函数直接通过标准SQL语句去调用，最后连存到算一体化执行，最终实现顶层推理的效果。

 

推理的效果指的是我们只需要告诉数据库我们的需求，则可得到相应的信息。建立统一的数据视图之后，可以用SQL语句定义，比如导致生产次品率上升的主要原因，汽车故障发生告警的主要原因等，这些能力都是现有的数据库和查询所不能实现的。

 

如果要提供以上能力，需要一系列的数据工具，如下所示。

上图为逻辑架构图，图中的最下方是能对接的第三方数据源，提供无缝的对接和支持。数据进来之后到宽表时序等文件引擎，在这里面根据业务场景不同，可以划分不同场景进行存储，有配套的数据转储和数据采集工具。

 

再上方就是计算引擎，还有数据检索的引擎。如Phoenix SQL引擎，Lindorm监控服务，以及时序数据分析等服务。再上层是人机界面，为了方便基于数据库开发数据应用，最上层是应用系统。

 

• 核心优势卖点
  1）高性价比存储

2）多模超融合检索

• 创新技术能力
  1）时序数据压缩

2）工业场景数据建模

3）时序统计及非确定性推理检索

• 贴近客户场景
  1）LindormStudioIDE、工具、SDK

2）文档、方案、案例库

3）专业、体系化IT&OT融合服务能力

• 打通数据生态
  1）开放生态：开源：CQL、PhoneixSQL、 ES、MachineBeat…

2）商业：OSIsoftPI、Splunk

• 融合方案生态
  OSIsoft、Intel、工业大脑、IoT、东软、 飞象互联…

上方为以前和当前存储方案对比，原来的部署方案需要应用开发人员和运营人员具备较高的动手能力，后续数据量增加的话，每个系统要单独做集群，需要耗费大量的人力和专家进行支撑。

 

当前的Lindorm存储方案是一个数据库帮助客户解决日常问题，用一个接口查询所有多模型的数据库。

 

（三）Lindorm车联网数据存储解决方案

在部署形态上，未来的车联网与物联网是便载、地域分布广的场景，单独在云端搭建数据库无法满足性能实时性的需求，所以未来数据库形态逻辑和物理部署可能是一对多，称为云边端一体化的数据库部署方案。

 

边缘端不管是车联网路测端的设备或者车机上的TBox，都可以去嵌入轻量级持续数据采集的数据库或者是多模数据库。在工业场景下，已经实现了在边缘计算节点上部署边缘数据库，它可以无缝对接混合云、私有云数据中心或者是公有云平台数据库，做实时或按策略批量的数据同步。

 

用户在实际部署和使用过程中，可以把分布部署的数据库作为逻辑一体的数据库来管理和实现。比如边缘端部署，它可以采集存储一段时间周期的数据，然后支撑实时面向边缘端所连接的设备或者车辆数据，实时查询与监控的场景。

 

一旦需要全景数据或者是需要回溯分析出报表，统计数据的时候，可以借助云端强大的计算能力与存储能力，做全量数据的回溯，做复杂计算以及根源分析，甚至机器学习场景的模型训练，完美实现逻辑一体，实际物理分离。既能支撑实时场景，又能支撑批量分析场景的数据存储解决方案。

• 物联网行业数据主要以终端设备、传感器实时产生的状态数据、用户操作数字足迹和控制执行结果数据为主；
• 利用监控状态数据可以及时发现设备、异常操作、潜在风险、客户数字体验，从而指导运营运维；
• 物联网实时监控数据经过实时流数据处理平台，或时序数据库聚合对接实时监控大屏，支持设备实时监管、风险态势感知等应用场景；
• 批量存储在近场端、数据云端的全量物联网数据可用来做故障回溯分析、主动探伤检测、异常定位及预测等。

BEV新能源汽车监控场景主要是为了满足GB/T32960国标和地标的需求，以便车厂能够获得平台符合性及车辆符合性认证。在整车厂建设过程中，出于日常运营需求，往往会在国标基础上建设额外服务，例如：通知、告警、监控、追迹、调度服务、统计报表、数据转发等功能。

 

针对这个场景，我们提供了基于阿里云Lindorm数据库的整体解决方案。

 

首先，这个方案里除了Lindorm，还用到了其他阿里云数据库产品，比如多维数据分析数据库ADB，第三方开源的Spark streaming，还有IoT网关MQTT等。

 

这个流程从车机端对接云端一般有两套方案，一套方案是车厂对接车联网的服务提供商，他们有自己私有云平台来对接车机端的提供，然后再由他们的平台来对接到阿里云的Lindorm数据库。

 

另外也可以直接按标准协议去对接车机端现有的TBox，直接用 REST接口来同步数据，或者MQTT协议直接发送到IoTGateway。这些数据到了云端之后，它可以分成两个流，一个实时写入Lindorm，快速上报国家平台，周期10秒，在周期内完成上报国家平台以及存入数据库这些动作。

 

另外一个为了实现实时报警与数据分析，数据流也同步推送一份到Spark streaming，由它做实时流数据分析生成事件，然后再存入Lindorm数据库。

 

如果有第三方数据的对接，比如车厂以及其他第三方系统做数据的归集备份，或者是第三方的平台的应用也需要这块数据，就需要推到Kafka里边，然后再由Kafka消息队列发到车场的数据中心。

 

车场数据中心也可以部署一套Lindorm数据库和云端做实时数据同步，当出现网络链路不稳定，或者车厂做数据分析的时候，在车场本地的数据中心也可以完成数据分析的工作。

 

国家数据平台最主要是北理工的平台，有标准的接口协议直接在云端开发相应的数据推送服务节点对接国家平台，地方平台有地方标准和相应接口，可以云端直接转发。

 

这里用到的数据库主要有，Lindorm数据库做全量数据的存储，Lindorm数据库中需要结合其他数据，比如说CRM的数据，车辆信息数据，基于密码查询相关的信息等复杂高维的数据查询，可以同步到ADB，再用ADB同步到数据分析平台QuickBI，来做数据的统计和可视化。

 

另外一个就是开源的Grafana，如果是需要监控全景或针对特定车辆的信息，可以通过Grafana来实时查看最近时间窗口的状态。

 

IoTGateway主要负责和车机端对接，或者和车联网的专有云平台对接。

 

（四）车联网场景下Lindorm商业价值在哪？

• 快：
  1）高通量车联网数据并发写入快

2）时序数据聚合、划窗、统计计算快

3）海量监控数据检索查询快

4）数据全生命周期管理流程搭建快

• 省：
  1）海量车联网数据存储成本省

2）占用计算、存储资源省

3）数据库搭建、应用对接开发工作量省

4）数据全生命周期运维管理成本省

 

在车联网场景下Lindorm商业价值可以总结为两点，一个是快，另外一个就是省。

 

快就是，说在高通量的车联网数据并发写入的场景下，可以在云端进行云原生的模式，随机汲取的模式，去实现车企端、在线车辆产生的实时海量高通量的数据，可以快速地在云端数据库写入以及数据快速向第三方平台转发。

 

时序数据聚合、划窗、统计时，在有原生的自研时序数据库情况下，很快地在数据库内做大量数据的聚合、划窗、统计分析。海量监控数据检索查询快，因为它是时序数据库引擎来处理的，可以支持海量多维度数据的聚合查询的计算检索。

 

数据全生命周期的管理流程搭建很快，因为很多能力都是数据库内提供的，就不需要再去人工搭建，或者是维护自建的开源数据库来定制开发能力，或者数据对接的接口，所以说搭建过程也很快。阿里云之上开通Lindorm数据库，几分钟时间就可以完成。

 

省就是，对海量数据存储成本会有大幅的下降，除了自研的冷数据、热数据备份的策略，在存储层也做了自己的优化。在时序数据库数据压缩方面，在现有的压缩算法上做了一些改进，达到了10倍数据压缩效果。

 

占用计算存储资源通过云原生的方式，随机汲取，在没有太多的在线车辆的情况下，收缩它的计算能力，按实际的数据的访问使用量来收费，这样就节约很多数据超配的成本。

 

数据库搭建应用对接开发工作量也会省下很多的人工的成本，一方面是数据库本身支持很多的第三方大数据生态接口的对接，另外云端搭建就不需要关心数据库安装和备份策略等配置的问题。

 

数据库全生命周期运维管理的成本，也会节省很多，灾备集群的方案，数据库的整个转储等这些都是数据库内自动解决的。

 

（五）Lindorm关键技术优势

 

1. 实时无损，高压缩比存储> 10:1

10:1的深度优化，基于ZSTD算法的压缩，可以把原始的采集的时序数据，比如10GB数据存入到数据库内去做无损的压缩，做到10GB数据存到数据库内，1GB数据的存储容量就足够了，压缩效率相比现在业绩通用的SNAPPY压缩提升50%以上的压缩效率。

 

2. 面向低价值密度监控数据的冷热分离低成本存储

冷热分离的低成本的存储方案，我们是在Lindorm数据库内做的一体化整个分离，数据也是自动做分层，冷热的分离，就不需要人工介入。冷数据存储成本一般比现在的热数据要降低80%以上，热数据为了满足性能的要求，一般用SD等高端的存储来存冷数据，性价比较高的存储来存这些历史数据。这样的话既兼顾了查询的性能，同时又节约了成本。

 

3. 云边端融合存储，数据自动实时、批量同步

• 特点：
  1）边缘版轻量级快速集成部署

2）2HA高可用架构

3）具备与云端版本一样的功能

4）数据自动同步至阿里云TSDB实例集群

 

云边端一体化的存储的方案，边缘端的数据库、嵌入的数据库，根据策略去做实时的云端数据同步以及批量的数据的导入与导出。

 

4. 多引擎超融合数据快速迁移同步

在数据库内部是集成了一个ETL工具，做多模数据之间的数据导入导出，甚至对接第三方的HBase或者Cassandra、OpenTSDB等数据的迁移，可以把第三方的数据源数据通过LTS直接迁移到Lindorm数据库，就不用再依赖于第三方工具实现。

 

5. 多模数据融合检索打通IT&OT数据交互

多模数据融合检索打通IT&OT数据交互，实现跨多引擎引擎查询，提供全维检索能力。

 

• 统一API，简单易用
  1）系统自动维护索引，应用开发不感知索引表

2）索引支持非冗余、冗余部分列、全冗余

3）查询时基于编译优化（RBO）全自动路由到搜索引擎，并智能判断是否需要回查宽表/时序引擎

• 数据自动同步到搜索引擎
  1）异步增量索引，基于LTS提供可扩展的同步通道，数据同步可视化

2）实时同步索引，引擎间数据强一致

 

针对IT数据和OT数据的交互融合，这一点可以实现一致的跨引擎查询，全文全维度的数据检索能力，通过上层一致数据，试图来帮助评比下层的数据存储、数据引擎的异构性，进一步简化使用成本和维护成本。

 

文章转自公众号：阿里云数据库