本申请要求2016年1月11日提交的第62/277,417号临时申请的权益。
本文涉及一种“查询即服务”系统，该系统代表远程客户端计算机针对由实时经处理的数据流式传输系统子部件提供的经处理的数据连续地执行查询，该实时经处理的数据流式传输系统子部件从大量的远程处理器控制的且联网的对象和实体生成经处理的数据。
背景技术
在过去几十年中，现代分布式计算机系统的带宽、复杂性和容量大大地增大。数百万个人计算机、移动设备和其他处理器控制的用户装备当前在全球范围内通过互联网彼此互连，并且与向处理器控制的用户装备的用户提供娱乐内容、信息、服务、零售商交易和其他服务的成千上万的分布式计算系统互连。电子商务和电子市场已经从20世纪90年代首次出现的相对较小和粗糙的初始零售网站发展到处理相当大比例的零售和商业交易。
分布式计算实现的服务和零售的兴起和快速发展产生了许多额外的电子服务和服务提供系统的类型。作为一个示例，电子零售商通常使用第三方web分析服务，以便收集关于用户与网站交互的数据，并分析数据，从而提高网站的零售效率。在某些情况下，第三方web分析服务向html文件、脚本文件和网页的其他类型的编码插装代码(instrument)，然后接收和处理由在远程用户装备上的用户浏览器内执行的插装代码(instrumentation)向web分析服务提供商数据中心转发的数据。web分析服务提供商通常还向客户端提供设计和运行各种类型的实验的能力，在这些实验的上下文下插装代码产生的数据被收集并随后用于设计、改进和部署各种类型的有效且高效的网站。电子商务零售商和电子服务提供商继续寻求新型的数据收集和数据分析方法和系统，以推进其在电子商务和其他类型电子服务方面的目标。
物联网的出现对由与数据处理系统传送数据的许多不同类型的实体所生成的大量数据的高效处理产生了巨大的需求。为了向电子商务零售商和电子服务提供商提供数据而开发的实时经处理的数据流式传输子系统仅提供处理物联网产生的大量数据量所需的功能的一部分。因此，涉及物联网的研究人员、开发人员、系统设计人员和应用设计人员继续寻求具有足够容量和带宽的数据收集解决方案以处理由物联网产生的大量数据，并且该数据收集解决方案能够提供将大量数据用于分析、实时控制和其他实际目的所需的数据处理功能。
技术实现要素：
本文涉及“查询即服务”系统(“qaas系统”)，该系统从联网实体(在短语“物联网”中称为“物”)收集大量数据、持久地存储收集的数据，并提供分布式查询执行引擎，该引擎允许远程客户端对收集的数据(包括实时数据流以及持久地存储的数据)连续执行查询。在所描述的实现方案中，原始数据和查询结果二者都被持久地存储在qaas系统中，其中原始数据被存储长得多的时间段。由查询处理引擎生成的查询结果被安全地传输到qaas远程客户端，以便分发到客户端系统内的文件系统、存储设备、应用程序和其他数据接收器。
附图说明
图1例示了其中可以采用本文所涉及的方法和系统的电子商务环境。
图2例示了可以由当前公开的qaas系统的经处理的数据流式传输子系统实现的应用程序类型的示例。
图3提供了典型计算机系统(例如处理器控制的用户装备或数据处理中心内的服务器)的高级体系结构图。
图4a-图4d例示了接收和呈现由经处理的数据流式传输子系统提供的实时处理流式传输的数据的控制台或监视器型应用。
图5例示了子系统的一个实现方案中的高级部件和数据路径，该子系统将实时处理的数据从在处理器控制的用户装备上执行的web浏览器流式传输到控制台或监视器型应用，例如上面参考图2和4a-4d所讨论的控制台或监视器型应用。
图6示出了存储在每个远程计算机系统的存储器内的cookie或小数据结构，该远程计算机系统被插装了代码以用于数据收集子系统进行的数据收集。
图7例示了由应用发送到处理中心的连接请求(作为通信套接字(socket)的打开的一部分)的json编码，以及处理中心响应于连接请求发送回应用程序的响应消息。
图8a-图8e例示了在图5所示的示例系统中的计算机之间传输的各种类型的数据消息。
图9a-图9b例示了通过插装代码收集并最终传递给处理中心产生的数据消息消费者的数据。
图10a-图10b例示了在将数据流引导到客户端应用之前由处理中心对数据流进行基于查询的过滤。
图11以类似于图5的方式例示了实时经处理的数据流式传输子系统的示例。
图12例示了在图5和11所示的实现方案中数据流式传输系统的客户端和处理中心之间的交互。
图13a-图13b提供了插入网页内的执行数据收集的插装代码的示例。
图14提供了描述浏览器内的如上参考图13a-图13b所讨论的事件生成过程的控制流程图。
图15例示了本文所涉及的实时经处理的数据消息流式传输系统和方法的一个实现方案。
图16例示了数据收集子系统的操作。
图17-图18提供了例示整合系统的操作的控制流程图。
图19-图23例示了处理中心的操作。
图24示出了可视地表示当前访问者的网站的示例监视器显示。
图25提供了结合有上述实时经处理的数据流式传输子系统的qaas系统的概览。
图26例示了qaas系统对数据的持久存储。
图27例示了向远程客户端系统内的qaas远程客户端传输查询结果。
图28例示了查询结果数据从qaas系统到qaas远程客户端的安全传输。
图29例示了qaas远程客户端进行的用户界面提供。
图30提供了实现qaas远程客户端的主事件循环的控制流程图。
图31提供了qaas系统的分布式部件的事件循环的控制流程图。
图32提供了查询处理引擎进行的查询处理的概览。
图33例示了由会话消息增强引擎实施的会话消息与外部数据的类似联接(join-like)的组合。
图34-图36例示了如何存储或存档由处理中心产生的会话消息流，以供在查询处理中的后续使用。
图35例示了存储在qaas系统中的存档会话消息数据。
图36例示了上面参考图34-图35讨论的每个盘或虚拟盘内的数据存储的细节。
图37a-图37d例示了查询处理引擎的操作。通常，查询处理引擎为它代表远程客户端执行的每个查询实例化查询处理子系统。
图38示出了一个示例聚合类型的查询。
图39例示了qaas系统对hyperloglog方法的使用。
图40例示了hyperloglog方法背后的一般原理。考虑具有n个不同元素的多重集4002。
图41-图43例示了如何在当前描述的qaas系统中使用hyperloglog方法计算聚合值。
图42例示了本地散列图与全局散列图的合并。
图43示出了分层散列图合并。
图44a-图44e提供了由qaas系统的查询处理引擎实施的查询处理的控制流程图。
具体实施方式
目前由电子商务零售商和其他电子服务提供商使用的web分析服务提供商和各种类型的web分析工具提供了数据消费系统的一个示例，其中这些web分析服务提供商和web分析工具被用于分析网站的性能以及用户与网站交互的特性，以便设计更好的网站和改进现有网站以实现特定目标。作为一个示例，对用户与电子零售网站的交互的分析可以允许电子零售商设计使得访问网站的更高百分比的用户购买产品和/或服务的的网站。目前，由网站编码(例如html文件和javascript例程)内的插装代码产生的数据被数据收集系统收集、电子地存储、并且然后由各种不同的分析工具和应用离线处理，以产生报告和分析。这些报告和分析为电子零售商和其他电子服务提供商提供了非常有价值的反馈。然而，由于这些报告和分析是离线生成和分发的，因此目前许多web分析服务和工具在向电子商务客户和其他电子服务提供商提供的信息类型方面受到限制和约束。此外，在电子商务和电子服务是相当动态的同时，与产生报告和分析相关的显著滞后时间目前阻碍了基于收集的数据提供实时、动态的反馈。
本文涉及一种qaas系统，该qaas系统包括作为部件子系统的经处理的数据流式传输子系统，该经处理的数据流式传输子系统将来自远程处理器控制的装备的实时数据(包括来自在远程用户处理器控制的设备中执行的web浏览器的实时数据)流式传输至数据消费者，数据消费者包括处理和呈现数据以供向网站所有者、电子商务组织、其他电子服务提供商和其他类型的客户端，以及qaas系统内的查询处理功能实时显示的应用。qaas系统的经处理的数据流式传输子系统启用各种不同类型的实时控制台和监视器，这些实时控制台和监视器向客户显示用于提供电子商务和其他电子服务的网站的高度动态和高度地理分散的操作的可视表示。经处理的数据流式传输子系统弥合了当前离线分析处理中固有的延迟间隔，从而允许对网站操作进行各种类型的实时分析。此外，还存在实时经处理的数据的许多其他类型的消费者，包括监控网站使用、为单个用户和用户组修改和定制网站、以及实时提供经修改和定制的网页和其他类型的信息的自动化系统。另外的数据消费者包括自动决策系统，其可以响应于根据实时流式传输数据作出的实时决策来发起许多不同类型的自动化过程。
“实时”在本文中指的是在两秒的平均时间间隔内在数百、数千、数百万或更多的地理上分散的远程的处理器控制的用户装备上收集数据并将包括所收集的数据的经处理的数据流式传输到数据消费应用、系统或设备的数据收集、数据处理和经处理的数据流式传输子系统。在某些实现方案中，从在远程处理器控制的用户装备上进行数据收集到由实时数据流消费者接收到包含该数据的经处理的数据消息的平均时间间隔是一秒半或更短。在某些实现方案中，从在远程处理器控制的用户装备上进行数据收集到由实时数据流消费者接收到包含该数据的经处理的数据消息的平均时间间隔是一秒或更短。数据收集、数据处理和经处理的数据流式传输子系统可以同时将一种或多种类型的一个或多个数据流引导到数十个、数百个、数千个或更多个数据消费者。
图1例示了其中可以采用本文所涉及的方法和系统的电子商务环境。在图1中，在处理器控制的用户装备(在该例子中是膝上型计算机102)内执行的web浏览器处理超文本标记语言(“html”)文件和其他资源文件，以在处理器控制的用户装备的显示设备上显示网页104。html和其他资源文件由浏览器经由超文本传输协议(“http”)请求106来请求，http请求106经由互联网108从处理器控制的用户装备102传输到web服务器系统110。web服务器系统110将所请求的html文件和其他资源文件返回到在处理器控制的用户装备内执行的浏览器，该浏览器执行并处理html文件和其他资源文件以产生所显示的网页104。web服务器系统110可以附加地经由互联网112从一个或多个远程计算机系统114获取信息，以转发到web浏览器。为了呈现特定网页，web浏览器可以将http请求引导到多个web服务器系统。在电子商务中，共同构成网站的一个或多个所显示的网页可以允许用户查看产品的照片和描述、实施基于文本的对产品和服务的搜索、以及通过安全电子商务交易来购买产品和服务，以及进行其他活动。网站还可以允许在用户和网站之间交换信息，并且可以充当门户或跳转点，用户通过该门户或跳转点导航到其他网站。
图1是当前描述的系统可以从其获取数据的许多不同类型的处理器控制的用户装备的一个示例。除了web浏览器外，这些系统还包括执行呈现html编码的信息以显示给用户的应用的系统，以及许多其他类型的信息呈现和信息传输系统，其控制子系统包括处理器执行的指令，数据收集插装代码被引入到这些指令中。插装代码可以被引入到从对大量不同类型的编程、脚本和其他类型的语言中的任何一种的编译或解释所产生的指令中。处理器控制的装备可以包括台式计算机、诸如膝上型电脑和平板电脑之类的移动计算机、移动电话、处理器控制的消费装备和车辆以及系统部件，但是也可以包括诸如射频标识(“rfid”)标签之类的更为低端的设备，以及执行存储在小型闪存或其他类型的非易失性存储器中的简单例程的许多其他类型的设备。在某些缺少处理器和处理器指令的低端设备中，硬件逻辑电路可以被插装代码以传输由数据收集子系统收集的信息。通常，处理器控制的装备需要与数据收集子系统通信地互连。经常地，互连是将处理器控制的装备连接到互联网的通信系统。
作为一个示例，经处理的数据流式传输子系统向一个或多个应用程序提供来自正在访问网站的网页的远程处理器控制的用户装备的实时流式传输的经处理的数据，或者由被添加到处理器指令序列或逻辑电路的插装代码提供的其他类型的信息。图2例示了可能由当前公开的qaas系统的经处理的数据流式传输子系统实现的应用程序类型的示例。在图2中，正在与处理器控制的用户装备进行交互的大量不同的、地理上分散的用户当前正在访问网站，所述用户装备包括个人计算机202-206、电子平板207-214、膝上型计算机215-217和移动电话218-221。图2所示的处理器控制的用户装备是潜在的成千上万或更多的处理器控制的用户装备的微小子集，用户当前可以通过这些用户装备从世界各地访问该网站。从由用户装备内的浏览器执行和呈现的html文件和其他资源文件内的插装代码实时收集的数据被处理，并且被流式传输到在计算机系统内运行的应用程序，该应用程序产生类似控制台或监视器的显示230。该应用程序呈现流式传输数据以产生动态的、不断变化的控制台或监视器230，在图2所示的示例中，该控制台或监视器230指示访问网站的当前用户的数量232、查看网站内的特定网页的用户的数量234-235、以及各种不同用户类别中的每一类别的用户数量236-237。由接收实时处理的流式传输数据的应用程序提供的类似控制台或监视器的显示230允许客户实时查看网站的全球范围操作的特性。这对于理解网站在任何特定时刻的功能和操作而言是非常动态和强大的工具。作为一个示例，这些类型的应用程序实现的控制台和监视器可以允许网站所有者、开发人员、管理员或其他客户跟踪世界上任何位置处的各个网站用户的活动。这提供了实时调整网站以便实时满足各个用户的需求的能力。
图3提供了典型计算机系统(例如处理器控制的用户装备或数据处理中心内的服务器)的高级体系结构图。计算机系统包含一个或多个中央处理单元(“cpu”)302-305、通过cpu/存储器子系统总线310或多个总线与cpu互连的一个或多个电子存储器308、将cpu/存储器子系统总线310与附加总线314和316互连的第一桥312、或包括多个高速串行互连的其他类型的高速互连介质。这些总线或串行互连又将cpu和存储器与诸如图形处理器318之类的专用处理器以及与一个或多个附加的桥320连接，这些附加的桥320与高速串行链路或与诸如控制器327之类的多个控制器322-327互连，这多个控制器322-327提供对各种不同类型的大容量存储设备328、电子显示器、输入设备以及其他这样的部件、子部件和计算资源的访问。
首先应该指出的是，本文涉及有形的物理系统和由有形的物理系统实施的方法，而不是针对某种抽象概念。本文所涉及的物理系统和方法包括用户计算机、在包括存储在物理存储器和/或大容量存储设备中的计算机指令的用户计算机内执行的web浏览器、实现互联网通信的通信系统、数据收集子系统、整合计算机系统、数据处理中心，以及最终执行接收流式传输数据并呈现流式传输数据以在电子显示设备上显示给客户的应用程序的客户端计算机。正如那些熟悉科学技术的人所理解的，这些复杂的系统不是抽象的，并且这些复杂的系统所实施的活动不可能由人类手动实施。虽然这些复杂系统的某些部分是由存储的计算机指令实现的，但是这些系统不能被表征为软件或抽象概念。还应该注意，正如那些熟悉科学技术的人所理解的那样，计算机指令不能存储在电磁辐射(例如通信信号)中。计算机指令和数字编码的数据只能存储在物理的数据存储设备中，例如电磁盘、光盘、电子存储器和其他这样的物理数据存储设备中。相反，电子信号和电磁辐射用于将计算机指令从一台计算机传输到另一台计算机。
图4a-图4d例示了接收和呈现由经处理的数据流式传输子系统提供的实时处理流式传输数据的控制台或监视器型应用。如图4a所示，所显示的控制台或监视器402显示新闻网站的实时读者信息。所显示的监视器的中央盘形部分404示出了世界地图，其中具有最大数量的当前浏览者的区域由暗像素和阴影盘指示，诸如区域406-408。大的数值410指示网站上每分钟的当前浏览者数量，其也由在监视器的当前实例化期间已经显示的每分钟浏览值范围414内的箭头状图标412指示。
环形部分显示条416指示当前在网站的各个部分内查看页面的浏览者的部分，其中浏览者的数量与指派给该部分的面积成比例。例如，最大数量的当前浏览者正在浏览“新闻(news)”部分418。其他部分包括“科技(tech)”、“生活(life)”、“世界(world)”、“文化(culture)”、“评论(comments)”、“金融(finance)”和“体育(sports)”。在监视器显示的主面板420中，在环形显示带416之外，上述部分的各个子部分中的每个子部分内的当前读者的数量由带标签的盘的面积表示，例如标签为“欧洲(europe)”的盘422。在监视器显示的右侧面板424中，前十篇当前最多浏览的文章以降序显示在条目中，这些条目包括照片、章节、标题和作者以及当前读者数量。当前时间和日期显示在主面板426的右上角。
图4b-图4d示出了在记录了图4a所示的监视器显示的屏幕截图的时间11:28:15之后的各个时间点的同一监视器显示的屏幕捕获。图4a-图4d例示了监视器显示的动态特性。例如，在图4a所表示的时间点，浏览最多的文章是妇女部分的关于道路安全的文章430。相比之下，24秒后，如图4b所示，浏览最多的文章是天气部分的关于一个女孩在风暴中死亡的文章432。另一个不同之处是将非洲的地区434识别为具有最多当前浏览者的地区之一，而在图4a中，非洲的该地区没有被识别为这样。在图4a-图4d的序列中可以观察到许多其他变化。
因此，图4a-图4d所示的显示监视器以视觉上引人注目的、动态的、易于理解的格式提供与新闻网站的全世界当前浏览者相关的即时实时数据。这种类型的信息可以用于为网站、针对特定地理区域、针对广告以及为许多其他这样的目的而选择文章。
图5例示了子系统的一个实现方案中的高级部件和数据路径，该子系统将实时处理的数据从在处理器控制的用户装备上执行的web浏览器流式传输到控制台或监视器型应用，例如上面参考图2和4a-4d所讨论的应用。初始地，当应用开始执行时，应用初始化各种数据结构，然后打开到处理中心的至少一个通信套接字。在图5中，类似控制台或监视器的应用502在由在计算机系统508内的硬件平台506之上执行的操作系统504提供的执行环境内执行。处理中心510通常是远程分布式计算机系统，其包括数十至数百台服务器计算机和其他类型的处理器控制的设备、系统和子系统。为了打开通信套接字并与处理中心进行通信，将发生以下高级步骤：(a)应用执行打开套接字系统调用520；(b)响应于该系统调用，操作系统创建打开套接字请求消息，并经由设备驱动器将该消息排队到通信控制器的输入队列中，并向通信控制器发信号以将该消息传输到处理中心521；(c)通信控制器控制收发器将打开套接字请求消息传输到在处理中心内的计算机上执行的监听进程522；(d)处理中心向计算机系统508内的收发器返回确认消息523；(e)向计算机508内的操作系统504通知接收到确认消息，并从存储器缓冲区检索确认消息524；以及(f)将确认消息传递到应用程序以指示通信套接字的成功打开525。各种不同类型的套接字请求和底层通信协议可以被用于在处理中心和应用之间建立通信链路。这些协议中的某些协议可能涉及实现握手操作的三个或更多不同消息。此外，在大多数通信系统中，在通信栈的不同级别之间交换各种不同类型的信息。当应用程序尝试打开套接字时，可能发生错误，错误的类型通常由处理中心向应用返回错误消息指出，或者由计算机系统508内的操作系统向应用返回错误指示来指出。
一旦套接字被打开，或者换句话说，在应用502和处理中心510之间建立了基于协议的通信链路，处理中心就开始通过通信套接字向应用程序发送数据消息流。该流持续到出现某种类型的流结束事件，例如由应用程序通过系统调用来关闭套接字、应用程序的终止或各种类型的故障和计算不连续性。应用程序可以选择打开到处理中心的两个或更多个不同的套接字，以便同时接收两个或更多个不同的数据消息流。
继续图5，接下来描述创建数据消息并将其传输到应用程序的过程。该系统取决于被引入到由web浏览器或其他类型的应用程序或控制程序使用的html文件和/或其他资源中的插装代码。在图5所示的示例中，该插装代码包括在html文件中，该html文件由web浏览器548处理以向远程计算机系统530上的远程用户呈现和显示网页。在示例中，用户正在浏览当前显示的网页532。在本示例中，发生以下事件：(1)用户按下键或点击鼠标按钮540，以便向web浏览器输入命令、进行选择或实施一些其他这样的输入；(2)用户输入由远程计算机系统542的硬件感测，该硬件生成到该远程计算机系统内的操作系统544的中断或其他信号；(3)操作系统接收中断并向远程计算机系统内的浏览器548通知546输入事件；(4)作为接收到输入的结果，浏览器执行脚本例程550，在脚本例程550中嵌入了用于收集数据的插装代码；(5)脚本内的插装代码以编程方式收集数据552，在统一资源定位符(“url”)内对该数据进行编码，并请求浏览器检索由url指定的远程资源；(6)浏览器执行对资源的http请求554，这会导致对操作系统544的系统调用；(7)操作系统创建请求消息，并将请求消息传递给通信设备控制器556，用于传输558到数据收集子系统560；(8)数据收集子系统从url请求中检索编码数据，并将数据封装在json编码的事件消息中；(9)该事件消息由数据收集子系统562传输到整合系统564；(10)整合系统将从许多不同的数据收集子系统接收到的事件消息整合到临时存储装置中，其中为与一个或多个不同客户端中的每一个客户端相对应的事件消息分配临时存储区域；(11)根据来自处理中心510的请求，整合系统将下一组事件转发566到处理中心进行处理；(12)处理中心510通过将导出和计算出的数据添加到事件消息中，并且在某些情况下，将各个事件消息聚合和合并成更高级别的消息，以及过滤消息以输出到每个连接/流，来处理接收到的事件消息；(13)属于应用程序所请求的流的那些经处理的消息由处理中心转发570到计算机系统508；(14)计算机系统的硬件层通知操作系统，并将接收到的一个或多个经处理的消息传递给操作系统572；(15)操作系统将接收到的经处理的消息通知并传递给应用程序574；(16)然后，该应用程序基于接收到的数据，使用该数据生成并更新到监视器显示或控制台显示，并将该更新576传递到操作系统；(17)操作系统控制图形处理器和硬件级的其他视频部件578更新监视器显示或控制台显示；以及(18)更新操作从图形子系统转移到显示设备580，导致监视器显示或控制台显示的更新。整合系统可以将收集的数据存储指定的时间段，在某些情况下，存储一周或更长时间，从而允许存储的数据被后续地流式传输或重新流式传输以用于各种目的。数据可以附加地在整合系统或处理中心内被存档以供后续检索、处理和流式传输。
数据收集子系统通常维护远程计算机系统内的状态信息，以便于数据收集和处理。图6示出了存储在每个远程计算机系统的存储器内的cookie或小数据结构，该远程计算机系统被插装了代码以用于数据收集子系统进行的数据收集。cookie602包括用于用户/处理器控制的装备604的唯一标识符、指示插装代码检测到的最新事件的系统时间戳606、以及指示包括该最新事件的会话开始的时间的会话开始时间戳608。用户/处理器控制的装备的标识(id)通常是ip地址和唯一地标识该用户/处理器控制的装备的其他号码的组合。指示最后检测到的事件或最后一次访问(lv)和会话开始(ss)的时间戳通常是指示自某个任意时间点以来经过的秒数或几分之几秒的系统时间值。cookie中包含的数据由插装代码使用以在url内对数据进行编码，以供传输到数据收集子系统以及后续对数据的下游处理。
图7例示了由应用发送到处理中心的连接请求(作为通信套接字的打开的一部分)的json编码，以及处理中心响应于该连接请求发送回应用程序的响应消息。在图7和后续的图中，包含一系列“x”符号的一对引号表示在json编码中发生对数据值的符号-串编码的位置。连接请求和连接响应包括许多键/值对。在连接请求中，外括号702-703表示由一个或多个键/值对组成的json对象。第一个键是“access_token”704，并且对应于该键的值706出现在冒号分隔符708之后的一对引号内。除了最终键/值对之外，每个键/值对都通过逗号(如第一个键/值对704、706和708之后的逗号710)与后续键/值对分离。访问令牌是从数据流式传输服务获得的符号串，作为允许应用程序访问数据流的凭证。键“command”712与从处理中心请求特定类型的动作或服务的符号-串值714(诸如符号串“stream”)相关联。键“stream_type”716与值718相关联，该值718指示应用程序希望通过通信套接字接收的流的各种类型之一。示例包括事件流和会话流。键“query”720与符号-串值722相关联，符号-串值722指定类似于结构化查询语言(“sql”)的查询，处理中心使用该查询来过滤数据消息和数据消息的内容，之后将经过滤的数据消息流引导到应用程序。“api_version”键/值对724和“schema_version”键/值对726向处理中心指定流应用程序接口(“api”)版本和查询语言版本。因为流api和查询语言可以被修改和更新以生成具有增大的版本号的一系列版本，所以这些键值对通知处理中心应用程序正在使用的api版本和应用程序用来创建包括作为“query”键/值对的值的查询的查询语言版本，从而允许处理中心适当地对连接请求进行响应。
连接响应消息730具有json编码的数据消息的形式。在所有json编码的数据消息中，在一个实现方案中，消息对象包括由符号串“meta”732指定的初始“meta”对象以及由括号734和736分隔的meta对象(元对象)内的多个键/值对。meta对象包括上面讨论的“api_version”键/值对和“schema_version”键/值对。此外，meta对象包括“message_type”键/值对738(其示例值包括“success”和“error”)，以及“stream_type”键/值对740(其值指定已经打开的数据流的类型，示例包括“event”和“session”)。在meta对象之后，连接响应包括响应键/值对742，该响应键/值对742具有指示成功或提供已经发生的错误的解释的值。json编码的连接请求作为打开套接字请求的一部分被传输到处理中心，并且处理中心响应于打开套接字请求返回json编码的连接响应消息。
图8a-图8e例示了在图5所示的示例系统中的计算机之间传输的各种类型的数据消息。如上面所讨论的，初始地由web浏览器内的插装代码收集的数据被编码为url内的一系列键/值对。图8a例示了由插装代码在url内生成的键/值对的编码。url802包括到往存储在数据收集服务器804上的资源的路径名，随后是问号805，然后是一系列分号分隔的键/值对806。在图8a和后续的图中，符号串“k1”、“k2”...用于指示不同的键，并且对应的值通常由一对单引号或双引号之间的一系列“x”符号来指示，例如图8a中指示与键“k1”和“k2”相对应的值的“x”符号串808和810。这些值可以是任何字母数字符号串，并且键名称也可以是任意字母数字符号串。
图8b例示了json编码的事件消息，该事件消息由数据收集子系统生成、被传输到整合系统以供存储、并从存储装置中被提取和传输到处理中心。json编码的事件消息包括先前参考图7讨论的“meta”对象812以及“data”对象，该“data”对象由符号串“data”814引入并包括括号对816-817内的键/值对和对象。“data”对象可以包括键/值对(例如键/值对818和820)以及对象(例如名为“wt”的对象822，其包括括号824-825内的键/值对)。键/值对可以包括由冒号分隔的两个符号串(例如键/值对826)，或者可以包括键，后跟冒号，接着是符号串阵列，例如键/值对828。符号串的阵列由方括号(例如一对方括号830)分隔。事件消息通常包括“meta”对象和“data”对象。
图8c例示了在处理中心(图5中的510)内产生的丰富化(enriched)事件消息。丰富化事件消息包括“meta”对象840、“data”对象842和“ext”对象844。“ext”对象包括三个较低级别的对象“geo”846、“device”848和“browser”850。geo(地理)对象包含描述用户/处理器控制的用户装备的地理位置的键/值对。device(设备)对象848包括表征用户/处理器控制的装备的键/值对。browser(浏览器)对象850包括表征用户使用的浏览器类型的键/值对。包含在“ext”对象844中的数据值是从包含在“meta”和“data”对象中的数据值以及处理中心可访问并用于事件消息丰富化的附加计算值和数据源导出的。多种类型的丰富化都是可能的。例如，丰富化事件消息可以包括用户位置处的当前天气的指示、用户所在的城镇或城市的大小、与用户相关的公共数据，和许多其他类型的信息。
图8d1-图8d3例示了会话消息。会话消息是包括会话信息以及“session_summary”对象和“event”对象的阵列的高阶消息。“meta”对象860与先前描述的事件消息中的“meta”对象相同。多个键/值对862描述会话相关信息。“session_summary”对象描述包括在会话消息中的事件数量以及与会话相关的其他信息864。最后，键/阵列对“events”866包括用于一系列事件中的每一个事件的传统丰富化事件数据。
json编码的数据消息内的数据可以替代地使用分层表示来描述。在图8e中提供了用于图8c所示的扩展事件消息的替代分层表示。“meta”对象内的键由以子串“meta”开始的串870指定。包含在data对象842中的键由以子串“data”开始的串872指定。包含在“ext”对象844中的键由以子串“ext”开始的符号串874指定。使用句点来分隔分层级别。例如，meta对象内只有一个分层级别，因此图8e的meta对象内的所有键都在子串“meta”和meta对象中包含的键/值对的键的名称之间包括一个句点。相比之下，在“wt”对象内出现的键(“wt”对象又位于“data”对象842内)包括两个句点876，以指示两个分层级别。图8e所示的分层键名称可以被认为是变量的名称，并且对应的值是存储在变量中的值。
图9a-图9b例示了通过插装代码收集并最终传递给处理中心产生的数据消息消费者的数据。在图9中，左侧列902表示可以在由web浏览器提供的执行环境中执行的脚本内通过插装代码收集的非常大量的不同类型的数据值。该列内的每个单元格都代表不同的数据值。可以从脚本访问或由脚本计算的几乎任何类型的数据值都是插装代码进行的数据收集的候选。数据值可以是由系统调用(例如对系统时间例程的调用或检索在其中执行web浏览器的计算机的ip地址的调用)产生的值。其他值包括指示网站上下文中显示的网页的特定状态的数据值，诸如用户当前访问的页、章节和子章节的指示，对网页的各种类型的输入事件的指示，用户在导航到当前网站时通过的其他网站的指示，用户请求并向用户显示的信息，以及与用户和网站的交互有关的许多其他类型的信息。如上参考图8e所讨论的，数据值被分层地命名，或者等效地，与在json编码的消息内编码的键符号序列相关联。在任一情况下，每个数据值都是唯一命名的，并且可以从由在远程用户计算机上执行的web浏览器传递到数据收集子系统的url内的参数中提取。
如上面所讨论的，参考图7，实时经处理的数据流式传输系统的客户端可以打开通信套接字以接收经处理的数据消息的流。可以请求不同类型的流。如图9所示，每个不同的流类型(例如流类型1)904表示可由插装代码收集的数据值的子集。因此，每个不同的流类型都标识数据值的不同子集，并因此表示一种数据过滤类型，该数据过滤类型使得通过特定通信套接字仅将可能数据类型的期望子集流式传输到特定客户端，而不是流式传输所有可能收集的数据并且要求客户端花费通信和处理带宽来接收和处理每个数据消息中的大量数据以便获得数据值的期望子集。
图9b例示了可以包括在流式传输至客户端的数据消息中的数据值的类型。这些数据值可以包括对所有数据消息公共的一组数据值910、对特定流类型唯一的一组数据值912、从由图9a中的列902表示的一组数据值中选择的附加的自定义选择的数据值914、以及由特定客户端指定的附加数据值916。在后几个数据值的情况下，插装代码被修改，以便收集未被包括在如图9a中的列902所示的、可以由实时经处理的数据流式传输服务内的现有插装代码收集的数据值中的客户端指定的数据值916。
图10a-图10b例示了在将数据流引导到客户端应用程序之前由处理中心对数据流进行基于查询的过滤。在图10a中，共同表示由流类型以及由客户端的自定义选择或定义指定的那些数据值的数据值集合由列1002表示，如它们在图9b中表示的那样。在将数据消息传输到被引导到客户端的数据消息流中之前，处理中心将客户端指定的查询1004应用于每个数据消息。该查询表示可以过滤掉整个数据消息或数据消息的一部分的第二级过滤器。在图10a所示的示例中，作为查询1004的结果，添加到被引导到客户端的流的最终数据消息1006仅包括由查询1004选择的meta对象数据值1008和四个附加数据值1010。查询可包括“select”子句、“where”子句或“select”子句和“where”子句两者。查询1004包括“select”子句1012和“where”子句1014，其中该“select”子句1012选择要包括在被流式传输至客户端的数据消息中的四个具体数据值，该“where”子句1014过滤掉除了包含与键“ext.geo.k20”相关联的数据值“louisiana”的数据消息之外的数据消息。
图10b例示了许多不同的查询。查询1020选择包括在特定流类型的传入数据消息中的所有数据值并选择所有传入数据消息，因为没有与该查询相关联的“where”子句。在查询中“*”符号是通配符，并且在查询1020中代表所有可能的键。查询1022选择要包括在被流式传输到在连接请求中发出了该查询的客户端的数据消息中的多个具体数据值。查询1024是类似的，但使用通配符来选择事件消息内的对象“data”和对象“geo”中的所有数据值。查询1026选择与具体会话相关的数据值和会话消息内的所有事件，但仅针对表示完整会话的那些会话消息，如“where”子句“wheresession.closed＝'true'.”所指定的那样。查询1028仅包括“where”子句，并且仅选择表示用户在其中没有从网站购买任何东西的会话的关闭的会话消息。查询语言是类似sql的，支持各种布尔连接符、圆括号、比较运算符和其他类似sql的常见查询语言特征。因此，处理中心表示qaas系统中可能发生的第一级查询处理。
图11以类似于图5的方式例示了实时经处理的数据流式传输子系统的示例。如前面所讨论的，数据收集发生在由运行在列1102所示的远程处理器控制的用户装备内的浏览器执行的html文件或脚本内。web浏览器发出对由url指定的资源的http请求，这些http请求被引导到各种不同的地理上分散的数据收集子系统1104-1106。数据收集子系统中的监听器进程接收资源的url规范中的符号“？”后面的参数串、从该参数串中的键/值对生成json编码的事件消息、并将该json编码的事件消息传输到整合系统1110和1111。
在一种实现方案中，整合系统包括大量的服务器，这些服务器以分布式方式执行kafka分布式消息传递系统。kafka是被开发用于以低延迟收集和递送大量的日志数据的分布式消息传递系统。kafka处理传入消息的流，将传入消息分成属于多个类别(称为“主题”)中的每一个类别的消息。实时经处理的数据流式传输子系统可以例如将收集的数据划分成若干个主题，每个主题都对应于不同客户组织。kafka进一步将主题划分为主题分区，每个主题分区都包括存储在存储器和/或大容量存储设备中的一组段文件。kafka还定义代理(broker)，这些代理是分布式进程，每个代理都可以处理针对特定一组主题和主题分区的传入消息。消息由生产者输入到kafka，因此数据收集子系统代表生产者。kafka系统聚合针对每个主题的传入消息，并将消息存储在段文件中以供消费者后续检索。一个或多个处理中心1114是由kafka分布式消息传递系统整合的消息的消费者。传入消息被追加到当前存储器内段文件。一旦段文件填满，它就会被转储(flush)到大容量存储装置中，此时，消息可以被置为对消费者可用。kafka将消息存储定义的时间段，通常在一周左右。在这段时间期间，消费者可以重复访问消息。一般而言，kafka分布式消息系统充当一种非常大的输入/输出队列，当用在实时经处理的数据流式传输系统中时，消息输入和消息消费之间的滞后时间大约为几秒或几分之几秒。
在一种实现方案中，实时处理的数据流式传输系统在处理中心内采用storm大数据处理系统。storm是最初被开发用于处理twitter消息的开源系统。storm是完全分布式的，并且具有高性能、容错和保证消息处理的特点。storm的概念模型是表示作为数据源的“喷口(spout)”和作为数据处理实体的“栓(bolt)”之间的互连的图表。喷口从整合系统中拉取数据消息，并将数据消息传递给一个或多个栓，每个栓都执行处理活动，包括丰富化、查询过滤和其他此类处理。喷口和栓通过通信路径互连，其中最下游的栓通过通信套接字向客户端应用发出经处理的数据消息。
接下来，参考大量控制流程图来讨论实时经处理的数据流式传输系统的操作。图12例示了在图5和11所示的实现方案中的经处理的数据流式传输子系统的客户端和处理中心之间的交互。如上面所讨论的，客户端通常是应用程序，其在客户端计算机系统上运行，并且呈现传入的流式传输的经处理的数据消息，以便在监视器显示或控制台显示的上下文中进行可视显示。在图12中，客户端活动显示在图的左侧，并且处理中心活动显示在图的右侧部分。在步骤1202中，客户端执行使用流式传输数据的应用程序。在步骤1204中，应用程序执行打开套接字命令，向该命令提供json编码的连接请求，如上面参考图7所讨论的那样。在步骤1206中，处理中心内的监听器进程接收套接字请求，并在步骤1208中处理连接请求。处理涉及使用连接中提供的访问令牌来授权访问以及解析连接请求。如步骤1210中所确定的那样，当连接请求格式良好时，然后在步骤1212中，处理中心处理连接请求，以建立经处理的数据消息的流，以供通过通信套接字传输到客户端应用。这可以涉及初始化数据结构、启动一个或多个流式传输进程以及其他这样的初始化活动。然后，在步骤1214和1216的连续循环中，在步骤1214中，一个或多个流式传输进程等待下一个经处理的数据消息以便通过通信套接字传输到应用程序，并且在步骤1216中将该消息传输到应用程序。否则，在步骤1218中，当连接请求格式不正确时，处理中心向客户端返回错误消息。在步骤1220中，客户端应用接收错误消息，并且通常在步骤1222中将错误报告给客户端用户或管理员。在某些情况下，应用程序可能尝试在新的连接请求中纠正或改变连接请求并自动重新提交该连接请求，以便继续执行。当处理中心在步骤1212中返回成功消息时，客户端应用在步骤1224中接收成功消息，然后进入连续循环，在该连续循环中，应用程序在步骤1226中等待下一个经处理的数据消息、在步骤1227中接收该消息、并在步骤1228中处理该消息。如上面所讨论的，对经处理的数据消息的处理通常导致内部应用状态和内部数据的更新，该更新立即或后续地反映在由客户端用户查看的控制显示或监视器显示的改变中。
当然，在实际实现方案中，多个不同的协作进程可以协作以实施参考图12描述的活动。此外，还可以采用许多不同的缓冲技术、异步事件处理技术和其他技术中的任何技术来在处理中心和客户端计算机系统两者中实现流处理。
图13a-图13b提供了插入网页内的实施数据收集的插装代码的示例。数据收集由嵌入html文件内的脚本(图13b中的1302)从网页发起，其中该html文件指定显示给用户的特定网页。脚本创建新的标签对象1304，然后调用“dcscollect”标签成员函数来收集数据，并将数据转移到数据收集子系统1306。“dcscollect”成员函数1308调用“dcstag”函数1310。“dcstag”函数1312为单像素资源图像创建url，然后在该url中在符号“？”之后嵌入键/值对的列表。该url包含在被传递给“dcscreateimage”例程1314的符号-串变量p内。“dcscreateimage”例程1316向图像变量1318进行指派，该图像变量1318由浏览器通过使用http请求和由“dcstag”例程创建的url进行处理以获取单像素图像。该单像素图像不用于显示，而仅仅是用于将url内的参数中的键/值对编码传输到数据收集子系统的载体。
应该注意，插装代码所收集的数据是非结构化的。键/值对的值可以是任意符号串或符号串阵列。多个值可以随后被组合以创建更长的符号串。收集的数据由插装代码或电路指定。数据处理、基于查询的数据过滤和选择以及数据增强通常发生在下游，在远离执行插装代码以收集数据的地方的处理中心或其他系统中。下游数据处理有许多优点，包括处理中心能够从公共数据集合发出许多不同类型的数据流、对收集的数据分开地应用不同类型的查询、过滤和增强以生成分开的数据流。此外，插装代码仍然保持简单且有效，并且不会给处理器控制的用户装备引入潜在的破坏性计算负担。通过插装代码收集的数据也相对独立于其余的系统部件。例如，可以修改插装代码以收集新的键/值对，并且该键/值自动地最终传递给没有选择使用查询来过滤键/值对的数据消费者。在许多情况下，即使在收集数据并将其流式传输给数据消费者的同时，也可以对插装代码进行修改。请注意，短语“插装代码”是指被添加到已经存在于工作脚本、例程、程序或电路中的指令中的代码或电路。插装代码以正交的方式被添加到已经起作用的代码和电路中，并且仅旨在将数据传输到数据收集子系统。术语“插装代码”在用于描述为了调试和优化的目的而添加到程序中的特殊附加语句的相同意义上被使用。
图14提供了描述浏览器内的如上参考图13a-13b所讨论的事件生成过程的控制流程图。在步骤1402中，浏览器执行实施数据收集的脚本。在步骤1404中，数据收集代码访问存储在处理器控制的用户装备内的cookie，以确定上面参考图6讨论的标识符、最后一次访问和会话开始的值id、lv、和ss。在步骤1406中，浏览器脚本获取当前系统时间t。如步骤1408中确定的那样，当当前时间t和值lv之间的差大于阈值时，那么在步骤1410中，存储在cookie中的值ss被设置为当前系统时间t，以指示新会话的开始。如上面所讨论并且下面进一步讨论的，会话是与特定用户/处理器控制的用户装备相关的、全都发生在指定的时间窗口内一组事件。当当前时间与最后一次访问时间戳之间的差大于阈值时，新会话开始。在步骤1412中，值lv被设置为当前系统时间t并被存储在cookie中。在步骤1414中，表示由插装代码收集的数据的一组键/值对被收集并形成串s，该串s在步骤1416中跟随符号“？”被放置到为图像资源创建的url中。在步骤1418中，浏览器脚本执行指派或某种其他语句，该指派或其他语句导致在步骤1420中浏览器使用httpget请求从数据收集子系统获取由url指定的资源。
图15例示了本文所涉及的实时经处理的数据消息流式传输系统和方法的一个实现方案。如上面所讨论的，该系统包括由图15中的列1502表示的一组数据收集子系统、由图15中的列1504表示的多个整合系统以及由图15中的列1506表示的一个或多个处理中心。每个数据收集子系统，例如数据收集子系统1510，将事件消息传输到特定整合系统的每个主题内的特定分区，例如整合系统1516的主题1514内的分区1512。通常，数据收集子系统可以针对多个客户端/主题中的每一个来收集数据。在处理中心1506内，喷口与数据整合子系统内的每个分区相关联，例如喷口1520与分区1512相关联。喷口从整合系统中拉取事件消息，并将其发出到一级丰富化栓1526-1528。丰富化栓可以实施粗略的一般过滤，并且还计算和确定被添加到事件消息中以创建丰富化事件消息的各种丰富化值。然后，将丰富化事件消息从丰富化栓1526-1528传递到下游栓1530-1538。每个丰富化栓1526-1528都与特定客户端相关联。客户端可以从诸如事件流栓1530之类的事件流栓接收丰富化事件消息的流。在通过打开套接字向客户端应用发出丰富化事件消息的流之前，事件流栓实施特定于特定客户端的基于查询的过滤。诸如会话流栓1531之类的会话流栓实施附加处理，以将从丰富化事件消息中提取的数据分组为会话消息，并通过通信套接字向客户端应用程序发出会话消息。诸如访问者流栓1532之类的访问者流栓也聚合和处理丰富化事件消息以生成访问者数据消息，访问者数据消息实时描述网站内特定访问者的活动。其他类型的栓产生其他类型的经处理的数据消息。这些其他类型的栓可以执行各种类型的数据聚合，以允许客户端应用显示各种类型的聚合和集合性数据，这些聚合和集合性数据通常表示与多个网站用户相关联的多个事件。在某些系统中，当为特定会话收集的数据超过阈值量时，将该会话划分为两个或更多个不同的会话以便于下游处理。
可以使用部件系统的许多其他集合、部件系统的组织和消息传递拓扑来产生实时经处理的数据流式传输子系统的替代实现方案。可以在storm分布式系统中使用许多不同的拓扑来实现丰富化、过滤和聚合。
图16例示了数据收集子系统的操作。在步骤1602中，数据收集子系统打开到整合系统的一组通信套接字。在步骤1604中，数据收集子系统注册为与接收实时经处理的数据消息流的每个客户端相对应的每个主题内的、与数据收集子系统相对应的分区的生产者。然后，在步骤1606-1611的连续循环中，数据收集子系统在步骤1606中等待下一个图像请求、在步骤1607中接收下一个图像请求、在步骤1608中从图像请求中提取键/值对、在步骤1609中创建包含提取的数据的json编码事件消息、在步骤1610中根据提取的数据确定消息将被引导到的客户端，以及，在步骤1611中，将json编码的事件消息发布到与该客户端相对应的主题以及与整合系统内的数据收集子系统相对应的分区。注意，在该控制流程图中，等待步骤1606并不意味着在接收每个图像请求之前执行单独的等待操作。相反，当连续接收到图像请求时，可以在每次等待操作之后处理成批的图像请求，类似于操作系统现场硬件中断并调用相应中断处理程序的方法。
图17-图18提供了例示整合系统的操作的控制流程图。图17示出了整合系统操作的消息接收部分。在步骤1702中，整合系统等待来自数据收集子系统的下一个json编码的事件消息。同样，与数据收集子系统一样，当整合系统连续接收到消息时，实际等待消息到达的事件可能很少发生。在步骤1704中，整合系统从数据收集子系统接收下一个json编码的事件消息。在步骤1706中，整合消息系统将接收到的消息追加到用于消息所指向的主题/分区的当前段文件中。如步骤1708中确定的那样，该段文件包含多于阈值数量的字节，在步骤1710中将段文件的内容转储到大容量存储装置并且分配新的段文件以用于接收指向该主题/分区的后续消息。
图18例示了整合系统的输出侧。在步骤1802中，整合系统等待下一个消费者请求。在步骤1804中，接收下一个消费者请求。消费者请求通常包括段文件内的从其开始输出消息的偏移和消费者的用于存储消息的缓冲区容量。在步骤1806中，整合系统访问一个或多个存储的段文件，这些段文件存储从该偏移开始直到将填满缓冲区容量的多个连续消息的消息。如在步骤1808中确定的那样，当在这些段文件中存储有附加消息时，则在步骤1810中将上至缓冲区容量的附加消息返回给进行请求的消费者。否则，在步骤1812中将没有附加消息的指示返回给消费者。
图19-图23例示了处理中心的操作。图19例示了由整合系统提供的json编码事件消息的喷口消费。在步骤1902中，初始化喷口。在步骤1904中，喷口等待缓冲区为低的状况，其中缓冲区为低的状况指示喷口可以申请和存储附加消息。在步骤1906中，喷口请求来自整合系统的附加消息。如步骤1908中确定的那样，如果接收到附加消息，则在步骤1910中将附加消息添加到缓冲区。如在步骤1912中确定的那样，当缓冲区现在包含多于阈值量的数据时，在步骤1914中移除缓冲区为低的状况。当没有接收到附加的消息时，则在步骤1916中，喷口可以进行延迟，然后在步骤1906中再次从整合系统请求消息。
图20例示了处理中心内的喷口的输出功能。在步骤2002中，喷口等待缓冲区为低的状况被移除。然后，当缓冲区中有附加消息时，喷口实施步骤2004-2011的while-loop(while循环)。在步骤2005中，喷口使下一个消息从缓冲区中出列，并且然后在步骤2006-2008的内部for-loop(for循环)中，将该消息传输到从该喷口接收消息的每个栓。如步骤2009中确定的那样，当缓冲区内容低于阈值时，在处理下一个消息之后，喷口在步骤2010中引发缓冲区为低的状况。如步骤2011中确定的那样，当有更多消息要从缓冲区中检索时，控制返回到步骤2005。否则，控制返回到步骤2002。
图21例示了丰富化栓的操作。在步骤2102中，栓等待要处理的下一个可用消息。在步骤2104中，栓从喷口接收该下一个消息。在步骤2106中，丰富化栓基于用于由丰富化栓发出的消息的下游消费者的当前查询来应用通用过滤器，以便基于具体的查询来丢弃将不能在下游过滤中存活的消息。如在步骤2108中确定的那样，当消息被至少一个下游消费者需要时，然后在步骤2110中，丰富化栓产生丰富化值，这些丰富化值可以根据包括在接收到的事件消息以及其他信息源中的栓可访问的数据以及栓进行的计算来确定。在丰富化(其中生成的数据值被包括在丰富化消息的“ext”对象中)之后，在步骤2112中将丰富化消息转发给下游栓和消费者。
图22例示了事件流栓的操作。在步骤2202中，事件流栓等待来自丰富化栓的下一个消息。在步骤2204中，事件流栓从丰富化栓接收下一个丰富化事件消息。然后，在步骤2206-2210的for-loop(for循环)中，在步骤2207中事件流栓将用于每个消费者的特定于消费者的查询应用于丰富化事件消息，并且如步骤2208中确定的那样，当在应用查询之后消息保持可转发到具体消费者时，在步骤2209中将经处理和过滤的消息发送给消费者。
如上面所讨论的，可以在从远程处理器控制的用户装备收集数据并将其流式传输到数据消费者的同时修改插装代码。例如，当在特定远程处理器控制的用户装备内改变或修改插装代码以收集新类型的数据时，以及当恢复从远程处理器控制的用户装备的数据收集时，由插装代码收集的新类型的数据被引导到正在进行的数据收集、数据整合、数据处理以及经处理的数据流中，而不会中断或重新配置正在进行的经处理的数据流。以类似的方式，由数据消费者指定的查询可以在从远程处理器控制的用户装备收集数据以及将对应的经处理的数据流式传输到数据消费者期间被数据消费者修改。在某些实现方案中，带外查询修改协议允许数据消费者修改当前正由代表该数据消费者的数据处理中心应用的查询。在替代实现方案中，数据消费者在通过最初打开的套接字接收经处理的数据的同时，使用新的或经修改的查询来打开到数据处理中心的新套接字/连接，并且一旦开始通过新的套接字/连接接收到经处理的数据，就关闭最初打开的套接字，并且如果需要，对在最初打开的套接字和新套接字两者都打开时接收到的经处理的数据执行临时重复消除。这一原理同样适用于整个实时经处理的数据消息流式传输系统。一旦插装代码在一个或多个远程处理器控制的用户装备上被激活，数据就从该一个或多个远程处理器控制的用户装备被连续地传输到一个或多个数据收集子系统，数据从这些数据收集子系统穿过实时经处理的数据消息流式传输系统的剩余部件系统，最终位于一个或多个经处理的数据流中。假如数据收集子系统由于各种原因中的任何原因被关闭，那么数据可以自动重新路由到其他或新的数据收集系统。类似的考虑也适用于实时经处理的数据消息流式传输系统中的其他系统和子系统。在所有数据处理中心都暂时离线的情况下，数据可以累积在数据整合子系统中，并且然后可以被转移到重新启动的数据处理中心，而没有数据丢失并且经处理的数据流式传输只有暂时的中断。可以在不中断数据收集和数据流式传输的情况下即时地修改实时经处理的数据消息流式传输系统的每个部件内的各种功能，条件是在修改特定部件系统上的功能期间其他系统保持正常工作。
图23提供了例示会话流栓操作的控制流程图。在步骤2302中，会话流栓等待来自上游丰富化栓的下一个可用消息。在步骤2304中，会话流栓从丰富化栓接收下一个丰富化事件消息。如在步骤2306中确定的那样，当丰富化事件消息对应于会话的第一事件时，会话流栓在步骤2308中为由id值标识的用户/处理器控制的用户装备记录新会话。如步骤2310中确定的那样，当记录新会话导致前一会话现在完成时，在步骤2312中记录前一会话的完成。否则，当接收到的丰富化事件消息与会话的第一事件不对应时，在步骤2314中，将接收到的丰富化事件消息中的数据添加到对应的当前会话。接下来，在步骤2316-2322的嵌套for-loop(for循环)中，会话流栓考虑当前由会话流栓管理的每个经更新的会话，而对于会话流的每个消费者，在步骤2318中将消费者的查询应用于经更新的会话，以在步骤2319中确定在过滤之后会话是否可转发给消费者。如果是，则在步骤2320中生成与经更新的会话相对应的会话消息，并将其传输给消费者。会话流栓还可以在单独的循环中考虑那些没有被更新的会话，以检测由于流逝了超过阈值量的时间而终止的会话，并且在进行步骤2316-2322的嵌套的for-loop(for循环)之前将那些会话记录为完成。
如上面所讨论的，除了事件流和会话流之外，各种附加类型的流可以由处理中心内的一个或多个栓生成，并发出到消费者应用。一种这样的附加类型的流是访问者流，它提供关于网站内每个当前访问者的信息。图24示出了可视地表示当前访问者的网站的示例监视器显示。在左侧列2402中，通过id和国家来标识当前访问者。在中央显示面板2404中，针对当前访问者的子集中的每一个，以图形方式示出访问者通过网站的进展。例如，时间轴2406例示了特定的当前访问者通过活动2408(例如网站所有者发送给访问者的电子邮件)到达了网站，最初访问了baroncustomaccessories页面2410，然后，在24秒后，访问了reviewbaroncustomaccessories页面2412。因此，访问者消息数据流允许网站所有者实时监视网站内的访问者活动。举例来说，这可以允许网站所有者实时改变网站的内容或者向具体访问者产生特定于访问者的信息，以便将访问者引导到网站所有者可能认为最有利于鼓励购买的网页、产品和服务。
本文所涉及的实时经处理的数据消息流式传输系统和方法为网站监控和动态调整提供了许多额外的机会。该系统和对应的方法有可能为向客户提供独特的和完全动态的特定于客户的网站体验提供基础。实时数据还可以为许多类型的预测以及为基于预测发起动作和过程提供基础。
接下来，提供了各种类型查询的一些示例，这些查询提供经过滤、经处理的数据流，以支持特定类型的应用和其他数据消费者。在某些这些示例中，插件(而不是插装代码)被用于在处理器控制的设备中生成数据。与插装代码所提供的相比，插件可以提供显著更多的设备侧逻辑和计算复杂性。一般来说，经处理的数据流式传输子系统不知道数据是如何由为数据收集和处理供应数据的设备生成的。在许多情况下，插装代码为经处理的数据流式传输子系统提供了最低影响、最容易部署和最容易重新配置的数据源。然而，插件和其他替代数据生成实体和方法可以用于向经处理的数据流式传输子系统供应数据。
在第一示例中，应用程序消费来自远程处理器控制的用户装备的流式传输数据，以便显示网站网页的热图，该热图指示用户向网页的每个部分进行输入的频率。为了产生用于支持热图显示的经处理的数据流，热图插件被加载到一个或多个远程处理器控制的用户装备中的每一个中。该插件跟踪鼠标移动、并且发送鼠标控制的光标的位置的坐标、并且跟踪鼠标和/或触摸事件。插件将收集到的信息发送到一个或多个数据收集子系统。实时经处理的数据消息流式传输系统将该信息流式传输至热图应用，该热图应用使用该数据来覆盖页面顶部的用户活动热图。使用查询来过滤数据流，例如：
any(ext.geo.region＝′oregon′anddata.wt.mc_id＝′10001′)and
data.cs-uri-stem＝′/products/bikes/helmets.asp′
其产生与到往目标网页的访问者相关的数据流，其中这些访问者来自oregon，访问者通过活动id：10001到达，并且访问者正在浏览‘头盔’页面并与之进行交互。
作为另一示例，facebook应用用户被监视，将关于特定类型用户的信息返回给facebook、监视子系统或应用开发组织跟踪应用使用情况并修改或动态改变facebook应用或facebook应用使用的信息，以便最好地服务当前facebook应用用户。为了产生用于支持facebook应用的修改或动态改变的经处理的数据流，将facebook插件加载到一个或多个远程处理器控制的用户装备中的每一个中。该插件异步地拉取facebook图形数据以包括在被发送到一个或多个数据收集服务器的数据中，并且当每个facebook应用页面呈现和/或每个facebook应用点击事件发生时，将事件和用户数据发送到一个或多个数据收集服务器。实时经处理的数据消息流式传输系统将数据流式传输回来，以使其可用于优化或应用开发系统，这继而确保后续的facebook应用页面为特定访问者提供更多相关信息。使用查询来过滤该数据流，例如：
any(ext.source.name＝′facebook′anddata.wt.mc_id＝′10001′)and
data.wt.fb.user_gender＝′m′
此查询产生描述到往目标facebook应用的访问者的数据流，其中访问者经由活动id：10001到达，并且访问者是男性。
作为又一个示例，已经在各种网站上发起广告活动的组织跟踪通过该活动到达网站的某些类别的网站用户，例如发起了产品选择和购买但没有实施购买的用户。在某些情况下，组织可以实时干预，以向这些用户提供更多信息，以鼓励他们完成交易。使用移动设备活动的访问者的活动效果是利用被包括在用于抵达特定网站的url上的专门活动数据来创建的。访问者使用移动设备点击这些链接中的一个链接并且到达网站，然后继续点击网站上的其他几个页面。然后，访问者将物品放在访问者的购物车中。虽然有些访问者进行购买，但有些访问者放弃他们的购物车。该组织希望通过了解在鼓励访问者完成购物时什么是有效的以及什么是无效的，来优化活动。使用查询来过滤数据流，例如：
any(ext.source.name＝′campaign′andprocess_number＝′1′)and
any(data.wt.tx_e＝′a′)and
all(data.wt.tx_e！＝′p′)andsession.closed＝′true′andext.device.type！＝′computer′该查询产生描述到往网站的访问者的数据流，其中访问者的第一个事件被记录为从活动到达，访问者正在使用移动设备，访问者已经将物品放入他们的购物车，访问者尚未进行购买，访问者的访问已经达到“关闭”阈值目标，并且购物车被认为被放弃。
虽然以上讨论集中在将收集和经处理的数据流式传输到数据消费者，但是收集的数据在处理以及随后的处理之前也可以存储在处理中心内用于非实时目的，包括后续访问、由插装了代码的装备重放动态数据生成以及用于许多其他目的。可以将数据压缩，以便更有效地存储。在某些实现方案中，数据可以被存储达到最长的存储时间，之后可以选择性地存档或删除数据。
“查询即服务”系统
上述实时经处理的数据流式传输子系统最初是作为一个完整的系统被设计和开发以满足大规模web分析应用以及其他应用。然而，随着时间的推移和计算系统的进一步发展，上述实时经处理的数据流式传输子系统现在已经被合并到更大并且更有能力的“查询即服务”系统(“qaas系统”)中。图25提供了合并有上述实时经处理的数据流式传输子系统的qaas系统的概览。除了合并有前述实时经处理的数据流式传输子系统2504之外，qaas系统2502还包括将前述系统扩展成更大规模的系统的附加部件和功能，该更大规模的系统从更多的各种处理器控制的装备和联网实体中收获数据，以便代表远程客户端连续和/或间歇地对所收获的数据执行查询，并且近实时地或作为间歇成批查询结果向远程客户端提供查询结果。地球2506图形和从地球表面上的点指向qaas系统的许多箭头(例如箭头2508)旨在说明qaas系统可以从分布在全世界的大量联网实体接收事件消息和其他数据。qaas系统实质上是短语“物联网”中引用的“物”的全球数据收集和查询处理系统。这些“物”可以是处理器控制的设备和计算机系统，包括膝上型电脑、平板电脑、pc、智能手机、个人计算机和其他相对高端的设备，但是也可以包括无数不同类型的机器、系统、装备和包括联网的传感器、电子器件和/或处理器的对象中的任何一种，其中这些传感器、电子器件和/或处理器允许对象生成和传输事件消息。这些对象可以从标记有rfid标签的衣服、家具和其他消费品到汽车、火车、飞机、机器工具、家用电器，以及随着计算的发展已经或者很快将当然地连接到互联网的许多其他类型的对象。物联网的这些物会产生大量的数据，潜在地每秒高达兆兆字节的数据或更多的数据。因此，qaas系统需要是高度可扩展的并且能够实时处理大量数据，而且也能够将该数据持久化达到足够长的时间段，以允许数据最初由qaas系统处理并且然后被传输到各种不同的组织、分布式计算机系统、云计算设施和单独的计算机系统，以供输入到各种不同类型的应用和服务，这些应用和服务将这些数据用于各种特定于组织的目的。作为一个示例，qaas系统可以被电力设施公司用于跨大的地理区域收集电表数据。作为另一个示例，qaas系统可以提供对商业航空公司机队甚至私人汽车的实时监控。qaas系统收集数据、将数据持久化、存储远程客户端系统提交的查询，并对所收获的数据连续执行这些查询，以向远程计算机系统提供查询结果的连续流式传输或成批传输。因此，在图25中，响应于提交的查询，远程系统(例如远程系统2508)从qaas系统2502接收查询结果的连续流或成批传输2510，其中该查询可以由qaas系统在非常长的时间段内连续执行。
图26例示了qaas系统对数据的持久存储。如上面所讨论的，qaas系统的实时经处理的数据流式传输部件从大量数据源收集数据并处理数据以产生多个经处理的数据流2602-2604，其中，如上面所讨论的，图26中的省略号(例如省略号2606)指示可能存在大量的流。从qaas的实时经处理的数据流式传输子系统部件流式传输的经处理的数据既被引导到一个或多个查询处理引擎2608，也被引导到持久存储装置2610，使得该数据既可以由查询处理引擎实时处理，也可以在后续的时间点通过访问持久存储的数据来处理。
查询处理引擎2608是上面关于实时经处理的数据流式传输子系统讨论的查询处理类型的详细说明。已经开发了物联网查询处理语言，以允许远程客户端系统和组织的用户制定查询，以便实时地从输入到查询处理引擎的各种流或者从存档存储中收获本质上无限数量的不同的查询指定数据集。利用各种类型的访问权限和强健的授权和认证来对经处理的数据流和底层原始数据进行仔细控制，使得特定组织能够严格保护机密的组织拥有的信息，并将对该信息的查询执行和查询响应的接收隔离为仅限于组织本身，或者允许组织仅与特定的且被仔细控制的附加用户共享其数据。查询处理引擎2608连续地执行由远程客户端和组织提交的查询，以生成查询结果流2612-2615，这些查询结果流都被实时地传输到分发器部件2618，并且被持久地存储在查询结果缓冲区2620-2623中。查询结果通常存储的时间比从经处理的数据流2602-2604接收的底层经处理的数据短得多。一般来说，假如从查询结果持久存储装置中不再可用的查询结果后续被需要，则客户端或组织可以重新提交查询以针对持久化的经处理的数据流执行，以便重新生成查询结果。qaas2618的分发器部件通过互联网或其他通信系统将查询结果引导到客户端计算机系统。在某些实现方案中，查询结果首先被持久地存储，并且分布式部件2618从持久存储缓冲区2620-2623读取查询结果以传输到客户端。在其他实现方案中，某些客户端可能希望接收实时数据，在这种情况下，分发器接收并传输由查询处理引擎产生的实时查询结果，以及访问持久存储缓冲区2620-2623，以便检索成批查询结果并将其传输到其他客户端。在某些实现方案中，查询结果可以从流式传输数据和存档数据两者生成。
图27例示了向远程客户端系统内的qaas远程客户端传输查询结果。在图27中，qaas系统2502的分发器部件2618通过传输层安全性(“tls”)或安全套接字层(“ssl”)安全隧道2702向远程客户端系统2706内的qaas远程客户端2704传输查询结果。查询结果以许多不同的指定格式(包括xml、json、逗号分隔值格式(“csv”)、经优化的行列格式(“orc”)和其他格式)中的任何一种来进行传输。在某些实现方案中，数据格式可以被指定为qaas系统连续执行的查询的一部分，而在其他实现方案中，可以由用户通过用户界面与qaas远程客户端的交互而在qaas系统内建立的各种客户端属性和参数来控制。qaas远程客户端2704然后根据需要实施附加的查询-响应-数据转换或重新格式化，以便将查询数据供应给可从客户端系统访问的各种不同类型的数据接收器、应用或远程系统中的任何一个。例如，数据可以由qaas远程客户端传输到客户端系统内的文件系统或数据存储装备2708，或者被转发到许多不同的数据处理子系统和应用中的任何一个，例如hadoop或客户开发的业务应用2710。可替代地，qaas远程客户端2704可以将数据转发到分级和通信子系统2712，以进行该数据到往远程系统2714的由客户端控制的分发。qaas远程客户端不仅将接收到的数据转换为来自客户端系统的各种数据接收器所期望的格式，在许多实现方案中，qaas远程客户端还管理必要的数据传输协议、数据缓冲、定时和同步以及与在客户端系统内分发接收到的查询结果数据相关的其他问题。
图28例示了查询结果数据从qaas系统到qaas远程客户端的安全传输。查询数据被封装到通信消息2802-2804中，以便由qaas系统的分发器部件2618进行传输。在第一安全步骤中，分发器部件采用由客户端系统通过安全通信供应给qaas系统的公共加密密钥，以加密每个查询结果数据消息内的数据，以产生经加密的查询数据消息2810。经加密的查询数据消息由底层安全通信隧道2812重新加密，以产生双重加密的查询结果数据消息2814，该双重加密的查询结果数据消息2814通过安全隧道传输到客户端系统内的qaas远程客户端。由安全隧道实施第一解密2816，然后在客户端系统内运行的qaas远程客户端使用客户端私有加密密钥2820实施附加的私有密钥解密2818，以产生明文查询-响应-数据消息2822。在安全隧道系统中采用多路认证和授权协议，以在使用第三方证书组织提供的认证证书进行数据传输之前对qaas系统和qaas远程客户端两者进行认证。客户端私有密钥2820由客户端计算机生成并安全地存储在qaas远程客户端内。它不由客户端传输到qaas系统，在大多数情况下也不传输到任何其他远程系统。因此，在通过互联网或其他通信系统传输之前，查询结果数据在qaas系统内是完全安全的。
如上面所讨论的，qaas系统的实时经处理的数据流式传输系统部件采取了许多附加类型的安全措施，以确保客户端计算机只能生成对客户端组织被授权对其执行查询的经处理的数据进行访问的查询。这种类型的授权可以在多个级别进行。例如，在医疗数据的情况下，可以应用严格的控制，以防止包含患者标识符的任何原始数据被除了在其中生成该数据的医疗组织之外的任何组织访问。然而，保证从查询结果中清除了所有患者信息的查询可以由更多的组织执行。例如，这些更多的组织不能执行将揭示向患者提供的特定治疗或患者状况的查询，但是可以被授权执行返回聚合统计数据的查询，例如特定病理或状况在各种不同地理区域的年龄组、种族和居民之间的分布。因此，不仅查询结果数据得到安全保护和安全传输，底层原始数据也通过多层访问控制得到保护，以防止未经授权的客户端对其他组织拥有的机密数据执行查询。
qaas远程客户端向客户端计算机系统的用户提供了丰富且功能强大的用户界面，以允许用户浏览客户端可访问的数据和事件类型的列表、配置特定于客户端的数据收集、并制定用于访问数据的查询。图29例示了qaas远程客户端提供的用户界面。如图29所示，远程客户端系统2904内的qaas远程客户端2902与qaas系统2906进行通信，以从qaas系统获得关于客户端可用的数据类型的信息，并代表客户端配置具体信息的收集。该信息可以显示在用户界面的一个或多个页面中。用户界面2910提供输入功能，以允许用户浏览该信息2912-2915。此外，用户界面通常提供查询构造窗口或页面2916以及各种工具，以允许用户制定、编辑和管理查询以及启动查询执行。
图30提供了实现qaas远程客户端的主事件循环的控制流程图。在步骤3002中，事件循环等待下一个事件。然后，在一系列条件语句中，事件循环确定发生了什么类型的事件，并调用适当的处理程序。例如，如在步骤3004中确定的，当下一个发生的事件是数据请求或数据请求定时器到期时，在步骤3006中调用处理程序以从qaas系统获取下一批数据。通过用户界面对qaas远程客户端进行控制，以确定数据获取间隔和任何特定间隔的最大量。在某些实现方案中，系统可以根据客户端系统能够多快地处理数据，来动态调整数据获取的数据量和间隔。在又一些附加的实现方案中，数据可以从qaas系统推送到qaas远程客户端，而不是由客户端拉取。如步骤3008中确定的那样，当下一个发生的事件是请求重置查询结果数据流的获取点时，则在步骤3010中调用获取点重置处理程序。一般来说，客户端系统将查询结果数据视为qaas系统不断向其追加新数据的数据序列。qaas远程客户端应用程序维护下一个获取地址或指示，qaas系统上的分发器也是如此，以使客户端能够通过qaas远程客户端从qaas系统迭代地拉取数据。然而，在某些情况下(包括各种类型的系统故障)，接收到的查询结果数据可能对客户端而言是丢失的，在这种情况下，客户端可以将获取点重置到查询结果数据序列中的较早位置，以便使丢失的数据被重新传输。当期望的查询结果数据不再可从qaas系统获得时，客户端可以选择重新提交针对存档的经处理的数据以及实时数据的查询以供执行，实质上是利用查询结果数据获取点重置将经处理的数据获取点在时间上设置为比可能的回退往回退更远。如在步骤3012中确定的那样，当下一个发生的事件是终止查询请求时，则在步骤3014中调用终止查询处理程序。qaas远程客户端将终止查询请求传输回qaas系统，qaas系统采取关闭连续执行的查询和取消被分配给该查询的资源涉及的许多步骤。如在步骤3016中确定的那样，当下一个发生的事件是用于发起查询处理的请求时，则在步骤3018中调用新的查询处理程序。qaas远程客户端将新查询执行请求传输回qaas系统，qaas系统分配必要的资源、实施在查询提交之前尚未实施的任何附加授权和认证步骤、分配所需资源、并发起将新查询应用于经处理的数据流。如在步骤3020中确定的那样，当下一个发生的事件是启动用户界面的请求时，qaas远程客户端执行用户界面逻辑，以便在步骤3022中在显示设备上向客户端计算机系统的用户显示用户界面。在某些情况下，可以仅通过本地处理来显示用户界面，但是在一般情况下，qaas远程客户端与qaas系统进行通信，以便提供关于数据类型、数据属性字段的信息以及用户制定查询所需的其他信息。如在步骤3024中确定的那样，当下一个发生的事件是获取用于用户界面的数据的请求时，在步骤3026中调用数据请求处理程序以与qaas系统进行交互，来获得所请求的数据。如在步骤3028中确定的那样，当存在要处理的附加的排队事件时，则在步骤3030中使下一个事件从队列中出列，并且控制返回到步骤3004。否则，控制返回到步骤3002，在步骤3002中事件处理程序等待下一个事件的发生。
图31提供了qaas系统的分布式部件的事件循环的控制流程图。此事件循环类似于用于qaas远程客户端的事件循环。例如，该事件循环可以处理数据获取请求3102、获取点重置请求3104、查询终止请求3106、数据请求3108，以及处理由查询执行引擎生成的数据可用事件3110。
图32提供了查询处理引擎进行的查询处理的概览。如图32所示，先前参考图11-图24描述的经处理的数据流式传输子系统的数据收集和数据整合子系统可以被可视化为大输出队列3202，数据收集和数据整合子系统将事件消息输入到该大输出队列3202中。处理中心连续地从输出队列中收集与特定会话id相关的事件消息，以便组成会话消息3204，从而产生会话消息的输出流。然后，会话消息被输入到查询处理引擎3206，查询处理引擎3206过滤、聚合并实施其他查询处理活动，以便生成与输入的会话消息相对应的查询结果的流。如下文进一步讨论的，并且如先前参考图26所讨论的，查询处理引擎可以直接从处理中心接收会话消息，可以接收从存储的会话消息流数据检索的会话消息，或者两者兼有。查询结果可以是数字数据、经过滤和选择的事件消息或事件消息的某些部分、导出的数据或这些类型数据的组合。将查询结果传输到会话消息增强引擎3208，会话消息增强引擎实施查询结果与对会话消息增强引擎可用的附加外部数据3210的类似联接的组合。在许多情况下，附加外部数据3210由通过查询-构造界面(图29中的2910)接收查询结果的客户端来提供。由会话消息增强引擎实施的类似联接的处理产生最终查询结果数据流，该数据流被传递到分发器(图26中的2618)以传输到qaas系统客户端(图27中的2704)。
图33例示了由会话消息增强引擎实施的会话消息与外部数据的类似联接的组合。在图33的左侧，使用与图8d1-图8d3所示的示例会话消息所使用的相同的图示约定来示出从查询处理引擎发出的会话消息内的数据值。示出了表示查询执行引擎发出的查询结果的示例会话消息3312的事件消息3306以及剩余事件消息3308-3310中的数据字段k13302和k43304的显式数据值。查询结果所联接的外部数据包括两个表3312和3314。第一表3312包括包含数据字段k1的值的第一列3316，以及包含用于数据字段k1的每个不同值的对应符号串的第二列s13318。类似地，第二表3314包括对应于用于数据字段k4的数据值的符号串。由查询处理引擎指示会话消息增强引擎3320以匹配会话消息3312中的k1和k4数据值，并将来自表3312和3314的对应符号串追加到每个事件消息。会话消息增强引擎3320产生经增强的会话消息3322，其中，每个事件消息(例如事件消息3324)被补充以包括用于k1数据字段的对应符号串3326和用于k4数据字段的对应符号串3328。当然，这是会话消息增强引擎类似联操作的非常简单的示例。会话消息增强引擎能够在各种不同类型的外部数据和包括来自查询执行引擎的结果的会话消息之间实施相对复杂的类似sql的联接。注意，例如，会话消息3312可以仅具有被流式传输至查询执行引擎的未经处理会话消息中存在的全部数据字段中的非常少的数据字段。查询执行引擎可以实施类似sql的选择语句以仅选择数据字段和事件消息的期望子集，并且可以实施许多其他类型的类似sql的查询处理步骤，以生成导出的数据以及为会话消息和事件消息的聚合字段生成数值。由会话消息增强引擎在初始查询处理之后实施的查询结果增强提供了额外的高效且强大的查询结果处理步骤，以合并除了由经处理的数据流式传输子系统收集的数据之外的各种不同类型的外部数据，从而产生适合远程客户端摄取的查询结果。这种类型的处理表示大量下游查询结果处理计算开销从客户端系统卸载到qaas系统。
图34-图36例示了如何存储或存档由处理中心产生的会话消息流，以供在查询处理中的后续使用。在图34中，会话消息流3402被示为被划分成子流3404-3410，这些子流各自指向不同的数据存储设备，通常是qaas系统内的盘或虚拟盘。图34中的符号“会话id[1]”3412表示存储在盘或虚拟盘3414中的会话id的列表或集合。在当前描述的实现方案中，列表的内容与和其他数据流相关联的其他列表的内容互斥。每个盘或虚拟盘都在定义的时间段内累积来自与该盘或虚拟盘相关联的会话消息子流的会话消息。在当前描述的实现方案中，每个盘或虚拟盘在一小时内通过会话消息子流接收会话消息。在这一小时结束时，盘或虚拟盘被认为已被填满或完成，并且来自与存储在现在完成的盘或虚拟盘中的会话id值相关联的会话消息流的后续会话消息在下一小时被引导到不同的盘或虚拟盘。在图34中，前一个小时的完成或已填满的盘或虚拟盘显示在列3416中，而当前向其流式传输会话消息的盘或虚拟盘显示在列3418中。
图35例示了存储在qaas系统中的存档会话消息数据。表示当前小时的标题“当前h”下方显示了当前正在向其流式传输会话消息的盘或虚拟盘的列3502。后面的盘或虚拟盘的列(如列3504)表示每一个前一小时存储的会话消息数据，一直回溯到代表会话消息流数据存储的最大时间长度中的最后一小时的前一个小时。
图36例示了上面参考图34-图35讨论的每个盘或虚拟盘内的数据存储的细节。尽管每个会话消息子流在图34中被示为被引导到单个盘或虚拟盘，但是为了容错和高可用性的目的，qaas系统将会话消息子流冗余地存储在三个不同的盘或虚拟盘中。因此，在图36中，在图34中会话消息子流被引导到的单个盘或虚拟盘3602实际上包括三个盘或虚拟盘3604-3606。
在每个盘或虚拟盘内，数据被存储在一个或多个文件3608-3609中。会话消息数据可以被视为关系数据库表中的条目，其中每个行表示会话消息，并且每个列对应于数据字段。在qaas系统中，会话消息数据的这种类似关系数据库表的组织被存储为文件中的连续列3610-3613，在这些列的前面前置了头部3614。对应于每一列的数据，(或者换句话说，每个会话消息的特定数据字段的值)以压缩形式存储，而头部通常不被压缩。在图36中以展开的详细信息3616示出了头部3614。头部包括数据存储在文件中的特定小时和日期的指示3618、各种其他类型的信息，包括版本信息、客户端信息、头部大小以及其他这样的信息。此外，头部还包括压缩列的数量的指示3620，后面跟着列描述符3622-3625的列表。图36示出了列描述符的扩展版本3626。列描述符包括对压缩列的长度的指示3628、文件内到压缩列的偏移3630、列id3632、用于压缩列的压缩技术的指示3634、存储在列中的数据类型的指示3636以及其他信息3638。文件头部还包括其数据存储在文件中的会话id的数量的指示3640，以及会话id3642-3649的列表。如破损单元3650所示，文件头部可以包含附加数据。图36所示的文件头部结构旨在说明存储在文件头部中的文件数据的类型。实际的文件头部可以被不同地格式化和组织，并且可以包含附加类型的信息以及不同于图36所示信息的信息。头部旨在提供足够的信息，用于在由查询处理执行引擎实施的查询处理期间处理文件内容。另外，此信息中的某些信息可以存储在文件外部的各种表格或其他形式的存储数据中，这些表格或其他形式的存储数据可以由查询处理引擎访问以识别在查询处理期间需要访问和至少部分解压缩的盘、虚拟盘和文件。
关于qaas系统对会话消息流的存储，现在可以提出一些重点。因为会话消息数据是按列而不是按会话消息存储的，所以qaas系统只提取和解压缩处理具体查询所需的数据是非常高效的。例如，查询可以从查询指定的一组会话消息的事件消息内中的二十个或更多个可能的数据字段中仅选择两个或三个数据字段。在这种情况下，只需要从存储指定会话消息的文件中提取和解压缩几个选定的数据字段，每个数据字段对应于不同的列。
另一个重点是，qaas系统不像最常见的数据库管理系统那样对包含存储会话消息的文件进行索引。由于数据量和经处理的数据流式传输子系统接收和处理这些数据量的速率，用于对数据进行索引的计算开销将是繁重的。因为数据值存储在单独的压缩列中，所以qaas系统能够高效地仅提取和压缩产生查询结果所需的数据。
另一个需要注意的重点是，在查询处理期间，如下文进一步讨论的，数据文件和从数据文件提取的数据不需要在qaas系统内的处理系统之间进行内部移动或转移。相反，数据的查询-执行-处理由与盘或虚拟盘相关联的工作器计算机系统执行。通过消除在qaas系统内的不同工作器服务器和计算机系统之间传输和重新传输解压缩数据的需要，获得了巨大的计算效率。
图37a-图37d例示了查询处理引擎的操作。通常，查询处理引擎为它代表远程客户端执行的每个查询实例化查询处理子系统。如图37a所示，查询处理子系统包括驱动器计算机系统3702，并且通常包括多个工作器计算机系统3704-3709。如下面进一步讨论的，驱动器根据处理查询(查询处理子系统针对该查询被实例化)所需的估计计算带宽，并考虑到可用的工作器计算机系统资源，来组装工作器计算机系统。例如，查询可以与开始时间和结束时间相关联，该开始时间和结束时间定义了在其中接收由查询指定的会话消息的时间段。此信息连同附加信息允许驱动器计算盘或虚拟盘的数量，每个盘或虚拟盘对应于一小时的会话消息子流数据，这些会话消息子流数据需要被访问和处理以便处理查询。注意，在某些实现方案中，除了包含存储的会话消息的盘或虚拟盘之外，或者代替包含存储的会话消息的盘或虚拟盘，还可以指派一定数量的工作器来处理实时流式传输的会话消息或事件消息。
如图37b所示，驱动器3702对查询3710的初始处理允许该驱动器建立最佳或接近最佳的工作器计算机系统集合3704-3709，其受到qaas系统上的工作器可用性和计算负载的约束。如图37c所示，使用从查询中提取的信息，驱动器识别包含需要处理的会话消息数据的盘或虚拟盘(称为分区)，并向工作器分发这些分区3716-3721。如图37所示，单个分区被分发给每个工作器，但是驱动器可以选择将两个或更多个分区分发给每个工作器或所选择的工作器，这些工作器的指示被放置在与工作器相关联的本地队列中。
如图37d所示，当工作器3704完成对指派给该工作器的第一分区3716的处理时，该工作器将对该分区的查询处理的结果3724传输给驱动器。这一组结果3724通常被称为“部分结果”。然后，当在工作器的本地队列中存在下一个分区3726的指示时，或者当存在要处理的附加分区(在这种情况下，驱动器将工作器要处理的下一个分区的指示转发给工作器)时，工作器可以开始处理下一个分区3726。一旦接收到结果，驱动器就可以尽快向会话消息增强引擎和分发器发出3730部分结果3724。具体而言，对于选择类型的查询，部分结果可以与它们被工作器产生的那样一样快地，并且与它们可以在远程客户端内路由到它们的目的地那样一样快地，被流式传输到远程查询即服务客户端。
由查询处理引擎实施的查询处理是高度并行的操作，一般来说，其中许多不同的工作器系统中的每一个都处理需要被处理的整个数据集的子集以返回期望结果。如上面所讨论的，这种高度并行的多工作器系统处理没有工作器系统间通信开销的负担，并且因此使用工作器系统的聚合计算带宽的大部分来进行查询处理，而不是将显著的计算带宽浪费给工作器间通信开销。
除了选择类型查询之外，qaas系统还可以处理聚合类型查询。作为一个示例，这些查询对特定数据字段的经处理的数据中的不同值的数量进行计数。图38示出了示例聚合查询，其中针对每个城市在插装代码收集的数据中接收的不同visitor_id(访问者id)值的数量进行计数。在很多情况下，聚合查询可以通过对工作器系统返回给驱动器的部分结果中提供的计数进行累加来精确处理。然而，对于visitor_id字段，这通常是不可能的。问题在于，在具有不同session_id(会话id)值的会话消息的事件消息中，可能会出现相同的visitor_id值。因此，给定的visitor_id值可以跨多个分区分布，尽管每个分区都包含用于任何特定session_id的所有会话消息。因为聚合查询的执行返回计算出的数值，而不是工作器系统处理的不同visitor_id值的列表，所以工作器系统返回的聚合数值部分结果不能被相加地组合，因为部分结果中的聚合数值可能反映了特定visitor_id值在两个或更多个分区中的多次出现。
为了解决与数据字段相关联的聚合查询处理问题(例如不能累积由多个工作器系统枚举的visitor_id字段)，qaas系统使用hyperloglog基数(cardinality)确定方法的变体。qaas系统跨多个工作器系统以及工作器系统向驱动器发出部分结果的时间来利用hyperloglog方法。
图38示出了示例聚合类型查询。该查询寻求与会话消息相关联的唯一visitor_id值的计数，其中这些会话消息又与特定城市相关联。存在以各种替代查询规范语言来表达聚合型查询的许多可能的方法。在许多实现方案中，聚合型查询可以嵌入在更复杂的查询中。
图39例示了qaas系统对hyperloglog方法的使用。如第一列3902所示，由特定工作器系统处理的分区内的一组会话消息可以被认为是一组数据块，每个块包括visitor_id字段。为了对visitor_id字段进行聚合查询，可以将经处理的数据视为一组visitor_id值3904。这是一个多重集，这意味着与数学集合不同，该多重集可以包含各自具有相同的visitor_id值的多个元素。
使用密码散列3906对每个visitor_id进行散列化，该密码散列3906产生跨散列值空间均匀分布的散列值。在图39所示的示例中，散列值中各自具有l个位。如垂直线3910所示，散列值3908被划分成两个部分x3912和w3914。索引j被计算为x部分加上1的整数值3916。索引j是被初始化为全都具有值“0”被称为“散列图”的一组m个寄存器3918的索引。函数p(w)3920返回二进制散列值3908的w部分中具有值“1”的最左边位的索引。对于给定visitor_id值的给定散列值，由计算出的索引j所索引的寄存器被设置为寄存器中当前值和由函数p(w)返回的值两者中的最大值3922。一旦已经处理了多重集中的所有visitor_id值，就可以根据m个寄存器值的调和平均值来计算多重集3904中唯一visitor_id值的数量的估计e3924。
图40例示了hyperloglog方法背后的一般原理。考虑具有n个不同元素的多重集4002。然后，考虑为多重集中的元素生成的散列值。注意，对于任何特定的散列值，密码散列函数生成相同散列值。散列值4004被表示为具有最低有效位4006和最高有效位4008的二进制值。因为密码散列函数在可以用具有l个位的散列值表示的值的范围内均匀地分布visitor_id值，所以可以预期不同散列值中的大约一半(n/2)将在最低有效位中具有“0”位。然而，给定最低有效位4006的值是“0”的情况下，则n个不同散列值中仅有四分之一(n/4)将在最低有效位4006和次最高有效位4009两者中都具有“0”值。因此，二进制散列值具有五个前导“0”值位和第六个“1”位的概率等于2-6。更一般地，在索引s处出现具有最低有效“1”位的不同散列值的概率是2-s。
m个寄存器中的每一个寄存器包含一个值，该值指示观察到的散列值中、对于观测到的散列值中的至少一个具有值“1”的最高位的索引。因此，如果寄存器包含在被添加到分区索引时等于位索引值“8”的值，那么观察到的散列值中没有一个在第九位具有位值“1”。寄存器索引值i可以被认为是观察到的散列值中总是具有“0”值的第一位4012的索引，其中各个位现在以04014开始被索引。如果i远大于log2n，则观察到的散列值的第i位总是“0”的概率接近1(4020)。另一方面，如果i远小于log2n，则在所有观察到的散列值中由i索引的位为“0”的概率接近0(4022)。如果i近似等于log_2(n)，则在观察到的散列值中由i索引的位总是0的概率落在0.0和1.0之间的某个位置(4024)。因此，寄存器值i用作多重集中唯一值的基数n的指示。如上面所讨论的，对多重集中唯一值的估计基数n的计算(图39中的3924)计算寄存器值的调和平均值，并包括校正因子。
图41-图43例示了如何在当前描述的qaas系统中使用hyperloglog方法计算聚合值。图41使用与图37a-图37d相同的图示约定。图41是图37d的替代图，类似于在查询执行的描述中，图37d在图37c之后。图41例示了正在执行聚合查询的情况。当工作器3704完成对一个分区的处理时，工作器3704返回部分结果4102，该部分结果4102包括本地估计的唯一visitor_id基数4104和由hyperloglog方法为刚刚完成的分区4106生成的散列图或寄存器表。如在图37d中那样，当工作器3704的队列为空并且存在更多的分区要处理时，驱动器向该工作器供应下一个分区4108，在这种情况下，该工作器重新初始化散列图以准备处理该下一个分区。驱动器保存全局散列图或寄存器集4110，以便基于由工作器系统返回的本地散列图来累积全局散列图寄存器值。当驱动器接收到本地散列图4106时，驱动器将本地散列图与全局散列图4110合并，然后可以计算唯一visitor_id值的基数的当前全局估计，以供传输到客户端4112。
图42例示了本地散列图与全局散列图的合并。在图42中，散列图4202是全局散列图，并且散列图4204是由工作器系统传输到驱动器的部分结果本地散列图。在合并操作中，将每个寄存器设置为全局散列图和本地散列图中的寄存器的最大值4206，以创建经合并的散列图4208。因此，hyperloglog方法可以在多个工作器之间划分，每个工作器处理总数据的子集，并且可以在整个处理时间内划分。在任何给定的时间点，可以给远程客户端供应唯一visitor_id值的基数或者不能根据部分结果相加地计算的另一个聚合数据字段的最佳当前估计。
图43示出了分层散列图合并。在图43中，工作器组(例如工作器4302-4305)本地地合并它们的散列图4306-4308，以产生被发送到驱动器的中间散列图4310，该驱动器将中间散列图与全局散列图合并。不同的分层组织可以被用于任意数量的工作器系统之间的本地合并。本地合并从驱动器抵消了散列图合并的计算负担中的一些。
当然，尽管针对visitor_id值(其唯一实例不能在qaas系统使用的并行查询处理方法中被有效地计数)讨论了在qaas系统中使用hyperloglog方法，但是，上面参考图39-图43讨论的hyperloglog方法可以用于其唯一值跨多个分区分布的任何其他数据字段。hyperloglog方法可以与其他类型的查询处理结合使用，以便处理更复杂的查询类型。
图44a-图44e提供了由qaas系统的查询处理引擎实施的查询处理的控制流程图。图44a提供了最高级别的控制流程图。在第一步骤4402中，由查询处理引擎从远程客户端接收查询。驱动器被选择以管理过程的其余步骤。在步骤4403中，驱动器通过对例程“解析查询”的调用来解析该查询。在步骤4404中，驱动器通过对例程“配置查询处理”的调用来配置查询处理子系统，以执行查询。在步骤4406中，驱动器通过对例程“启动查询处理”的调用来启动查询处理。在步骤4408中，一旦查询处理完成，驱动器就通过对例程“解除对查询处理的配置”的调用来解除对查询处理子系统的配置。
图44b提供了在图44a的步骤4403中被调用的例程“解析查询”的控制流程图。在步骤4410中，例程“解析查询”解析通过查询的语言，以便生成可执行查询计划。在步骤4412中，例程“解析查询”确定查询的时间范围，或者换句话说，确定为了执行查询而需要处理的存储数据的时间范围。在步骤4414中，例程“解析查询”确定要处理的数据分区和数据流(统称为“数据源”)。在步骤4416中，例程“解析查询”确定为了处理查询而需要被处理的字段，这些字段对应于分区内存储的数据文件中的列。如在步骤4418中确定的，当查询涉及到在不能通过相加部分结果来计数的字段(如上述示例的visitor_id字段)上进行聚合时，则在步骤4420中，驱动器为基于散列图的聚合结果设立数据结构，包括全局散列图或者说寄存器集，以及用于将散列值划分为x和w部分中的位索引。最后，在步骤4422中，例程“解析查询”配置会话消息增强引擎，以在将经增强的查询结果转发到分发器之前提供对查询结果的类似联接的处理。
图44c提供了在图44a的步骤4404中被调用的例程“配置查询处理”的控制流程图。在步骤4430中，例程“配置查询处理”确定用于处理查询的最佳或接近最佳的工作器系统集合。这种确定可以涉及估计查询处理所需的总体计算带宽，以及将估计的计算开销与qaas系统内可用的工作器系统资源进行平衡。其他因素可能涉及客户端所期望的数据流带宽、qaas系统和远程客户端之间的通信系统的带宽，以及需要处理的分区和数据源的数量。在步骤4432中，“配置查询处理”例程将工作器系统配置为处理每个源，向工作器系统提供需要解压缩和处理的列或字段的列表，以及向工作器系统提供是否需要维护本地散列图的指示。在步骤4434中，例程“配置查询处理”初始化数据源的全局队列，并且在某些实现方案中，可以初始化与每个工作器系统相关联的数据源的本地队列。当然，全局队列和本地队列不包含分区本身，而是包含工作器系统可以如何访问分区的指示。在步骤4436中，如果需要的话，例程“配置查询处理”初始化全局散列图，并与分发器协调，以将查询结果传输到远程客户端。最后，在步骤4438中，例程“配置查询处理”组装会话消息管理引擎所需的外部数据源。这些数据源可以本地地存储在qaas系统内，或者可以在查询处理期间由会话消息增强引擎访问。
图44d提供了在图44a的步骤4406中被调用的例程“启动查询处理”的控制流程图。在步骤4440中，例程“启动查询处理”在工作器系统上发起本地查询处理，并从全局队列向每个工作器系统分发一个或多个源。在步骤4442中，例程“启动查询处理”等待下一个部分结果事件发生。如参考图37d和图41所讨论的，当工作器系统完成对数据源的处理时，发生部分结果事件。在步骤4444中，例程“启动查询处理”从工作器系统接收部分结果。如在步骤4446中确定的，当部分结果包括本地散列图和本地估计的唯一值基数时，例程“启动查询处理”在步骤4448中将本地散列图与全局散列图合并，并计算聚合数据字段的唯一数据值的基数的当前估计。在步骤4450中，部分结果被转发到会话管理引擎以进行任何类似联接的后处理。在步骤4452中，例程“启动查询处理”与分发器进行交互，以将当前部分结果流式传输到客户端以及本地存档机制。如在步骤4454中确定的，当所有数据源都已经被处理时，例程“启动查询处理”返回。否则，如在步骤4456中确定的，当生成了部分结果事件的工作器系统的本地队列为低或空时，驱动器在步骤4458中将一个或多个附加源添加到工作器系统的本地队列。然后，控制返回到步骤4442，在步骤4442中例程“启动查询处理”等待下一个部分结果事件。
图44e提供了在图44a的步骤4408中调用的例程“解除查询处理的配置”的控制流程图。在步骤4460中，例程“解除查询处理的配置”向分发器传输数据结束指示。在步骤4462中，例程“解除查询处理的配置”解除为处理当前查询而发起的查询处理子系统内的工作器系统的配置，并将工作器系统返回到自由流工作器系统以用于处理其他查询。在步骤4464中，例程“解除查询处理的配置”解除全局散列图和驱动器本地的其他资源的分配，从而将该驱动器准备用于接收和执行下一个查询。
尽管已经根据特定实施例描述了本发明，但并不意味着本发明限于这些实施例。在本发明精神内的修改对于本领域技术人员来说是清楚的。例如，经实时经处理的数据消息流式传输系统和qaas系统可以通过改变许多不同的设计和实现参数中的任何一个(包括部件系统和子系统的类型和组织、硬件操作系统和其他部件的类型、编程语言、代码、数据结构、控制结构的模块化组织以及丰富的附加设计和实现参数)，来以各种不同的方式实现。qaas系统可以从大量的传入数据中产生数百个经处理的数据流，并代表大量的客户端对经处理的数据流和持久化的经处理的数据流执行大量查询。
应当理解，提供实施例的前述描述是为了使本领域技术人员能够制作或使用本公开。对这些实施例的各种修改对于本领域技术人员来说是清楚的，并且在不脱离本公开的精神或范围的情况下，这里定义的一般原理可以应用于其他实施例。因此，本公开并不旨在限于本文所示的实施例，而是要符合与本文所公开的原理和新颖特征一致的最宽范围。