本发明涉及车辆通信领域，特别是涉及一种车辆数据管理系统。
背景技术：
：：目前，整车厂oem(originalequipmentmanufacturer，原始设备制造商)注重车辆自身的研发和换代升级，不擅长车外系统的研发，更不了解云计算。同时，市面上的互联网公司，虽然可能有大数据分析处理方案，但对于智能网联汽车这个“新生事物”，缺乏行之有效的数据采集方案(整车厂oem不会轻易把车辆大数据释放出来)，并且数据格式、通信接口等都是保密的。此外，智能驾驶领域是当前最新、最热的研究领域之一，要分析什么业务场景、要采集哪些车辆数据，尚没有统一标准，而且基于云计算平台，对于车辆大数据的处理和统计分析流程，也没有统一标准。技术实现要素：本发明的一个目的是提供一种能够自动将车辆自动驾驶产生的数据进行分类并存储的车辆数据管理系统。本发明的另一个目的是降低人工操作和执行成本。本发明提供了一种车辆数据管理系统，其特征在于，包括原始数据源模块、数据加工模块和工作流调度编排监控模块；所述原始数据源模块包括数据接收单元、临时存储单元和正式存储单元，所述数据接收单元用于通过云服务平台获取多个车辆的原始总线数据，并将所述原始总线数据存入所述临时存储单元；所述工作流调度编排监控模块用于生成第一控制指令并发送至所述数据加工单元；所述数据加工模块用于根据所述第一控制指令加载所述临时存储单元内的所述原始总线数据并对其进行加载、分类和归档处理，并将处理后的所述原始总线数据存入所述正式存储单元。可选地，所述第一控制指令根据所述数据加工模块的工作状态生成，包括第一加载周期信息。可选地，车辆数据管理系统还包括：系统管理员gui/cli客户端应用模块，用于通过浏览器gui界面或者cli命令行界面访问和操作所述工作流调度编排监控模块，以控制所述工作流调度编排监控模块生成所述第一控制指令。可选地，车辆数据管理系统还包括：数据仓库模块，包括数据仓库；所述工作流调度编排监控模块还用于生成第二控制指令并发送至所述数据加工单元；所述数据加工模块还用于根据所述第二控制指令提取所述原始数据源模块的所述正式存储单元的数据并对其进行过滤、清洗和降噪处理，并将处理后的数据发送至所述数据仓库，以在所述数量仓库内形成事实表和维度表。可选地，车辆数据管理系统还包括：远程监控数据源模块，用于获取并存储所述多个车辆的行车状态数据；所述工作流调度编排监控模块还用于生成第三控制指令并发送至所述数据加工单元；所述数据加工模块还用于根据所述第三控制指令提取所述远程监控数据源模块中的数据并对其进行过滤、清洗和降噪处理，并将处理后的数据发送至所述数据仓库，以在所述数量仓库内形成业务表。可选地，所述行车状态数据包括：行车异常检测数据、故障诊断数据、车辆出行数据、驾驶员安全评分数据。可选地，车辆数据管理系统还包括：云-应用数据交互模块，与所述远程监控数据源模块数据连接，用于提取并存储所述远程监控数据源模块内的维度数据；和历史业务视图模块；所述数据仓库模块还包括处理引擎；所述工作流调度编排监控模块还用于生成第四控制指令并发送至所述处理引擎；所述处理引擎用于根据所述第四控制指令提取并联机分析处理所述云-应用数据交互模块中的数据和所述数据仓库内的所述事实表和维度表，并将处理后的数据存储至所述历史业务视图模块内。可选地，车辆数据管理系统还包括实时数据分析模块、实时业务视图模块、汇聚处理服务模块和业务服务视图模块：所述实时数据分析模块用于通过云服务平台获取所述多个车辆的原始总线数据并进行实时分析，将实时分析后的数据实时存入所述实时业务视图模块；所述工作流调度编排监控模块还用于生成第五控制指令并发送至所述汇聚处理服务模块；所述汇聚处理服务模块用于根据所述第五控制指令提取并联机分析处理所述实时业务视图模块和所述历史业务视图模块内的数据，并将处理后的数据保存至所述业务服务视图模块内。可选地，车辆数据管理系统还包括：互联网高并发客户端应用模块，与所述云-应用数据交互模块通信连接；所述云-应用数据交互模块还用于接收所述实时业务视图模块、所述历史业务视图模块和所述业务服务视图模块的数据并发送至所述互联网高并发客户端应用模块。可选地，车辆数据管理系统还包括：数仓元数据管理模块，用于存储所述多个车辆的元数据并建立所述元数据的内表和外表，所述内表的数据存储至所述数据仓库指向的路径，所述内表记录数据所在的路径。本发明通过原始数据源模块、数据加工模块和工作流调度编排监控模块实现了一种车辆大数据统计分析平台的大数据存储方法。该系统支持海量车载can总线大数据的存储和预处理，即分类和归档处理，为后续的车辆历史can总线大数据的离线分析提供了数据基础服务保障。通过工作流调度编排监控模块自动化地完成车辆can总线大数据从临时存储单元到正式存储单元的数据逻辑计算和数据转移，自动将车辆自动驾驶产生的数据进行分类并存储。进一步地，在aws公有云环境中，通过分布式工作流引擎进行服务编排，完成车辆大数据仓库的建立、自动化etl和olap分析全过程，系统管理员更多的是通过可视化界面监控各项数据处理任务的完成情况，从而使人工操作和执行成本降至最低。本发明通过amazon的7层负载均衡器集群、airflowonamazonec2工作流引擎、livy监控服务插件、sparkonamazonemr并行计算框架、hiveonamazonemr大数据仓库、amazons3简单存储服务桶、prestoonamazonemr的olap查询分析引擎、amazon托管的关系型数据库mysql集成联动，实现了一套智能网联汽车大数据分类存储方案，包括数据仓库建表，车辆大数据从amazons3到amazonemrhive的etl处理，以及车辆大数据从hive数据仓库被olap处理后保存到amazon托管数据库服务rdb(mysql)历史业务视图的整个数据处理、工作流任务编排、数据处理任务调度监控全过程，为后续的分析、检索和可视化提供技术和数据服务保障。附图说明后文将参照附图以示例性而非限制性的方式详细描述本发明的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。附图中：图1是根据本发明一个实施例的车辆数据管理系统的原理框图；图2是根据本发明另一个实施例的车辆数据管理系统的原理框图。具体实施方式图1是根据本发明一个实施例的车辆数据管理系统的原理框图。如图1所示，本发明提供了一种车辆数据管理系统，其一般性地可以包括原始数据源模块10、数据加工模块20和工作流调度编排监控模块30。原始数据源模块10包括数据接收单元、临时存储单元和正式存储单元，数据接收单元用于通过云服务平台获取多个车辆的原始总线数据，并将原始总线数据存入临时存储单元。工作流调度编排监控模块30用于生成第一控制指令并发送至数据加工单元。数据加工模块20用于根据第一控制指令加载临时存储单元内的原始总线数据并对其进行加载、分类和归档处理，并将处理后的原始总线数据存入正式存储单元。本实施例通过原始数据源模块10、数据加工模块20和工作流调度编排监控模块30实现了一种车辆大数据统计分析平台的大数据存储方法。该系统支持海量车载can总线大数据的存储和预处理，即分类和归档处理，为后续的车辆历史can总线大数据的离线分析提供了数据基础服务保障。通过工作流调度编排监控模块30自动化地完成车辆can总线大数据从临时存储单元到正式存储单元的数据逻辑计算和数据转移。一个实施例中，第一控制指令根据数据加工模块20的工作状态生成，包括第一加载周期信息。即按第一加载周期去触发数据加工模块20对临时存储单元内的数据进行分类和归档处理。图2是根据本发明另一个实施例的车辆数据管理系统的原理框图。如图2所示，可选地，云服务平台为aws车联网核心服务域201，其设有规则引擎。原始数据源模块10的数据接收单元为kinesisdatastream和kinesisfirehose；临时存储单元为amazons3的临时桶；正式存储单元为amazons3的正式桶。aws车联网核心服务域201的规则引擎将所有采集到的车辆原始can数据路由给原始数据源模块10的kinesisstream，以便后续历史数据统计分析。原始数据源模块10包括多种异构数据的来源，一般包括两种：一种是由前台的业务系统产生的数据，也就是业务系统会去记录和处理的数据；另一种是系统运行产生的日志数据。异构数据源存储介质覆盖但不限于dynamodb、amazons3等。本发明中在前期的车辆数据监控平台中已经采集到的原始can数据作为原始数据源模块10的输入，车辆所有生成的消息都通过awsiot的规则引擎存入该域的kinesisdatastream传输加密的数据流，kinesisfirehose根据缓存大小(设置10mb)和时间间隔(5分钟)为触发条件(满足任一条件将触发)，获取kinesisdatastream数据，并写入amazons3临时桶中。一个kinesisfirehose只能与一个kinesisstream连接。kinesisstream分区：每个kinesis流由一个或多个分片shard组成，每个shard提供一个固定的容量单位。每个shard均可支持最多每秒5次交易可用于读取，最多可达的最大总数据读取速率为2mb/s和最多每秒1000条记录可用于写入，最多可达的最大总数据写入速率为1mb/s(包括分区键)。流的总容量是其分片容量的总和。车辆的数据是串行发送到云端(aws车联网核心服务域201)的，且每条数据尺寸<250bytes，所以1个shard只能支持1000辆车的数据。在kinesisdatastream中创建了200个shard(如果需求的shard数量更大，则需要aws提供底层技术支持)，那么可以支持20万辆车。当然也可以考虑创建多个kinesisstream，但这样做成本将会比较高。kinesisstream分区键：分区键用于按分片对流中的数据进行分组。kinesisdatastream将属于一个流的数据记录隔离到多个分片中，它使用与每个数据记录关联的分区键确定指定数据记录属于哪个分片。分区键是最大长度限制为256个字节的unicode字符串。md5哈希函数用于将分区键映射到128位整数值并将关联的数据记录映射到分片。但应用程序将数据放入流中时，它必须指定一个分区键。本案例中将车辆编号vin作为分区键，这就意味着，同一辆车的数据会被保存到同一个kinsisstream的分片中。数据加工模块20为原始数据源模块10amazons3桶里存储的车辆原始数据做分类整理和正式归档，包括周期性的对amazons3临时桶数据加载、数据并行计算、以及将分类处理完的数据回写存储amazons3正式桶。一个实施例中，数据加工模块20为amazon的emr，采用amazon的emr托管环境提供的hivesql和spark处理程序，未来amazon的glue服务在中国开放后，将进行升级替换。部署和运行在aws的ec2上的sparkcore包含了spark的基本功能，比如任务调度、内存管理、容错机制等，内部定义了rdd、dataframe、dataset等，另外定义了相关的操作api和动作。spark是一个围绕速度、易用性和复杂分析构建的、全面的、统一的大数据处理框架，基于aws的ec2的spark运行流程为：为应用构建起基本的运行环境，即由driver创建一个sparkcontext进行资源的申请、任务的分配和监控；资源管理器为executor分配资源，并启动executor进程；sparkcontext根据rdd的依赖关系构建dag图，dag图提交给dagscheduler解析成stage，然后把一个个taskset提交给底层调度器taskscheduler处理；executor向sparkcontext申请task，taskscheduler将task发放给executor运行并提供应用程序代码；task在executor上运行，把执行结构反馈给taskscheduler，然后反馈给dagscheduler，运行完毕后写入数据并释放所有资源；一个实施例中，工作流调度编排监控模块30包括aws的弹性http应用程序负载均衡器elb，以及ec2双节点集群。每个ec2服务节点安装了airflow服务系统(因为airflow不是aws的标准托管服务，为了保证高可用性，需要使用至少2个ec2节点进行airflow的安装和部署)。本案airflow定时任务触发，自动周期性调度数据加工模块20的spark处理程序/hivesql。airflow是airbnb公司于2014年开发开发的一个编排、调度和监控的工作流平台，现在在apachesoftwarefoundation孵化。airflow通过python文件作流，而不用其他调度器使用xml或者text文件方式定义工作流，本案我们通过编写python脚本代码，完全自定义自己的业务级工作流。然后由airflow将workflow编排为tasks组成的dags，调度器在一组workers上按照指定的依赖关系执行tasks。airflow同时对工作流执行过程中步骤进行监控和报警。工作流调度编排监控模块30的airflow将每小时触发一次数据加工模块20的spark程序，读取原始数据源模块10的amazons3临时桶数据，解析并通过vin车辆编号与时间段将原始数据组合(每小时组合生成一个结果文件)，并将它存储到amazons3的正式桶中，最后删除临时桶数据。本发明基于aws公有云环境，通过awsiotcore的规则引擎、kinesisstream、kinesisfirehose、amazons3、amazonemr(spark/hivesql)、amazonec2上的airflow、amazon弹性http应用程序负载均衡器elb的组合，实现了一种车辆大数据统计分析平台的大数据存储方法。通过amazonec2上的airflow，实现了分布式工作流程自定义，周期性地触发大数据处理任务，自动化地完成车辆can总线大数据从amazons3临时桶到正式桶的数据逻辑计算和数据转移。如图2所示，另一个实施例中，车辆数据管理系统还包括系统管理员gui/cli客户端应用模块40，用于通过浏览器gui界面或者cli命令行界面访问和操作工作流调度编排监控模块30，以控制工作流调度编排监控模块30生成第一控制指令。系统管理员可通过浏览器gui界面或者cli命令行界面，访问和操作airflow，以实现airflow对工作流进行编排，对任务进行管理、触发、监控等。如图2所示，一个实施例中，车辆数据管理系统还包括数据仓库模块50，数据仓库模块50包括数据仓库。工作流调度编排监控模块30还用于生成第二控制指令并发送至数据加工单元。数据加工模块20还用于根据第二控制指令提取原始数据源模块10的正式存储单元的数据并对其进行过滤、清洗和降噪处理，并将处理后的数据发送至数据仓库，以在数量仓库内形成事实表和维度表。数据仓库具有四个特点：面向主题、集成性、相对稳定性、反映历史变化。面向主题：数据仓库中的数据是按照一定的主题域进行组织。主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的面，一个主题通常与多个操作型信息系统相关。而操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离。集成性：数据仓库中的数据是在对原有分散的数据库数据抽取、清洗的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。相对稳定性：数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。反映历史变化：数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势作出定量分析和预测。而操作型数据库主要关心当前某一个时间段内的数据。如图2所示，一个实施例中，数据仓库模块50由amazon的emr实现，其内置了大数据仓库hive和olap处理引擎presto。大数据仓库hive存储了干净的、一致的、准确的、清洗后的数据，它的数据一般都遵循数据库第三范式，并按照一定的主题域进行组织，包含了事实表、维度表。hive数据仓库模块50会保存bi系统中所有的历史数据，保存期一般为10年。数据仓库内的数据包括行星模式和雪花模式。星型模式是多维的数据关系，它由事实表和维表组成。每个维表中都会有一个维作为主键，所有这些维的主键的结合成事实表的主键。事实表的非主键属性称为事实，他们一般都是数值或其他可以进行计算的数据；而维大都是文字、时间等类型的数据，按这种方式组织好数据，就可以按照不同的维(事实表主键的部分或全部)来对这些事实数据进行求和、求平均、计数、百分比的聚集计算，甚至可以做20～80分析。这样就可以从不同的角度数字来分析业务主题的情况。雪花模型是当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的“层次”区域，这些被分解的表都连接到主维度表而不是事实表。相比星型模型，雪花模型的特点是贴近业务，数据冗余较少。但由于表连接的增加，导致了效率相对星型模型来的要低一些。如图2所示，一个实施例中，车辆数据管理系统还包括远程监控数据源模块60，用于获取并存储多个车辆的行车状态数据。工作流调度编排监控模块30还用于生成第三控制指令并发送至数据加工单元。数据加工模块20还用于根据第三控制指令提取远程监控数据源模块60中的数据并对其进行过滤、清洗和降噪处理，并将处理后的数据发送至数据仓库，以在数量仓库内形成业务表。可选地，行车状态数据包括：行车异常检测数据、故障诊断数据、车辆出行数据、驾驶员安全评分数据。如图2所示，可选地，远程监控数据源模块60内置有dynamodb业务库。dynamodb数据库是一种完全托管的nosql数据库服务，提供快速而可预测的性能，能够实现无缝扩展。dynamodb可自动将表的数据和流量分布到足够多的服务器中，以便处理客户指定的容量请求和数据存储量，同时还能保持性能一致、访问高效。为了快速、有效地分析dynamodb中存储的数据，需要将dynamodb和amazonemr与自定义版本的hive配合使用。如果要对车辆远程监控的数据进行统计分析，需要从远程监控数据源模块60获取车辆业务级大数据。在车辆远程监控平台中，涉及到的业务级数据库包括行车异常检测数据库、故障诊断数据库、车辆出行数据库、驾驶员安全评分数据库，这些业务数据都采用dynamodb进行存储持久化。如图2所示，一个实施例中，车辆数据管理系统还包括云-应用数据交互模块70、历史业务视图模块80、数据仓库模块50还包括处理引擎。云-应用数据交互模块70与远程监控数据源模块60数据连接，用于提取并存储远程监控数据源模块60内的维度数据。工作流调度编排监控模块30还用于生成第四控制指令并发送至处理引擎。处理引擎用于根据第四控制指令提取并联机分析处理云-应用数据交互模块70中的数据和数据仓库内的事实表和维度表，并将处理后的数据存储至历史业务视图模块80内。在hive数据仓库中，事实表的内容来源于原始数据源模块10的amazons3，业务表的内容来源于远程监控原始数据源模块10的dynamodb，维度表的内容是自建的。如果涉及到海量维度数据，比如车辆vin和对应的车型，这个内容是在车辆远程监控平台中保存到云-应用数据交互模块70的业务应用mysql数据库中的。可以由数据仓库模块50emr的presto集群对多个数据源(hive事实表、业务应用mysql数据库)进行跨库联合查询和并行计算。hive数据仓库中的业务表，将与远程监控原始数据源模块10的dynamodb数据库表建立映射关系，并由数据加工模块20emr的spark集群完成etl、数据格式的转换、表字段的映射、以及向数据仓库hive中保存数据。hive中建立好的业务数据表，后续可由presto框架进行olap分析计算。hive外部表与内部表之间的区别是：大多数情况，两者的区别不明显，如果数据的所有处理都在hive中进行，那么倾向于选择内部表；但是如果hive和其它工具要针对相同的数据集进行处理，外部表更合适。使用外部表访问存储在hdfs上的初始数据，然后通过hive转换数据并存到内部表中，使用外部表的场景是针对一个数据集有多个不同的schema。通过外部表和内部表的区别和使用选择的对比可以看出，hive其实仅仅只是对存储在hdfs上的数据提供了一种新的抽象，而不是管理存储在hdfs上的数据。所以不管创建内部表还是外部表，都可以对hive表的数据存储目录中的数据进行增删操作。删除内部表时，将删除内部表中的业务数据；而删除外部表时，仅删除hive中对外部表的引用，而不删除业务数据。hive分区表和分桶表的区别：hive数据表可以根据某些字段进行分区操作，细化数据管理，可以让部分查询更快。同时表和分区也可以进一步被划分为buckets，分桶表的原理和mapreduce编程中的hashpartitioner的原理类似。分区和分桶都是细化数据管理，但是分区表是手动添加分区。由于hive是读模式，所以对添加进分区的数据不做模式校验。分桶表中的数据是按照某些分桶字段进行hash散列形成的多个文件，所以数据的准确性也高很多。在本案中，以vin车辆编号和数据产生日期作为分区字段，即vin车辆编号作为hive外部表的一级目录，数据产生日期作为某个vin车辆编号目录下的二级子目录。另外，根据数据分析业务需求，暂未定义分桶表。未来随着业务开展，如果要方便抽样和提高表join查询效率，将考虑增加分桶表。而实际生产中分桶策略使用的频率较低，更常见的还是使用数据分区。数据加工模块20根据数据分析需求，为数据仓库创建事实表、维度表。然后从异构数据源提取数据，经过加工处理(比如过滤、清洗、降噪等)，将etl处理后的数据结果生成到数据仓库中；这里主要采用amazon的emr托管环境提供的hivesql和spark处理程序，未来amazon的glue服务在中国开放后，将进行升级替换。原始数据源模块10到数据仓库模块50的数据抽取，可以考虑每天定时抽取一次，或者通过在hive大数据仓库建立外表关联amaons3。远程监控原始数据源模块10到数据仓库模块50的数据抽取，也是每天定时抽取一次。对于dynamodb业务库数据的etl，可由该域的amazonemr的spark程序调用和执行并行计算，并将处理后的数据格式写入数据仓库模块50的hive业务表中。aws提供的emrspark集群默认运行模式是yarn-client，当然可以修改成yarn-cluster。另外，需要在该域的emr集群上配置livy服务，以便airflow对spark任务处理集群的返回结果进行监控和实现工作流编排。apachelivy是一个服务，它可以通过一个rest接口与spark集群轻松交互。它可以通过一个简单的rest(representationalstatetransfer)接口或rpc(remoteprocedurecall)客户机库，轻松提交spark作业或spark代码片段、同步或异步结果检索以及spark上下文管理。apachelivy还简化了spark和应用服务器之间的交互，从而使spark能够用于交互式web/移动应用程序。其功能包括：具有可供多个客户机用于多个spark作业的长时间运行的spark上下文；跨多个作业和客户端共享缓存的rdd或数据帧；可以同时管理多个spark上下文、spark上下文在集群(yarn/mesos)上运行，而不是在livy服务器上运行，以获得良好的容错性和并发性；作业可以作为预编译的jar、代码片段或通过java/scala客户端api提交；通过安全的认证通信确保安全。如图2所示，另一个实施例中，车辆数据管理系统还包括实时数据分析模块90、实时业务视图模块100、汇聚处理服务模块110和业务服务视图模块120。实时数据分析模块90用于通过云服务平台获取多个车辆的原始总线数据并进行实时分析，将实时分析后的数据实时存入实时业务视图模块100。工作流调度编排监控模块30还用于生成第五控制指令并发送至汇聚处理服务模块110。汇聚处理服务模块110用于根据第五控制指令提取并联机分析处理实时业务视图模块100和历史业务视图模块80内的数据，并将处理后的数据保存至业务服务视图模块120内。airflow定时任务触发，自动周期性调度数据加工模块20的spark处理程序/hivesql，数据仓库模块50的presto，以及汇聚处理服务模块110的presto。数据加工模块20的emr计算集群，有三个主要的周期性处理任务，任务一是对原始数据源模块10的amazons3桶数据进行分类处理；任务二是从amazons3提取数据做etl，然后生成到数据仓库模块50的hive中；任务三是从dynamodb数据库中提取数据做etl，然后将处理转换后的数据格式生成到数据仓库模块50hive中的业务表。此外，数据仓库模块50emr的presto集群，有周期性计算任务，它每天执行一次，完成从hive数据仓库的事实表、维度表、以及云-应用数据交互模块70的业务应用mysql数据库表中提取数据，做联合join，并将olap处理后的结果数据保存到历史业务视图模块80的bi数据库mysql中。最后，汇聚处理服务模块110emr的presto集群，也有周期性计算任务，它根据较短的时间周期(比如每半小时执行一次)，将访问实时业务视图模块100的redis和历史业务视图模块80的mysql，将并行计算后的结果数据生成到业务服务视图模块120的统计分析结果库mysql中。以上这些周期性计算任务的启动，有些依赖于其他任务执行的完成。因此需要使用airflow创建工作流编排服务，这里在airflow所在的ec2上，采用python脚本编程，通过http协议对远端数据加工模块20的emrspark任务集群的工作状态进行轮询检测，默认30秒一次request-reponse(可以调整轮询时间间隔)，直至获取到spark的job任务全部完成的应答，才结束轮询检测。而对于各个emr的presto计算任务的触发，采用airflow定时器技术，周期性的触发任务事件，来引导presto计算集群的执行。如图2所示，另一实施例中，车辆数据管理系统还包括：互联网高并发客户端应用模块130，与云-应用数据交互模块70通信连接。云-应用数据交互模块70还用于接收实时业务视图模块100、历史业务视图模块80和业务服务视图模块120的数据并发送至互联网高并发客户端应用模块130。业务服务视图模块120通过云-应用数据交互模块70为互联网高并发客户端应用模块130130提供数据来源，供客户可视化地分析和检索。如图2所示，一个实施例中，车辆数据管理系统还包括：数仓元数据管理模块140，用于存储多个车辆的元数据并建立元数据的内表和外表，内表的数据存储至数据仓库指向的路径，内表记录数据所在的路径。默认情况下，hive元数据保存在内嵌的derby数据库中，只能允许一个会话连接，只适合简单的测试。为了支持多用户多会话，则需要一个独立的元数据库。hive的元数据信息通常存储在关系型数据库中，hive内部队mysql提供了很好的支持。hive的元数据信息在mysql数据库中有57张表，其中主要涉及到的表包括：tbls(所有hive表的基本信息，包括表名、创建时间、所属者等)，table_param(表级属性，包括如是否外部表、表注释、最后修改时间等)，columns(hive表字段信息，包括字段注释、字段名、字段类型、字段序号等)，sds(所有hive表、表分区所对应的hdfs数据目录和数据格式)，serde_param(序列化-反序列化信息，包括行分隔符、列分隔符、null的表示在字符等)，partitions(hive表分区信息，包括所属表、分区值等)，partition_keys(hive分区表分区键，即分区字段)，partition_key_vals(hive表分区名，即键值)。hive的数据在hdfs的warehouse目录下，一个表对应一个子目录。本地的/tmp目录存放日志和执行计划。hive的表分为两种，内表和外表。hive创建内部表时，会将数据移动到数据仓库指向的路径；若创建外部表，仅记录数据所在的路径，不对数据的位置做任何改变。在删除表的时候，内部表的元数据和数据会被一起删除，而外部表只删除元数据，不删除数据。这样外部表相对来说更加安全些，数据组织也更加灵活，方便共享源数据。根据上述实施例的内容，本发明具有以下优点：本发明从车辆主机厂oem的背景出发(天然地具有车辆数据采集优势)，针对车辆主机厂oem的车辆大数据消息和信号，结合全球云计算排名在首的aws公有云环境，提出了一套车辆数据的分类以及存储方法，实现了一个车辆大数据统计分析平台的数据仓库建设方案，为智能驾驶业务的开展提供了有力的数据服务支撑。在aws公有云环境中，通过分布式工作流引擎进行服务编排，完成车辆大数据仓库的建立、自动化etl和olap分析全过程，系统管理员更多的是通过可视化界面监控各项数据处理任务的完成情况，从而使人工操作和执行成本降至最低。本发明通过amazon的7层负载均衡器集群、airflowonamazonec2工作流引擎、livy监控服务插件、sparkonamazonemr并行计算框架、hiveonamazonemr大数据仓库、amazons3简单存储服务桶、prestoonamazonemr的olap查询分析引擎、amazon托管的关系型数据库mysql集成联动，实现了一套智能网联汽车大数据分类存储方案，包括数据仓库建表，车辆大数据从amazons3到amazonemrhive的etl处理，以及车辆大数据从hive数据仓库被olap处理后保存到amazon托管数据库服务rdb(mysql)历史业务视图的整个数据处理、工作流任务编排、数据处理任务调度监控全过程，为后续的分析、检索和可视化提供技术和数据服务保障。根据服务、组件的高内聚、低耦合和平台抽象化思路，设计和划分不同的服务域和系列服务组件，保证了车辆大数据分析平台具有良好的可扩展性、灵活性。通过amazonec2上的airflow，在分布式环境下实现了自定义的工作流程任务编排，让数据加工模块20的emr自动化地、周期性地触发大数据处理任务：一是为原始数据源模块10amazons3桶里存储的车辆原始数据做分类整理和正式归档，包括周期性的对amazons3临时桶数据加载、数据并行计算、以及将分类处理完的数据回写存储amazons3正式桶；二是根据数据分析需求，为数据仓库创建事实表、维度表。然后从异构数据源提取数据，经过加工处理(比如过滤、清洗、降噪等)，将etl处理后的数据结果生成到数据仓库中；三是周期性触发数据仓库模块50emr的presto和汇聚处理服务模块110emr的presto，做数据olap处理；各业务组件职责单一、分工明确，因此整体技术架构具有良好的可维护性和可扩展性。从技术框架层面，通过自定义方式创建的amazonemrspark集群，让基于amazon的emr大数据存储分析系统(hive/presto)，能够很好地与amazon自主研发的s3和dynamodb中存储的大数据交互，完成各种车辆历史大数据统计分析功能。在设置网络时，将整个计算集群建立在vpc私有子网中，可使amazon的emr集群应用能够访问处在db子网中的elasticcache和mysql等，进而在保证网络安全的情况下，完成车辆大数据业务分析功能。另外，amazon的emr集群设置了三个基本节点，即master、core、task。master负责resourcemanager，namenode等控制进程的部署；core主要负责集群所有数据的部署，可以按需进行扩容；task不保存数据，主要用作调整集群的计算力，可以按需追加。三种类型的节点采用统一的通用型实例规格硬件配置，根据未来数据进入量，可调整硬件配置。三种节点硬件配置为：4vcore,8gibmemory,ebsonlystorage，ebsstorage:32gib；通过这样的硬件和集群配置，保证了emr环境对大数据处理的能力，可未来的可扩展性。同时，系统开启日志记录功能，将日志数据保存到amazon的s3路径下，对作业调试和错误排查都有极大的帮助；另外使用ec2keypair完成ssh登录访问的安全配置。至此，本领域技术人员应认识到，虽然本文已详尽示出和描述了本发明的示例性实施例，但是，在不脱离本发明精神和范围的情况下，仍可根据本发明公开的内容直接确定或推导出符合本发明原理的许多其他变型或修改。因此，本发明的范围应被理解和认定为覆盖了所有这些其他变型或修改。当前第1页12当前第1页12