CN117076426A - 基于流批一体化的交通智能引擎系统构建方法及装置 - Google Patents

Abstract

本申请公开了一种基于流批一体化的交通智能引擎系统构建方法及装置。首先构建各个交通设备的数据链路，通过数据链路把基础交通数据导入到StarRocks数据库中；使用StarRocks的多种数据模型建立用于数据分析的各种数据表；然后通过RoutineLoad方式将分析后的数据导入到目标数据表中，并采用存算分离的方式对目标数据表进行数据存储管理；最后采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警。本发明利用数据流批一体化技术实现数据融合，提高了对交通数据的处理效率。

Description

基于流批一体化的交通智能引擎系统构建方法及装置

技术领域

本发明涉及大数据交通管理技术领域，特别涉及一种基于流批一体化的交通智能引擎系统构建方法及装置。

背景技术

目前，交通行业中的大数据、人工智能、云计算等技术发展已日趋成熟，交通业务也在不断进化。城市交通管理面临着两个重要的问题：一是缺乏高效的数据采集手段和技术手段，无法实现实时、动态和精细化的数据采集，二是缺乏统一的数据分析平台和技术手段，无法支撑各类交通业务应用的建设。

面对上述问题，现有技术如公开号CN116186173A具体通过大数据存储处理框架，实现了大数据的流处理、批处理、融合处理，同时实现了处理数据与处理算法的动态扩充，并结合OLAP、OLTP以及微服务等系统设计思想对整个系统设计进行优化。

然而，现有技术面对与交通数据处理的效率较低，并且不能利用数据流批一体化技术实现数据融合，提炼数据效率较低，实现的数据价值不高，不能满足不同业务侧人员的需求。

发明内容

基于此，本申请实施例提供了一种基于流批一体化的交通智能引擎系统构建方法及装置，能够解决现有技术中所存在的问题。

第一方面，提供了一种基于流批一体化的交通智能引擎系统构建方法，该方法包括：

构建各个交通设备的数据链路，通过数据链路把基础交通数据导入到StarRocks数据库中；其中，具体包括：实时数据与离线数据的导入；

使用StarRocks的多种数据模型建立用于数据分析的各种数据表；其中，所述数据模型至少包括明细模型、聚合模型、更新模型以及主键模型；

通过RoutineLoad方式将分析后的数据导入到目标数据表中；

采用存算分离的方式对目标数据表进行数据存储管理；其中，具体包括：构建统一的存储访问层以进行数据存储、使用磁盘缓存热点数据以及通过预设的数据分布方式进行数据管理；

采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警。

可选地，根据所述数据链路导入交通设备数据，具体包括：

将离线数据定时通过Broker Load方式导入StarRocks；对接不同厂商的消息队列，将实时数据统一采集到kafka中。

可选地，构建各个交通设备的数据链路，通过数据链路把基础交通数据导入到StarRocks数据库中，具体包括：

交通数据为卡口过车数据，将卡口过车数据按照业务需求进行清洗、转换；其中，原始卡口过车数据为结构化json数据，根据json的key和value类型创建对应的表字段。

可选地，根据数据模型对导入的交通数据进行分析，包括：

通过明细模型创建表，建表时定义排序键；其中，排序键为卡口摄像头ID；在查询的过滤条件包含定义的排序键，以快速过滤数据。

可选地，通过RoutineLoad方式将分析后的数据导入到目标数据表中，具体包括：

首先向StarRocks提交一个创建RoutineLoad导入作业的SQL语句；然后StarRocks会自动解析SQL语句，并创建一个常驻的导入作业，持续生成一系列导入任务；最后StarRocks消费kafka集群Topic中的全部或部分分区的消息并导入到StarRocks中的目标数据表。

可选地，通过RoutineLoad方式将分析后的数据导入到目标数据表中，还包括：

在每个导入作业中设置有对应标签；所述标签为用户指定或系统自动生成，用于标识该导入作业。

可选地，采用存算分离的方式对目标数据表进行数据存储管理，包括：

通过兼容AWSS3协议的对象存储系统以及传统数据中心部署的HDFS进行后端存储；其中，将表数据统一存储至对象存储指定的bucket或HDFS目录中，根据类型的不同存储在data/、meta/等子目录下。

可选地，通过预设的数据分布方式进行数据管理，包括：

