多云环境中的分层数据分析

最新推荐文章于 2025-11-25 13:41:55 发布

原创最新推荐文章于 2025-11-25 13:41:55 发布 · 380 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#物联网 # 多云环境 # 语义网 # 分析即服务 # OpenIoT

通过语义支持的分层数据处理在多云环境中实现分析即服务

摘要

大量云中间件平台和工具被部署以支持各种物联网（IoT）数据分析任务。通常情况下，这些云平台仅由其所有者使用，以实现其主要且预定义的目标，其中原始数据和处理后的数据也仅由他们消费。然而，允许第三方访问处理后的数据以实现其自身目标，将显著增强集成与协作，并可能促进数据的创新使用。多云、隐私感知环境有助于实现此类数据访问，使不同各方能够共享处理后的数据，从而共同减少计算资源消耗。然而，在涉及异构数据和分析即服务提供商的此类环境中，存在互操作性问题。目前既缺乏可支持此类多样化多云环境的架构蓝图，也缺少证明此类架构可行性的实证研究。本文提出了一种创新的分层数据处理架构，该架构在多云环境中利用语义技术贯穿物联网架构的各个层级。我们基于该架构构建了一个系统，采用OpenIoT作为中间件，Google Cloud和Microsoft Azure作为云环境，以此验证了该架构的可行性。评估结果表明，该系统具有可扩展性，且无明显限制或开销。版权所有 © 2016 John Wiley & Sons, Ltd.

2016年1月29日收到；2016年6月8日修订；2016年7月3日接受

关键词 ：物联网；多云环境；大数据；语义网；数据分析

1. 引言

最近的研究表明，我们每天产生250万亿字节的数据[1]，并且预计到2020年这一数据量将激增至40尧字节。这相当于地球上每个人约拥有5200GB的数据。这些数据中的大部分当前及未来都将来自物联网（IoT）[2]。物联网是未来互联网的一部分，包含数十亿个互联网连接对象或‘物’，其中每个‘物’都能感知、通信、计算、可能执行操作，并具备智能、多模态接口、物理/虚拟身份和属性。互联网连接对象可包括无线/有线传感器、射频识别（RFID）、社交媒体数据、智能消费电器（电视、智能手机等）、智能工业（如配备传感器的设备）、科学仪器（例如高能物理同步加速器）以及执行器。该愿景

物联网的目标是让‘物’能够随时随地与任何事物和任何人互连，理想情况下使用自配置的路径、网络和服务。这一愿景促使物联网成为大数据的主要生产者。如今，云计算技术[3, 4]通过提供软硬件资源组合，并以与实际使用成比例的适度运营成本（按需付费模式）来存储和高效处理大规模数据集[5]。众所周知，物联网大数据应用需要处理和管理来自地理上分布的数据源的流数据。云计算模型已成为满足物联网大数据应用数据处理需求的合适解决方案。云本质上在物联网与应用程序之间充当一个透明层，提供了灵活性和可扩展性，并隐藏了两层（物联网和应用程序）之间的复杂性。将云与物联网融合为“物联云”，催生了以下新的云计算范式（但不限于）：感知即服务、感知与执行即服务、视频监控即服务、大数据分析即服务、数据即服务以及传感器事件即服务。然而，集成的物联云方法从物联网层开始就带来了一系列挑战，包括设备发现、高效成本通信、设备管理与监控、互 operability、服务质量以及机器对机器（M2M）问题；在云层则包括服务发现与交付、大数据管理与分析、云监控与编排、云访问中的移动性问题、隐私与安全以及服务等级协议（SLA）管理。此外，-即服务模式的概念将使多个独立运营商能够在物联云层次上提供各种服务，并根据应用需求进行集成。物联网的迅猛发展及其相应生态系统将很快导致设备由独立提供商拥有和运营。这些解决方案大多将受限于彼此独立的多云提供商孤岛。多云环境由多个数据中心组成，这些数据中心在互联网上地理和拓扑上分布[6, 7]。本工作的重点是应对来自由多个服务提供商拥有和运营的‘物’所产生的物联网数据在多云环境中进行数据分析的挑战。允许第三方访问这些数据及分析能力，可以显著提升终端用户应用的创新与价值。需要处理和管理来自多个源的流数据的物联网大数据应用，必须利用分布在多个云数据中心的资源，原因如下[8]：

物联网数据集和数据源可能是地理上分散的；因此，将它们移动到单一的集中式数据中心可能会导致较高的网络通信开销。
任何单个数据中心所提供的计算与存储资源都无法满足物联网数据的存储和处理需求。例如，在Azure云中，每个应用部署的限制为300个核心（即在任何时刻可部署的虚拟机最大数量）。显然，如果物联网数据集以高容量和高速度流动，这可能会导致严重问题。
物联网数据集可能受到安全和法律政策的约束；也就是说，数据可能不得离开国家司法管辖区，或不能传输到远程的国际数据中心。

