有价值数据的挖掘方法与服务器

技术领域

本申请涉及自动驾驶技术领域，尤其涉及一种有价值数据的挖掘方法与服务器。

背景技术

目前自动驾驶技术行业、领域已经呈现爆发趋势，面对不断扩展的自动驾驶应用领域，各类传感器的海量数据作为支撑自动驾驶技术的关键依据，需要对海量的自动驾驶数据进行大量的数据处理和训练，不断提升自动驾驶AI司机的能量。

然而，现有的自动驾驶数据进行提取的时候，每次需要遍历所有的自动驾驶数据进行提取相应的数据，如此，耗费自动驾驶系统大量的算力，效率较低。

发明内容

有鉴于此，实有必要提供一种高效的有价值数据的挖掘方法与服务器。

第一方面，本申请实施例提供一种有价值数据的挖掘方法，所述有价值数据的挖掘方法包括下面步骤：根据数据来源信息和多个预设提取指令，并行从源数据存储区相应地抓取一段时间内一个区域或者多个区域的来源数据、一段时间内一辆或者多辆自动驾驶车辆的源数据、以及一段时间内一个或者多个传感器的源数据形成若干初始数据包；对每个初始数据包中相应的数据进行分析得到异常数据；对异常数据添加标签形成第一版本数据包，第一版本数据包带有第一数据包时间戳；当接收一个或者多个用户端发送的标签请求时，根据标签请求将若干初始数据包中与标签请求相关联的数据添加标签形成第二版本数据包，第二版本数据包带有第二数据包时间戳，第二数据包时间戳表示添加标签的时间；当接收一个或者多个用户端发送的数据分析请求时，并行解析数据分析请求得到相应的标签；数据分析请求包含标签的表示信息；并行根据解析出来的标签从第一版本数据包和/或第二版本数据包中获取相应的数据作为有价值的数据。

第二方面，本申请实施例提供一种服务器，其特征在于，所述服务器设备包括：

计算机可读存储介质，用于存储程序指令，处理器，用于执行所述程序指令以实现有价值数据的挖掘方法。

上述有价值数据的挖掘方法与服务器，通过预设指令在源数据存储区中获取数据，在获取的数据中筛选异常数据并对异常数据打上标签，打标签的同时自带打标签时的时间，再将打上标签的异常数据输入到预设算法模型进行运算，最终得到有价值的数据。从而可以高效的在海量自动驾驶数据中根据时间和/或事件名称来直接提取数据，还可以减少自动驾驶系统大量的算力。

附图说明

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

图1为本申请实施例提供的有价值数据的挖掘方法流程示意图。

图2为本申请实施例提供的有价值数据的挖掘方法的第二实施例流程示意图。

图3为为本申请实施例提供的有价值数据的挖掘方法的第三实施流程示意图。

图4为本申请实施例提供的有价值数据的挖掘方法的第二实施例的第一子流程图。

图5为本申请实施例提供的有价值数据的挖掘方法的第三实施例的第一子流程图。

图6为本发明实施例提供的服务器的内部结构示意图。

图7为本申请实施例提供的源数据存储区的示意图。

图8为本申请实施例提供的自动驾驶系统的示意图。

图9为本申请实施例提供的并行获取数据包的示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的规划对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，换句话说，描述的实施例根据除了这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，还可以包含其他内容，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于只清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者多个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

请结合参看图1、图7、图8和图9，自动驾驶系统2包括服务器10和车辆100，每辆车上设有多个传感器和多个计算模块。在本实施例中接收自动驾驶系统2中的所有自动驾驶车辆发送的源数据，并存储于源数据存储区1。源数据存储区1为数据库200的存储区域。源数据包括来源于所有自动驾驶车辆采集的采集数据702、来源于所有自动驾驶车辆在路测过程中产生车辆运行状态数据704、以及来源于所有自动驾驶车辆计算得到的处理数据706，采集数据来源于每辆车辆的多个传感器进行采集而得，不同来源的源数据具有不同的数据结构属性，数据结构属性包括数据来源信息，数据来源信息包括表示车辆所属地理区域的区域标识、表示自动驾驶车辆身份的车辆标识、表示传感器身份的传感器标识、源数据时间戳。以自动驾驶车辆A和N为例，自动驾驶车辆A的多个传感器A1-AN采集的数据以及自动驾驶车辆的多个计算模块1-n计算得到的数据都并行传输给服务器10进行存储于源数据存储区1。同样地，自动驾驶车辆N的多个传感器N1-NN采集的数据以及自动驾驶车辆的多个计算模块1-n计算得到的数据都并行传输给服务器10进行存储于源数据存储区1。可以理解地，不同类型或者厂商提供的传感器数据结构不同，同样地，不同车辆上的计算模块也根据不同类型和厂商不同而导致数据结构不同。也就是说，自动驾驶系统中的所有自动驾驶车辆获得的数据都会传输给服务器10进行存储，从而形成海量的数据源，为后续进行自动驾驶仿真或模型训练、深度学习等提供了数据基础。具体地，有价值数据的挖掘方法具体包括如下步骤S102-S112。