通过Hash数据分布方式和Range+Hash数据分布方式进行数据管理；其中：在Hash数据分布方式中，一张表为一个分区，分区按照分桶键和分桶数量进一步进行数据划分；在Range+Hash数据分布方式中，一张表拆分成多个分区，每个分区按照分桶键和分桶数量进一步进行数据划分。

可选地，采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警，包括：

使用内置的StarRocksManager或Prometheus+Grafana方案进行监控报警；其中：使用内置的StarRocksManager进行监控报警，具体包括：通过自带的Agent从各个Host采集监控信息，上报至Center Service，然后做可视化展示；通过StarRocksManager提供邮件和Webhook的方式发送报警通知；使用Prometheus+Grafana方案进行监控报警，具体包括：通过直接连接BE或FE的HTTP端口来获取集群的监控信息，Prometheus通过Pull方式访问FE或BE的Metric接口，然后将监控数据存入时序数据库。

第二方面，提供了一种基于流批一体化的交通智能引擎系统构建装置，该装置包括：

数据汇聚模块，用于建立与各个交通设备的数据链路，通过所述数据链路导入交通数据到StarRocks数据库中；其中，具体包括：实时数据与离线数据的导入；

数据建模模块，用于构建多种数据模型，并在数据模型中建立用于进行数据分析的各种数据表；其中，所述数据模型至少包括明细模型、聚合模型、更新模型以及主键模型；

数据集成模块，用于确定常驻的目标数据表，通过RoutineLoad方式将分析后的数据导入到目标数据表中；

数据存储管理模块，用于采用存算分离的方式对目标数据表进行数据存储管理；其中，具体包括构建统一的存储访问层以进行数据存储、使用磁盘缓存热点数据以及通过预设的数据分布方式进行数据管理；

系统监控运维模块，用于采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警。

本申请实施例提供的技术方案中首先建立与各个交通设备的数据链路，通过所述数据链路导入交通数据到StarRocks数据库中；构建多种数据模型，并在数据模型中建立用于进行数据分析的各种数据表；然后确定常驻的目标数据表，通过RoutineLoad协议会将数据导入到目标数据表中；采用存算分离的方式对目标数据表进行数据存储管理；最后采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警。可以看出，本发明的有益效果至少包括：

(1)简洁的分布式架构。通过采用简洁的分布式架构，可以水平扩展以处理大规模数据和高并发查询。将数据分片存储在多个节点上，存算分离，实现了数据的并行处理和查询，提高系统的可扩展性，并降低了成本。

(2)高性能查询。StarRocks由于采用了列式存储、分布式架构和向量化引擎，能够提供优秀的查询性能。它支持多种查询操作，包括聚合、排序、连接和过滤等，适用于复杂的分析查询，并且支持较高的QPS。

(3)灵活的数据模型。支持多维度数据模型，可以方便地进行多维度分析。它支持丰富的数据类型，灵活的数据模型设计，适用于各种数据分析需求。并且支持海量数据场景下的快速更新和删除。

(4)易于使用和管理。提供了易于使用的管理界面和命令行工具，方便用户进行集群的配置、监控和管理。它还支持资源隔离，可以比较方便的定位和解决用户问题。

附图说明

为了更清楚地说明本发明的实施方式或现有技术中的技术方案，下面将对实施方式或现有技术描述中所需要使用的附图作简单地介绍。显而易见地，下面描述中的附图仅仅是示例性的，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图引申获得其它的实施附图。

图1为本申请实施例提供的一种基于流批一体化的交通智能引擎系统构建方法的总体流程图；

图2为本申请实施例提供的数据集成部分流程图；

图3为本申请实施例提供的监控架构图；

图4为本申请实施例提供的一种基于流批一体化的交通智能引擎系统构建装置的框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明晰，以下结合附图及实施例，对本申请进行进一步详细说明。

在本发明的描述中，术语“包括”、“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包括了一系列步骤或单元的过程、方法、系统、产品或设备不必限于已明确列出的那些步骤或单元，而是还可包含虽然并未明确列出的但对于这些过程、方法、产品或设备固有的其它步骤或单元，或者基于本发明构思进一步的优化方案所增加的步骤或单元。