本文提出了一种适用于多云环境的分层数据分析模型。我们所提出的方法允许终端用户应用集成并利用独立的基础设施和分析服务提供商。我们提供了一个用例，以展示所提出的分层和分布式多云方法，促进跨云提供商的分析数据的有效且高效的共享。我们采用流行的开源物联网中间件平台OpenIoT[9]来验证该方法在多云环境中的可行性。最后，我们在谷歌云和微软Azure平台上进行了实验评估，以验证所提出的分层和分布式多云方法系统的性能。

需要注意的是，我们的方法不依赖于应用，因此可以推广到任何应用领域，只需根据不同需要使用不同的分析功能即可。在我们提出的基础设施上，可以使用任何类型的分析功能。本文假设参与特定数据分析任务的所有云实例在组织成特定的分层结构以支持给定应用之前，都是可信且经过验证的。

2. 动机：分析即服务

在感知即服务[10]模型中，数据生产者（所有者）和消费者通过云资源无缝交换数据。数据生产者是物联网设备（产品）的所有者，并将其部署在自己的环境中。这些物联网产品进行感知、分析并执行操作，以满足数据所有者的需求。尽管这些数据通常孤立地存储在各自的系统中，感知即服务模型促进了数据共享（将数据从孤岛中解放出来），允许数据消费者通过安全机制访问数据。例如，研究植物疾病传播的植物生物学家可能希望了解受影响农场的列表，以更好地理解疾病的传播轨迹。在这种情况下，该生物学家的目的并不是识别单个农场，而是特定区域内的一组农场。当数据提供者和消费者的数量增加时，就有必要建立一个开放数据市场。该市场中的数据不一定免费提供[11]（可能遵循云计算的按需付费模式），但其元数据描述将是公开的。元数据将帮助用户和其他服务发现存储在数据拥有者孤岛中的相关数据。

分析即服务指的是下一代物联网数据处理应用，其中第三方将负责在私有/公共云基础设施上托管物联网分析和数据处理应用（例如，从视频摄像头流中检测事件以及从智能家居传感器中检测事件）。这些分析应用将以按使用付费的模式提供给最终用户。目前，诸如亚马逊网络服务等提供商已为基于云的硬件（中央处理器、存储和网络）和软件（数据库、消息队列系统等）资源提供此类服务模型。诸如SalesForce.com等提供商则为企业资源规划（ERP）和客户关系管理（CRM）应用程序提供按使用付费模型。然而，ERP和CRM应用程序与物联网分析应用在本质上存在差异。此外，分析即服务模型还引入了更多复杂性，因为不仅需要描述数据，还需要描述对数据执行的分析。进一步地，当数据分析作为独立数据所有者云中的数据孤岛存在时，有必要开发能够跨多个云服务提供商运行的系统。此类系统本质上需要具备以下能力：（i）通过标准接口实现互操作的能力，（ii）描述数据的能力，（iii）支持机器对机器通信，以及（iv）描述基于所获取数据构建的分析的能力。

分析即服务模型提供的另一个优势是，它在降低隐私风险的同时支持知识共享。由于该模型不共享原始数据，因此消除了与共享原始数据相关的风险，例如已分析数据的匿名共享，并可对数据存储位置施加限制。另一个优势是由于消除了冗余数据处理而节省了计算资源。这意味着当一个云物联网平台对数据执行特定的数据处理任务后，接收方的云平台无需再次执行相同的数据处理任务。例如，一个物联网云平台可以收集来自运动传感器和摄像头的数据，以确定一个人在某个队列中的平均等待时间。一旦完成此类数据处理，接收方云平台便可将平均等待时间作为输入。我们将在第5节介绍用例场景时详细阐述此示例。此外，分析即服务模型还减少了数据通信需求。通常，原始数据在大小上较大，而已处理的数据则显著小于原始数据。因此，从一个云传输到另一个云的数据量大幅减少，从而节省了网络通信带宽和成本。

3. 当前技术水平：处理分布式物联网数据

现有的大数据处理技术和数据中心基础设施在应对分布式物联网数据处理挑战方面具有不同的能力。在本节中，我们根据以往工作中的综述总结了现有技术的能力。所提出的分析即服务模型预计将广泛利用这些技术。我们从六个不同主题对文献进行了回顾：（i）基础数据中心云计算基础设施服务栈，（ii）大规模数据处理模型和框架，（iii）可信且集成跨数据中心的数据管理服务、（iv）数据密集型工作流计算、（v）基准测试、应用核心、标准与建议，以及（vi）云中的感知中间件。

数据中心云计算基础设施服务堆栈