步骤S102，根据数据来源信息和多个预设提取指令，并行从源数据存储区1相应地抓取一段时间内一个区域或者多个区域的来源数据、一段时间内一辆或者多辆自动驾驶车辆的源数据、以及一段时间内一个或者多个传感器的源数据形成若干初始数据包。举例来说，如图9，例如，预设提取指令是提取上海和北京昨天上午9点到今天上午12点的数据，则根据预设指令在数据来源信息中选择区域为北京和上海，源数据时间戳为昨天上午9点到今天上午12点的数据，将满足条件的数据提取出来得到第一组数据，并对获取的第一组数据进行做包得到数据包A，其中数据包A为北京和上海昨晚上午9点到今天上午12点的数据汇总形成的，若预设提取指令是提取上海和北京昨天上午9点到今天上午12点的数据，并将数据根据不同区域分开提取，则根据不同区域得到两组数据，将这两组分开做包得到数据包B和数据包C，其中数据包B为北京昨天上午9点到今天上午12点的数据，数据包C为上海昨天上午9点到今天上午12点的数据；再例如：根据预设提取指令获取下午2点到下午3点车辆A的远距离雷达的目标检测的数据，则根据数据来源信息中选择车辆标识为车辆A，时间戳为下午2点到下午3点时间段，传感器为远距离雷达作为数据提取条件，将满足条件的数据提取出来得到第二组数据，并对获取的第二组数据进行打包得到数据包D。其中数据包D为满足车辆A在下午2点到下午3点之间的远距离雷达的目标检测数据的数据。上述获取数据过程是并行处理。也就是说，数据源的数据是海量的，而在对数据进行分析的过程往往仅需要对与分析数据的目的相关的数据。若每次都对海量的源数据进行一一计算，这对服务器10的算力要求很高，且效率也会非常低。本实施例中，可以根据用户设定的提取指令对海量数据进行分包处理，在对后续数据分析的时候只对相关联的数据包中的数据进行分析即可，从而大大减少了数据分析时的数据量，进而大大地降低服务器10算力，同时提高了分析效率。

步骤S104，对每个初始数据包中相应的数据进行分析得到异常数据。在步骤S104是服务器10自动根据预先设置的规则进行异常数据的筛选。举例来说，在分析异常数据时，可以对一份数据进行全局分析后从中得出局部的异常数据，例如，可以根据时间区间T内红绿灯数据进行比对分析，其中时间区间T包含了时段T1,当时段T1中的红绿灯数据与时间区间T的其他时段的红绿灯存在差异时，则认为时段T1内的红绿灯数据有异常。又例如，在分析异常数据时，也可以对一份数据进行逐段依次分析，当将突变的数据作为异常数据，例如出现交通事故导致数据突变。又例如，在分析异常数据时，也可以对一份数据中存在信息中断的数据作为异常数据，也就是传感器无法采集到数据从而出现信息中断。

步骤S106，对异常数据添加标签形成第一版本数据包，第一版本数据包带有第一数据包时间戳。在步骤S104是服务器10自动根据预先设置的添加标签规则对异常数据添加标签。其中，第一版本数据包可以是对得到的异常数据根据时间添加时间戳和事件标签并将异常数据整合而成。例如，当一份异常数据是关于红绿灯的，则可以添加红绿灯故障标签。又例如，当一份异常数据是关于交通事故的，则可以添加交通事故标签。

