专利名称：云边拓扑的制作方法
技术领域：
本发明涉及网络的领域，具体涉及云边拓扑。
背景技术：
消费者对智能电话等“智能”便携式计算设备的广泛采用以及大量的基于云的计算资源的可用性已经导致所谓的“云边拓扑”。这些智能便携式计算设备之所以称为“智能”是因为处理器和存储器的进步允许这些设备具有用户可利用的丰富计算资源。智能便携式计算设备可以产生实时数据，如GPS定位、电池消耗、速度等。这些智能便携式计算设备还可被认为是云边设备，因为各个设备和基于云的资源之间的通信可被认为是一条边。假设智能便携式计算设备上有可利用的丰富计算资源，则用户可以选择要在他/她的设备上运行的各种应用。这些应用中的许多应用可被称为云边应用，因为一个应用实例在该智能便携式计算设备上运行，而另一个应用实例在基于云的计算资源上运行。存在一大类的在多个智能便携式计算设备和云间将数据相互关联，以实现其功能的云边应用。一个例子是交友应用，其功能是如果任何好友在附近则通知用户。该应用的功能依赖于实时位置和缓慢改变的数据如社交网络的相互关联。尽管在智能便携式计算设备和基于云的资源上可获得大量的计算资源，但是当大量的智能便携式计算设备正在运行云边应用时，通信资源等资源的使用率可能是值得重视的。
发明内容
本发明涉及云边拓扑。一些方面涉及在各种云边拓扑中的云边应用和资源的使用。一个例子可以评估使用来自多个不同边计算设备的数据的实时流查询。所述多个不同边计算设备可以被配置为与基于云的资源通信，但是不直接相互通信。各个边计算设备包括用说明性时序语言(declarative temporal language)表达的应用的实例。该例子可以比较第一和第二场景之间的资源使用。第一场景涉及将查询数据从多个不同边计算设备上传到基于云的资源用于处理。第二场景涉及将所述查询数据从所述多个不同边计算设备中除了一个节点以外的所有节点上传到基于云的资源并且将所述查询数据下载到所述多个不同边计算设备中的所述一个节点用于处理。本发明的云边拓扑的另一方面可以涉及使用时序语言的云边应用的说明。另一方面可以涉及在云和云边计算机上运行数据流管理系统(DSMS)引擎以运行各查询部分的架构。根据本发明的一个方面，提供了一种方法，包括:获得在包括多个边设备和基于云的资源的云边拓扑中的说明性流查询；将说明性流查询转换为反映多个边设备的查询图；以及基于云边拓扑的资源使用来判断是在各个边设备上执行查询图的算符还是在基于云的资源上执行查询图的算符。根据本发明的另一个方面，提供了一种系统，包括:基于云的云边上实时应用即RACE管理业务，其被配置为与在云上以及在与云通信的各个边计算设备上执行的应用交互，基于云的RACE管理业务被配置为模拟数据流管理系统即DSMS引擎，以从各个边计算设备接收时序性说明性查询；以及RACE处理器，其被配置为拦截时序性说明性查询并且将各个时序性说明性查询分析并编译为对象表达。上文列出的例子意图提供快速参考以帮助读者，并且不意图限定本文描述的构思的范围。
附图示出本发明中表达的构思的实施例。通过参考以下结合附图的描述将更容易理解所示出的实施方式的特征。在不同的图中相同的附图标记用于表示相同的要素。此外，每个附图标记中最左边的数字表达该附图标记第一次被引入的图和相关讨论。图1示出根据一些实施例的可应用本发明的云边应用资源使用构思的系统的例子。图2示出根据一些实施例的可应用本发明的云边应用资源使用构思的系统架构的例子。图3至图9示出根据一些实施例的可应用本发明的云边应用资源使用构思的图的例子。图10示出根据本发明的构思的一些实施例的云边应用资源使用技术的一个例子的流程图。
具体实施例方式MM本发明的构思涉及基于云的系统，以及在基于云的系统和所连接的设备上运行的应用所进行的动态的、与资源有关的处理。为了解释的目的，考虑介绍性的图1，图1示出可以实施本发明的构思的系统100的例子。系统100包括三个云边计算设备(在下文中称为“计算设备”)102 (I)、102 (2)和102 (N)(其中N表示可使用的计算设备的任意数目)。计算设备102 (I)-102 (N)可以分别经由线108(1)-108(3)所表示的网络106与云104通信。在该例子中，各个计算设备可以通过云104相互通信，但是不直接与其它计算设备通信。云104可以提供大量的计算资源110，但是这些计算资源的精确物理位置可能不是很明显。云计算由于其提供的相对廉价且丰富的计算资源而日益普及。计算设备102(1)_102(N)可以是任何类型的计算设备。通常这些计算设备是便携式计算设备，如智能电话和平板计算机。在本文中使用的术语“计算机”或“计算设备”可以指具有一定程度的处理能力的任何类型的设备。尽管为了解释的目的而示出了这种设备的特殊例子，但是这种设备的其它例子可以包括传统计算设备，如个人计算机、蜂窝电话、智能电话、个人数字助理或者无数的正在设计中的或尚未开发出的设备类型。此外，计算机可以被结合在另一设备中而不是独立的。例如，仪表板计算机可以被包括在汽车或其它交通工具中。从一个角度来看，计算设备102(1)_102(N)可被认为是在云104和网络106所支持的拓扑中的“边设备”。这些边设备中的多数安装有传感器，这些传感器产生频繁的或连续的实时数据流，如用户的GPS位置、速度、当前活动、设备的电池使用率等。另外，可能存在数量日益增多的变化较慢的参考数据，如在云上，例如通过数据市场，可以获得的社交网络图和加油站的燃料价格。计算设备和数据的激增导致对新兴的一类实时云边应用的关注日益增加。这些云边应用可以基于从大量的边计算设备和云收集来的实时资料提供业务，如通知或推荐。在一些情况下，计算设备102(1)_102(N)将它们的数据传送到云104，以供在云计算资源110上运行的一个或多个业务提供商进行处理。例如，为了解释的目的，假定一个这种业务是当用户的任何好友出现在用户的当前位置附近时向通知用户的交友业务。在一些实施例中，交友业务可以由运行在云计算资源110上的交友应用和运行在各个计算设备102 (I)-102 (N)上的相应交友应用来完成。对交友应用的使能需要来自用户的智能电话(例如，计算设备102 (I)-102 (N))的实时位置以及(限定好友关系的)缓慢变化的参考数据如社交网络的相互关联。为了便于解释，只考虑计算设备102(1)和102 (2)，并且假定计算设备102(1)属于用户1，计算设备102(2)属于用户2。此外，假定用户I和用户2已经被认为是“好友”。每个计算设备可以如箭头112(1)和112(2)所表示的那样时不时地向云上传数据。上传的数据可以被在云计算资源110上操作的业务提供商处理。业务提供商可以确定每个计算设备的结果并且将这些结果传送回到各自的计算设备102 (I)和102 (2)。在有些情况下，这种处理可能需要通过网络106在云104和计算设备102(1)和102(2)之间进行大量的上传和下载通信。本发明的构思可以考虑替代方案。该替代方案可被认为是动态的考虑资源的方案。在该动态的考虑资源的方案中，计算设备102(1)和102(2)之一可以判断，该计算设备个体通过从云获得其它计算设备的数据并且在该计算设备上进行本地处理可以减少系统资源的使用，如这些网络通信。(可以按照数目和/或网络带宽使用来考虑网络通信)。在此情况下，该计算设备个体不上传。其它(其余的)计算设备正常上传，并且该计算设备个体下载。该动态的考虑资源的方案可被认为是动态的，因为资源使用的计算可以随着场景的变化而变化。下面描述一个关于计算设备产生位置数据的速率的例子。当位置数据的速率改变时资源使用的计算可以产生不同的结果。因此，可以随着条件或参数变化以迭代的方式重复进行判断而不是一次性判断。为了说明这种减少资源使用的情况，假定计算设备102(1)属于用户1，计算设备102(2)属于用户2。进一步假定用户I正在他/她的办公室工作(例如，相对静止)，用户2在附近开车。在上述固定配置中，现有的交友应用将需求用户2 (计算设备102 (2))频繁地上传(112(2))他/她的位置，使得云知道他/她的最新位置是否与用户I的位置相关联。然而，用户I (计算设备102(1))可以不那么频繁地(例如，每小时一次)上传(112(1))他/她的位置，因为他/她的移动没有那么活跃。在该例子中，用户I和用户2的总通信开销是通过网络106每小时361个消息(忽略最终通知消息)。这样的网络使用可能是昂贵的，特别是当用户具有很多好友或者运行很多应用时。这可能严重限制应用的效用，因为这会被迫限制以什么样的频度将用户数据相互关联，这导致长的通知延迟。此外，由于应用对资源的高度占用，用户可能简单地关闭该应用。然而，在上述动态的考虑资源的方案的例子中，能够容易地解决该低效率问题。代替使用在云上相互关联的方法，用户I的位置可(通过分别由箭头114和116表示的云104)被发送到用户2的计算设备102(2)。然后可以由用户2的计算设备进行相互关联。在此情况下，用户2无论在哪都不需要发送他/她的位置，并且总成本变为每小时仅2个消息(一个消息是从用户I到云，另一个消息是从云到用户2)。注意，在随后的时间点，例如当用户I正在往家走时，该动态的考虑资源的方案可以确定不同的方法,例如在云104上处理。总之，该动态的考虑资源的方案可以确定要推出什么(如果有的话)计算以及要将它推给哪个边计算设备。该确定可被认为是优化问题，该优化问题取决于各种因素，如网络拓扑、数据流的速率、数据上传和下载成本、要相互关联的流对等。此外，由于这些参数可以随时间改变(例如，当用户I下班后开始走时他/她的速率可能改变)，所以该确定可被动态更新。一个动态的考虑资源的方案的实施例被称为RACE，下面对其进行详细描述。简言之，RACE(Real-time Applications over Cloud-Edge,云边实时应用)是用于说明和有效率地执行云边应用的架构和系统。RACE可以使用数据库技术来处理两个主要方面。第一，RACE处理实时云边应用的说明。第二，RACE处理与执行实时云边应用相关联的系统资源的使用。系统资源的使用可被增强和/或优化(在下文中，为了简洁，术语“优化”表示“增强和/或优化”)。云边应用的说明RACE通过提取云边应用的核心逻辑作为在一组流数据源上的与平台无关(p I at f orm-agno s t i c )的连续查询(CQ ),来解决实时云边应用的说明问题。云边应用通常用标准的命令式语言,如Objective C (面向对象的C)、Java或C#编写而成。应用开发人员需要手动实施应用逻辑中处理跨设备通信、公布和订阅数据流以及时间相关的语义的机制，如时序性连接和加窗计算。该处理是费时而且易出错的。RACE可以添加对大多数云边应用所共享的公共功能的平台支持。然后应用设计者可以将精力集中于核心应用逻辑，而不是实施细节。本发明的实施例利用如下事实:尽管不同的云边应用具有不同的应用特有特征(例如，可视化和对隐私的支持)，但是它们可具有一些共同性。例如，云边应用的数据和核心应用逻辑二者本质上通常是暂时性的。换句话说，云边应用可被视为在庞大的分布式系统中将实时的和缓慢变化的(但仍然是时序性的)参考数据持续相互关联的持续查询。例如，交友应用可被认为是边设备的实时GPS位置与缓慢变化的社交网络流之间的时序性连接。感知位置的优惠券应用将(在历史时间窗上计算出的)带有用户简档的当前用户位置信息与当前广告相关联。因此，在一些实施例中，云边应用的说明语言应该包含对时序性语义的原生支持。这种支持能够清楚地表达面向时间的操作,如时序性连接和加窗聚集(windowed aggregation)。可选地或附加地,该语言可以具有其它属性。例如，一个这种属性是说明语言的说明性本质。这可以允许应用设计者以说明性的并且与网络拓扑无关的方式说明应用，这样他们可以将精力集中于应用是“什么”，而不是它们被“怎样”实施。实施细节对应用设计者可以是透明的，并且可以改为由底层平台自动处理。另一个属性可涉及简洁性。应用的说明可以是简洁的，允许应用设计者进行富有成效的原型开发、部署和调试。简洁性自然与说明性(描述性)说明的采用相符。灵活性可以是另一个属性。该说明语言可以是灵活的，使得应用设计者能够容易地根据不同的输入/输出源和配置定制应用。现在根据这些属性描述说明语言的设计空间。说明性语言，如SQL和Datalog(及其变体，如Network Datalog)可以允许对分布式环境中的持续查询进行简洁和灵活的说明。然而，这些语言不具有对时序性语义的原生支持，而对于大多数云边应用来说对时序性语义的原生支持是至关重要的。另一方面，数据流管理系统(DSMS)使用满足所需属性的说明性时序语言。例子包括Streamlnsight 的LINQ 和Oracle CEP的StreamSQL 以及StreamBase 。以下描述使用Stream Insight的LINQ作为说明语言,但是该描述也适用于其它配置。LINQ允许时序性查询的说明性(描述性)说明，并且是基于与云边应用的时序性质很好地符合的的明确定义的代数和语义的。下面的讨论提供云边应用说明的一个例子。假设交友查询发现了满足如下条件的所有用户对(用户1、用户2):1)用户2是用户I的好友；以及2)在给定的时间，这两个用户在地理上彼此很近。在这点上，为了解释的目的，假定好友关系是非对称的，即，给定一时间点，用户2是用户I的好友不一定意味着反之亦然。存在对交友应用的两个输入，即，由边设备报告的GPS位置流和社交网络数据。在运行时间主动收集GPS位置，而社交网络数据是相对缓慢改变的并且通常可在云中获得。交友应用可被写为下面所示的两阶段时序性连接查询。var queryO=from elin locationfrom e2in social Networkwhere el.Userld==e2.Useridselect new {el.Userid, el.Latitude,el.Longitude, e2.Friendld};var queryl=from elin queryOfrom e2in locationwhere el.Friendld==e2.UserIdMDistance (el.Latitude, el.Longitude,e2.Latitude, e2.Longitude)<THRE SHOLDselect new{Userl=el.Userid, User2=e2.Userid};第一查询(queryO)连接将GPS位置流(location)与社交网络参考流(socialNetwork)连接,并且(在queryl中)得到的输出流再次与GPS位置连接连接，以检查每对好友之间的距离。最后的输出是(用户1、用户2)对的流，其中这两个用户是好友并且在地理上彼此接近。上述查询说明将查询的高等级逻辑定义为时序性连接，并且参考位置流和社交网络流的模式(schemas)。它是在社交网络流上编写的，并且是构思上统一的GPS位置流输入，因此是与网络拓扑无关的。作为另一个例子，假定所需功能是找到在上一周到访特定位置(如饭店)的好友。为了说明这一点，本发明的构思可以允许用location.AlterEventDuration (Time Span.From Days (7))替换queryl中的位置输入。这将位置事件的“寿命”扩展到7天，允许该连接考虑上一周内来自朋友的事件。总之，RACE可以使用云边应用的说明性(描述性)说明。RACE可以在由边设备和云构成的分布式系统上执行该逻辑。RACE可以使用未修正的DSMS作为黑盒子以在各个边设备和云上本地执行查询。一些RACE实施例可以在如下假定下操作:DSMS提供用户提交查询(其限定要执行的持续查询)用的管理应用程序接口(API )、事件类型(其说明输入数据流的模式)以及输入和输出适配器(其限定流数据如何从外界到达DSMS，以及从DSMS到达外界)。此外，API还允许用户在DSMS上开始和停止查询。换句话说，一些实施例可以将不同的数据流(或流的各部分)移动到云并且/或者通过云移动到其它边计算设备。一些其它数据流可以被本地保留在设备上并且不上传到云。此外，这些不同的(被移动的和本地的)流可以用作对运行在不同位置上的应用查询段的输入(例如，在一子组设备上或者甚至在云上)。这种查询的输出流本身可以被保留在本地以用于进一步的计算，或者被上传到云(然后可能被转发到其它设备)。总之，可以用分布式方式进行由最终用户说明的计算。RACE 结构图2示出一个RACE实施例的总体系统或系统架构200。系统架构200延续了图1的计算设备102 (I)-102 (N)、云104和网络106。系统架构200引入RACE管理业务202和RACE处理器204。该RACE处理器包括图构造器206、优化器208和查询构造器210。系统架构200还包括静态数据214、参考数据216、控制层218和数据层220。计算设备102 (I)-102 (N)分别包括DSMS222(l)-222(3)的实例。DSMS实例222 (4)还出现在云104中。结合提供给应用开发者224的体验来解释系统架构200。该应用开发者可以通过用说明性的时序语言(如LINQ226)编写应用与RACE管理业务202交互。为了解释的目的，假定该应用是交友应用228。上面结合图1介绍了交友应用的功能。交友应用228可以在各计算设备102 (I)-102 (N)上分别表现为交友应用实例228 (I) -228 (3)，并且在云104上表现为交友应用实例228(4)。此外，尽管为了简洁起见仅以计算设备102(1)为例，但是各个计算设备可以包括各种硬件230。在该例子中，所示出的硬件是处理器232、存储器234和其它硬件236。在下面对上面提到的元件进行更详细的描述。处理器232可以执行计算机可读指令形式的数据以提供功能，如交友功能。诸如计算机可读指令之类的数据可以被存储在存储器234上。该存储器可以在计算设备的内部或外部。存储器234可以包括易失性或非易失性存储器、硬盘驱动器和/或光存储设备(例如，⑶、DVD等)等中的任一个或多个。计算机102(1)还可以被配置为从存储器234接收和/或产生计算机可读指令形式的数据。计算机102(1)还可以通过网络接收计算机可读指令形式的数据，然后将该数据存储在该计算机上以由该计算机的处理器来执行。在可选的配置中，计算机102(1)可以被实施为片上系统(SOC)类型的设计。在此情况下，由该计算机提供的功能可以被集成在单个SOC上或者多个耦合的SOC上。在有些配置中，计算设备可以包括共享资源和专用资源。接口方便共享资源和专用资源之间的通信。如名称所暗示的，专用资源可以被认为包括专用于实现特定功能的各个部分。共享资源可以是存储器、处理单元等，它们可以被多个功能所使用。一般来说，能够使用软件、固件、硬件(例如，固定逻辑电路)、人工处理或者这些实施例的组合来实施本文中描述的任何功能。在本文中使用的术语“工具”、“部件”或“模块”一般代表软件、固件、硬件、整个设备或网络、或者它们的组合。例如，在软件实施例的情况下，这些可以代表程序代码，当在处理器(例如，一个或多个CPU)上执行该程序代码时该程序代码执行指定任务。该程序代码可以被存储在一个或多个计算机可读存储设备，如计算机可读存储介质中。部件的特征和技术是独立于平台的，这意味着它们可以被实施在具有各种处理配置的各种商业计算平台上。
在本文中使用的术语“计算机可读介质”可以包括瞬时指令和非瞬时指令。相反，术语“计算机可读存储介质”不包括瞬时指令。计算机可读存储介质可以包括“计算机可读存储设备”。计算机可读存储设备的例子包括易失性存储介质(如RAM)和非易失性存储介质(如硬盘驱动器、光盘和闪存等)。其它硬件236可以包括可以在各种计算设备上实施的显示器、输入/输出设备、传
感器等等。RACE管理业务202可以在云104中运行，并且可以呈现与DSMS的管理API充分兼容的管理业务。因此，各个计算设备102 (I)-102 (N)可以将它们的说明性云边应用逻辑提交给RACE管理业务202，作为由各自的DSMS222 (I) -222 (N)支持的规则的时序性说明性查询。注意，从边设备(例如，计算设备102(1)-102(2))的角度来看，它们看起来只是与通常的DSMS引擎通信。从其它角度来看，RACE管理业务202可以被认为是被配置为与在云上和在与云通信的各个边计算设备上执行的应用交互。RACE管理业务202可以被配置为模拟DSMS引擎以从各个边计算设备接收时序性说明性查询。简言之，RACE处理器204可以被认为是拦截和分析来自运行交友应用228的各个计算设备102(1)-102 (N)的输入查询、适配器和类型。然后RACE处理器204将这些输入编译为原始查询的对象表达。该对象表达被传送到图构造器模块206，图构造器模块206将该原始查询转换为较大的查询图。例如，该较大的查询图可以包括每个边输入流和算符。该查询图被传送到优化器模块208，以决定最优算符布局。最后，查询构造器模块210可以产生要在各个计算设备102 (I)-102 (N)或云104处执行的类型、适配器和(子)查询的对象表达。这些对象被(经由各个DSMS的管理API)发送到各个计算设备的各个DSMS，以用分布式方式执行该应用逻辑。注意，尽管在该配置中在云104上实施RACE管理业务202和RACE处理器204，但是在其它实施例中，可选地或附加地，可以在一个或多个计算设备102 (I)-102 (N)上实施RACE管理业务和/或RACE处理器。在计算设备上实施的RACE管理业务和/或RACE处理器可以是独立的或者与对应的RACE管理业务和/或云上的RACE处理器实例以合作的方式工作。图构造器206可以被认为是将查询的对象表达连同流速率的统计以及每个输入的元数据信息作为输入。该图构造器首先使用查询的对象表达来产生查询模式，该查询模式代表用于产生扩展的查询图的模版或框架。例如，图3示出由上文结合第25段描述的交友查询的图构造器206输出的查询模式302。查询模式302中的一些输入流参考按设备的数据流，如GPS位置源。图构造器206可以通过将所述流分解成多个输入(每个边一个)来创建所述查询模式的多个实例。可将缓慢变化的参考数据输入(如社交网络)具体化，以限制所产生的查询图的大小。例如，图4示出四个用户P、Q、R和S的社交网络400。图5示出用于交友查询的对应的实例化查询模式502(1),502(2)和502(3)。注意，为了在该实例化的查询模式中允许信息共享和避免重复的边，如图5中所示，实例化的源和连接接合算符被小心地命名。最后的步骤是将该实例化的查询模式502(1)-502(3)结合成完整的查询图。图6示出从图5中所示的实例化的查询模式得出的最终查询图602。注意，当结合实例化的查询模式时，(在实例化的模式中)具有相同名称的顶点被映射到最终查询图中相同的顶点。例如，Join〈GPS-P，SNP>顶点被边(P;R)和(P;S)的实例化模式所共享。回到图2，优化器模块208接受最终查询图602作为输入，并且决定在哪里执行该查询图中的每个算符(例如，查询部分)，使得该应用的总的或累积的通信成本被最小化(或者至少减小)。在数千个或者甚至数百万个用户参与该云边系统的情况下，最终查询图可能是巨大的——包含数百万个算符。对于这种大查询图，最优算符布局不是小事。RACE优化器模块可以使用各种技术来确定最优算符布局。一个技术是在下面的标题“最优算符布局(Optimal Operator Placement)”下描述的。RACE可以进行周期性的重优化以根据该查询图和/或统计的变化来调节该布局。在确定了增强/最优算符布局之后，RACE处理器204具有一组根查询图(每个图包括时序性算符的有向无环图(directed acyclic graph, DAG))。每个这种图对应于一些位置(边或云)。查询构造器模块210可以产生每个图的查询组成(包括事件类型、适配器和查询)的对象表达。然后该查询构造器模块可以经由控制层218将对象表达提交给对应的DSMS0注意，在每个DSMS实例中可以安装两个附加适配器一一个用于将事件数据发送到数据层220，另一个用于从该数据层接收事件数据。RACE控制层218用于使用DSMS的管理API将所产生的查询片段和元数据部署到DSMS的云实例和边实例。一个复杂因素是通常不能从RACE管理业务202直接到达或寻址边设备(例如，电话)。相反，RACE管理业务可以维护服务器，边设备建立和保持与该服务器的持续连接服务器，以接收被转发给边上的DSMS实例的管理命令。在查询执行期间，事件在边设备和云之间流动。RACE管理业务202可以使用单独的数据层220，该数据层220在云104上表现为服务器，并且边计算设备102 (I)-102 (N)可以经由控制层218连接到该数据层220。边计算设备和云上所产生的查询订阅并公布使用数据层220注册的所谓的流。该数据层将来自云104的事件路由到边计算设备102 (I)-102 (N)，以及将来自边设备的事件路由到云。在数千或者甚至数百万个用户参与到该云边系统中的情况下，最终查询图可能是巨大的一包含数百万个算符。由于数据源是分布式的(例如，不同用户的GPS数据流源自他们的边设备)，所以每个算符的布局会影响到查询评估开销。算符布局存在指数增长的众多不同组合。搜索整个设计空间的单纯方法可能是不可行的。另外，对中间结果的共享的考虑使得问题更加困难。以下讨论涉及通过利用云边系统的特殊“星形”拓扑的用于最优算符布局的有效算法的例子。对于一些实施例，在下面给出的两个假定下，可以证明该算法的正确性。此外，发现最优布局的开销可以非常低。假定1.与输入流数据相比，查询的最终输出小得多，因此可以忽略其成本。考虑到云边应用的普遍性质，该假定是合理的。另外，基于隐私考虑，一些实施例可以限制算符的允许位置。例如，流数据可能包括敏感的个人信息(例如，移动电话的地理位置踪迹)。边客户可能不想暴露原始信息，除非它被适当处理(通过从连接操作的最终结果中排除该敏感数据)，或者它只被传送到授权的节点。假定2.对于任意连接A [><d B(其中A和B是该连接的输入流)，在云上或者A或B所起源的节点上进行连接操作。注意，该假定没有简化布局问题；仍然存在指数增加数目的可能的算符布局。在给出该论证和所提出的算法之前，描述几个基于图的表示。定义(需求)，可以被表示为一对(Vl，V2)，其中流数据源V2 “需要”由另一个源V1产生的数据(即，需要与另一个源V1产生的数据相关联)。定义(需求图),对于云边应用，需求图G=(V, E)被定义如下:顶点集合V={v/v是流数据源}，和E=Kv1, V2) I (Vl，V2)是需求对}。每个边e=(i，)e E与速率相关联，速率rij表示Vj需求的Vj的流速率。算法1.从查询图产生需求图
权利要求
1.一种方法(1000)，包括: 获得在包括多个边设备和基于云的资源的云边拓扑中的说明性流查询(1002); 将所述说明性流查询转换为反映所述多个边设备的查询图(1004);以及 基于所述云边拓扑的资源使用来判断是在各个边设备上执行所述查询图的算符还是在所述基于云的资源上执行所述查询图的算符(1006 )。
2.根据权利要求1所述的方法，其中所述边计算设备包括智能计算设备，该智能计算设备被配置为通过网络直接与所述基于云的资源通信，并且其中所述网络被配置为不允许各个智能计算设备直接相互通信，而是所述各个智能计算设备通过所述基于云的资源间接地相互通信。
3.根据权利要求1所述的方法，其中所述判断包括:关于网络带宽资源的使用，确定与所述基于云的资源有关的全局优化。
4.根据权利要求3所述的方法，其中所述确定全局优化包括:允许所述查询图的节点以贪心方式进行本地决策，并且其中所述本地决策在被查看时累积地产生所述全局优化。
5.一种系统(200),包括: 基于云的云边上实时应用即RACE管理业务(202)，其被配置为与在所述云上以及在与所述云通信的各个边计算设备上执行的应用交互，所述基于云的RACE管理业务被配置为模拟数据流管理系统即DSMS引擎，以从所述各个边计算设备接收时序性说明性查询；以及 RACE处理器(204)，其被配置为拦截所述时序性说明性查询并且将各个时序性说明性查询分析并编译为对象表达。
6.根据权利要求5所述的系统，其中所述RACE处理器包括图构造器，所述图构造器被配置为从所述对象表达产生查询模式。
7.根据权利要求6所述的系统，其中在所述查询模式包括指向来自每个边计算设备的数据流的输入流的实例下，所述图构造器被进一步配置为通过将所述数据流分解成所述查询模式的多个实例，所述查询图的每个边一个输入流，来产生包括所述查询模式的多个实例的查询图。
8.根据权利要求7所述的系统，其中所述RACE处理器包括优化器，所述优化器被配置为确定在哪里执行所述查询图的各个算符，以减小所述边计算设备和所述基于云的资源之间的总通信成本。
9.根据权利要求8所述的系统，其中所述优化器被配置为确定在哪里执行所述查询图的各个算符，以使所述边计算设备和所述基于云的资源之间的总通信成本最小化。
10.根据权利要求5所述的系统，其中所述RACE处理器包括查询构造器，所述查询构造器被配置为产生要在每个边计算设备或者在所述云上执行的类型、适配器和子查询的对象表达。
全文摘要
本发明涉及云边拓扑。一些方面涉及在各种云边拓扑中的云边应用和资源的使用。该云边拓扑的另一方面可涉及使用时序语言的云边应用的说明。另一方面可涉及在云以及云边计算机上运行数据流管理系统(DSMS)引擎以运行查询的各个部分的架构。
文档编号H04L29/08GK103108031SQ20121057976
公开日2013年5月15日 申请日期2012年12月27日 优先权日2011年12月27日
发明者巴德里什·钱德拉蒙利, 苏曼·纳特, 周文超 申请人:微软公司