商业或公共数据中心，例如亚马逊网络服务和微软Azure，通过应用程序编程接口（API）将计算、存储和软件资源作为远程可编程云服务提供。这些资源通过部署虚拟化软件/中间件堆栈进行编排。众所周知，虚拟化使数据中心提供商能够通过允许多个虚拟云资源实例并发运行，从而更充分地利用物理资源。例如，虚拟机编排系统如Eucalyptus和亚马逊EC2，镜像管理工具如FutureGrid镜像仓库[13],，海量数据存储/文件系统如谷歌文件系统（GFS）、Hadoop分布式文件系统和Amazon S3，以及数据密集型执行框架如亚马逊弹性MapReduce。此外，FutureGrid‡和OpenStack也为云数据中心提供软件堆栈定义。

另一方面，私有数据中心通常是通过组合多种软件工具和服务构建而成。这些软件可包括集群管理系统，如Torque、OSCAR、VMware的vCloud和/或vSphere套件以及简单Linux资源管理工具；并行文件/存储系统，如存储区域网络（SAN）/网络附加存储（NAS）§、Lustre；以及数据管理系统，如BeST-Man¶和dCache||。此外，一些私有数据中心还通过网格计算中间件（如Globus工具包、Unicore和g Lite）实现资源共享。通常情况下，由于严格的安全与隐私问题，对私有数据中心资源的访问仅限于已知的应用管理员和用户组。

大数据处理模型与框架

大数据处理框架包括能够创建大数据应用架构的软件框架[14][15]。这些框架可以分类如下：

大规模数据挖掘框架（FlexGP、Apache Mahout、MLBase 和 Yahoo SAMOA）通过利用分布式资源，实现多种数据挖掘算法（聚类、决策树、潜在狄利克雷分配、回归和贝叶斯），以并行方式分析海量数据集（历史与流式）。
分布式消息队列框架（亚马逊Kinesis 和 Apache Kafka）提供了一个可靠、高吞吐量、低延迟的系统，用于队列化实时数据流。
并行与分布式数据编程框架（Apache Hadoop 和 Apache Storm）。此类框架支持开发分布式应用，以处理大量云资源，并对海量历史与流式数据进行并行处理[15, 16]。前述的大规模数据挖掘框架通常构建于并行与分布式数据编程框架之上。底层分布式系统管理复杂性（任务调度、数据暂存、故障管理、进程间通信和结果收集）由这些框架自动处理。
数据存储框架分为NoSQL和结构化查询语言（SQL）。NoSQL框架（MongoDB、HyperTable、Cassandra和Amazon Dynamo）支持基于事务编程原语的访问，其中通过精确的键可查找精确的值。这种预定义的访问模式有助于提高可扩展性并预测性能，适用于存储大量非结构化数据（例如社交媒体帖子）。SQL数据存储（MySQL、SQL Server和PostGreSQL）

在关联性表中管理数据，可以使用通用SQL来操作数据（插入、删除和更新）。本质上，当需要严格的事务完整性（ACID特性）时，SQL数据存储比NoSQL存储更有效。

未来的大数据应用程序可能会同时使用NoSQL和SQL数据存储，以满足数据多样性和查询需求。SQL引擎（Apache Hive和Apache Pig）能够基于结构化查询语言对多种云存储资源（包括Amazon S3和Hadoop分布式文件系统）中的数据进行查询。

Da计算密集型工作流编排框架 ework

用于管理科学大数据应用程序的典型工作流框架[17, 18]包括Pegasus、Kepler、Taverna、Triana、Swift和Trident。传统上，在服务计算领域，使用业务流程执行语言（BPEL）和另一种工作流语言（YAWL）[19]进行编排已被广泛研究。另一方面，服务协同则通过WS-CDL**实现。最近，出现了诸如Yet Another Resource Negotiator（[20]）和 Mesos [21]等编排框架，用于跨多个大数据处理框架协调物联网数据分析工作流任务（例如 Apache Hadoop 和 Apache Storm

基准测试、应用核心、标准与建议

已开发出多种基准测试和应用核心，例如 Graph 500（graph500.org/）、Hadoop Sort†† 和排序基准（sortbenchmark.org）、MalStone[22],、Yahoo! 云服务基准‡‡、Google 集群工作负载§§、TPC-H 基准（www.tpc.org/tpch）、BigDataBench、BigBench、HiBench、PigMix、CloudSuite 和 GridMix，这些均由分析不同大数据工作负载性能的需求所推动。这些基准测试套件对大数据处理框架的一个或多个类别（如 Apache Hadoop 和 Apache Mahout）进行压力测试的工作负载建模。

在当前一代的框架套件中，BigDataBench 和 BigBench 是最全面的，因为它们涵盖了适用于多种处理框架的大数据工作负载模型，包括 NoSQL、数据库管理系统、流处理引擎和批处理框架。主要来说，BigDataBench 针对搜索引擎、社交网络和电子商务等应用领域。然而，目前针对异构数据中心和物联网数据类型的可用基准测试与应用核心仍然有限。

