随着万物互联时代的到来，智能互联化成为不可逆转的趋势，生活中常用的物品都在逐渐联网化，例如洗衣机、电视、智能家居等，通过联网可以用手机控制，甚至于智能穿戴设备，如衣服、眼镜、鞋都有逐渐联网的趋势。存在了百年之久的汽车行业，也在物联网时代焕发出新生。下图是一个典型的车联网系统，在这个系统中，主要有三类参与方，他们在面对物联网时代的海量数据处理时都存在不同的痛点。
第一类是车载信息服务提供商（TSP），TSP目前在车联网产业链中处于一个非常核心的地位，这一方参与者除了奔驰宝马一类的整车厂商和第三方技术提供商，全球知名高科技企业如苹果、微软等也在积极进入这个领域。这类厂商往往有大量的数据需要从车辆回传到后端平台去做存档或者车辆的诊断。在新能源汽车国标（ GB/T 32960）里，强制要求新能源汽车存储近期车辆数据以便进行事故的回溯，精度甚至要求1s回传一帧数据。有一些大型车厂商，车辆保有量可能超过100万辆，每秒上报一次数据的话，数据库入库的TPS就有100万/秒。这种大吞吐的写入，大部分传统数据库是无法支撑住的。另外，一些TSP还会提供一些与车辆轨迹相关的增值服务，比如电子围栏，当车辆行驶出用户设定的围栏时自动报警，这些需求，都需要一个能够高效处理轨迹时空查询的数据库。
第二类是自动驾驶厂商，自动驾驶是目前最炙手可热的领域，新兴的自动驾驶公司也如雨后春笋般冒出。这类厂商不仅要面对海量数据收集的问题，还面临着大量非结构化数据处理的挑战。他们往往要从测试车上采集大量的音频，视频和雷达数据来做AI训练，可能一个包传上来就几十MB，甚至几百MB，那么传统的数据库中，大KV的处理是非常低效的。同时，在AI领域，数据处理的链路会非常长。首先他们要把原始数据入库，然后要把数据读取出来进行模型训练，然后训练后的标注数据又要写入数据库，所以这里有高速点查的需求，又有高吞吐并发读写的需求，还有分布式分析，跑AI模型的需求，使用传统数据库和大数据架构的话，会引入非常多的组件，运维成本非常大的。
第三类参与方是平台管理方，如政府的车辆监管平台，城市道路监控和路网信息维护，这类用户会管理一个地域所有的车辆或者路网信息，面对海量信息上报，而往往这些数据只会归档存储，数据价值密度非常低。因此，存储成本以及快速进行BI分析产生报表来指导政府决策成为主要压力。
通过车联网三类参与方的介绍，我们看到海量数据处理使车联网企业面临了前所未有的挑战，非结构化数据如音视频，半结构化数据如打包在JSON里上千种车机数据以及结构化关系型数据的混合处理让传统数据库力不从心。结构化、半结构化、非结构化等多种数据往往需要用户引入大量数据库组件从而带来复杂的数据链路管理。
面对种种挑战，很多汽车行业用户都选择了阿里云Lindorm云原生多模数据库。Lindorm是阿里云自研的一款适用于任何规模、多种模型的云原生数据库服务，支持海量数据的低成本存储处理和弹性按需付费，提供宽表、时序、搜索、文件等多种数据模型，是阿里巴巴核心业务提供关键支撑的数据库之一。
目前，在使用Lindorm的车联网用户涵盖了国内外客/货车厂商、主流汽车品牌、造车新势力、各类自动驾驶的初创企业，以及各级政府的车辆管理平台，路网信息平台等等。Lindorm不仅解决了用户的挑战，还与用户共同进步。其中Lindorm助力上海市新能源汽车数据平台的案例，还在今年被IDC评选为“可持续发展特别奖”。
万物互联时代，为什么Lindorm成为了大多数车联网行业用户的一致选择，现在，就来带大家看下Lindorm的出众之处。
Lindorm是基于LSM-Tree存储结构的NoSQL数据库，本身适合存储灵活schema和列稀疏的数据。加上LIndorm基于开源ZSTD压缩算法进行了深入优化，因此Lindorm具有超高的数据压缩比。我们选取了NGSIM数据集（Next Generation Simulation，是由美国联邦公路局发起的一项数据采集项目，被交通界学者广泛用于车辆跟驰换道等驾驶行为研究，交通流分析，微观交通模型构建，车辆运动轨迹预测），存入了Lindorm，HBase，MySQL和MongoDB中，通过对比，我们看到，Lindorm的压缩比基本上是HBase，MySQL和MongoDB的2到3倍。也就是说，车联网的海量数据存储到Lindorm中，立刻就可以收获成倍的成本节省。
除了Lindorm的超高压缩比之外，Lindorm还支持透明的冷热分离技术，像车联网中存储的轨迹数据，如果超过一段时间后查询量变少，或者是其他归档数据，Lindorm可以支持自动将数据归档到冷存储中去，因此能大幅缩减成本。
车联网、共享出行、智慧物流等领域的快速发展产生了大量的时空轨迹数据。这些数据源源不断的产生，要求存储系统具备较高的写入能力、可扩展能力以及较低的存储成本。同时针对这些轨迹数据又产生了各类时空查询，比如根据车辆轨迹计算行驶距离，判断车辆是否驶出电子围栏，根据历史轨迹做数据挖掘等等
一直以来，各类NoSQL数据库对时空数据的高并发写入、在线查询等支持并不完善，每个NoSQL数据库基本上只能用于某种特定场景。比如：基于Hadoop平台的方案一般会在UDF层提供时空算子，但缺少时空索引，无法将时空算子下推到存储层，基本上只能用作离线查询；Apache Sedona（原GeoSpark）内置了时空索引，但一般用于时空数据挖掘等场景，不适合实时在线查询；MongoDB内置了2dsphere空间索引，但由于写入速度、扩展性的瓶颈，普遍只将其用作LBS等场景；GeoMesa作为一款中间件，可以借助HBase等存储具备较高的写入能力，而且支持空间填充曲线作为时空索引，但不支持二级索引，当客户从多维度查询时需要建立多张表，数据存在冗余，存储成本非常高。
而Lindorm内置了达摩院空天数据库引擎Ganos，可以一站式的解决海量轨迹场景的存储和各类查询需求，弥补了各类NoSQL在时空方面的不足。在Lindorm中，可以使用SQL语法非常便捷地处理各类时空查询场景，在查询性能上，要大幅领先业界已有系统2~3倍。详细的评测大家可以参考这篇文章《轨迹数据处理“小钢炮”，Lindorm时空引擎Ganos实测》。
车联网场景中，经常会遇到大对象数据的处理，如传感器打包数据，rosbag数据，音视频文件等等，这些数据从几十KB到数GB不等。传统数据库很难处理这些大对象。因此很多公司都是把大对象的元数据存储在数据库中，把对象本身上传到OSS/S3等对象存储上，这种分散的管理方式给用户带来了过高的运维和开发成本。而在Lindorm数据库中，内置了Blob类型。Blob类型的数据会直接存储在Lindorm底层的文件系统中，并由ChuckStore来进行管理，这种Key-Value分离的存储方式，避免了传统数据库存储大KV数据库时产生的读写放大问题，并且Lindorm底层的ChunkStore支持流式传输大KV数据，也避免了OOM。所以在Lindorm中，使用SQL就可以轻松存储数GB的大对象数据。
车联网中的数据一般都会有“有效期”这一概念，如收集的车辆传感器数据，轨迹数据等，等到一定的时间之后，这些数据就不再需要存储，需要从数据库中删除这些过期的数据。在传统数据库中，往往需要用户来手动删除这些数据。比如写一个定时的脚本，定期从数据库中删除过期数据。这样增加了运维的复杂度，而删数据这个操作，本身也会对数据库造成过大的压力。而Lindorm支持数据的全生命周期管理。Lindorm里支持不同等级的TTL（Time-To-Live）设置，自动管理数据的过期。比如在表上设置数据过期时间为7天，那么7天前写入的数据将自动被删除，无需用户管理，大大降低了运维成本。
在车联网系统中，每辆车每秒产生的传感器数据有上千种，这些数据明细都会通过网关最终写入到数据库中，而在用户的数据平台上，不同的业务会去通过不同传感器数据范围，比如速度值，发动机温度值，环境湿度值等等去圈选指定的车辆，查询条件多达数百种！这在传统数据库中通过二级索引显然是无法实现的，而用户通过在Lindorm的搜索引擎中建立了多达300多个索引，非常轻松地满足了这个客户的查询需求！关于Lindorm的搜索索引，可以参考《深度解析Lindorm全文索引(SearchIndex)特性》一文。
JSON类型也是今年Lindorm推出的新能力，给车辆网这种存在大量半结构化数据的场景带来了极大的便利。用户使用JSON，可以实现整存零取，部分更新，甚至支持给JSON的部分列建立二级索引，搜索索引。由于JSON是目前车联网数据处理的事实标准，很多车企的车辆位置信息汇报都是直接都是用JSON上传，Lindorm支持了JSON后，用户无需对原始数据进行处理，我们可以直接利用JSON内的经纬度坐标直接建立Ganos时空索引，实现时空查询。关于JSON的使用，可以参考阿里云使用文档。
在今年的云栖大会上，我们还公布了Lindorm的高维向量检索能力，以及以图搜图的落地案例。用户可以将图片经过AI引擎分析过的特征向量数据存储在Lindorm中，在查询过程中，用户可以通过Lindorm新推出的向量引擎，快速地检索出特征匹配的图片。相对于传统多个数据库组合的图片检索方案，Lindorm通过多模引擎的融合，能够一站式地满足用户的需求。
在Lindorm中，这些功能并不是分散在各个子模块或者独立的引擎中，我们用SQL统一了多模的使用体验。用户只需要在Lindorm中建立一张宽表，通过指定不同列的类型，即可完成对多模数据的写入，查询和检索。极大地简化了用户的使用体验。
如在下图的例子中，在一张表里就使用了Lindorm中的JSON，Blob，时空引擎等多种能力。
CREATE TABLE vehicle_data (
vehicle_id VARCHAR,
vtime BIGINT,
vender VARCHAR,
vevent JSON,
vloc GEOMETRY(POINT),
blf_data BLOB,
PRIMARY KEY (vehicle_id, vtime)
) WITH (NUMREGIONS='256');
Lindorm是阿里云面向物联网、互联网、车联网等设计和优化的云原生多模超融合数据库，在阿里内部已经服务了长达十年之久，其有着高吞吐、低成本，多模数据融合处理的能力。Lindorm在以下几个方面上具有鲜明的特征：
Lindorm的自研压缩算法和透明冷热分离能力能够给用户带来数倍的存储成本节省
Lindorm内置的JSON，Geo时空类型，Blob大对象存储，搜索索引等丰富的数据类型和功能，能够让用户轻松应对各种业务场景，达到事半功倍的效果
Lindorm多模融合的架构，用户不需要再管理多套数据库，全托管的云服务可以让用户专注用户业务本身，多级TTL管理实现了数据生命周期全管理，无需运维介入。
在Lindorm上，可以非常快速地实现车辆轨迹分析，以图搜图，传感器数据存储和查询等车辆行业常见数据业务，用户可以利用Lindorm轻松实现一站式的车联网数据平台。
这也是为什么Lindorm目前越来越得到广大汽车行业用户的青睐，成为了汽车行业数据平台一致选择的原因。欢迎广大汽车行业用户前来试用Lindorm，Lindorm官网地址：https://www.aliyun.com/product/apsaradb/lindorm
原文始发于微信公众号（IoT物联网技术）：为什么 Lindorm 成为了 IoT 物联网企业的一致选择？
评论