流批一体化是指将数据流处理(Stream Processing)和批量处理(BatchProcessing)结合在一起的一种数据处理方式。传统上，数据处理被分为两个模式：流处理模式和批处理模式。

在流处理模式下，数据是实时到达并立即处理的，无需等待一定的时间窗口。

而在批处理模式下，数据会在收集一段时间后一次性处理掉，常见的例子是每天对一天的销售数据进行统计分析。

流批一体化通过将批处理和流处理结合起来，解决了实时性和准确性之间的矛盾。它可以处理实时数据流，并且可以根据需要对数据进行聚合、过滤、转换等操作，同时也能够处理历史数据进行离线分析。可以应用于各种场景，例如实时监控系统、实时风控系统、实时推荐系统等。它提供了更灵活、高效的数据处理能力，能够满足对实时性要求较高的应用场景。

现有技术面对与交通数据处理的效率较低，并且不能利用数据流批一体化技术实现进行数据融合，提炼数据效率较低，实现的数据价值不高，不能满足不同业务侧人员的需求。并且，现有引擎无法满足对于高QPS场景，复杂度高的查询场景、Join等场景，查询性能不能满足需要；同时交通系统中不同厂商数据各自存储，数据存在分散问题，不同厂商使用技术不同，技术组件较多，所以导致难以维护，难以发展。

基于此，本申请提出了一种基于流批一体化的交通智能引擎系统构建方法解决了上述问题，请参考图1，该方法可以包括以下步骤：

步骤101：构建各个交通设备的数据链路，通过数据链路把基础交通数据导入到StarRocks数据库中。其中，具体包括实时数据与离线数据的导入。在本步骤中具体实现了数据汇聚功能，具体包括了：

打通不同厂商的交通设备数据链路和上下游生态，包括实时、离线数据导入自动化等；建设云原生管控平台，提供高效的运维管理和业务交付能力。

离线数据定时通过Broker Load方式导入StarRocks，实时数据对接不同厂商的消息队列，统一采集到kafka中。

步骤102，使用StarRocks的多种数据模型建立用于数据分析的各种数据表。在本步骤中具体实现了数据建模功能，具体包括了：

本实施例中主要支持四种数据模型，分别是明细模型(Duplicate Key Model)、聚合模型(Aggregate Key Model)、更新模型(Unique Key Model)和主键模型(Primary KeyModel)。这四种数据模型能够支持多种数据分析场景，例如日志分析、数据汇总分析、实时分析等。以下结合数据表设计来具体阐述四种模型的建立过程以及用途：

(1)明细模型(Duplicate Key Model)

建立过程：将每条原始数据作为一个记录，保留所有维度和指标信息。

用途：适用于需要对原始数据进行详细分析的场景，如日志分析、异常检测等。通过明细模型，可以直接查询和分析原始数据，获得更详细和精确的分析结果。

表设计：交通系统数据场景分析数据(交通数据)主要是卡口过车数据，产生的数据是不会变化的，数据都是追加的新数据，没有修改历史数据的情况。基于此，采用明细模型((Duplicate Key Model))进行创建表。创建表时，定义排序键，排序键为卡口摄像头ID。通过定义排序键，在查询的过滤条件包含排序键，能够快速地过滤数据，提高查询效率。

(2)聚合模型(Aggregate KeyModel)

建立过程：对原始数据进行聚合，生成汇总数据。根据业务需求，选择适当的维度和指标进行聚合。

用途：适用于需要进行数据汇总分析的场景，如路段每日在途量统计、趋势分析等。通过聚合模型，可以减少数据量，提高查询效率，同时仍能满足常见的分析需求。

表设计：交通系统数据场景分析数据包括交通指标数据，多为指定维度查询，旧数据更新不频繁，只会追加新的数据。基于此，采用聚合模型(Aggregate Key Model)进行创建表。创建表时，定义排序键，排序键为路段ID。从数据导入至数据查询阶段，聚合模型内部同一排序键的数据会多次聚合。能够减少查询时所需要的处理的数据量，进而提升查询的效率。

(3)更新模型(Unique Key Model)

建立过程：建表时，支持定义主键(如卡口ID、时间等)和指标列，查询时返回主键相同的一组数据中的最新数据。相对于明细模型，更新模型简化了数据导入流程，能够更好地支撑实时和频繁更新的场景。