特别是，在跨分布式数据中心执行大规模物联网应用的性能基准测试方面尚无共识。事实上，跨中心基准和标准的缺失应成为未来的主要研究议程。目前，包括美国国家标准与技术研究院、开放网格论坛、DMTF 云计算工作组、云安全联盟和云标准用户委员会在内的国际组织均在致力于云标准的制定（occi-wg.org/）¶¶。

云中的感知中间件

在过去几年中，越来越多的物联网云已进入感知中间件市场。Thingworx（thingworx.com）和Xively（xively.com）是基于云的在线平台，可通过多种不同协议处理、分析和管理获取的传感器数据。HomeOS[23] 是一个支持家庭自动化的平台。HomeOS 是一种可在普通PC上安装的软件平台。与SmartThings平台类似，可安装应用程序以支持不同的上下文感知功能（例如，当有人按门铃时，从门铃摄像头捕获图像并发送给用户）。Lab-of-things[24] 是为实验性研究构建的平台。它允许用户轻松地将硬件传感器连接到软件平台，并实现数据收集以及数据、代码和参与者的共享。然而，这些平台大多由其所有者托管在云上，客户对所使用的云计算技术没有选择权。目前存在少数开源物联网平台，由研究社区（例如 OpenIoT[9]）和

** http://www.w3.org/TR/ws-cdl-10/. †† http://wiki.apache.org/hadoop/Sort. ‡‡ http://research.yahoo.com/Web_Information_Management/YCSB. §§ http://code.google.com/p/googleclusterdata/. ¶¶ http://www.dmtf.org/standards/ovf.

4. 多云环境中的分层数据分析

在本节中，我们首先解释分层数据分析在多云环境中的含义及其重要特征和特性。然后，我们介绍广泛使用的开源物联网平台OpenIoT，并描述其支持多云分层处理的功能。所介绍的OpenIoT平台由语义网概念驱动，因此广泛使用本体来定义设备和服务。这一将在下文详细阐述的OpenIoT特性，是实现分层多云数据分析模型的基础。

让我们考虑图1。需要注意的是，分层数据分析并不意味着通信网络必须是分层的。分层数据分析可以在任何类型的网络中进行。其基本思想如下：首先，数据由叶节点采集。在图1中，节点A、B、C和D可被视为叶节点，负责收集来自不同源生成的数据流。数据源可以是硬件传感器（例如温度传感器）或虚拟传感器（例如调用天气服务）。首先，叶节点可以分析其收集的数据。每个节点可能具有基于其所能访问的数据分析工具库的自身数据分析能力（如a1:::a10所示）。一旦叶节点应用了数据分析，数据就会被传输到下一层节点（即节点E和F）。这些节点将对传入的数据流执行另一组分析，并生成更高级的抽象输出（即一个数据流）。最后，节点E和F将其输出传输给节点G。

示意图0

需要注意的是，数据处理并不遵循任何特定的分层结构。其思路是在一个节点中执行分析，并将结果传递到另一个节点以执行另一组分析。因此，节点A、B、C和D不必位于同一层。如果节点A不需要节点E中执行的分析，则数据流可以直接发送到节点A，而无需经过节点E。

在感知即服务模型和分析即服务模型中，节点通过收集和处理数据以实现其自身目标。多云环境中的分层数据分析

当某个节点无法访问所需数据时（例如节点G），就会出现这种情况。此时，发起节点会向其他节点发送请求，以获取其所需的数据。此外，如图1中的红色箭头所示，每经过一层，需要在节点之间传输的数据量以及带宽需求都会减少。这主要是因为每一层都会对数据执行某种分析，并生成更加聚合的结果。例如，平均函数可以在5分钟内对数据进行聚合，并生成一个单一元组。在另一个实例中，某个函数可以结合来自视频摄像头的传感器数据，识别在一小时内进入特定区域的人数。通过感知流式视频流，每个处理节点可能只需将人数统计结果流式传输到层次结构中的下一个节点。该提出的模型具有多个优势，即：

它促进了跨各个层的服务集成
它允许数据生产者和消费者无缝集成，同时对基础设施和技术保持无关性
它是一个用于构建复杂终端用户应用的平台，而无需拥有数据生产基础设施或数据处理工具/基础设施
它支持服务提供者能力的无缝发现，可通过多种机制实现，包括语义发现、概率发现和面向服务架构风格的发现。

4.1. OpenIoT：一种物联网开源中间件

OpenIoT中间件[9]是一种用于从物联网数据源收集和处理数据的多功能蓝图架构。OpenIoT提供了一个创新的完整物联网架构平台，支持物联网/云计算融合，能够实现：（i）在云计算基础设施内集成和流式传输物联网数据与应用程序；（ii）在云中部署语义上可互操作的应用程序；（iii）在物联网领域实施主流云计算概念和特性，包括“感知即服务”概念（即按需、基于效用的访问物联网服务）以及物联网应用程序的按使用付费模式；（iv）处理移动传感器（如智能手机）及其相关的QoS参数（如能效）。目前，OpenIoT使用标准通信协议，如传输控制协议/互联网协议和RESTful架构，以实现不同组件之间的通信。然而，它是一个开放框架，支持任何新协议，例如CoAP。

