长安汽车使用 IoTDB 构建 1.5 亿时间序列车况数据处理方案，查询稳定实现毫秒级返回|长安汽车|汽车|信号

　　本文采访自：长安汽车

　　1. 长安汽车业务场景

　　重庆长安汽车股份有限公司是中国汽车四大集团阵营企业，是一家开发、制造、销售全系列乘用车和商用车的汽车公司，其主要产品有全系列乘用车、小型商用车、轻型卡车、微型面包车和大中型客车，全系列发动机等。长安汽车始终以“引领汽车文明，造福人类生活”为使命，以客户为中心，以产品为主线，持续提供高品质的产品和服务，奋力推进第三次创业——创新创业计划，向智能低碳出行科技公司转型，为实现世界一流汽车企业努力奋斗。

　　目前，数字化技术对于汽车进行了深度的重构，汽车从一个配备电子功能的机械产品逐渐演变为一个配备机械功能的电子产品，云数据及 AI 技术的融合逐渐将汽车变为一个大型的智能移动终端、数据采集载体、能源储能单元和一个移动的多功能空间。总的来说现在的智能汽车已经逐渐转变为一个具备多功能空间的轮式移动机器人。在这样的背景下，国家政策大力鼓励发展智能化汽车和自动驾驶的产学研带动，国内头部和新势力主机厂也逐渐将智能网联车或自动驾驶方向作为核心业务开展。

　　长安汽车着力发展智能化汽车方向，应用全景包括智能车控(远程控制分析)、智能座舱(车机埋点、车机用户行为分析)、IoT 数据接入(准入检测、车机激活监控)和 IoT 的车况管理(车况监控、动力研究、车联网大屏)，实现业务展现包括慧眼系统、车辆远程诊断和远程预警系统、远程调试系统等。

　　为实现智能化汽车建设，长安汽车构建了长安智能汽车数据平台，此大数据处理平台一共分为五层：数据接入层、数据存储层、资源调度层、计算引擎层、业务展现层。目前 IoTDB 主要用于数据存储层，以应对车联网海量时序数据的管理。

　　实现智能化汽车方向的工业场景涉及到车辆设备和传感器层大量的时序数据采集，这就对于时序数据解决方案的完善性和效率提出了巨大挑战。长安汽车目前的时序数据解决方案存在明显局限性，因此希望寻求对于智能化汽车领域的时序数据更优的写入、存储、查询、分析方案。

　　基于 IoTDB 时序数据库的特点和优势，长安汽车选择使用 IoTDB 作为海量智能网联车辆的车况时序数据处理方案，实现了大体量数据写入与存储灵活扩容，并有效提高查询性能，降低设备与运维成本。

　　2. 业务需求痛点

　　2.1亿级数据测点，每秒超千万条新增数据点

　　长安汽车作为中国四大汽车集团之一，业务体量庞大，需处理车辆多、数据量大。目前长安汽车的网联车海量车况时序数据管理系统共采集网约车约 57 万辆，总计数据测点达到 1.5 亿，数据点每秒新增超千万。因此，长安汽车对于此数据量下时序数据库的实时写入、压缩与存储能力均要求较高。

　　2.2 高速信号采集频率高

　　长安汽车的车辆采集信号分为高速信号和常规信号两种。高速信号需达成毫秒级采集，常规信号 3-4 秒级采集。长安汽车的时序数据解决方案需能够同时支持此两类不同的采集频次，并保证高速信号的实时低延迟采集的持续运行。

　　2.3 低延迟数据查询

　　长安汽车的车辆数据查询场景主要包括单车多时间序列的高效查询和单车全时间序列的最新点的查询，也就是车联网场景中很经典的实时车况和离线车况/历史车况的查询场景。长安汽车的时序数据解决方案需在低延迟的情况下有效支持即时的实时查询，与大体量已存储的历史数据查询。

　　基于之前长安汽车的时序数据解决方案，一份车况数据进入 HBase 后如果要做分析，需要从 HBase 里把增量的数据完全卸载出来，而这个批量的范围读取过程耗时很长。例如 HBase 如果要做昨天数据的离线处理，今天凌晨就需要把操作性数据卸载出来放入 Hadoop 做分析。另外，随着业务量增大，使用 HBase 进行批量读取的耗时也越来越长，不适应快速扩张的数据量场景。

　　2.4 成本、维护难度高

　　长安汽车最开始对时序数据管理的解决方案采用 HBase，但面对每秒千万的数据测点，HBase 的集群数据写入用了 25 个数据节点承担，如此多的数据节点直接导致系统的维护难度和成本较高。

　　3. 选型IoTDB原因

　　3.1 数据结构保证高扩展性、低成本、高稳定性

　　针对长安汽车庞大的已有数据体量及新增数据体量处理需求，IoTDB 专属的物联网原生时序模型以设备、测点/传感器为层级存储时间序列数据，随着数据量的不断增加，只需直接扩展查询节点的硬件设备，无需中断系统的正常运行，可达成秒级扩容，有效降低管理与运维成本。

　　3.2 实现千万写入速度

　　针对长安汽车对于时序数据频密写入的需求，IoTDB 能够实现每秒千万数据点写入、处理多设备亿级点位的能力，且写入速率不随数据量增长而下降，维持稳定高速水平。