用途：适用于需要实时分析和实时更新的场景，如卡口过车数据实时趋势统计等。通过更新模型，可以及时获取最新的数据信息，并进行实时分析和决策。

(4)主键模型(Primary KeyModel)

建立过程：根据主键(如卡口ID、路段ID等)将相关数据进行关联和组织，形成具有层次结构的数据模型。

用途：实时对接事务型数据到StarRocks,如路段数据、卡口数据。

表设计：交通系统数据场景分析数据包括路网数据，除了插入数据外，一般还会涉及较多更新和删除数据的操作。基于此，采用主键模型(Primary Key Model)进行创建表。创建表时，定义主键，主键为路段ID。查询时不需要执行聚合操作，保证了查询的高效执行。

步骤103，通过RoutineLoad方式将分析后的数据导入到目标数据表中。在本步骤中具体实现了数据集成功能，如图2，具体包括了：

数据导入将原始卡口过车数据按照业务需求进行清洗、转换、并加载到StarRocks中，从而可以在StarRocks系统中进行极速统一的数据分析。数据导入可以导入多重数据源，如离线的过车数据，实时的消息数据等。通过导入作业实现数据导入。每个导入作业都有一个标签(Label)，由用户指定或系统自动生成，用于标识该导入作业。每个标签在一个数据库内都是唯一的，仅可用于一个成功的导入作业。一个导入作业成功后，其标签不可再用于提交其他导入作业。只有失败的导入作业的标签，才可再用于提交其他导入作业。这一机制可以保证任一标签对应的数据最多被导入一次，即实现“至多一次(At-Most-Once)”语义。

所有导入方式都提供原子性保证，即同一个导入作业内的所有有效数据要么全部生效，要么全部不生效，不会出现仅导入部分数据的情况。这里的有效数据不包括由于类型转换错误等数据质量问题而被过滤掉的数据。

其中，在本申请可选的实施例中，具体包括：

(1)指定目标数据库和表

通过对数据表创建，指定创建后的表；

(2)创建常驻的导入作业SQL

通过RoutineLoad方式将kafka数据流不间断地导入至StarRocks，首先向StarRocks提交一个创建RoutineLoad导入作业的SQL语句。然后StarRocks会自动解析SQL语句，并创建一个常驻的导入作业，持续生成一系列导入任务，最后StarRocks消费kafka集群Topic中的全部或部分分区的消息并导入到StarRocks中的目标数据表。

(3)执行导入作业的SQL

可以将来自Kafka消息队列中的数据导入到名为traffic_db的数据库中的traffic_cars表中。具体地，在traffic_db数据库中的traffic_cars表中创建一个RoutineLoad任务，该任务会从指定的Kafka消息队列中消费数据，并按照指定的列和分隔符将数据加载到traffic_cars表中。并指定如并发加载任务数、Kafka broker列表、Kafka主题、Kafka分区列表等属性，以控制导入过程的行为和配置。在导入过程中，会选择性地导入指定的数据列，并通过表达式计算生成一个名为pay_dt的列。并指定了如并发加载任务数、数据格式为JSON、JSON中各字段的路径等属性。综上，向StarRocks提交一个Routine Load导入作业traffic，持续消费Kafka集群中topic名称为traffic_data的消息，并导入至数据库traffic_db的表traffic_cars中。并且导入作业会从该Topic所指定分区的最早位点(Offset)开始消费。

步骤104，采用存算分离的方式对目标数据表进行数据存储管理。其中，具体包括构建统一的存储访问层以进行数据存储、使用磁盘缓存热点数据以及通过预设的数据分布方式进行数据管理。在本步骤中具体实现了数据存储管理功能，具体地：

数据存储采用存算分离的技术方案，核心在于将存储与计算解耦，计算节点无状态，实现快速扩缩容。而且，对象存储通常具备更好的数据可靠性和更低的成本，同时数据存储使用列式存储，采用分区分桶机制进行数据管理。

(1)存储

构建统一的存储访问层，屏蔽了后端不同存储系统的差异。基于该统一存储访问层，本系统可以在轻松地支持新的存储系统的同时保持对上层应用的透明。支持多种主流存储系统，包括兼容的对象存储系统(如OSS、MinIO)以及HDFS等。目前，本系统存算分离技术支持两种后端存储方式：兼容AWSS3协议的对象存储系统(主流对象存储均支持)以及传统数据中心部署的HDFS。该技术将表数据统一存储至对象存储指定的bucket或HDFS目录中，根据类型的不同存储在data/、meta/等子目录下。在上述步骤二数据建模模块可以指定存储系统，或者用内部存储系统。