4.1.1. OpenIoT：架构概述

OpenIoT架构由七个主要元素组成，这些元素属于三个不同的逻辑平面，如图2所示。这些平面分别为效用/应用平面、虚拟化层和物理层，包含以下模块：

效用/应用平面 ：效用和应用平面负责管理与终端用户应用的交互。特别是，它提供了一套工具和接口，用户可利用这些工具和接口动态部署物联网应用。它包含以下关键组件，即：

请求定义支持向OpenIoT平台指定服务请求。它包含一组用于定义和构建此类请求的服务，同时将这些请求提交至全局调度器。该组件可通过功能丰富的图形用户界面实现以支持用户交互，或通过应用程序编程接口实现机器对机器通信。
请求呈现负责可视化物联网服务的输出结果。该组件根据服务描述创建信息聚合，以促进已分析数据的呈现。
配置与监控组件支持对传感器以及在OpenIoT平台上部署的（OpenIoT）服务的功能进行管理和配置。此外，它还允许用户监控各个已部署模块的运行状态。

示意图1

虚拟化层 ：虚拟平面负责连接设备层（物理的）与应用层。在大多数情况下，虚拟平面部署在云环境中，负责向物理层和应用层提供核心功能和服务。请注意，云基础设施可以是公共基础设施（例如亚马逊弹性计算云（EC2）），也可以是私有基础设施（例如基于OpenStack部署的私有云（http://www.openstack.org/)）。它包含以下组件

目录服务（轻量级链接传感器中间件（LSM-Light））保存有关OpenIoT平台中所有可用传感器和服务的信息。它还提供将传感器和服务注册到目录以及查找（即发现）传感器和服务的手段（即服务）。该架构指定在其目录服务中使用传感器的语义标注描述。该组件通过扩展万维网联盟（W3C）语义传感器网络（SSN）本体而开发，[9]以实现对传感器及其相应服务的表示。由于目录服务主要支持传感器数据流及其元数据的存储与管理，因此可将其表征为传感器云。作为OpenIoT平台的关键组成部分，它对于所提出的分层多云数据分析方法的关联性至关重要，将在下一节中详细讨论。
全局调度器处理所有关于服务按需部署的请求，并确保其对资源（例如数据流）的正确访问。该组件负责解析服务请求，并相应地发现能够参与满足该请求的传感器。同时，它还选择用于支持服务部署的资源（即传感器），并执行相关的资源预留操作。
服务交付与效用管理器（SDUM）发挥双重角色：一方面，它根据服务工作流描述整合数据流，以交付所需的服务；为此，该组件利用服务描述以及由（全局）调度器组件识别和预留的资源。另一方面，该组件充当服务计量设施，持续跟踪每个单独服务的效用指标，从而通过基于效用的计量支持由不同服务提供商所提供的服务来开发应用程序。

物理层 ：物理层指的是部署在物理环境中的设备。这可以包括真实硬件传感器和虚拟传感器。该层负责管理设备层与上层（虚拟层和应用层）之间的交互。该层具备感知和执行能力。该层包含以下组件：

传感器中间件（网关）收集、过滤并整合来自虚拟传感器（例如信号处理算法、信息融合算法和社交媒体数据流）或物理传感设备（如温度传感器、湿度传感器和气象站）的数据流。该中间件充当OpenIoT平台与物理世界之间的枢纽，使其能够访问来自现实世界的信息。此外，它还支持与多种物理和虚拟传感器的接口连接，例如符合 IETF COAP的传感器（即提供RESTful接口的传感器）、其他物联网平台（如 https://xively.com）的数据流以及社交网络（如Twitter）。传感器中间件的主要特性之一是能够在云中传输符合W3C SSN的传感器数据。传感器中间件部署在一个或多个分布式实例（节点）上，这些实例可能属于不同的管理实体。OpenIoT平台的原型实现采用了一种增强/扩展版本的GSN中间件（即X-GSN，目前作为OpenIoT开源项目的一个模块）。然而，在OpenIoT架构的其他实现和部署中，也可以使用其他传感器中间件平台。

安全平面 ：安全平面贯穿OpenIoT架构堆栈，确保端到端的安全机制。该平台采用基于令牌的认证系统，并通过基于角色的访问控制实现认证、授权和身份管理。

4.2. 使用OpenIoT的分层多云数据分析

