用于处理地理定位事件数据以获得低延迟的系统的制作方法

用于处理地理定位事件数据以获得低延迟的系统


背景技术：

1.汽车行业正在经历一场前所未有的彻底变革。整个运动出行生态系统都在发生颠覆。其结果是车辆更加自动化、互联化、电气化和共享化。这导致了汽车生成的数据爆炸式增长。这一丰富的新数据资产在很大程度上尚未开发。
2.车辆位置事件数据(诸如gps数据)极其庞大，每秒可涉及200000条至600000条记录。位置事件数据的处理对传统系统提出了一项挑战，即提供对数据的近乎实时分析，尤其是针对个别车辆。此外，识别个别车辆数据以进行此类规模的分析的同时，个别车辆数据面临着正确匿名化的挑战。需要的是系统平台、数据处理算法和流程，被配置为以低延迟处理和存储大容量数据，同时使大容量数据仍然可用于分析和再处理。
3.虽然有跟踪车辆的系统，但需要的是从大量车辆数据中获得实时准确的行程数据。需要的是系统和算法，被配置为依据车辆运动和路线分析准确地识别行程和行程目的地。


技术实现要素：

4.下面简要说明实施方案以提供对本文阐述的创新的一些方面的基本理解。本简要说明并非意在作全面概述。其并非意在识别主要或关键要素，或划定或以其他方式缩小范围。其目的仅仅是以简化的形式呈现一些概念，作为稍后呈现的更详细说明的前奏。
5.简而言之，描述的是用于处理车辆事件数据的系统、方法和计算机程序产品的各种实施方案。
6.至少一个实施方案描述了一种系统，该系统包括包含程序指令的存储器以及被配置为执行用于方法的指令的处理器，该方法包括：摄取位置事件数据；将事件数据中的位置数据编码为邻近区域，该编码包括：将每个事件的纬度和经度地理哈希为每个事件的邻近区域。事件数据可包括时间、位置(纬度/经度)和关注事件。关注事件可能包括紧急制动和紧急减速。紧急制动可被定义为在预定时间段内的减速。紧急加速被定义为在另一预定时间段内的加速。
7.在实施方案中，处理器被配置为执行用于方法的指令，该方法包括：在将事件数据中的位置数据编码为邻近区域之前，验证事件数据。处理器可被配置为执行用于将事件数据中的位置数据编码为邻近区域的方法的指令，该方法还包括：将纬度和经度地理哈希为定义邻近区域的形状。用于将事件数据中的位置数据编码为邻近区域的方法的指令可还包括以下至少一项：对该地理哈希进行编码以识别国家；对该地理哈希进行编码以识别州；对该地理哈希进行编码以识别邮政编码；以及对该地理哈希编码到可唯一地识别车辆的精确度。用于将事件数据中的位置数据编码为邻近区域的方法的指令可还包括以下至少一项：将地理哈希编码为4个字符以识别国家；将地理哈希编码为5个字符以识别州；将地理哈希编码为6个字符以识别邮政编码；以及将地理哈希编码为9个字符以唯一地识别车辆。将事件数据中的位置数据编码为定义邻近区域的形状可包括：将纬度和经度地理哈希为矩形，该矩形的边与字符串中的字符成比例。将事件数据中的位置数据编码为邻近区域可包括将
地理哈希编码为4个至9个字符。
8.在实施方案中，处理器被配置为执行还包括事件数据的内部记录过滤的指令，其中，该过滤包括过滤具有7秒或更短延迟的事件数据。
9.在实施方案中，处理器被配置为执行还包括将地理哈希映射到地图数据库的指令。映射还可包括将地理哈希映射到关注点的数据库。
10.在实施方案中，处理器被配置为执行还包括将事件数据匿名化的指令。
11.在实施方案中，处理器被配置为执行指令，该指令还包括：依据事件数据识别车辆的行程，其中，该行程识别包括识别给定车辆的路线或运动是否出于驾驶到行程目的地的目的；识别车辆的发动机启动/开始运动；识别车辆的发动机关闭/停止运动；以及确定车辆的发动机启动/开始运动和发动机关闭/停止运动是否满足一个或多个标准，该一个或多个标准包括：车辆的最短行驶持续时间、最短行驶距离和停止的最长停留时间。最短行驶持续时间可包括约60秒至约90秒的持续时间。停止的最长停留时间可为约30秒至约90秒。最短行驶距离可为约100米至约300米。
12.在实施方案中，系统可被配置为提供主动式车辆检测。处理器可被配置为执行用于主动式车辆检测的指令，该主动式车辆检测包括依据一段时间内的多项事件识别车辆路径。处理器可被配置为执行用于主动式车辆检测的指令，该主动式车辆检测包括：依据一天的时间段内的多项事件识别车辆路径，该识别包括使用连通分量算法，该连通分量算法包括识别包含当天车辆事件的有向图中的车辆路径。在该图中，节点是行程起点或终点，节点之间的连接是识别的车辆路径。
13.至少一个实施方案描述了一种由计算机实现的方法，该计算机包括处理器以及包括程序存储器的存储器，该程序存储器包括用于执行上述和本文阐述方法的指令。
14.至少一个实施方案描述了一种包括程序存储器的计算机程序产品，该程序存储器包括当由处理器执行时执行上述和本文阐述的方法的指令。
15.如本文所使用的，行程可包括到目的地的任何旅行、航程或旅程。
16.本文阐述的系统和方法的示例性优点是经优化的低延迟，截至本公开，该低延迟每秒能够为多达1200万辆车摄取和处理多达600,000条记录的车辆事件数据。
附图说明
17.结合以下附图对非限制性实施方案和非穷尽性实施方案进行说明。在附图中，除非另有说明，否则各个图中相似的附图标记指代相似的组件。
18.为了更好地理解，以下将结合详细说明(将与附图相结合阅读)，其中：
19.图1是可以实现各种实施方案中的至少一者的环境的系统图。
20.图2示出了用于根据本公开的各种实施方案中的至少一者的入口服务器系统的逻辑架构和流程图。
21.图3示出了用于根据各种实施方案中的至少一者的流处理服务器系统的逻辑架构和流程图。
22.图4表示用于根据各种实施方案中的至少一者的出口服务器系统的逻辑架构和流程图。
23.图5图示了用于根据各种实施方案中的至少一者的分析服务器系统的流程的逻辑
架构和流程图。
24.图6图示了用于根据各种实施方案中的至少一者的门户服务器系统的流程的逻辑架构和流程图。
25.图7是示出了系统的数据处理检查的数据质量流水线的流程图。
26.图8图示了根据各种实施方案中的至少一者的云计算架构。
27.图9图示了根据各种实施方案中的至少一者的用于云计算平台的逻辑架构。
具体实施方式
28.现在下文将结合附图对各种实施方案进行更全面的说明，附图构成本文的一部分并且通过图示的方式示出了可以实施本文阐述的创新的具体实施方案。然而，这些实施方案可以以多种不同的形式体现并且不应被解释为限于本文阐述的实施方案。相反，提供这些实施方案是为了使本公开全面且完整，并将向本领域技术人员充分传达实施方案的范围。除此之外，各种实施方案可以是方法、系统、媒体或设备。因此，以下详细说明不应被视为限制意义。
29.在整个说明书和权利要求书中，除非上下文另有明确规定，否则以下术语采用与本文明确相关联的含义。术语“本文”是指与本技术相关联的说明书、权利要求书和附图。如本文所用的短语“在一个实施方案中，或“在实施方案中”尽管可以，但不一定指相同的实施方案或单个实施方案。此外，如本文所用的短语“在另一个实施方案中”尽管可以，但不一定指不同的实施方案。因此，如下所述，在不脱离本发明的范围或精神的情况下，可以容易地组合各种实施方案。
30.此外，如本文所用，除非上下文另有明确规定，否则术语“或者”是包含性的“或者”并且等同于术语“和/或”。除非上下文另有明确规定，否则术语“基于”并非是排他性的，并且允许基于未阐述的其他因素。此外，在整个说明书中，“一种”、“一个”和“所述”的含义包括复数引用。“在
……
中”的含义包括“在
……
中”和“在
……
上”。
31.图示性逻辑系统架构和系统流程
32.图1是根据至少一个实施方案的用于地理定位事件处理和分析的系统10的逻辑架构。在各种实施方案中的至少一者中，入口服务器系统100可被布置为与流处理服务器系统200和分析服务器系统500通信。流处理服务器系统200可被布置为与出口服务器系统400和分析服务器系统500通信。
33.出口服务器系统400可被配置为与数据消费者通信并向其提供数据输出。出口服务器系统400还可被配置为与流处理服务器200通信。
34.分析服务器系统500被配置为与入口服务器系统100、流处理服务器系统200和出口服务器系统400通信并接受来自它们的数据。分析服务器系统500被配置为与门户服务器系统600通信并向其输出数据。
35.在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500和门户服务器系统600各自可以是一台或多台计算机或服务器。在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500和门户服务器系统600中的一者或多者可被配置为在单台计算机(例如网络服务器计算机)上或跨多台计算机操作。例如，在至少一个实施方案中，系统10可
被配置为在网络服务平台主机上运行，诸如亚马逊网络服务(aws)或微软azure。在示例性实施方案中，系统被配置在采用spark streaming服务器的aws平台上，其可被配置为执行如本文所述的数据处理。在实施方案中，系统可被配置为采用高吞吐量消息服务器，例如apache kafka。
36.在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500和门户服务器系统600可被布置为使用apf或由服务提供的其他通信接口来集成和/或通信。
37.在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500和门户服务器系统600可托管在托管服务器上。
38.在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500和门户服务器系统600可被布置为使用一个或多个直接网络路径(包括广域接入网络(wan)或本地接入网络(lan))通过网络直接或间接地与客户端计算机通信。
39.本领域普通技术人员将理解，系统10的架构是非限制性示例，其说明实施方案的至少一部分。因此，在不脱离本文阐述的创新的范围的情况下，可采用和/或以不同的方式布置更多或更少的部件。然而，系统10至少足以公开本文要求保护的创新。
40.参照图2，示出了根据至少一个实施方案的用于摄取数据和数据吞吐量的入口服务器系统100的逻辑架构。在至少一个实施方案中，可确定来自一个或多个事件源的事件。在实施方案中，如图1所示，事件源可包括车辆传感器数据源12、oem车辆传感器数据源14、应用数据源6、远程信息处理数据源20、无线基础设施数据源17和第三方数据源15等。在至少一个实施方案中，确定的事件可对应于可由系统的下游部件(诸如流处理服务器系统200和分析服务器系统500)管理的位置数据、车辆传感器数据、各种用户交互、显示操作、印象等。在至少一个实施方案中，入口服务器系统100可进入比图1和图2所示更多或更少的事件源。
41.在至少一个实施方案中，可以从一个或多个事件源接收和/或确定的事件包括来自一个或多个数据源的车辆事件数据，例如gps设备，或由第三方数据源15提供的位置数据表，诸如oem车辆传感器数据源14。可以以数据库格式(例如json、csv和xml)摄取车辆事件数据。可通过服务提供的api或其他通信接口和/或入口服务器系统100来摄取车辆事件数据。例如，入口服务器系统100可提供与入口服务器api 106集成的api网关102接口，该入口服务器api 106使入口服务器系统100能够确定可与车辆事件源14提供的数据库相关联的各种事件。示例性的api网关可包括例如aws api网关。入口服务器系统100系统的示例性托管平台可包括kubernetes和docker，但也可以采用其他平台和网络计算机配置。
42.在至少一个实施方案中，入口服务器系统100包括被配置为接受原始数据的服务器104，例如，可被配置为接受车辆事件数据的安全文件传输协议服务器(sftp)、api或其他数据输入。入口服务器系统100可被配置为将原始数据存储在数据存储器107中以供例如分析服务器系统500进行进一步分析。事件数据可包括点火开启、时间戳(tl...tn)、点火关闭、关注事件的数据、纬度和经度以及车辆信息编号(vin)信息。示例性事件数据可包括来自本领域已知来源的车辆运动数据，例如来自车辆本身(例如，通过gps、api)或从第三方数据源15提供的位置数据表。
43.在实施方案中，入口服务器系统100被配置为处理事件数据以获取车辆运动数据，例如速度、持续时间和加速度。例如，在实施方案中，每隔x秒(例如3秒)对事件数据库拍摄快照。然后，可处理纬度/经度数据和时间数据，以使用车辆位置和时间获取车辆跟踪数据，例如速度和加速度。
44.在实施方案中，入口服务器系统100被配置为接受来自设备和第三方平台的数据。入口服务器api 106可被配置为向系统10认证设备或第三方平台和平台主机。
45.因此，在实施方案中，入口服务器系统100被配置为接收原始数据，并且对原始数据执行数据质量检查和执行模式评估。摄取和验证原始数据是系统的质量检查的数据质量流水线的开始，如图7的方框701所示。表格1示出了可接收到系统中的原始数据的示例。
[0046][0047]
表格1
[0048]
在另一个实施方案中，来自入口源的车辆事件数据可包括更少的信息。例如，如表格2所示，原始车辆事件数据可包括有限数量的属性，例如位置数据(经度和纬度)和时间数据(时间戳)。
[0049]
[0050]
表格2
[0051]
本公开的实施方案的示例性优点是缺失的信息可从本文阐述的创新算法获取。例如，车辆事件数据可不包括行程识别，或者可具有不准确的行程识别。因而，当初始进入的数据具有有限的属性时，系统可被配置为获取额外的车辆事件属性数据。例如，系统可被配置为针对进入的车辆事件数据识别特定的车辆并附加车辆id。因此，系统可仅使用例如与车辆id相关联的位置和时间戳数据来跟踪车辆运动——包括启动和停止、速度、航向、加速度和其他属性。
[0052]
在实施方案中，在方框702处，接收的数据可符合外部定义的模式，例如avro或json。数据可被转换为内部模式并验证。在实施方案中，在事件数据被传递到消息传递系统以供数据质量流水线进行下游处理之前，可根据约定的模式定义对事件数据进行验证。例如，在将经验证的数据传递到apache kafka消息传递系统之前，可采用apache avro模式定义。在另一个实施方案中，原始运动和事件数据也可由客户端节点集群配置处理，其中，每个客户端是消费者或生产者，并且实例内的集群可在它们之间复制数据。
[0053]
例如，入口服务器系统100可被配置有pulsar客户端，该客户端连接到用于pulsar集群的apache pulsar端点。在实施方案中，apache pulsar端点跟踪上次读取的数据，允许apache pulsar客户端随时连接以从上次读取的数据中提取数据。在pulsar中，“标准”消费者接口涉及使用“消费者”客户端来监听主题，处理传入的消息，并在消息被处理完毕后最终确认这些消息。每当客户端连接到一个主题时，客户端会自动从未被确认的最早消息开始读取，因为该主题的游标由pulsar broker模块自动管理。但是，客户端的客户端阅读器界面使客户端应用程序能够以定制的方式管理主题游标。例如，pulsar客户端阅读器可被配置为连接到主题，以指定阅读器在连接到主题时从哪条消息开始读取。当连接到主题时，阅读器界面使客户端能够从主题中最早的可用消息或主题中的最新可用消息开始。客户端阅读器还可被配置为从最早消息和最新消息之间的某个其他消息开始，例如通过使用消息id从持久性数据存储器或缓存器中获取消息。
[0054]
在至少一个实施方案中，入口服务器系统100被配置为清理数据和验证数据。例如，入口服务器系统100可被配置为包括入口服务器api 106，该入口服务器api 106可验证摄取的车辆事件数据和位置数据并将经验证的位置数据传递到服务器队列108，例如apache kafka队列108，然后，其被输出到流处理服务器系统200。服务器104也可被配置为将经验证的入口的位置数据输出到数据存储器107。入口服务器系统100还可被配置为将无效数据传递到数据存储器107。例如，可将无效载荷存储在数据存储器107中。示例性无效数据可包括，例如具有错误字段或未识别字段，或相同事件的数据。入口服务器系统100可被配置为输出所存储的无效数据或允许将所存储的数据从数据存储器107拉到分析服务器系统500以进行分析，例如，以改进系统性能。例如，分析服务器系统500可被配置有诊断机器学习，该诊断机器学习被配置为对具有未识别字段的无效数据的数据库执行分析，以重新识别和标记字段以进行验证处理。入口服务器系统100还可被配置为传递所存储的入口的位置数据以供分析服务器系统500处理，例如，用于进行如本文所述的行程分析。
[0055]
如本文所述，系统10被配置为在流上下文和批量上下文两者中处理数据。在流上下文中，低延迟比完整性更重要，即不需要处理旧数据，事实上，处理旧数据可能会产生不利影响，因为它可能会阻止其他较新数据的处理。在批量上下文中，数据的完整性比低延迟
更重要。因而，为了便于在这两种上下文中处理数据，在实施方案中，系统可默认是流式连接，该流式连接在数据可用时立即进入所有数据，但也可被配置为跳过旧数据。批量处理器可被配置为填充流处理器因旧数据而留下的任何空白。
[0056]
图3是根据至少一个实施方案的用于数据吞吐量和分析的流处理服务器系统200的逻辑架构。如本文所述的流处理实现系统处理改进，包括每秒至少200,000至600,000条记录的吞吐量线性扩展的改进。改进还包括20秒的端到端系统处理，并且正在进一步改进系统延迟。在至少一个实施方案中，系统可被配置为采用服务器进行微批处理。例如，如本文所述，在至少一个实施方案中，流处理服务器系统200可被配置为在网络服务平台主机(诸如采用spark流服务器的aws)以及高吞吐量消息传递服务器(诸如apache kafka)上运行。在实施方案中，流处理服务器系统200可包括设备管理服务器207，例如aws ignite，其可被配置为输入来自数据处理服务器的经处理的数据。设备管理服务器207可被配置为使用匿名化的数据进行个别车辆数据分析，这些数据可从外部提供或连接。系统10可被配置为实时输出数据，以及将数据存储在一个或多个数据存储器中以供将来分析。例如，流处理服务器系统200可被配置为经由接口(例如apache kafka)向出口服务器系统400输出实时数据。流处理服务器系统200还可被配置为将实时数据和批量数据存储在数据存储器107中。数据存储器107中的数据可被访问或提供给insight服务器系统500以用于进一步分析。
[0057]
在至少一个实施方案中，事件信息可被存储在一个或多个数据存储器107中，以用于以后的处理和/或分析。同样地，在至少一个实施方案中，可以在确定或接收事件数据和信息时对其进行处理。此外，可将事件有效载荷和流程信息存储在数据存储器中，诸如数据存储器107，以用作历史信息和/或比较信息并用于进一步处理。
[0058]
在至少一个实施方案中，流处理服务器系统200被配置为执行车辆事件数据处理。
[0059]
图3示出了根据至少一个实施方案的流处理服务器系统200的逻辑架构和概览流程图。在方框202处，流处理服务器系统200对来自入口的位置201的位置事件数据执行验证。格式不正确、重复或无法识别的数据将被过滤掉。示例性无效数据可包括，例如，具有错误字段、无法识别字段或相同事件(重复)的数据或在相同地点和时间发生的发动机启动/发动机关闭数据点。验证还包括延迟检查，丢弃早于预定时间段(例如7秒)的事件数据。在实施方案中，可采用其他延迟过滤器，例如在4秒至15秒之间。
[0060]
在实施方案中，如图7中的方框703所示，流处理服务器系统200被配置为执行属性边界过滤。属性边界过滤检查以确保事件数据属性在对数据有意义的数据预定义边界内。例如，航向属性被定义为圆(0—359)。squish-vin是9个至10个字符的vin。示例包括由数据提供方预定义的或由标准设置的数据。不在这些边界内的数据值表示该数据对于该属性是固有错误的。可检查并过滤掉不合格的数据。表格3给出了示例性的属性边界过滤。
[0061][0062]
表格3
[0063]
在实施方案中，在方框704处，系统被配置为执行属性值过滤。属性值过滤检查以确保属性值在内部设置或自定义范围。例如，虽然1970年的日期可以通过事件的日期属性的属性边界过滤检查，但对于车辆跟踪数据来说，该日期并不是合理的值。因而，属性值过滤被配置为过滤早于预定时间(例如6周或更早)的数据，这些数据可被检查和过滤。表格3给出了示例性的属性边界过滤。
[0064][0065]
表格3
[0066]
在方框705处，系统可对记录中的属性执行进一步验证，以确认记录数据点的属性之间的关系是一致的。例如，非零行程开始事件对于如本文所述的行程确定没有逻辑意义。系统10可被配置为过滤为相同属性记录的非零速度事件，以获取作为“tripstart”或行程点火启动事件的位置的捕获的时间戳和接收的时间戳。
[0067][0068]
返回图2，在方框204处，在至少一个实施方案中，流处理服务器200对位置事件数据执行地理哈希。尽管可以使用地理哈希的替代方案，例如ubertm所采用的h3算法或googletm所采用的s2算法，但人们发现地理哈希为系统10提供了示例性的改进，例如系统延迟和吞吐量的改进。地理哈希还为系统10准确性和车辆检测方面提供了数据库改进。例如，使用精确度为9个字符的地理哈希可允许车辆与地理哈希唯一地关联。可在如本文所述的行程确定算法中采用此种精确度。在至少一个实施方案中，事件数据中的位置数据被编码为邻近区域，该编码包括将每个事件的纬度和经度地理哈希为每个事件的邻近区域。事件数据包括时间、位置(纬度/经度)和关注事件数据。关注事件的数据可包括紧急制动和紧急加速。例如，紧急制动可被定义为在预定时间段内的减速(例如在x秒内，从40到0)，紧急加速被定义为在预定时间段内的加速(例如在x秒内，从40英里/小时到80英里/小时)。可关联和处理关注事件数据，以便在其他算法中使用。例如，在位置上映射到时空集群的紧急制动集群可用作拥塞检测算法。
[0069]
地理哈希算法将来自事件数据的纬度和经度(lat/long)数据编码为n个字符的短字符串。在实施方案中，地理哈希的纬度/经度数据被地理哈希为形状。例如，在实施方案中，纬度/经度数据可被地理哈希为矩形，该矩形的边与字符串中的字符成比例。在实施方案中，地理哈希可被编码为4个至9个字符。
[0070]
采用如本文所述的地理哈希的事件数据具有许多优点。例如，在数据库中，由地理哈希索引的数据将具有连续切片中给定矩形区域的所有点，其中，切片的数量由编码的地理哈希精确度决定。这通过允许对单个索引进行查询来改进数据库，这比多索引查询更容易或更快。地理哈希索引结构对于简化的邻近区域搜索也很有用，因为最近的点通常在最近的地理哈希中。
[0071]
在方框206处，在至少一个实施方案中，流处理服务器系统200执行位置查找。如上所述，在实施方案中，系统可被配置为对地理哈希进行编码以识别定义的地理区域，例如国家、州或邮政编码。系统可将纬度/经度地理哈希为矩形，该矩形的边与字符串中的字符成比例。
[0072]
例如，在实施方案中，地理哈希可被配置为将地理哈希编码为5个字符，并且系统可被配置为将州识别为5个字符的地理哈希的位置。例如，编码为精确度为5个切片或字符的地理哈希精确到 /-2.5公里，这足以识别州。6个字符的地理哈希可用于将地理哈希的位置识别为邮政编码，因为它精确到 /-0.61公里。4个字符的地理哈希可用于识别国家/地区。在实施方案中，系统10可被配置为对地理哈希进行编码以唯一地识别具有地理哈希的位置的车辆。在实施方案中，系统10可被配置为将地理哈希编码为9个字符以唯一地识别车
辆。
[0073]
在实施方案中，系统10还可被配置为将地理哈希的事件数据映射到地图数据库。地图数据库可以是例如关注点的数据库或其他地图数据库，包括公共的或专有的地图数据库。示例性地图数据库可包括现存的街道地图数据，诸如用于当地街道地图的geofabric或世界地图数据库。采用如本文所述的地理哈希的示例性优势在于在下游处理时允许更快的、延迟较低且丰富的车辆事件数据。例如，地理定义、地图数据和其他丰富内容可以轻松地映射到地理哈希的位置和车辆id。也可以将馈送数据组合成聚合的数据集并使用界面使其可视化，例如gis可视化工具(例如：mapbox、carto、arcgis或google maps api)或其他界面来生成和连接图形报告或将报告输出给第三方15，该第三方使用经处理的数据生成分析见解，例如，经由出口服务器系统400或门户服务器系统600。
[0074]
在至少一个实施方案中，在方框208处，流处理器服务器系统200可被配置为将数据匿名化以删除识别信息，例如，通过移除或模糊事件数据中的车辆数据的车辆识别号(vin)中的个人识别信息。在各种实施方案中，事件数据或其他数据可包括vin编码，其包括代表车辆的产品信息的编号，例如品牌、型号和年份，还包括唯一地识别车辆以及可用于将其识别为属于某个车主个人的字符。系统10可包括算法，例如从车辆数据中删除vin中唯一地识别车辆的字符，但留下其他识别序列号(例如品牌、型号和年份)的算法，例如squish vin算法。在实施方案中，系统10可被配置为向匿名化的数据添加唯一的车辆标签。例如，系统10可被配置为向匿名化的数据添加唯一的编码、字符或其他识别信息，以便在删除了与vin相关联的个人识别信息之后，可跟踪、处理和分析唯一车辆的事件数据.匿名化的数据的示例性优点在于匿名化的数据允许在外部提供经处理的事件数据，同时仍然保护数据中的个人识别信息，例如可能是法律要求的或用户可能希望的信息。
[0075]
在至少一个实施方案中，如本文所述，9个字符的地理哈希还可提供车辆的唯一识别而无需获得或需要个人标识信息，诸如vin数据。可通过处理数据库事件数据来识别车辆，并且将其地理哈希到可识别独特的车辆的足够精确度，例如编码到9个字符，然后可识别、跟踪车辆，并如本文所述的对它们的数据进行处理。
[0076]
如上所述，对于实时流处理，在方框202处，数据验证过滤掉具有过长延迟的数据，例如超过7秒的延迟。但是，批量数据处理可在没有空白的情况下通过完整的数据集运行，因此可包括未过滤延迟的数据。例如，如关于图5所示的用于分析的批量数据处理可被配置为接受长达6周的数据，而流处理服务器系统200的流堆栈被配置为过滤超过7秒的数据，并且因此包括在方框202处的延迟验证检查，并拒绝具有更高延迟的事件。
[0077]
在实施方案中，在方框212处，过滤了延迟的转换的位置数据和被拒绝的延迟数据两者均被输入到服务器队列中，例如apache kafka队列。在方框214处，流处理服务器系统200可将数据拆分成数据集，该数据集包括完整数据216——过滤了延迟的转换的位置数据和被拒绝的延迟数据——以及转换的位置数据的另一个数据集222。完整数据216存储在数据存储器107中，以用于访问或传送到分析服务器系统500，而过滤后的转换的位置数据被传送到出口服务器系统400。在另一个实施方案中，也可以将包括被拒绝的数据的完整数据集或其部分传送到用于第三方平台的出口服务器系统400，以供其自身使用和分析。在此类实施方案中，在方框213处，可将过滤了延迟的转换的位置数据和被拒绝的延迟数据直接提供给出口服务器系统400。
[0078]
图4是出口服务器系统400的逻辑架构。在至少一个实施方案中，出口服务器系统400可以是被布置为摄取、吞吐记录和输出事件数据的一台或多台计算机。出口服务器系统400可被配置为基于推或拉的方式提供数据。例如，在实施方案中，系统10可被配置为采用apache spark集群的推送服务器410。推送服务器可被配置为处理来自流处理服务器系统200的转换的位置数据，例如，用于延迟过滤411、地理过滤412、事件过滤413、转换414和传输415。如本文所述，地理哈希极大地改善了系统10的吞吐量延迟，这使得在接近事件的情况下(例如在几分钟甚至几秒钟内)，处理的数据能够得到及时推送通知的优势。例如，在实施方案中，系统10被配置为以低于60秒的延迟为目标。如上所述，流处理服务器系统200被配置为过滤延迟少于7秒的事件，并且还提高了吞吐量。在实施方案中，可经由api网关404提供用于拉取数据的数据存储器406，并且拉取api 405可跟踪哪些第三方15用户正在拉取数据以及用户正在请求什么数据。
[0079]
例如，在实施方案中，出口服务器系统400可基于由系统10提供的过滤器提供模式数据。例如，系统可被配置为提供地理围栏过滤器412来过滤给定位置的事件数据。提供地理围栏过滤器412以过滤一个或多个给定位置的事件数据。如将理解的，地理围栏可被配置为如本文所述的针对多种模式和配置界定和处理行程和事件数据。例如，在实施方案中，出口服务器系统400可被配置为提供“停车”过滤器，该过滤器被配置为将数据限制在由用户提供或选择的经度/纬度范围内的行程的开始和结束(点火-钥匙打开/关闭事件)。可配置此数据的更多过滤器或例外情况，例如按州(州代码或纬度/经度)。系统10还可被配置有“交通”过滤器以提供交通模式数据，例如，具有从过滤器中排除的给定州和纬度/经度边界框。
[0080]
图5表示用于数据分析和见解的分析服务器系统500的逻辑架构。在至少一个实施方案中，分析服务器系统500可以是被布置为分析事件数据的一台或多台计算机。实时数据和批量数据两者均可被传递到分析服务器系统500，用于本文阐述的其他部件进行的处理。在实施方案中，分析服务器系统500可采用集群计算框架和批量处理器，诸如结合了批量数据处理和流数据处理的apache spark集群。提供给分析服务器系统500的数据可包括，例如来自入口服务器系统100、流处理服务器系统200和出口服务器系统400的数据。
[0081]
在实施方案中，分析服务器系统500可被配置为接受可存储在数据存储器(诸如数据存储器107)中的车辆事件有效载荷和经处理的信息。如图5所示，存储包括来自出口服务器系统400的实时出口的数据、来自流处理服务器系统200的转换的位置数据和拒绝的数据、以及来自入口服务器系统100的批量和实时原始数据。如图2所示，存储在数据存储器107中的入口的位置可被输出或拉入分析服务器系统500。分析服务器系统500可被配置为以与图2所示的流处理服务器系统200相同的方式处理入口的位置数据。如上所述，流处理服务器系统200可被配置为将数据拆分成完整数据集216，完整数据集216包括完整数据(过滤了延迟的转换的位置数据和被拒绝的延迟数据)以及转换的位置数据222的数据集。完整数据集216存储在数据存储器107中，以用于访问或传送到分析服务器系统500，而过滤后的转换的位置数据被传送到出口服务器系统400。如图5所示，可处理实时过滤的数据以用于近乎实时的上报，包括性能522、入口与出口524、操作监控526和警报528的报告。
[0082]
因而，在图5的方框502处，在至少一个实施方案中，可选地，分析处理服务器系统500可被配置为以与图2中的方框202和图7中的方框701至705所示相同的方式对来自入口
的位置的原始位置事件数据执行验证。在实施方案中，如图7所示，在方框706处，系统10可以采用记录的批处理来对多个事件记录的属性执行进一步的验证，以确认事件数据点的属性之间的内部记录关系是有意义的。例如，如表格5所示，系统10可被配置为分析所分析的数据点以确保行程事件的逻辑顺序(例如：行程的行程事件交替“tripstart-tripend-tripstart”并且不重复“tripstart-tripstart-tripend-tripend)”。
[0083][0084]
表格5
[0085]
参照图5的方框504，在至少一个实施方案中，可选地，分析服务器系统500可被配置为对如图2，方框204所示的位置事件数据执行地理哈希。在图5的方框506处，可选地，分析服务器系统500可执行位置查找。在图5的方框508处，可选地，分析服务器系统500可被配置为执行设备匿名化，如图2的方框206和方框208所示。
[0086]
在方框510处，在至少一个实施方案中，分析服务器系统500对事件数据执行行程分段分析。在实施方案中，系统10被配置为从事件数据识别车辆的行程，包括识别给定车辆的路线或运动是否是出于驾驶到行程目的地的目的，其中，该行程识别包括：识别车辆的发动机启动或第一次运动；识别车辆的发动机关闭或停止运动；确定车辆的停留时间；以及确定最短行驶持续时间。
[0087]
在至少一个实施方案中，行程可包括从起点到最终目的地的一个或多个行程分段。行程分段包括车辆的发动机启动/开始运动和发动机关闭/停止运动事件之间的行驶持续时间和距离。
[0088]
然而，真实的驾驶员在前往目的地时可能有一个或多个停靠点。行程可以有两个或多个行程分段，诸如当有多个停靠点的行程时。例如，驾驶员在从家去上班时可能需要停下来加油或在红绿灯处停车。因此，车辆事件分析中的问题和挑战包括为如本文所述的实施方案开发准确的车辆跟踪。尽管本领域中已经采用了其他行程算法或处理，例如，对从已识别车辆的已知目的地出发的行程进行反向工程，本公开包括使用如本文所述的技术为不可知的车辆跟踪而开发和有利实施的实施方案和算法，包括数据分析、数据库、接口、数据处理和其他技术产品。
[0089]
在方框512，分析服务器500被配置为执行计算以依据事件信息限定行程。在实施方案中，系统10被配置有行程检测标准，包括持续时间标准、距离标准和停留时间标准。在至少一个实施方案中，持续时间标准包括最短持续时间标准，其中，系统需要最短行驶持续时间以在行程中包括行程分段。在发动机启动或开始运动之后的最小行驶持续时间可包括行驶持续时间，例如，约60秒至约90秒。在示例性实施方案中，系统10可被配置为要求车辆行驶超过60秒，以便将其包括为行程分段。例如，如果识别了车辆的(1)发动机启动/点火事件，或(2)已识别车辆在已知的(例如，前一次旅程或行程的)最后一次运动之后的第一次运
动，或(3)新识别的车辆的第一次运动，并且该事件之后的短持续时间行驶少于60秒，系统10被配置为从行程确定中排除该行程分段。系统10被配置为确定车辆的短持续时间运动不是行程开始或目的地。
[0090]
在实施方案中，行程检测标准包括行驶距离标准，例如200米。系统10可被配置为从行程分段中排除200米或更短的距离。最短行驶距离标准可包括预定的行驶距离的持续间隔，例如，约100米至约300米。最短距离x(例如200米)可被定义为包括最短距离x的约50％容差的指数。
[0091]
在实施方案中，停留时间标准可包括车辆的停止时间。例如，停留时间标准可以是约30秒至约90秒。最长停留时间可包括同一车辆的发动机关闭/停止运动和发动机启动/开始运动之间的停止持续时间，例如，约20秒至约120秒。例如，如果系统10确定车辆停止或其发动机关闭少于30秒，则系统可被配置为不将该停止时段包括在行程结束或行程对象中。
[0092]
如上所述，在实施方案中，系统10被配置为处理车辆事件数据以确定一个或多个行程分段是否包括车辆的行程。例如，发动机启动或开始运动事件之后的距离可以超过距离标准(例如超过200米)。因此，系统的持续间隔标准将其识别为行程的分段。然而，如果该汽车此后停止并继续保持静止超过30秒，则系统10被配置为不将其计为行程的分段。如果车辆随后停止少于30秒然后再次运动，则满足停留时间标准，并且系统10被配置为将该行程分段包括在该车辆前往其最终目的地的行程中。因此，该算法可以将每天实时驾驶目的地的行程或行程对象的多个行程分段连接起来，例如，当驾驶员在家中启动汽车(发动机启动/开始运动)，行驶10英里(距离标准)，在红绿灯处停止29秒，继续行驶到工作中的最终目的地(发动机关闭/停止运动)时。然而，系统10被配置为忽略不太可能代表行程中断的事件，例如在红绿灯处停止29秒(停留标准)或运动少于200米(距离标准)或少于60秒(持续时间标准)。
[0093]
在实施方案中，例如，系统10可以基于可变数据包括用于停留标准、距离标准或时间标准中的每一者的多个标准。因此，该算法可以将普通实时驾驶到目的地的行程的多个行程分段连接起来，其中关于车辆和位置的附加数据是已知的。例如，如果车辆被识别为合法上路的电动车辆，例如电动汽车，则停留标准可包括在识别为充电站的位置处的最长停留时间标准为20分钟。因此，例如基于有关位置的其他数据(例如，指示停靠点是诸如加油站、休息区或餐厅之类的关注点的数据)，停留时间可延长至2分钟至20分钟之间。当电动汽车的驾驶员在家启动汽车(发动机启动或第一次运动)，行驶100英里(距离标准)到充电站进行充电(发动机关闭/停止运动、12分钟、停留标准、变量、充电站)，然后再次启动(发动机启动/开始运动)并继续行驶至销售会议的最终目的地(发动机关闭/停止运动)时，系统10可被配置为识别行程。因而，如将理解的，以上标准中的每一者可被配置为可变的，尤其取决于关于事件车辆数据点获取或获得的知识。
[0094]
在实施方案中，系统10被配置为根据上述标准为给定设备识别候选的行程分段链。此外，可以实例化复合旅程对象，其起点为链的起点，其终点为链中最后分段的终点。可以从事件数据中提取单独的行程对象表格，并且可将获取的复合行程生成到另一个表格中。在实施方案中，包括所有发动机启动/发动机关闭或开始运动/停止运动事件的数据集被标识为唯一的车辆id。例如，车辆的发动机启动/发动机关闭或开始运动/停止运动事件中的每一者可被放置在包括候选行程分段的单行上。然后，可以通过距离标准、持续时间标
准和停留标准中的每一者来处理发动机启动/发动机关闭或开始运动/停止运动事件的行，以确定可以从行程对象的行程确定中包括或排除哪些行程分段。在实施方案中，系统10可生成另一个行程表格，表格中填有依据满足上述行程标准的车辆的事件而确定的行程对象。
[0095]
在至少一个实施方案中，在方框514处，系统10被配置为通过分析车辆事件数据的数据库并将行程点汇总成具有诸如开始时间、结束时间、开始位置、结束位置、数据点计数、平均间隔等属性的行程对象来提供主动式车辆检测。在实施方案中，可以将行程对象放入单独的数据表格中进行处理。
[0096]
在示例性实施方案中，系统10可被配置为执行车辆跟踪，而无需预先识别车辆(例如，通过vin编号)。如上所述，可以对事件数据的数据库采用地理哈希以将数据地理哈希到9个字符的精确度，其对应于足以将事件与车辆唯一地相关的形状。在实施方案中，主动式车辆检测包括依据一段时间内的多项事件识别车辆路径。在实施方案中，主动式车辆检测可包括依据一天(24小时)的时间段内的多项事件识别车辆路径。该识别包括使用例如连通分量算法。在实施方案中，连通分量算法用于识别包含当天车辆事件的有向图中的车辆路径，其中，在该图中，节点是车辆并且节点之间的连接是识别的车辆路径。例如，创建行程起点和行程终点的图形，其中，节点代表起点和终点，边线是车辆采取的行程。在每条边线上，起点和终点按时间排序。创建边线以将终点连接到该节点的下一个起点，按时间排序。节点是gps坐标的9位数的地理哈希。连通分量算法查找连接的节点和边线的集合，并且在一天开始时将生成的设备id沿确定的子图传递，以唯一地识别由同一车辆采取的行程(边线)。
[0097]
本方法的示例性优点是无需预先识别事件数据的车辆。在满足如本文所述的行程标准的车辆路径中的行程分段可用于检测行程并排除如上所述的不合格的行程事件。例如，显示车辆相隔x秒(30秒)的时间内从停止运动/发动机关闭到开始运动/发动机启动的编码为9位数(最高分辨率)的事件数据的地理哈希可被视为行程的同一车辆。对于到达和离开的序列，可以通过图形将行程计算为行程分段的最短路径。
[0098]
在至少一个实施方案中，在方框515处，系统10可被配置为将事件数据和行程确定数据存储在数据仓库517中。可以以数据库格式存储数据。在实施方案中，时间列可被添加到处理的数据中。在实施方案中，数据库还可包括关注点(poi)的数据。
[0099]
分析服务器系统500可包括分析服务器部件516以对存储在数据仓库517中的数据执行数据分析，例如spark分析集群。分析服务器系统500可被配置为执行评估530、聚类531、人口统计分析532和定制分析533。例如，可以将日期列和小时列添加到数据以处理存储在仓库517中的行程数据和位置数据。这可以用于定制分析533，例如，根据日期和时间确定交叉口x处的车辆数量。系统10还可被配置为在出口服务器系统400处提供定制分析533，如图4所述。
[0100]
在实施方案中，可将地理空间索引行添加到存储的仓库517数据，例如，以执行超本地目标定位或加速对地理哈希的数据的即席查询。例如，解析为4位小数或4个字符的位置数据可对应20米或以下的分辨率。
[0101]
分析服务器系统500可被配置有诊断机器学习534，该诊断机器学习534被配置为对具有未识别字段的无效数据的数据库执行分析，以重新识别和标记字段以进行验证处理。
[0102]
在实施方案中，系统10可被配置为执行如方框510所述的行程分段的批量分析。例如，在图7的方框707处，行程分段提取可包括通过识别标有唯一id的所有事件进行简单的行程提取。行程分段提取及计数的示例如表格6所示。
[0103][0104]
表格6
[0105]
系统10还可被配置为使用如方框512所述的用于图7的方框708处的行程值过滤的行程标准来执行计算，以依据事件信息限定行程。行程值过滤的示例如表格7所示。
[0106][0107]
表格7
[0108]
在实施方案中，可处理批量数据以用于系统性能上报535。例如，在实施方案中，系统10可被配置为生成关于系统延迟的报告。针对捕获的和接收的时间戳数据之间的百分比范围进行的批量分析延迟上报的示例如表格8所示。系统10可被配置为对潜在数据执行间隔分析。针对百分比范围进行的间隔/捕获率上报的示例如表格9所示。
[0109][0110]
表格8
[0111][0112]
表格9
[0113]
图6是门户服务器系统600的逻辑架构。在至少一个实施方案中，门户服务器系统600可以是被布置为摄取和吞吐记录和事件数据的一台或多台计算机。门户服务器系统600可被配置有门户用户界面604以及用于门户api 608的api网关606，以与平台第三方15用户进行连接并接受其数据在实施方案中，门户服务器系统600可被配置为提供每日静态聚合并被配置有搜索引擎和访问门户，用于实时访问由分析服务器系统500提供的数据。在至少一个实施方案中，门户服务器系统600可被配置为向用户(例如，向第三方15客户端计算机)提供仪表板。在至少一个实施方案中，来自分析服务器系统500的信息可流向由门户用户界面604提供的报告生成器。在至少一个实施方案中，报告生成器可被布置为基于性能信息生成一个或多个报告。在至少一个实施方案中，可基于一个或多个报告模板来确定报告并使报告格式化。
[0114]
图7是示出了如上所述的数据处理的数据流水线的流程图。如图7所示，在实施方案中，事件数据通过七(7)个阶段的数据质量检查流水线来传递数据。此外，采用流处理和批处理两者进行数据处理。流式处理一次对一条记录进行操作，不保存行程的任何先前记录的上下文，并且可用于在属性和记录级别执行的检查。批处理可查看更完整的数据，并且可包含完整的端到端流程。批处理执行与流式处理相同的检查以及对跨多个记录和行程执行的检查。
[0115]
在至少一个实施方案中，仪表板显示器可呈现由系统10的其他部件产生的信息的显示。在至少一个实施方案中，仪表板显示器可呈现在通过网络访问的客户端计算机上。在至少一个实施方案中，可在不脱离要求保护的主题事项的精神和/或范围的情况下采用用户界面。此类用户界面可具有任意数量的用户界面元素，这些元素可以以各种方式布置。在一些实施方案中，可使用网页、移动应用程序、gis可视化工具、映射界面、电子邮件、文件服务器、pdf文档、文本消息等来生成用户界面。在至少一个实施方案中，入口服务器系统100、流处理服务器系统200、出口服务器系统400、分析服务器系统500或门户服务器系统600可包括用于生成用户界面的流程和/或apf。
[0116]
如本文所述，系统10、流程和算法的实施方案可被配置为在网络服务平台主机上运行，诸如亚马逊网络服务或微软云计算体系结构被配置为方便地按需
网络访问可配置的计算资源的共享池(例如网络、网络带宽、服务器、处理、内存、存储、应用程序、虚拟机和服务)。云计算机平台可被配置为允许平台提供方根据需要自动单方面提供计算能力，诸如服务器时间和网络存储，而无需与服务提供方进行人工交互。此外，云计算通过网络提供，并通过标准机制进行访问，这些机制促进异构瘦客户端平台或胖客户端平台(例如，移动电话、膝上型电脑和pda)的使用。在云计算架构中，可使用多租户模型来池化平台的计算资源，以为多个消费者、合作伙伴或其他第三方用户提供服务，并根据需求动态地分配和重新分配不同的物理资源和虚拟资源。还配置了云计算架构，使得可快速、弹性地(在某些情况下，自动地)提供平台资源，以快速向外扩展，并快速释放以快速向内扩展。
[0117]
云计算系统可被配置有通过利用适合于服务类型(例如，存储、处理、带宽和活跃用户帐户)的某种抽象级别的计量能力来自动控制和优化资源使用的系统。可监视、控制和报告资源使用情况。如本文所述，在实施方案中，系统10有利地由平台提供方配置为具有为低延迟而配置的创新算法和数据库结构。
[0118]
云计算架构包括多个服务和平台配置。
[0119]
软件即服务(saas)被配置为允许平台提供方使用在云基础设施上运行的提供方的应用程序。可通过瘦客户端界面，诸如网页浏览器(例如，基于网页的电子邮件)从各种客户端设备访问应用程序。消费者通常不管理或控制底层云基础设施，包括网络、服务器、操作系统、存储，甚至单个应用程序功能，但有限的特定于用户的应用程序配置设置可能除外。
[0120]
平台即服务(paas)被配置为允许平台提供方将消费者创建或获取的应用程序部署到云基础设施上，该应用程序使用提供方支持的编程语言和工具创建。消费者不管理或控制底层云基础设施，包括网络、服务器、操作系统或存储器，但可控制部署的应用程序和可能的应用程序托管环境配置。
[0121]
基础设施即服务(iaas)被配置为允许平台提供方提供处理、存储、网络和其他基本计算资源，其中消费者能够部署和运行包括操作系统和应用程序在内的任意软件。消费者不管理或控制底层云基础设施，但可控制操作系统、存储、部署的应用程序，以及可能对选定网络部件(例如主机防火墙)的有限控制。
[0122]
云计算架构可被提供为私有云计算架构、社区云计算架构或公共云计算架构。云计算架构也可被配置为包括两个或多个云平台(私有、社区或公共)的混合云计算架构，这些云平台仍然是独特的实体，但通过标准化或专有技术绑定在一起，实现数据和应用程序的可移植性(例如，用于云之间的载荷平衡的云爆发)。
[0123]
云计算环境是面向服务的，侧重于无状态性、低耦合、模块化和语义互操作性。云计算的核心是包括互连节点网络的基础设施。
[0124]
现在参照图8，示出了图示性云计算环境50。如图所示，云计算环境50包括一个或多个云计算节点30，具有云消费者使用的本地计算设备，例如个人数字助理(pda)或蜂窝电话23、台式计算机21、膝上型计算机22和事件，诸如oem车辆传感器数据源14、应用程序数据源16、远程信息处理数据源20、无线基础设施数据源17和第三方数据源15和/或汽车计算机系统，诸如车辆数据源12。节点30可以相互通信。它们可以在一个或多个网络，诸如本文所述的私有云、社区云、公共云或混合云或其组合中物理地或虚拟地分组(未示出)。云计算环境50被配置为提供云消费者无需在本地计算设备上维护资源的基础设施、平台和/或软件
即服务。应当理解，图9中所示的计算设备的类型仅旨在说明，并且计算节点30和云计算环境50可通过任何类型的网络和/或网络可寻址连接(例如，使用网页浏览器)与任何类型的计算机化设备通信。
[0125]
现在参照图9，示出了云计算环境50(图8)提供的一组功能抽象层。图9所示的部件、层和功能是说明性的，本文所述的实施方案不限于此。如图所示，提供了以下层和相应的功能：
[0126]
硬件和软件层60可包括硬件和软件部件。硬件部件的示例包括，例如：大型机61；服务器62；服务器63；刀片服务器64台；存储设备65；以及网络部件和联网部件66。在一些实施方案中，软件部件包括网络应用服务器软件67和数据库软件68。
[0127]
虚拟化层70提供了抽象层，从该抽象层可以提供以下虚拟实体的示例：虚拟服务器71；虚拟存储器72；虚拟网络73，包括虚拟专用网络；虚拟应用程序和操作系统74；和虚拟客户端75。
[0128]
在一个示例中，管理层80可提供以下所述的功能。资源供应81提供用于在云计算环境中执行任务的计算资源和其他资源的动态采购。计量和定价82提供了在云计算环境中使用资源时的成本跟踪，以及对这些资源的消耗进行计费或开票。在一个示例中，这些资源可包括应用程序软件许可证。安全性为云消费者和任务提供身份验证，以及对数据和其他资源的保护。用户门户83为消费者和系统管理员提供对云计算环境的访问。服务水平管理84提供云计算资源分配和管理，以满足所需的服务水平。服务水平协议(sla)规划和履行85根据sla预测未来需求的云计算资源提供预先安排和采购。
[0129]
工作负载层90提供了可利用云计算环境的功能的示例。可从该层提供的工作负载和功能的示例包括映射和导航91；入口处理92，流处理93；门户仪表板传送94-相同编号；数据分析处理95；以及出口和数据传送96.
[0130]
虽然本公开描述了关于云计算平台的实施方案，但是如本文所述的实施方案的实现不限于云计算环境。
[0131]
结合图1至图9描述的关于系统10、系统50、系统100、系统200、系统400、系统500、系统600和系统700的实施方案可由单台网络计算机实现和/或在单台网络计算机上执行。在其他实施方案中，这些流程或这些流程的部分可由多台网络计算机实现和/或在多台网络计算机上执行。同样地，在至少一个实施方案中，关于系统10、系统50、系统100、系统200、系统400、系统500和系统600或其部分描述的流程可在可利用的网络计算机、客户端计算机、虚拟机等的一种或多种不同组合上操作。此外，在至少一个实施方案中，结合图1至图9描述的流程可在具有诸如也结合图1至图9描述的逻辑架构的系统中操作。
[0132]
应当理解，流程图的每个方框，以及流程图中的方框的组合，可由计算机程序指令实现。可将这些程序指令提供给处理器以产生机器，使得在处理器上执行的指令创建用于实现在流程图方框或方框中指定的动作的装置。计算机程序指令可由处理器执行以使得处理器执行的一系列操作步骤产生计算机实现的流程，使得在处理器上执行的指令提供用于实现在流程图方框或方框中指定的动作的步骤。计算机程序指令还可使流程图的方框中所示的至少一些操作步骤并行执行。此外，一些步骤还可以跨多个处理器执行，诸如可能出现在多处理器计算机系统中，甚至可能出现在一组多计算机系统中。此外，在不脱离本公开的范围或精神的情况下，流程图中的一个或多个方框或方框的组合也可以与其他方框或方框
的组合同时执行，甚至以与所示出的不同的顺序执行。
[0133]
因而，流程图的方框支持用于执行指定动作的组合、用于执行指定动作的步骤的组合以及用于执行指定动作的程序指令装置。还应理解，流程图的每个方框以及流程图中的方框的组合可由基于专用硬件的系统来实现，该系统执行指定的动作或步骤，或者专用硬件和计算机指令的组合.前述示例不应被解释为限制性和/或详尽无遗的，而是说明性用例以示出各种实施方案中的至少一者的实施方式。