(2)缓存

为了解决性能的影响，使用磁盘(LocalDisk)来缓存热点数据。用户可以选择在建表时打开热数据缓存并同时指定热数据的生命周期，从数据写入开始到生命周期结束，热数据会一直缓存在本地磁盘中，以提升查询效率。

(3)数据管理

支持如下两种数据分布方式：

Hash数据分布方式：一张表为一个分区，分区按照分桶键和分桶数量进一步进行数据划分。主要作用是将一张表按照分区键拆分成不同的管理单元，针对每一个管理单元选择相应的存储策略，比如副本数、分桶数、冷热策略和存储介质等。支持在一个集群内使用多种存储介质，可以将新数据所在分区放在SSD盘上，利用SSD优秀的随机读写性能来提高查询性能，将旧数据存放在SATA盘上，以节省数据存储的成本。

Range+Hash数据分布方式：一张表拆分成多个分区，每个分区按照分桶键和分桶数量进一步进行数据划分。在同一分区内，分桶键哈希值相同的数据形成Tablet，Tablet以多副本冗余的形式存储，是数据均衡和恢复的最小单位。Tablet的副本由一个单独的本地存储引擎管理，数据导入和查询最终都下沉到所涉及的Tablet副本上。

步骤105，采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警。在本步骤中具体实现了系统监控运维功能，具体提供两种监控报警的方案：

(1)使用内置的StarRocksManager，如图3所示，其自带的Agent从各个Host采集监控信息，上报至Center Service，然后做可视化展示。StarRocksManager提供邮件和Webhook的方式发送报警通知。StarRocksManager的监控可以分成集群和节点两个维度。

(2)提供Prometheus+Grafana方案架构图如图3所示，StarRocks提供了兼容Prometheus的信息采集接口，可以通过直接连接BE或FE的HTTP端口来获取集群的监控信息，Prometheus通过Pull方式访问FE或BE的Metric接口，然后将监控数据存入时序数据库。用户可以通过Grafana配置Prometheus为数据源，自定义绘制Dashboard。

如图4，本申请实施例还提供的一种基于流批一体化的交通智能引擎系统构建装置，该装置包括：

数据汇聚模块，用于建立与各个交通设备的数据链路，通过所述数据链路把交通数据导入到StarRocks数据库中；其中，具体包括：

实时数据与离线数据的导入；

数据建模模块，用于构建多种数据模型，并在数据模型中建立用于进行数据分析的各种数据表；其中，所述数据模型至少包括明细模型、聚合模型、更新模型以及主键模型；

数据集成模块，用于确定常驻的目标数据表，通过RoutineLoad方式将分析后的数据导入到目标数据表中；

数据存储管理模块，用于采用存算分离的方式对目标数据表进行数据存储管理；其中，具体包括：构建统一的存储访问层以进行数据存储、使用磁盘缓存热点数据以及通过预设的数据分布方式进行数据管理；

系统监控运维模块，用于采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警。

本申请实施例提供的基于流批一体化的交通智能引擎系统构建装置用于实现上述基于流批一体化的交通智能引擎系统构建方法，关于基于流批一体化的交通智能引擎系统构建装置的具体限定可以参见上文中对于基于流批一体化的交通智能引擎系统构建方法的限定，在此不再赘述。上述基于流批一体化的交通智能引擎系统构建装置中的各个部分可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于设备中的处理器中，也可以以软件形式存储于设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于流批一体化的交通智能引擎系统构建方法，其特征在于，方法包括：

构建各个交通设备的数据链路，通过数据链路把基础交通数据导入到StarRocks数据库中；其中，具体包括实时数据与离线数据的导入；

使用StarRocks的多种数据模型建立用于数据分析的各种数据表；其中，所述数据模型至少包括明细模型、聚合模型、更新模型以及主键模型；

通过RoutineLoad方式将分析后的数据导入到目标数据表中；

采用存算分离的方式对目标数据表进行数据存储管理；其中，具体包括构建统一的存储访问层以进行数据存储、使用磁盘缓存热点数据以及通过预设的数据分布方式进行数据管理；