OpenIoT 系统由语义网技术驱动。它广泛使用 W3C SSN 本体的一个增强版本，即 OpenIoT 本体[25]，用于在物联网架构的每一层（即设备层、虚拟层和应用层）对数据进行语义标注。OpenIoT 利用其他语义网技术，例如关联数据[26]，以动态关联相关的传感器数据集与相应服务，反之亦然；并使用资源描述框架 (RDF)、网络本体语言以及简单协议和RDF查询语言 (SPARQL) 来实现传感器和服务的语义建模、表示、存储和检索。在本节中，我们将介绍 OpenIoT 架构的功能，这些功能支持多云数据分析应用的实现。

虚拟层服务，即LSM-Light、调度器和SDUM，是OpenIoT架构的核心，支持以下能力：（i）能够使用语义描述注册传感器；（ii）能够注册由用户/应用程序组合的服务；（iii）提供支持传感器和服务语义发现的发现服务。在OpenIoT中，service被定义为一种规范，用于定义在传感器数据流上执行的一组分析操作以及相应的可视化呈现。

示意图2

设备描述 ：OpenIoT 本体扩展了 W3C SSN 本体，使其能够通过虚拟层描述和注册设备（传感器和事物）。图3展示了一个部分传感器描述的示例。该RDF随后描述了一个名为Vaisala 气象站的传感器，其具备测量温度和湿度的能力。

服务描述 ：OpenIoT 服务描述规范（OSDSpec）能够详细描述由用户/应用程序组成的服务。OSDSpec 基于 OpenIoT 本体建模，并由虚拟层的目录服务和调度器组件进行存储和管理。该 OSDSpec 可以详细描述服务，包括查询控制功能，如查询计划和查询权限。列表1 是一个 OpenIoT OSDSpec 的示例。

设备与服务的发现与调用
一旦设备和服务在虚拟平面（即目录服务）中注册，便使用目录服务、调度器和SDUM来发现和调用

列表1. OpenIoT服务规范示例

<?xml version="1.0" encoding="UTF-8"?>
<osd:OSDSpec xmlns:st="http://www.w3.org/2007/SPARQL/protocol-types#"
xmlns:vbr="http://www.w3.org/2007/SPARQL/results#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:osd="http://www.openiot.eu/osdspec"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" {v4}>
<osd:OAMO 名称=" 名称0 " >
 <osd:OSMO 名称=" 名称1 " >
  <osd:queryControls>
   <osd:QuerySchedule>
   </osd:QuerySchedule>
   <osd:reportIfEmpty>false</osd:reportIfEmpty>
  </osd:queryControls>
  <osd:requestPresentation>
   <osd:widget widgetID="http://www.oxygenxml.com/">
    <osd:presentationAttr 名称=" 名称2 " 值= 值 0 "/>
    <osd:presentationAttr 名称=" name3 " 值= 值 1 "/>
   </osd:widget>
   <osd:widget widgetID=" http://www.oxygenxml.com/ ">
    <osd:presentationAttr 名称=" 名称4 " 值= 值 2 "/>
    <osd:presentationAttr 名称="name5" 值= 值 3 "/>
   </osd:widget>
  </osd:requestPresentation>
  <st:query-request>
   <query>query0</query>
  </st:query-request>
  <st:query-request>
   <query>query1</query>
  </st:query-request>
 </osd:OSMO>
</osd:OAMO>
</osd:OSDSpec>

清单2. 设备发现查询示例

SELECT ?graphNode_2197552479500_sensorId
FROM <http://openiot.eu/OpenIoT/sensormeta#>
WHERE
?{ graphNode_2197552479500_sensorId <http://www.w3.org/1999/02/22-rdf-syntax-ns#type><http://demo.org/ns#TestType>.
<http://demo.org/ns#TestType><http://www.w3.org/2000/01/rdf-schema#subClassOf><http://purl.oclc.org/NET/ssnx/ssn#Sensor>
.
?graphNode_2197552479500_sensorId <http://www.loa-cnr.it/ontologies/DUL.owl#hasLocation>?graphNode_2197552479500_loc
.
?graphNode_2197552479500_loc geo:geometry ?
graphNode_2197552479500_geo.
?graphNode_2197552479500_loc geo:lat?graphNode_2197552479500_lat
.
?graphNode_2197552479500_loc geo:long ?
graphNode_2197552479500_lon.
FILTER( <bif:st_intersects>( ?graphNode_2197552479500_geo, < bif:st_point>( 6.635227203369141, 46.52119378179781), 15) ) .
}

组合服务。清单2展示了一个用于在指定位置内对设备（事物）执行语义发现的SPARQL查询示例。该查询还接受诸如SensorType和SensorClass等附加参数，以实现更高效的发现。发现服务还可用于发现服务，例如由服务提供商提供的分析服务。通过虚拟平面，应用程序能够发现来自独立传感器基础设施所有者和分析服务提供商所提供的服务。

虚拟平面组件还提供API接口以调用已发现的服务。所提出的多云模型的关键贡献在于促进不同数据和分析服务提供商之间的互操作性。这是通过发现服务与API相结合，实现多云数据分析应用的开发而达成的。

