车联网多种应用场景
现代新能源汽车，作为一种内部系统极为复杂的交通工具，配备了大量传感器、导航设备、应用软件，这些传感器产生的数据都需要上报到车联网平台当中。对于这些车辆的状态数据（如车速、发动机转速等）、位置数据（经纬度等）以及用户行为数据，车联网平台需要对它们进行实时/离线计算分析，从而为用户提升驾驶体验，提供安全保障，为厂商提供质量检测、功能优化，为交通管理部门提供流量、违章监测、甚至为城市规划提供帮助。
因此，同样是车联网平台，对于车队管理，政府监督，主机厂商等不同场景，由于应用侧重点的不同，它们所需要接入的数据的类型，量级，频率也各不相同。
对于主机厂商来说，它的车联网平台服务的对象更为广泛，包括车主、经销商、售后服务部门以及主机厂自身的研发、生产等部门。由于目标是提升车辆的用户体验、增强品牌竞争力，因此主机厂商需要采集的数据量是最大也是最完整的。一辆汽车可能有数千个数据采集点甚至近万个采集点要随时上报数据，采集频率也各不相同。
性能和易用性难以兼得
以上原因，就导致了在同一时刻一定不会是所有的数据采集点都有数据上报。在数据库的建模环节中，如果采用最简单清晰的“一车对一表”数据建模方式，那么在一行高达几千列的数据中，会有相当多列的值为 NULL 。更主要的是，即使业务查询只涉及其中少数几列，在实际执行的时候也要整行整块地读取很多无效数据再做筛选，从而大大拖累查询性能。
但如果按照设备种类对这个表进行纵向的拆分，当涉及到统计分析的时候，必将又会导致原来的 SQL 语句引入大量的插值、连接等功能，这会使 SQL 的编写十分复杂，容易出错，难以维护，且难以适应业务的频繁变化。
一车一表模型，助力数据管理
为了解决这一难题，TDengine 结合自身底层的存储/查询模型，以创新的设计，将复杂 SQL 封装起来，这样一来，用户侧可以在没有任何感知的情况下编写 SQL 语句访问数据，既防止了大量无效数据导致的查询性能下降，又确保了 SQL 语句的简洁易懂、易维护、可扩展，从而在用户侧实现了：“一车一表的简洁建模设计”。 在性能方面，TDengine 利用每个数据流都是天然有时序的这一特点，把数据的写入变成最简单的追加操作。做到了在相同硬件资源下，单个数据流上最好的写入效率。在此基础上，TDengine 又使用分布式架构，让所有的 cpu 并行工作，甚至可以同时写入十亿百亿级别点位的数据流。
读取方面同理：由于车辆各个设备产生的时序数据在硬盘上都是连续存储。因此，批量拉取时便也均为连续读，有充分的性能保障，再辅以流计算、订阅、自定义函数（UDF）、各种时序数据场景的专用函数，共同为车联网平台各种实时/离线分析提供坚实的底座。
在此基础上，为了防止硬盘成为性能瓶颈，TDengine 可以为不同的存储路径，同时挂载不同的硬盘并发读写。
综上可见，TDengine 充分利用了计算机的最大能力，也充分适配了车联网行业数据上报量大，数据采集点多的特点。
支持 Geometry 类型，赋能空间分析
自 3.1.0.0 版本开始，TDengine 提供了全新的数据类型 Geometry 用于点线面等几何类型的存储，并且正在逐步提供一套符合 OGC(Open Geospatial Consortium) 标准的 SQL 函数，包括几何输入输出、空间关系、几何测量、集合操作和几何处理等等。 这样一来，各类车联网平台就可以更轻松地进行车辆轨迹数据的分析，比如：热点路线，轨迹段数据，停留点，行驶事件等等，从而进一步简化软件系统架构，真正做到针对车辆时间空间一体化的数据分析、预警等工作。
多级存储，降低数据成本
在存储方面，由于车联网行业监管法规、客户服务需求、自身产研基于数据的需求等原因，每辆车的数据保留数据经常要保留数年之久，因此存储成本十分之高。但得益于 TDengine 多级存储功能，可以使得最热的数据保留在内存，次热的数据保留在SSD，冷数据保留在机械盘，极冷数据保留在成本最低廉的 S3 存储上，再辅以列式存储+定制化压缩算法带来的高压缩比，用户的存储成本可以大幅下降。
由上可见，在对海量车联网数据的采集、存储、处理分发的整个数据管理过程中，TDengine 可以确保车辆上传的各种数据都能作为有效的资源而被高效地运用。作为一台巨大复杂的设备，新能源汽车彻底放大了 TDengine 的核心设计“一个设备一张表，一类设备一张超级表”的核心理念，因此可以说它们是天作之合。