步骤S108，当接收一个或者多个用户端发送的标签请求时，根据标签请求将若干初始数据包中与标签请求相关联的数据添加标签形成第二版本数据包，所述第二版本数据包带有第二数据包时间戳，所述第二数据包时间戳表示添加标签的时间。可以理解地，在步骤S108中，也可以由用户人工进行添加标签。例如，当用户得知一个时间段的一个区域出现了交通事故，则用户可以对该时间段内该区域中车辆的数据添加交通事故标签。当用户添加标签后，系统会根据用户添加标签对原来数据包相应的数据上添加事故标签，从而形成第二数据包，同时将人工添加标签的时间作为第二数据包的时间戳。也就是说，本实施例不仅对数据进行了分包，还可以对分包后的数据进一步供人工根据场景或者后续关注的数据进行进一步添加标签且重新生成新的版本的数据包，如此，可以供后续在进行分析的时，用户可以选择相应的最新或者原始版本进行分析，从而大大进一步简化了数据分析的数据源的选取效率，也进一步节省了服务器10的算力。

步骤S110，当接收一个或者多个用户端发送的数据分析请求时，并行解析数据分析请求得到相应的标签；数据分析请求包含标签的表示信息。也就是说，可以同时对多个数据分析请求进行并行处理。举例来说，当用户A发送红绿灯故障数据分析请求的同时用户B发送交通事故数据分析请求，服务器10可以并行处理用户A和用户B的请求得到用户请求中包含的红绿灯故障和交通事故的标签。

步骤S112，并行根据解析出来的标签从第一版本数据包和/或第二版本数据包中获取相应的数据作为有价值的数据。可以理解地，服务器10解析出用户需要分析的是红绿灯故障所需要的数据以及交通事故所需要的数据，则可以并行获取有关于红绿灯故障的数据和有关于交通事故的数据。而这些数据可以是从第一版本数据包中获取，也可以从第二版本数据包中获取，也可以从第一版本数据包和第二版本数据包中获取。可以理解地，在本实施例中，将海量数据进行了分包处理，可以根据用户需要分析的数据从对应的分包中获取数据。也就是说，服务器10可以并行访问相应的数据包来得到有价值的数据，如此，可以大大提高数据获取的效率。

上述实施例中，可以将海量数据划分为数据量较小的数据包，化整为零，在提取数据的过程中，可以直接从数据量较小的数据包中进行提取，使得并行处理更加容易，大大减少了自动驾驶系统的算力。由于在对有价值数据进行挖掘的过程中，服务器10采取的是并行处理方式，从而大大提高了数据挖掘的效率。

请结合参看图2，其为本申请实施例提供的有价值数据的挖掘方法的第二实施例流程示意图。具体地，有价值数据的挖掘方法的第二实施例包括步骤S202-S210。

步骤S202，输出有价值数据给相应的预设算法模型进行运算得到相应的运算结果。具体地，预设算法模型为自动驾驶系统所需要的算法模型，例如，感知模型、决策模型、预测模型等。预测模型包括用于识别红绿灯状态的红绿灯识别模型、用于预测运动物体运动轨迹的运动目标轨迹预测模型等。所述预设算法模型可以为现有技术中出现的与自动驾驶相关的算法模型，在此不再一一列举。

步骤S204，根据预设评估算法评估运算结果是否符合预设标准。具体地，评估算法可对模型进行准确率、精确率、召回率和错误率等进行评估，举例来说，将带有红绿灯识别异常的数据输入至红绿灯识别模型中，评估这批带有红绿灯识别异常的数据的正确率，预设红绿灯识别模型中输出的带有红绿灯异常标签的数据占总数据的90％及以上，若在红绿灯识别模型中输出的带有人脸识别标签的数据占总数据的95％，则认为这批数据是符合预设标准的，若在红绿灯识别模型中输出的带有人脸识别标签的数据占总数据的70％，则认为这批数据不符合预设标准。

步骤S208，当运算结果不符合预设标准时，重新对每个数据包中相应的数据进行分析得到异常数据直至运算结果符合预设标准。可以理解地，若上述步骤S204中红绿灯识别模型第一次输出的运算结果为70％时，则需要再一次的对输入红绿灯识别模型之前的每个数据包中的异常数据进行再一次的打标签，再将得到的带有识别红绿灯异常的标签的数据输入到红绿灯识别模型进行运算得到第二次运算结果，如果模型输出的第二次运算结果还是没有达到90％时，则需要再一次的对输入红绿灯识别模型之前的每个数据包中的异常数据进行再一次的打标签，再将得到的带有识别红绿灯异常的标签的数据输入到红绿灯识别模型进行运算得到第三次运算结果，直至输出的运算结果符合90％。

