This topic explains how to build a vehicle metadata management platform using a device management platform and Tablestore. It uses an Internet of Vehicles (IoV) scenario to describe the requirements and architecture of the solution.
Scenario requirements
Vehicles regularly report large amounts of status data while in motion, such as the Vehicle Identification Number (VIN), driving speed, engine speed, and interior temperature. You can use this information for business needs such as behavior analysis, driving status monitoring, trajectory analysis, and vehicle status retrieval.
Persistently storing and analyzing vehicle metadata allows for complex business applications. For example, you can count the number of vehicles in an area to determine road congestion. You can also monitor real-time changes in the latest data, such as vehicle speed and engine speed, to detect abnormal vehicle behavior or status. The requirements for vehicle metadata storage and analysis in an IoV scenario are as follows:
-
Data storage: Vehicle metadata is regularly reported to a data gateway and forwarded to downstream storage. The solution must support large-scale data storage.
-
Data updates: Massive amounts of vehicle metadata are updated frequently. The solution must support high-concurrency, real-time data updates.
-
Data retrieval: Vehicles can be retrieved based on their parameters. For example, you can query the current status of a car by its VIN. The solution must support combined searches using any vehicle parameters.
-
Real-time monitoring: Vehicle status changes can be monitored in real time. For example, you can save abnormal driving logs for later investigation. The solution must support real-time detection of data changes and real-time computing on updated data.
Vehicle metadata includes inherent properties, such as the VIN, vehicle color, and engine model. It also includes the latest status data, such as the current GPS coordinates, current engine speed, and current vehicle speed.
Sample scenario
Assume a car manufacturer manages 10 million smart cars. The manufacturer needs to ingest vehicle information into the cloud and use a cloud-based architecture to build a vehicle management platform. This platform must support business requirements such as status reporting, status retrieval, vehicle retrieval, and vehicle monitoring.
Solution implementation
-
The implementation process for the sample scenario is as follows:
-
Smart car status data is ingested into the device management platform through the Message Queuing Telemetry Transport (MQTT) protocol.
-
The device management platform connects to Tablestore to store the data in a wide table model. For more information, see Introduction to the wide table model.
-
Tablestore data tables are used to store, update, and query vehicle metadata. For information about the schema design for the wide table model, see Wide table model design.
-
Search indexes are used for vehicle retrieval and selection. For more information, see Introduction to search index.
-
SQL queries are used for vehicle retrieval and analysis. For more information, see SQL query.
-
Tunnel Service enables connections with Flink for real-time computing. For more information, see Tunnel Service.
-
-
Flink integrates with Tablestore to perform real-time data analysis. The computation results are then written back to Tablestore. For more information, see Flink tutorials.
Flink is mainly used to run stream computing jobs on device metadata or to connect to message queues such as Kafka to subscribe to messages.
-
-
The following figure shows the architecture for the sample scenario.
Solution advantages
-
Automatic data partitioning and load balancing.
-
A storage-compute disaggregation architecture that supports dynamic and seamless horizontal scaling.
-
Elastic scalability for a single table to trillions of rows, 10 PB of storage, and tens of millions of queries per second (QPS).