采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警。

2.根据权利要求1所述的交通智能引擎系统构建方法，其特征在于，根据所述数据链路导入交通设备数据，具体包括：

将离线数据定时通过Broker Load方式导入StarRocks；对接不同厂商的消息队列，将实时数据统一采集到kafka中。

3.根据权利要求1所述的交通智能引擎系统构建方法，其特征在于，构建各个交通设备的数据链路，通过数据链路把基础交通数据导入到StarRocks数据库中，具体包括：

交通数据为卡口过车数据，将卡口过车数据按照业务需求进行清洗、转换；其中，原始卡口过车数据为结构化json数据，根据json的key和value类型创建对应的表字段。

4.根据权利要求1所述的交通智能引擎系统构建方法，其特征在于，根据数据模型对导入的交通数据进行分析，包括：

通过明细模型创建表，建表时定义排序键；其中，排序键为卡口摄像头ID；在查询的过滤条件包含定义的排序键，以快速过滤数据。

5.根据权利要求1所述的交通智能引擎系统构建方法，其特征在于，通过RoutineLoad方式将分析后的数据导入到目标数据表中，具体包括：

首先向StarRocks提交一个创建RoutineLoad导入作业的SQL语句；然后StarRocks会自动解析SQL语句，并创建一个常驻的导入作业，持续生成一系列导入任务；最后StarRocks消费kafka集群Topic中的全部或部分分区的消息并导入到StarRocks中的目标数据表。

6.根据权利要求1所述的交通智能引擎系统构建方法，其特征在于，通过RoutineLoad方式将分析后的数据导入到目标数据表中，还包括：

在每个导入作业中设置有对应标签；所述标签为用户指定或系统自动生成，用于标识该导入作业。

7.根据权利要求1所述的交通智能引擎系统构建方法，其特征在于，采用存算分离的方式对目标数据表进行数据存储管理，包括：

通过兼容AWSS3协议的对象存储系统以及传统数据中心部署的HDFS进行后端存储；其中，将表数据统一存储至对象存储指定的bucket或HDFS目录中，根据类型的不同存储在data/、meta/等子目录下。

8.根据权利要求1所述的交通智能引擎系统构建方法，其特征在于，通过预设的数据分布方式进行数据管理，包括：

通过Hash数据分布方式和Range+Hash数据分布方式进行数据管理；其中：在Hash数据分布方式中，一张表为一个分区，分区按照分桶键和分桶数量进一步进行数据划分；在Range+Hash数据分布方式中，一张表拆分成多个分区，每个分区按照分桶键和分桶数量进一步进行数据划分。

9.根据权利要求1所述的交通智能引擎系统构建方法，其特征在于，采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警，包括：

使用内置的StarRocksManager或Prometheus+Grafana方案进行监控报警；其中：使用内置的StarRocksManager进行监控报警，具体包括：通过自带的Agent从各个Host采集监控信息，上报至Center Service，然后做可视化展示；通过StarRocksManager提供邮件和Webhook的方式发送报警通知；使用Prometheus+Grafana方案进行监控报警，具体包括：通过直接连接BE或FE的HTTP端口来获取集群的监控信息，Prometheus通过Pull方式访问FE或BE的Metric接口，然后将监控数据存入时序数据库。

10.一种基于流批一体化的交通智能引擎系统构建装置，其特征在于，所述装置包括：

数据汇聚模块，用于建立与各个交通设备的数据链路，通过所述数据链路把交通数据导入到StarRocks数据库中；其中，具体包括：实时数据与离线数据的导入；

数据建模模块，用于构建多种数据模型，并在数据模型中建立用于进行数据分析的各种数据表；其中，所述数据模型至少包括明细模型、聚合模型、更新模型以及主键模型；

数据集成模块，用于确定常驻的目标数据表，通过RoutineLoad方式将分析后的数据导入到目标数据表中；

数据存储管理模块，用于采用存算分离的方式对目标数据表进行数据存储管理；其中，具体包括：构建统一的存储访问层以进行数据存储、使用磁盘缓存热点数据以及通过预设的数据分布方式进行数据管理；

系统监控运维模块，用于采用预设的监控报警方案对数据存储管理后的目标数据表进行监控报警。