步骤S210，当运算结果符合预设标准时，确认有价值数据为目标数据。可以理解地，若想要红绿灯识别模型的正确率达到90％及以上，当该版本数据通过红绿灯识别模型输出后得到的运算结果的正确率达到了预设的90％及以上，则说明该版本数据可以让红绿灯识别模型的正确率达到90％及以上，则认为该版本数据是可以让红绿灯识别模型正确率达到90％及以上的目标数据。

上述实施例中，通过将数据放入模型中进行训练并达到预设标准得到目标数据，从而可以在海量数据中提炼出符合用来训练模型的目标数据。

请结合参看图3，其为本申请实施例提供的有价值数据的挖掘方法的第三实施流程示意图。具体地，有价值数据的挖掘方法的第三实施例包括步骤S302-S308。

步骤S302，输出有价值的数据给相应的预设算法模型进行运算得到相应的运算结果。

步骤S304，根据预设评估算法评估所述运算结果是否符合预设标准。

步骤S306，当运算结果不符合预设标准时，重新根据数据来源信息和多个预设提取指令，并行从源数据存储区1相应地抓取一段时间内一个区域或者多个区域的来源数据、一段时间内一辆或者多辆自动驾驶车辆的源数据、以及一段时间内一个或者多个传感器的源数据形成若干初始数据包，直至运算结果符合预设标准。举例来说，若当前将车辆A的远距离雷达采集的图像信息输入图像识别模型中进行运算，根据输出的运算结果，发现数据量不够模型过渡拟合了，需要增加图像数量来对模型进行运算，根据提取指令为获取远距离雷达和摄像头采集的图像数据，则在源数据存储区根据指令获取车辆A的远距离雷达采集的图像数据和车辆A摄像头采集的图像数据，将采集的图像数据做包，传送到服务器10，服务器10对包进行解析并将数据输入到图像识别模型中进行第二次运算，若第二次在图像识别模型中运算输出的结果还是不符合标准，则需要重复根据指令获取数据并输入模型中进行运算，直至输入到模型中运算后输出的结果符合预设的标准。

步骤S308，当所述运算结果符合预设标准时，确认有价值数据为目标数据。

上述实施例中，根据指令从源数据存储区中筛选数据来对模型进行训练并得到目标数据的，从而可以更加灵活的运用数据来对模型进行训练。

请结合参看图4，其为本申请实施例提供的有价值数据的挖掘方法的第二实施例的第一子流程图。第二实施例添加标签包括步骤S402-S406。

步骤S402，分析各辆车辆采集的数据是否出现中断。举例来说，远距离雷达将采集的数据打包发送给服务器10，服务器10对远距离雷达传送的数据包进行解析，对解析的数据包中的数据进行分析，当分析出现中断的时候，则证明采集的数据发生中断。

步骤S404，获取数据出现中断的时间。举例来说，若分析解析的数据包中只有一段时间远距离雷达采集信息中断，则，获取该段时间的起始时间和终止时间，若分析解析的数据包中有多段远距离雷达采集信息中断的数据，则，获取每一段中断时间的起始时间和终止时间，还可以将多段远距离雷达采集信息中断的数据整合成一个数据包并获取第一段的起始时间和最后一段的终止时间。

步骤S406，对出现中断的时间内采集的数据添加标签。举例来说，若分析解析的数据包中只有一段时间远距离雷达采集信息中断，并获取了该段出现中断数据的时间，则将该段时间打上远距离雷达采集数据中断的标签并带上对该数据进行打标签时的时间，同理，若是出现多段远距离雷达采集数据中断的数据并整合成一个数据包后，则将该数据包打上远距离雷达采集信息中断的标签，并带上对该数据包进行打标签时的时间。

上述实施例中，对出现中断的数据进行分析和打标签并带有打标签时的时间，从而可以在海量的数据中快速的找到相应设备出现中断的数据，还可以根据打标签时的时间在中断数据中找到相应时间的中断数据。

请结合参看图5，其为本申请实施例提供的有价值数据的挖掘方法的第三实施例的第一子流程图。第三实施例添加标签包括步骤S502-S506。

步骤S502，分析各辆车辆采集的数据跟历史数据相比是否存在差异。举例来说，当服务器10获取今天上午9点到今天上午12点的识别红绿灯的数据时，服务器10随机调用上午9点到上午12点的识别红绿灯的历史数据，进行对比分析发现当前获取的识别红绿灯数据在上午10的时候少识别了一个红绿灯，则认为当前获取的上午9点到上午12点的识别红绿灯的数据与历史上午9点到上午12点的识别红绿灯的数据存在差异；还可以当服务器10获取今天上午9点到今天上午12点的识别红绿灯的数据时，用户可以设定与那个历史版本的上午9点到上午12点的识别红绿灯的数据进行对比分析是否出现差异。