5. 实验与评估

在本节中，我们展示了一个真实世界的用例场景，以证明分层数据处理在多云环境中的重要性。然后，我们描述了使用OpenIoT系统实现的实验测试平台，以验证其可行性并进行性能评估。

5.1. 一个案例研究

TrueLeisure是一家运营多种娱乐设施的公司，其中包括特许经营的游乐园连锁。如图4所示，目前这些游乐园位于美国、英国和澳大利亚。这些游乐园由特许经营商完全拥有并负责运营。然而，TrueLeisure持续监控和评估每个游乐园的服务质量及其他多个方面。

Jane 是一名数据分析师，负责监督 TrueLeisure 游乐公园的数据质量评估任务。她需要持续监控服务质量参数。除了 Jane 之外，

示意图3

每个特许经营商都有自己的数据分析和质量控制部门，用于监控各自的质量参数。所有游乐园都配备了大量传感器，用于收集各种类型的信息，例如环境参数（如温度、湿度和压力）、人群流动、各游乐设施和景点的使用情况与需求，以及游乐园中机械设备的运行状态。每个游乐园都部署了各自的物联网平台，并将传感器连接至该平台。从概念上讲，查询语句可能类似于“从美国、英国和澳大利亚选择平均等待时间”。此类抽象的重要性在于，Jane 无需了解如何在每个地点获取等待时间，因为各个地点可能采用不同的技术手段来采集不同类型传感器数据，从而推导出等待时间。

一个重要的服务质量参数是‘等待时间’。这是影响客户满意度的主要因素之一。本地质量评估团队会持续测量其各自游乐园内每个游乐设施和景点的排队等待时间。通过运动传感器、摄像头、蓝牙信标和RFID标签等传感器生成的原始数据，用于计算这些等待时间。通过对等待时间进行测量，本地数据分析团队可以向运营部门报告园区内的任何瓶颈问题，以便管理方采取必要措施消除这些问题，从而提高客户满意度。从负责监督整个 TrueLeisure游乐园组合的Jane的角度来看，她只关注大局。这意味着Jane希望通过整合各个游乐设施的个别等待时间，创建一个统一的等待时间参数（即总体等待时间）。因此，她将获得三个衡量指标，分别代表位于美国、英国和澳大利亚的每个游乐园的等待时间。通过在折线图中绘制这些指标，Jane可以实时查看等待时间的变化情况。Jane将汇报这些高层级

示意图4

示意图5

通过语义支持的分层数据处理在多云环境中实现分析即服务

表I. OpenIoT 实现细节

服务器名称	位置/区域	配置
OpenIoT‐1‐Azure	澳大利亚东部	标准实例，A3（4核，7GB内存）
OpenIoT‐2‐Azure	澳大利亚东部	标准实例，A2（2核，3.5GB内存）
OpenIoT‐1‐Google	asia‐east1‐a	n1‐standard‐2（2 个虚拟中央处理器，7.5 GB 内存）

将这些措施引入她的企业管理后，TrueLeisure便能与其各连锁主题公园高效且有效地讨论未来的发展。图5展示了在此场景下，如何在多云环境中利用所提出的分层数据分析方法进行数据的收集、处理和传输。该场景是数据生产者、分析服务提供商和数据消费者各自运行和管理其基础设施（每个主题公园）及应用程序，并集成这些服务以满足特定需求（Jane关注各个主题公园的整体性能）的典型示例。

5.2. 实验设置

实验测试平台如图6所示。每一层的分析服务均使用OpenIoT平台实现。第4.1.1节中介绍的OpenIoT组件采用Java J2EE框架并结合Virtuoso RDF三元组存储[27]实现。有关OpenIoT实现的更多细节，请参见www.openiot.eu。

OpenIoT系统部署在两个Microsoft Azure服务器实例和一个谷歌云服务器实例上。表I提供了服务器配置的摘要。为了测试系统在负载下的性能，我们使用Apache JMeter |||| 生成用户查询。部署在Windows Azure上的OpenIoT实例连接到产生数据的传感器平台。出于实验目的，我们使用了从2014年公开的天气和污染数据中收集的测试数据集。Virtuoso三元组存储中的数据总量约为1000万条三元组。

5.3. 实验描述

为了评估所提出的分层数据分析系统在多云环境中使用已实现的OpenIoT系统的性能，我们进行了两个实验。部署在谷歌云上的OpenIoT实例（OpenIoT‐1‐Google）从 Windows Azure云上的两个OpenIoT实例获取数据。OpenIoT‐1‐Google服务器融合来自这两个Azure实例的数据，为最终用户提供综合分析结果。为了测量系统性能，我们使用跨层多云应用监控即服务（CLAMS）[5],，这是一种多云多层性能监控框架。CLAMS能够深入理解我们部署在不同云层（例如IaaS和PaaS）的分层数据分析系统中各个独立组件的性能表现。CLAMS弥补了现有云监控工具无法监控部署在多云提供商环境中的应用程序的不足。