　　3.3 支持高效明细、最新值查询

　　长安汽车在车辆故障报警场景下，会使用 IoTDB 进行海量网联车车况数据的明细查询。IoTDB 采用从根节点以下，以数据点自带的时间戳，与多层级存储的路径结合的存储架构，使得不同维度的时序数据可以被有效分类存储，继而在查询时可较快唯一确定 IoTDB 中的时序数据，从而在使用明细查询的情况下，依然保持查询高效率。

　　3.4 提升批量读取速率，达成实时分析

　　针对长安汽车在数据分析前对于数据的快速批量读取需求，IoTDB 因存在时间索引，可直接同步 IoTDB 底层数据文件，并运用 IoTDB 与其他大数据系统的无缝集成，用 Spark 引擎直接对存储文件 TsFile 进行实时分析，相比原先的方案减少分析数据所需的导出份数，提高分析计算效率。

　　3.5 及时运维，积极验证

　　长安汽车项目方认为，当业务场景给时序数据解决方案带来新的挑战时，处理问题的效率和思路是很重要的，一个优秀的时序数据解决方案背后的团队需要能够快速解决问题，使数据库涵盖业务场景所需的性能提升与丰富功能。长安汽车在生产环境上遇到的问题，IoTDB 的研发团队总会很快协调到相关的研发资源进行帮助。作为汇集了一批数据库核心技术专家和工业资深专家、拥有十几年研究和服务工业用户的经验的团队，团队成员也特别愿意用 IoTDB 在工业互联网场景去做生态环境的验证，使得项目的成功与产品的成熟可以实现互利共赢。长安汽车项目方表示了对 IoTDB 开发团队的感谢。

　　可以看到，IoTDB 的技术优势能够有效的解决长安汽车目前管理时序数据的业务痛点，因此长安汽车选择 IoTDB 构建长安智能汽车数据平台的数据存储层。下面就长安汽车基于 IoTDB 构建的大规模时序数据管理的解决方案架构、时序模型结构设置与查询性能效果展开介绍与分析。

　　4. 解决方案架构

　　车联网是一个典型的物联网场景。物联网场景的数据主体是时序数据，整个时序数据的生命周期分为采集、缓存、处理、存储、查询分析和可视化应用六大阶段。

　　在长安汽车车联网场景中，使用 Tbox 和 THU 等设备和传感器做车联网数据(例如发动机的电喷数据、转速、车辆的车速等)的采集。数据上云之后，基于长安汽车私有的 TCP 协议和基于 Netty 编写的网关进行报文的摄取。通过 CLB 进入 K8s 的 TU-GW 应用后，对报文进行解析。报文解析后发送到消息队列，并把不同业务所需要的时序消息分发到不同的存储端上。写入至存储引擎后，长安汽车 TSP 业务系统和 APP 将针对车辆的最新数据和历史车况，对时序数据进行查询操作。

　　目前长安汽车的大规模时序数据管理的架构，分为 1.0 和 2.0 版本。1.0 版本针对车况场景主要使用的时序存储引擎为 HBase，实现历史车况数据写入。因历史数据体量庞大，需 25 个 HBase 数据节点写入集群数据。同时，1.0 版本的 HBase 集群配置 10 个 Region Server。由于 HBase 的存储架构无法独立支持最新车况查询，最新车况查询需基于 Redis 实现。

　　2.0 版本的架构采用通过 Kafka 将数据写入 IoTDB 的架构。测试场景采用单机高 IO 的机型，即大内存(约 384 G)+全 SSD(约 50 T)的集群配置。经过 IoTDB 良好的数据 schema 设计后，一台 IoTDB 的机器即代替了 25 个 HBase 节点的写入功能，并成功维持超过一年的高稳定度。目前测试数据体量约 150 万条数据/秒，一条时序数据平均涉及 16-17 个测点，稳定支持整体写入数据体量约千万级。

　　同时，IoTDB 的强大数据查询能力，使基于 IoTDB 的 2.0 版本实现了一套引擎支持单车时间范围查询(实时查询)和单车全时间序列最新点的查询(最新车况查询)场景，并能稳定达成两种查询类型结果的毫秒级返回。

　　写入与查询能力的提升，让基于 IoTDB 的时序数据管理架构大幅降低了原有 HBase+Redis 方案的复杂度，并使 IoTDB 可接入设备和数据的体量得以不断增加。目前，长安汽车使用 IoTDB 单机接入设备约57万，托管时间序列约1.5亿。

　　　5. 时序模型和查询应用

　　目前，在 IoTDB 的根节点、业务名称、设备层、传感器层的四级节点时序模型设计上，长安汽车的设备层采用 TBOX 的 TUID，即设备 ID 作为第三级节点;在传感器/测点层，除涵盖信号名，使用下划线连接 CANID 作为第四级节点。此存储结构的设计原因是可以方便的使用 IoTDB 支持的 select last * from root.CANID 命令查询，以便查询单车在某 CANID 下所有的数据值，进而让 IoTDB 同时实现长安汽车的主要查询场景：实时车况和历史车况的组合查询。