步骤S504，当分析各辆车辆采集的数据跟历史数据相比存在差异，获取存在差异数据的时间段。可以理解地，当服务器10对当前获取的上午9点到上午12点的识别红绿灯的数据与历史上午9点到上午12点的识别红绿灯的数据进行对比分析时，发现当前获取的数据中在上午10点时对比历史数据少识别了一个红绿灯，则获取少识别了一个红绿灯时的这段数据中应该开始识别红绿灯到结束识别红绿灯的这段时间。若对当前获取的上午9点到上午12点的识别红绿灯的数据与历史上午9点到上午12点的识别红绿灯的数据进行对比分析时，发现有多段少识别红绿灯的数据和当前获取的该段时间的红绿灯信息为绿灯，历史数据获取的该段时间的红绿灯信息为红灯时，可以将少识别红绿灯的数据进行整合成一个数据包，并获取每一段的少识别红绿灯的数据的本应该识别红绿灯的起始时间和终止时间，还可以获取合并成一个数据包中的少识别红绿灯的数据的第一个的起始时间和最后一个少识别红绿灯的数据的终止时间，将无法合并的识别红绿灯数据不一致的数据则获取应该的起始时间和终止时间。

步骤S506，对时间段内采集的数据添加标签。举例来说，当前获取的上午9点到上午12点的识别红绿灯的数据在上午10点相比于历史获取的上午9点到上午12点的识别红绿灯的数据少识别了一个红绿灯数据，并获取了该段出现数据不一致的数据的时间，则将该段时间的数据打上识别红绿灯异常的标签并带上对该数据进行打标签时的时间，同理，若是对于出现多段相同少识别了红绿灯的数据并整合成一个数据包后，则将该数据包打上识别红绿灯异常的标签，并带上对该数据包进行打标签时的时间。

上述实施例中，通过比对数据发现数据差异，可以更加简便快速的发现数据异常盲区，从而可以在大量相同数据中发现数据异常盲区，还可以根据打标签时的时间找到相应时间的异常数据。

请结合参看图6，其为本申请实施例提供的服务器的内部结构示意图。服务器10包括计算机可读存储介质11、处理器12以及总线13。其中，计算机可读存储介质11至少包括一种类型的可读存储介质，该可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、磁性存储器、磁盘、光盘等。计算机可读存储介质11在一些实施例中可以是服务器10的内部存储单元，例如服务器10的硬盘。计算机可读存储介质11在另一些实施例中也可以是的外部服务器10存储设备，例如服务器10上配备的插接式硬盘、智能存储卡(Smart Media Card，SMC)、安全数字(Secure Digital，SD)卡、闪存卡(Flash Card)等。进一步地，计算机可读存储介质11还可以既包括服务器10的内部存储单元也包括外部存储设备。计算机可读存储介质11不仅可以用于存储安装于服务器10的应用软件及各类数据，还可以用于暂时地存储已经输出或者将要输出的数据。

总线13可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

进一步地，服务器10还可以包括显示组件14。显示组件14可以是发光二极管(Light Emitting Diode，LED)显示器、液晶显示器、触控式液晶显示器以及有机发光二极管(Organic Light-Emitting Diode，OLED)触摸器等。其中，显示组件14也可以适当的称为显示装置或显示单元，用于显示在服务器10中处理的信息以及用于显示可视化的用户界面。

进一步地，服务器10还可以包括通信组件15。通信组件15可选地可以包括有线通信组件和/或无线通信组件，如WI-FI通信组件、蓝牙通信组件等，通常用于在服务器10与其他智能控制设备之间建立通信连接。

处理器12在一些实施例中可以是一中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器或其他数据处理芯片，用于运行计算机可读存储介质11中存储的程序代码或处理数据。具体地，处理器12执行处理程序以控制服务器10实现有价值数据的挖掘方法。

可以理解地，图6仅示出了具有组件11-15以及实现有价值数据的挖掘方法的服务器10，本领域技术人员可以理解的是，图6示出的结构并不构成对服务器10的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘且本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

以上所列举的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此本申请权利要求所作的等同变化，仍属于本申请所涵盖的范围。