实验1 - 流数据 ：实现多云分层数据分析模型的关键在于其处理流数据的能力。在本实验中，我们使用两种不同的云配置，即OpenIoT‐1‐Azure和OpenIoT‐2‐Azure。通过将传感器数量从1个增加到10个，测试流数据性能。每个传感器产生5个数据流，包括温度、湿度、一氧化碳、压力和噪声。因此，当10个传感器全部运行时，系统总共处理约50个数据流。流速固定为每秒1个数据点。生成的数据为时间序列数据，即与数据点（双精度）相关联的时间戳组合。

实验2 - 分布式分层查询性能 ：在本实验中，我们测量查询处理的响应时间。查询由 Google Cloud OpenIoT实例生成，并由OpenIoT的Azure实例进行分布式处理。

在两个实验中，我们还计算了每个 OpenIoT 组件的中央处理器和内存消耗总量。这使我们能够细致地了解系统在负载下的性能表现。每次实验重复三次，此处呈现的结果是这些结果的平均值。

5.4. 实验结果

实验1- 流数据性能 ：图7展示了我们的实验结果。此处测量的三个组件包括JBOSS（托管所有OpenIoT模块）、Virtuoso（数据存储）和X‐GSN（将传感器连接到OpenIoT平台的流式引擎）。结果显示出一些有趣的观察现象，包括超过100%的中央处理器使用率。这是因为，在多核中央处理器中，当使用多个核心时，中央处理器使用率会超过100%。例如，在四核中央处理器中，CLAMS报告的最大中央处理器使用率最高可达400%。虚拟机1指的是 Azure‐1实例，而

示意图6 1a：中央处理器消耗和(b) 1b：内存消耗。)

VM2 指的是 Azure‐2 实例。总体而言，在以 1 秒的速率管理 50 个数据流（10 个传感器）时，系统表现良好，没有任何主要瓶颈。由于 JBOSS 的内存消耗由 JVM 控制，因此可以注意到虚拟机1 的内存消耗趋势较高。这是由于虚拟机1 上的可用内存（7 GB）高于 VM2（3.5 GB）所致。

实验 2- 分布式分层查询性能 ：图8展示了两种 Azure 配置下查询响应时间的结果。查询源自 Google Cloud OpenIoT 实例。总体而言，随着并行用户数量从 50 增加到 500，整体查询响应时间非常理想，约为 400–450 毫秒。正如预期，拥有更多内存和 CPU 核心的 Azure 1 实例性能优于 Azure 2 实例。此处有趣的结果是，响应时间随着用户数量增加而下降。我们怀疑这可能与 JVM 在系统负载增加时分配内存的方式有关。该结果与两种 Azure 配置的结果一致。

1a: CPU 消耗 – OpenIoT‐1‐Azure，(b) 1b: CPU 消耗 – OpenIoT‐2‐Azure，(c) 1a: 内存消耗 – OpenIoT‐1‐Azure 和 (d) 1b: 内存消耗 – OpenIoT‐2‐Azure。)

图 9 展示了 Azure 1 和 Azure 2 实例在处理来自 Google Cloud 实例的查询时的中央处理器和内存消耗情况。如前所述，由于 Azure 1 的配置更高，我们注意到 Azure 1 中 OpenIoT 的 JBOSS 组件最多消耗 300% 的 CPU。在每个实例上 JBOSS 的内存消耗也观察到了相同的结果。

实验结果验证了本文的以下关键贡献：（i）部署一个由不同提供商拥有的分层数据分析系统是可行的。（ii）通过设备与服务发现，我们可以组合多云数据分析应用。（iii）使用广泛采用的OpenIoT系统实现的此类系统具有可扩展的性能，并且没有表现出任何显著的限制或开销。

结论与未来工作

在本文中，我们提出了一种适用于多云环境的新型分层数据处理架构。该架构为托管各自云物联网平台的不同方提供了灵活性，使其能够共享经过处理的数据，从而共同降低计算资源消耗。同时，这也减少了共享原始数据所带来的风险。较低的隐私风险鼓励数据拥有者将数据与第三方共享，以便第三方将其用于次要目标。所展示的系统具备语义互操作性。这种互操作性使得部署在多云环境中的不同实例能够协同工作，通过分层数据处理共同分析数据以实现共同目标。本文通过在Azure和谷歌云平台上对OpenIoT系统进行实际实现验证了这一点。最后，实验结果验证了我们所提出的多云数据分析方法的可扩展性。此外，实验结果还表明，该系统不会带来任何显著的限制或开销。我们的下一步是开发一个互补的性能模型，用于多云环境中分层数据处理的云资源自主配置。

致谢
Charith查里特·佩雷拉的工作由欧洲研究理事会高级拨款291652（ASAP）支持。