基于边缘计算的实时传感器数据分析

大数据和认知计算

Article通过边缘计算从大型传感器数据中实时提取信息

Kyoung‐Don Kang *, 陈烈火，李炯大，王斌 和 沙墨
计算机科学系，美国纽约州宾汉姆顿，宾汉姆顿纽约州立大学，美国纽约州宾汉姆顿，13902； lchen66@binghamton.edu (L.C.)；hyi2@binghamton.edu (H.Y.)；bwang43@binghamton.edu (B.W.)；msha@binghamton.edu (M.S.)*通讯作者：kang@binghamton.edu

收到日期：2017年9月29日；接受日期：2017年10月12日；发表日期：2017年10月17日

摘要：

在数据密集型实时应用中，例如认知辅助和移动健康（mHealth），传感器数据量正在迅速增长。在这些应用中，理想的做法是从传感器数据流中实时提取增值信息（如心理或生理健康状况），而不是让用户面对海量原始数据。然而，由于数据体量庞大以及分析任务复杂且具有严格的时序约束，实现这一目标面临挑战。大多数现有的大数据管理系统（如Hadoop）并不直接适用于实时传感器数据分析，因为它们对时序不敏感，主要关注已存储数据的批处理，而这些数据可能已经过时并带来I/O开销。此外，嵌入式传感器和物联网设备缺乏足够的资源来执行复杂的数据分析。为解决这一问题，我们设计了一种新的实时大数据管理框架，通过扩展源自函数式编程的MapReduce模型，支持在网络边缘进行周期性内存实时传感器数据分析，同时根据数据重要性实现自适应的传感器数据传输至边缘服务器。本文设计并实现了一个原型系统作为概念验证。在性能评估中，实验结果表明重要传感器数据能够以优先方式被传输，并得以及时分析。

Keywords : 实时大型传感器数据分析架构；物联网；边缘计算

1. 引言

物联网（IoT）正在快速发展。预计到2017年和2020年，物联网设备数量将分别超过80亿和200亿[1]。这一快速部署得益于众多具有极高社会经济重要性的物联网应用，如认知辅助、移动健康（mHealth）和智能交通。理想情况下，希望以及时的方式从大型传感器数据中提取增值信息，以支持实时物联网应用，例如为佩戴物联网设备的视力障碍行人提供导航帮助，以及通过可穿戴或植入式传感器实时检测患者的异常健康状况。

然而，实现这一目标面临若干挑战：（1）传感器数据的体量庞大且快速增长；（2）从大型传感器数据中提取有价值的信息需要复杂的数据分析任务，而这些任务通常计算密集型；（3）许多重要的物联网应用，例如认知辅助、移动健康和交通控制，具有严格的时序约束。典型的物联网设备是低端嵌入式设备，例如传感器和微控制器，缺乏足够的计算资源以支持实时传感器数据分析。尽管硬件技术正在快速发展，但由于成本原因在嵌入式物联网设备中至关重要，预计物联网设备不会配备显著更多的资源。虽然云可以提供几乎无限的资源，但将所有传感器数据上传到云会受到互联网上传带宽的限制，导致显著延迟。边缘计算或雾计算是一种新兴范式，用于弥合这一差距

大数据认知计算2017，1，5；doi:10.3390/bdcc1010005 www.mdpi.com/journal/bdcc

在物联网设备与云之间[2,3]。通过在网络边缘支持计算密集型任务，边缘计算可显著降低延迟并缓解上传带宽瓶颈。

本文提出了一种在网络边缘实现软实时传感器数据分析的综合框架，该框架包括：（1）根据数据重要性，从物联网设备到边缘服务器的自适应传感器数据传输；（2）在边缘服务器上通过实时调度和MapReduce进行周期性内存实时分析。其中MapReduce源于函数式编程[4]，但并不局限于特定实现，例如Hadoop。MapReduce[5]和Hadoop[6]极大地简化了并行大数据分析应用的开发。

（尽管目前尚无统一的大数据定义被广泛接受，但大数据五V特性[7]——体量、速度、多样性、真实性和价值——已被普遍认可；即数据生成的体量、多样性和速度正在快速增长。此外，需要从可能包含不确定性的大数据中提取有价值的信息。）用户只需编写串行的map()和reduce()函数。底层运行时系统会将海量数据划分为较小的数据块，并代表用户调度Map/Reduce任务以并行处理这些数据块。

然而，由于多种原因，这些技术难以直接适用于实时传感器数据分析。首先，它们对时间不敏感，可能导致大量截止时间被错过，从而降低所衍生信息的价值。它们仅支持对存储在分布式文件系统中的静态数据进行一次性批处理，因此数据可能已过期。在实时传感器数据分析应用（如认知辅助、移动健康、交通控制或基于位置的服务）中，延迟生成的信息或使用过期的传感器数据生成的信息价值极低。

尽管对实时传感器数据分析的需求日益增长，但相关研究相对较少。先进的数据流管理系统，例如 Storm [8], S4[9],和 Spark Streaming [10],支持近实时流数据处理；然而，它们并未考虑明确的截止时间或实时调度，以确保数据处理的及时性。即使 Hadoop 中满足截止时间的问题已被研究 [11–17],，这些系统仍继承了 Hadoop 的缺点，即针对辅助存储中的数据进行批处理而优化。此外，这些系统主要关注后端云中的数据分析，而未考虑如何高效地将传感器数据传输到数据分析系统，而这在关键的实时物联网应用（如认知辅助和移动健康）中至关重要。尽管分组调度和介质访问控制已在实时无线传感器‐执行器网络中得到研究 [18,19],，但大多数现有工作并未考虑高效传感器数据传输的数据重要性。为解决该问题，我们设计了一种新的实时MapReduce框架，称为 RTMR（实时 MapReduce），它提供了包括 [5,6,8–17,20] 在内的先进大数据管理系统所不具备的多项独特功能：

我们支持基于不同传感器/物联网设备提供的相对数据重要性，对物联网设备到边缘服务器的周期性传感器数据传输进行动态速率自适应，以在总速率上限约束下优化总效用，即从传感器传输到边缘服务器的传感器数据的重要性值之和。所提出的传输速率自适应方案具有通用性，能够根据不同实时传感器数据分析应用的数据重要性度量进行适配。

• 使用RTMR的应用程序编程接口（Application Programming Interface），应用开发者可以为特定的实时数据分析应用编写串行的map()和reduce()函数，并指定数据分析任务参数，例如截止时间和周期。

支持非抢占式周期性实时任务模型，用于传感器数据的周期性实时分析。此外，提供了针对EDF（最早截止时间优先）调度算法的可调度性测试，以支持考虑计算和数据访问延迟的时序约束。

• 支持多种用于高效内存中传感器数据分析的机制。首先，传感器数据直接流式传输到主内存，使 RTMR能够实时从中提取信息。其次，Map/Reduce阶段生成的中间数据将被流水线化地直接传递到下一阶段（如果有的话），而无需像Hadoop那样暂存在本地磁盘或分布式文件系统中。

此外，支持内存预留，以确保为每个实时传感器数据分析任务分配足够的空间来存储输入、中间和输出数据。

此外，我们实现了基于重要性的自适应无线传感器数据传输，并通过扩展Phoenix[20],一个先进的开源多核/多处理器映射归约框架，以支持RTMR的关键特性用于实时数据分析，而非改造 Hadoop。

在性能评估中，我们采用逐步推进的方法。第一步，我们进行一个以人脸检测为模型的案例研究，人脸检测是支持例如跟踪、人群计数以及用于社交互动辅助的人脸识别等技术的核心。在该案例研究中，设置了几部智能手机以捕捉不同数量的人脸，并通过我们的自适应传输速率分配方案，对捕捉到更多人脸的智能手机分配更高的重要性。我们观察到，我们的方法能够根据真实值（实际人脸数量）有效地将传感器数据传输速率分配给各智能手机，以优化效用，同时满足数据传输与分析截止时间的要求。此外，与不了解数据重要性的基线方法相比，我们基于数据重要性的方法将效用提升了38%。

在第二步中，我们假设大规模传感器数据流能够以及时的方式周期性地传送到RTMR。给定传感器数据流后，我们通过利用实时任务调度和内存中MapReduce计算，评估RTMR是否能够满足数据分析的截止时间，所处理的传感器数据量显著大于案例研究中的规模。为此，我们使用四个微基准测试生成合成周期性工作负载，以建模实时数据分析任务：k‐均值聚类、线性回归、直方图和矩阵乘法，这些任务可应用于例如认知辅助、基于位置服务的移动用户聚类、传感器数据价值或金融市场预测以及交通控制等场景。利用这些基准测试，我们设计了多个实时数据分析任务集并分析其可调度性。对于截止时间最严格的任务集，性能评估结果通过实际满足所有截止时间，经验性地验证了可调度性测试；而作为基线的Phoenix则未能做到这一点。此外，在每次1000秒的实验运行中，RTMR处理了超过0.72 TB的传感器数据，相当于超过2.59 TB/小时和62 TB/天。

这项工作的初步成果已发表在一次会议上[21]。本文从以下几个方面显著扩展了[21]该工作：我们支持基于数据重要性的物联网设备到边缘服务器的自适应传感器数据传输，由边缘服务器对传感器数据进行实时分析。（在会议论文中，[21],未考虑数据传输问题。）我们已扩展系统架构以支持高效的传感器数据传输，如第2节所述。在第3节中，我们讨论了数据重要性的概念，并将高效传感器数据传输问题建模为一个优化问题。此外，我们提出了一种轻量级算法，用于实现物联网设备到实时边缘服务器的高效传感器数据传输，并从时间复杂度和最优性方面对该算法进行了分析。第3节中描述的自适应传输方法的有效性通过第5.1节的案例研究进行了实证验证。我们在第1、5和6节中讨论了更多相关工作。总体而言，本文还经过了全面的重新组织和重写，以增强表述的清晰性。

本文的其余部分组织如下。在第2节中，给出了RTMR架构概述和问题建模。在第3节中，讨论了基于传感器数据重要性的自适应传输速率分配算法。在第4节中，描述了实时任务模型以及实时数据分析的调度。在第5节中，逐步评估了我们方法的性能。相关工作在第6节中进行讨论。最后，第7节总结了全文并探讨了未来工作。

2. 系统概述

本节讨论了此项工作的背景以及整体系统设计。

2.1. Map-Reduce 基础

在图1所示的MapReduce模型中，用户只需编写一个串行的map()和reduce()函数，底层运行时会代表用户并行执行map()和reduce()函数[4]。在映射阶段，映射器并行地在不同的数据块上执行用户指定的map()函数。当所有映射器完成处理后，映射器产生的中间（键，值）对将在归约阶段由一个或多个归约器进行处理。

在本节的其余部分，我们将描述整体系统结构，以支持从传感器到边缘服务器的低成本数据传输，以及在服务器中进行实时数据分析，分别构成RTMR的前端和后端。

2.2. 整体系统结构

图 2 显示了通用架构。在边缘/雾计算中，边缘服务器连接到无线接入点（AP），例如 WiFi 接入点或 5G 微基站，以支持网络边缘的时间敏感型任务，同时在云中提供对时间要求较低的数据服务，例如长期数据存储与分析 [3,22,23]。本文重点关注从物联网设备到边缘服务器的高性价比的传感器数据传输以及服务器中的实时数据分析。我们假设每个物联网设备周期性地将传感器数据传输到运行 RTMR 的边缘服务器，以实时分析传感器数据，并根据其传感器数据的重要性为物联网设备分配适当的数据传输速率。

2.3. 基于数据重要性的物联网设备自适应速率分配

图 3 展示了支持基于传感器数据重要性从物联网设备到边缘服务器进行传感器数据传输速率自适应的RTMR前端的整体结构。传输速率分配管理器运行在RTMR上，并根据三个组件——设备管理器、数据重要性分析器和速率选择引擎，向连接的物联网设备分配传输速率。设备管理器负责管理连接到 RTMR的嵌入式物联网设备，同时控制设备的接入和退出网络。数据重要性分析器基于数据分析结果，分析从嵌入式设备收集的数据的重要性。运行在速率选择引擎中的速率选择算法，根据数据重要性分析器得出的传感器数据重要性信息以及设备管理器提供的设备信息，动态自适应调整嵌入式设备的传感器数据传输速率。在每个物联网设备中，设备控制器由速率控制器、应用管理器和数据预处理器组成，用于按照分配的传输速率传输传感器数据，与应用交互以根据给定速率生成感知数据，并对数据进行预处理（例如压缩数据），以减少带宽使用。

2.4. 实时传感器数据分析

从前端获取实时传感器数据流后，RTMR后端对周期性实时数据分析任务进行调度和执行，以从传感器数据中提取信息，如图4所示。在实时系统文献中，这些数据分析任务的周期性实例被称为任务（jobs），[24],它们通过最早截止时间优先调度器（EDF scheduler）进行调度。被调度器调度的任务由MapReduce（MR）引擎处理，直至完成，期间不被抢占，以避免在实时数据分析中产生较大的抢占和上下文切换开销。尽管在实时调度中通常假设上下文切换开销可以忽略，但对于处理大型传感器数据的实时数据分析而言，情况可能并非如此。如图4所示，传感器数据直接流入主内存，中间数据则流水线化传递至下一个Map/Reduce阶段（如果有的话），直到任务完成。最终，所衍生的信息将提供给用户。

在RTMR中，用户必须编写两个串行函数map()和reduce()，并为每个实时数据分析任务指定周期和截止时间。例如，图5和6中的映射和归约函数可用于定期监控本地蜂窝网络中每个小区内活动手机的数量，以此作为分析客户移动性和网络使用模式的基础。

给定用户指定的带有截止时间和周期的map()和reduce()函数，图4中RTMR的MR引擎基于 MapReduce模型处理实时传感器数据分析任务[4]（如图1所示）。具体而言，MR引擎按调度器调度的最早截止时间任务进行处理。

1// 输入: （小区ID，电话号码对
2// 输出：中间 ( 键 ,值对
3映射( 空指针输入 ) {
4对于输入中的每个小区ID {
5 发出中间结果 ( 小区ID ,1) ;
6 }
7 }

1// 输入:中间 （小区ID， 1)对
2 //输出 （小区ID，计数
3归约 (int 键 , 迭代器 值 ) {
4 int 计数 = 0;
5对于值中的每个 v {
6 计数 =计数 +v;
7 }
8发出（键，计数);
9 }

1. 在RTMR中，每个输入传感器数据表示为一个（键，值）对，例如基于位置服务中的（小区ID，电话号码），并流式传入内存。输入的（键，值）对由MR引擎均匀划分为多个数据块，并分配给映射器，即工作线程。2. 映射器在不同的数据块上并行独立执行用户指定的map()函数。例如，每个映射器执行图5中用于手机计数的map()函数，生成中间（键，值）对作为结果。3. 当所有映射器完成对所分配数据块的处理时，映射阶段结束。如果没有归约阶段（归约阶段是可选的），则映射器生成的（键，值）对将作为最终结果返回，任务终止。4. 如果存在归约阶段，则映射器生成的中间（键，值）对将直接流水线化传输至一个或多个归约器，并根据其键进行排序。具体而言，指向内存中中间结果的指针被传递给归约器，而无需昂贵的数据复制。

在RTMR中，所有输入、中间或最终的（键，值）对都存储在内存中，而不像MapReduce[5], Hadoop[6],或其变体。Phoenix [20]有效利用内存层次结构，使用多个CPU核心在内存中处理 MapReduce任务。然而，它不支持周期性任务模型、实时调度、传感器数据直接流式传输到内存或内存预留，仅支持先进先出调度。此外，它从磁盘读取输入数据并将输出写入磁盘。RTMR通过支持以下功能扩展了Phoenix：（1）输入传感器数据流；（2）中间数据流水线；（3）非抢占式周期性任务模型；（4）内存预留；以及（5）用于实时数据分析的基于最早截止时间优先的可调度性测试和调度。

3. 自适应速率分配

在本节中，讨论了数据重要性的概念。基于此，给出了问题建模，并描述了我们的动态速率分配方法。

3.1. 数据重要性

由于实时无线传感和传感器数据分析应用的多样性，数据重要性概念可以有不同的定义方式。本文并不主张其中任何一种定义是最合适或适用于所有物联网中的大规模传感器数据分析。相反，我们的目标是设计一个通用框架，能够根据应用设计者针对特定物联网应用（如认知辅助或交通控制）所选择的数据重要性度量，动态地为物联网设备分配无线带宽（数据传输速率）。

本文将数据重要性分为两类：（1）应用特定和（2）与应用无关的指标。

应用特定的数据重要性 ：可以使用预定义的标准来确定传感器数据源的相对重要性级别，以描述特定应用中感兴趣的事件。例如，在视觉监控中，检测到的人脸或感兴趣的对象（如武器）的数量可作为数据重要性度量，用于支持人群计数或跟踪。在水下无线传感器网络中，与异常事件相关的数据被视为重要。张等人应用数据重要性概念，消除多个监控摄像头产生的冗余观测值。在壁球比赛中对视觉数据进行分析，通过预测未来事件的发生频率（事件定义为壁球击中墙壁的特定区域），为预期观测到更多事件的摄像头分配更多带宽。此外，在云数据存储系统中产生更高收益的数据被视为更重要，并被进一步复制。尽管这些方法利用了数据重要性的概念，但均未利用边缘计算来缓解在新兴物联网时代实现实时传感器数据分析所面临的关键挑战。为弥补这一差距，运行在边缘服务器上的RTMR根据数据重要性动态分配物联网设备的数据传输速率，同时调度实时数据分析任务以满足其在边缘端的时序约束。

• 应用无关的数据重要性 ：数据相似性概念[25,29]不依赖于特定应用。通常情况下，连续传感器数据（例如温度/压力读数或监控图像）可能具有相似性。数据相似性检查在计算上通常开销较低，因此物联网设备可自行执行该检查，并仅在当前数据与先前数据的差异超过指定阈值（例如5%）时才传输数据。

此外，Hu 等人 [30]提出了一种称为卸载整形的新方法，使物联网设备能够通过一些额外的廉价计算来丢弃模糊图像，即低质量数据。其他指标，例如图像分辨率或传感器校准，可用于相应地估计传感器数据质量和重要性。

值得注意的是，这些数据重要性指标具有通用性，可用于通过多种方式提高传感器数据传输的效率：（1）可以为提供重要传感器数据的数据源分配更高的传输速率，例如指示异常健康状况的传感器数据或包含许多人脸的图像。这样，在总可用带宽限制条件下，可以更紧密地跟踪重要事件，例如传感器佩戴者的异常健康状况；（2）可直接丢弃较不重要的数据，例如模糊图像或与先前读数相似的传感器数据，以减少带宽消耗；或者（3）采用混合方法，丢弃不重要的传感器数据，并将总可用速率中的未使用部分重新分配给提供更重要数据的其他传感器数据源。在第5.1节中，为表述清晰起见，我们考虑第一种方法。对第二和第三种方法的深入研究留作未来工作。

3.2. 问题建模

本文中，总效用定义为物联网设备提供给边缘服务器的传感器数据传输速率与数据重要性级别之间的内积。假设n个嵌入式物联网设备周期性地向边缘服务器传输传感器数据。当嵌入式设备Ei的数据传输速率为ri（单位时间内传输的数据对象数量），且Ei所提供数据的重要性为oi时，传感器数据传输与分析的全局系统效用为：

u=~o ·~r (1)

其中~o=[o1,…, on],~r=[r1,. . . , rn]T，且 ·是两个向量之间的内积 .

由于从Ei传输到边缘服务器的数据的重要性可能随时间变化，边缘服务器通过计算由Ei提供的数据的指数加权移动平均（EWMA）来得到其平滑重要性。 （或者，Ei本身也可以根据之前的讨论，依据计算复杂度来计算该重要性。在这种情况下，它可以将重要性信息附带到传输给边缘服务器的数据上。）

oi(j)= α × oˆi(j)+(1−α)× oi(j −1) (2)

其中，oi(j)是平滑重要性值，ˆoi(j)是jth数据对象的 数据 重要性，而 α是满足 0 ≤ α ≤ 1的指数遗忘因子。

在本文中，我们使用EWMA，因为传感器数据未来的数据重要性会受到当前数据重要性的影响。

例如，假设佩戴在人身上的传感器在某一时刻指示出异常健康状况。尽管这种状况可能由于治疗或自然自愈而逐渐消失，但它可能会持续一段时间。在这种应用中，EWMA可以优雅地表示随时间变化的数据重要性。了解应用语义的系统管理员可以轻松设置 α值，即（2）中的遗忘因子，以指定传感器i提供的先前数据值对其数据重要性的影响。例如，她可以将 α= 0设为0.3，通过递归求解（oi(j)在三个感知周期后的影响小于3%。（2）。然而，如果在某个应用中仅当前数据的重要性相关，系统管理员可以简单地将 α= 1设置为0（2）。

根据(1)，我们的目标是在以下约束条件下最大化u：

rmin ≤ ri ≤ ri,max (3)

r1+…+ rn ≤ R (4)

` i ≤ D (5)

其中 ri是 Ei的当前传感器数据传输速率；即，Ei每秒向边缘服务器传输 ri个传感器数据对象，且 ri, max是 Ei能够支持的最大传输速率。 rmin是传感器数据的最小传输速率，例如心电图数据或摄像头图像。公式(R在(4)中表示所有物联网设备到边缘服务器的总数据传输速率的上限。例如，R可由蜂窝数据套餐或网络边缘处用于实时数据分析的可用无线带宽与预留的总数据传输速率中的较小值决定。

`i在(5)中表示网络边缘的端到端延迟，即传感器数据从 Ei传输到边缘服务器的延迟与服务器中数据分析延迟之和。此外，D是数据传输与分析的端到端截止时间。

事实上，我们的效用优化问题可以通过整数线性规划（ILP）来求解。然而，我们并未采用该方法，因为在最坏情况下求解ILP问题可能需要指数时间。相反，我们将在下一小节中提出一种针对物联网设备数量具有线性时间复杂度的高性价比算法。

3.3. 动态传输速率分配

在我们总结于算法1中的自适应传输速率分配算法中，ri对于Ei(1 ≤ i ≤ n)在每个控制周期内根据Ei提供的传感器数据流的相对重要性成比例地进行调整（如有必要），以优化系统的总效用。在第 kth个控制周期，图3中的速率选择引擎首先基于Ei的相对数据重要性计算针对Ei的新速率ri(k)：

ri(k)= rmin+ ⌊ oi(k) ∑n j=1 oj(k) ×(R−rmin × n)⌋ (6)

算法1：第 kth控制周期的动态传输速率分配
full = 0; for i = 1; i <= n; i++ do ri(k)= rmin+ b oi(k) ∑ n
if ri(k) ≥ ri,max then ri(k)=ri,max; full++;
end end slack = R −∑ n i=1 ri(k); if slack > 0 and n > full then inc = b slack n−full c; if inc > 0then for i = 1; i <= n; i++ do if ri(k)+inc <= ri,max then ri(k)= ri(k) +inc; end else ri(k)=ri,max; end end end

然后根据需要调整ri(k)，以确保ri(k) ≤ ri,max：

ri(k)={ri(k) if ri(k) ≤ ri,max
ri,max otherwise
(7)

在此步骤之后，它将R的任何未使用部分均匀分配给每个节点，但需满足以下约束条件：ri(k) ≤ ri,max。因此，我们的动态速率分配方法（1）根据各嵌入式设备提供的传感器数据流的重要性成比例地调整其传输速率，并且（2）在满足(R的约束条件下尽可能充分利用3)–(5)中规定的约束。

算法1的时间复杂度为 O(n)，其中 n表示物联网设备数量。需要注意的是，我们的算法是轻量级的，对 n个设备的速率分配下界为 Ω(n)。此外，在案例研究中用作低端边缘服务器的商用台式PC上，边缘服务器运行我们的速率自适应算法所需时间少于 20 µ秒。（系统配置详见第 5节）。此外，算法 1在公式(1)定义的总效用方面是最优的。

定理1。 定理1. 在（1）中定义的效用在将Ei的速率ri按oi的比例分配时达到最大，其中 1 ≤ i ≤ n。

证明。 根据柯西‐施瓦茨不等式[31], ，效用|u| = |~o ·~r| ≤ ||~o|| × || ~r||的绝对值 ||~o|| = √o 2 2+. . . o2n和 || ~r|| = √r12+ r22+. . . r2n，由于本文中{o,v19}r ∈IRn。柯西‐施瓦茨不等式还指出 |u| 被最大化；即 |~o ·~r| = ||~o|| × || ~r||仅当~r = c~o，其中c为常数，该条件通过在算法1中将 Ei的传输速率ri按比例分配给oi来实现。因此，在基于历史通过(2)进行的数据重要性预测准确的前提下，算法1可以优化总效用。

4. 实时任务模型与调度

本节讨论了RTMR支持的任务模型、内存预留和调度。

4.1. 任务模型与内存预留

本文中，我们假设一个实时传感器数据分析系统需要执行一组n个相互独立的周期性 MapReduce任务 Γ=(τ1, τ2, …, τn)，这些任务不会自行挂起。在该系统中，有m个 ≥ 1核心可用于实时数据分析。本文中，任意一个实时MapReduce任务 τi ∈ Γ具有周期Pi和相对截止时间Di= Pi（隐式截止时间）。如果任务 τi的一个任务实例（即 τi的一个周期性实例）在时间t被释放，则该任务必须完成的绝对截止时间为t+ Di。

τi是一个实时数据分析任务，包含si(≥ 1)个并行执行的映射/归约阶段，定义如下：

τi:((< e1i, m1 i>,…,< esi i, msi >), Ci, Di)

其中，si= 1，如果 τi 仅包含一个映射阶段。si= 2，如果它同时包含映射和归约阶段。si> 2，如果它由多对并行的映射和归约阶段组成，并按顺序迭代执行。此外，ej i 和 mj i 分别表示阶段 j 的估计的最大执行时间和该阶段使用的核心数量。 τi 的（估计）最大执行时间为：Ci=∑ s i j=1e j i。

使用RTMR的应用程序编程接口，用户需要指定map()和reduce()函数，以及si和Di，如第4.1节所述，需考虑应用语义。为了表述清晰，我们假设图1中的数据划分和洗牌步骤分别包含在映射和归约阶段中。此外，它们的延迟也被计入映射和归约阶段的执行时间。

在RTMR中，Ci在离线情况下进行估算，不仅考虑中央处理器时间，还考虑内存访问延迟，因为数据访问延迟在实时数据分析中可能不可忽略。本文中，τi ∈ Γ在离线情况下多次运行。对于每次 τi的运行，从读取第一个输入（键，值）对到产生最后一个输出（键，值）对的延迟被用作估算的执行时间，以同时考虑计算和数据访问延迟。通过预设次数的运行所获得的最大观测执行时间被用作Ci。通常，在多核处理器中对最坏情况执行时间的分析仍是一个开放问题。由于传感器数据规模的增大和波动性的增加，实时数据分析任务的执行时间分析更具挑战性。对更先进方法进行深入研究以分析实时数据分析任务的执行时间将留作未来工作。

在RTMR中，输入的传感器数据如前所述被流式传输到内存中。此外，我们假设输入传感器数据的大小是预先确定的。在一个阶段结束时， τi会产生中间数据，这些数据作为下一个连续执行阶段的输入。如果没有后续阶段，则它们就是任务 τi的最终输出。基于此，RTMR会分析中间/输出数据的最大尺寸，并为 τi预留足够的内存，该过程通常包含一些常见操作，例如过滤、聚合或对物理现象（如道路路段中的交通速度）进行预测。如果在某个阶段过滤掉了不重要的输入数据或对传感器数据进行了聚合，则该阶段末尾生成的输出或中间数据的大小不会超过输入数据的大小。例如，通过线性（或非线性）回归进行预测通常只生成少量预定义的模型参数，其大小远小于输入数据。即使执行了数据处理中最昂贵的操作之一——连接操作，且参与连接的两组输入传感器数据的大小分别为N和M，最坏情况下最大输出大小也仅限于NM。此外，与批处理数据分析系统（如Hadoop）所处理的数据规模相比，N和M相对较小，因为在RTMR中每个周期仅处理当前传感器数据以实现实时数据分析。

4.2. 可调度性测试

在jth段的 τi中，当 1 ≤j ≤ si时，mj个线程被用于并行段中运行用户指定的 τi的map()或 reduce()函数，具体取决于 τi当前处于映射阶段还是归约阶段。本文中，每个核心一次仅运行一个映射或归约线程。然而，mj个线程在jth段中并行执行，遵循数据并行、单指令多数据（SIMD）模型。

在并行实时数据分析中，数据并行性与任务并行性之间存在权衡。如果单个任务使用更多核心以 SIMD方式同时处理更多数据，则能并行运行的任务数量减少，反之亦然。由于多处理器实时系统中的调度问题是强NP难问题[32],，本文设计了一种启发式方法来调度实时数据分析任务。更具体地，我们旨在在可用硬件并行性的约束下最大化数据并行性，通过为 τi设置m j i= m实现，其中m是系统中可用于实时数据分析的核心总数。通过这种方式，我们尽可能早地完成一个实时数据分析任务的任务，同时避免因抢占而导致的上下文切换。

在本文中，我们采用非抢占式单处理器最早截止时间优先调度，通过针对不插入空闲时间的非抢占式周期任务的可调度性测试 [33],来满足实时数据分析任务的时序约束，因为m个核心被当作一个更快的单处理器用于数据和计算密集型的实时数据分析。具体而言，任务集 Γ=(τ1, τ2, …, τn)是可调度的，当且仅当满足以下两个必要且充分条件：

条件1
n
∑
i=1 Ci
Pi ≤ 1 (8)

条件2. ∀i, 1< i ≤ n; ∀L, P1< L< Pi:
L ≥ Ci+
i−1
∑ j=1 ⌊L−1 Pj ⌋ Cj (9)

条件1 要求处理器不超载。在 条件2 中， Γ中的任务按周期非递减顺序排序。条件2 中不等式右侧是在长度为 L的时间区间内可实现的处理器需求的最小上界，该区间从 τi的任务被调度时开始，在该任务截止时间之前的某个时刻结束。这两个条件是相互独立的，即可能存在总利用率为 1 的可调度任务集，也可能存在利用率任意小的不可调度任务集 [33]。

如果 Γ在满足（8）和（9）以及内存约束的条件下是可调度的，则RTMR对周期性数据分析任务进行调度。否则，它会向用户提供反馈，以便用户调整任务参数，例如任务周期，或提供更快的map()和 reduce()函数，这些函数可能产生近似结果。调整后，对修改后的任务集重新执行可调度性测试。

我们承认，其他调度方法也可能适用。例如，如果在一定程度上可以接受偶尔的截止时间错失，则可以使用平均执行时间而非最大执行时间。 τi可以使用少于m个核心，使得多个任务能够一起运行，类似于[34,35],，前提是并发数据分析任务之间的最大内存访问延迟和共享资源（如系统总线和内存控制器）争用可以在时间上被量化。在多核系统中，可以使用装箱启发式算法[32]将实时数据分析任务划分为多个核心集合。在每个分区中，静态分配给该分区的任务可以采用本文所述的方法进行调度。然而，实时数据分析任务的分区调度具有挑战性，因为装箱问题是NP完全的。对这些问题的深入研究超出了本文的范围，留待未来工作解决。

5. 性能评估

在本节中，我们实现了一个原型RTMR系统，并以逐步的方式评估其性能。我们评估了（1）基于传感器数据重要性的动态传输速率分配算法以及（2）实时数据分析任务的及时性。

5.1. 面向物联网设备的低成本速率分配

在本小节中，我们实现并评估了动态服务速率分配算法（算法1），使用多部智能手机和一台配备四核Intel处理器i7‐4790（3.6 GHz）及16 GB主内存的台式PC来模拟一个专用于图像处理的低端边缘服务器 [36]以展示我们系统的实际应用性。为了评估不同设备上的端到端及时性，我们使用了5部不同的智能手机：华为荣耀 6、三星 Galaxy S6、LG G3、谷歌 Nexus 6 和 谷歌 Nexus 3，通过校园公共WiFi网络 busecure 将图像传输至边缘服务器 [37],该网络的标称带宽为144 Mbps。由于 busecure是校园内的公共WiFi网络，我们无法获得预留任何信道或带宽的权限，因此无法提供任何硬或软实时保证。相反，我们的重点在于
在优化传感器数据传输与分析的效用。

在本实验中，我们设置 R= 12 fps（每秒帧数），rmin= 1 fps，以及 rmax= 5 fps。我们所使用的智能手机均无法支持以超过 5 fps 的速率拍摄、压缩并传输图像。传输速率自适应的控制周期设为 10 秒。所有智能手机向边缘服务器传输图像持续 2 分钟。图像分辨率为 720 × 486。（可调整图像分辨率而非传输速率，以在满足(3)–(5)中指定的约束条件下提升总效用。这将留作未来工作。）每张图像在经过JPEG压缩后的大小介于 4.9−10.2 KB 之间。平均人脸检测准确率为 97.3%。尽管我们的方法不限于特定的感知与分析应用，但我们将人脸检测作为一个案例研究。在此背景下，oi被定义为嵌入式物联网设备 Ei提供的传感器数据流中检测到的人脸数量。在本小节中，传感器数据（即图像）传输和分析（即本案例研究中的人脸检测）的端到端截止时间为 100毫秒。

为了验证基于数据重要性的动态速率自适应的可行性，我们构建了一个实验场景，其中每个摄像头在特定时间间隔内捕捉到一定数量的人脸，如图7a 上半部分所示。如图7a 下半部分所示，嵌入式设备（智能手机）的传输速率根据其数据重要性值（检测到的人脸数量）成比例地进行动态调整，有效跟踪了真实值的变化。初始阶段，嵌入式设备 4 和 5（图中的 EB4 和 EB5）被分配最高的传输速率，因为它们各自被配置为在整个 2 分钟实验过程中持续捕捉一个人脸。而其他设备在开始时未检测到任何人脸。然而，随着边缘服务器检测到 EB1 提供的图像流中人脸数量增加，相应地提高了 EB1 的速率，EB4 和 EB5 的速率则随之降低。在实验后期，当 EB1 检测到的人脸数量减少时，EB4 和 EB5 的速率再次上升。因此，从图7可以看出，我们的速率分配通过根据嵌入式物联网设备的相对数据重要性成比例地动态调整其传输速率，有效反映了数据重要性的变化，从而优化了效用。在此案例研究中，与不考虑数据重要性、对所有智能手机分配相同传输速率的基线方法相比，我们的方法将效用（即传递到边缘服务器的人脸总数）提升了 38%，该基线方法是视觉监控中的事实标准[38,39]。

在本案例研究中，最慢的智能手机的第95百分位端到端延迟为100毫秒（等于端到端截止时间），如图7所示，并在表1中进行了总结。网络延迟范围为14–36毫秒。其余延迟由实时数据分析引起。除了图7和表1中的性能结果外，我们还在所拥有的最快的智能手机（Galaxy S6）上独立执行人脸检测任务100次，未将任务卸载至边缘服务器，结果发现其第95百分位延迟为309毫秒。基于此结果和表1，我们观察到，与另一种基线相比，我们利用边缘服务器的方法将第95百分位端到端延迟降低了3.09倍 −3.59倍，该基线中每台智能手机均自行执行数据分析而无任务卸载。事实上，大多数物联网设备的性能可能远低于智能手机。此外，实时数据分析可能需要处理更大的传感器数据和更复杂的数据分析；因此，如果在嵌入式物联网设备上执行计算密集型任务，可能会遭受显著更长的延迟。这些观测值进一步推动了在边缘服务器上进行实时数据分析。

表 1. 不同智能手机的端到端延迟95百分位。
| 手机型号 | 端到端延迟（毫秒） |
| — | — |
| 华为荣耀 6 | 100 |
| 三星 Galaxy S6 | 86 |
| LG G3 | 98 |
| 谷歌 Nexus 6 | 93 |
| 谷歌 Nexus 3 | 98 |

5.2. 实时数据分析任务调度

在本小节中，我们假设传感器数据已高效地传输至网络边缘的RTMR。（例如，我们基于数据重要性的方法可与新兴的5G或Gbps WiFi技术集成，从而显著降低延迟并提升吞吐量。）

事实上，可以配置一个实时数据分析系统，使得相对低端的边缘服务器在较短的截止时间内处理特定任务（例如人脸检测），而更强大的边缘服务器则执行更全面、深入的数据分析。（物联网设备与边缘服务器之间实时数据分析任务的高效划分超出了本文的范围，将留作未来工作进行深入研究。）因此，我们通过运行与第5.1节中所用更大的输入传感器数据相关的具有时序约束的基准测试，来评估 RTMR的实时性能。

为了进行性能评估，以下流行的数据分析基准测试 [20] 被调整用于建模周期性实时数据分析任务。

• 直方图（HG） ： 直方图是用于数据分布图形表示的一种基本方法。在本文中，我们考虑图像直方图，它绘制每个色调值对应的像素数量，以支持数据密集型实时应用中的基础分析，例如认知辅助、交通控制或视觉监控。（直方图（HG）不仅限于图像数据，还可普遍适用于其他类型的数据，例如传感器读数。）该周期性任务的输入是一幅大型图像，每个任务周期包含4.7 × 108像素。每个周期处理的输入数据量约为1.4 GB。

• 线性回归（LR） ： 线性回归适用于实时数据分析。例如，可通过时间序列分析来预测传感器数据的值。在LR中，二维空间中的2.7 × 107(x,y)点，每个任务周期输入总量为518 MB，用于通过线性回归建模x与y之间的近似线性关系。

• 矩阵乘法（MM） ： 矩阵乘法（MM）在各种大数据和物联网应用中被广泛使用，例如认知辅助、自动驾驶和科学应用。本文中，每个任务周期内执行一次两个 2048 × 2048矩阵的矩阵乘法。每个输入矩阵为16 MB，输出矩阵也为16 MB。

• K均值聚类（KM） ：这是一种重要的用于聚类的 数据挖掘算法。例如，它可以用于根据移动用户的位置进行聚类，以实现 实时 基于位置的服务。它将 观测值 划分为 k个 簇 （通常为 k），使得 每个 观测值 属于具有 最近均值 的 簇。k‐均值 任务的 输入 是每个 任务周期 内二维空间中的107个点， 总计77 MB。

本文中，我们每个周期生成新数据，以最大化工作负载，在最坏情况场景下对RTMR进行压力测试。实际上，当用于认知辅助或自动驾驶的部分图像发生变化时，连续两个周期之间的某些直方图和子矩阵可能保持不变。此外，线性回归和k‐均值聚类可以在连续周期之间增量执行。我们采用这种方法，是因为需要设计一个考虑最坏情况场景的实时调度框架，以支持可预测性[24]。未来，我们可以 例如使用平均执行时间来提供时效性的概率保证。然而，这是一个复杂的问题，超出了本文的范围， 将作为未来工作保留。

所有基准测试都是归约性的；也就是说，所有基准测试的中间/输出数据大小不超过输入数据的大小。在测试的基准测试中，只有KM包含多于一对的映射‐归约阶段。具体而言，它被实现为七对迭代的映射和归约阶段序列。然而，它不会生成额外的中间/输出数据；在每一对映射和归约阶段中，它仅查找新的k个均值，并根据新均值更新每个点的聚类成员关系。对于测试的基准测试，如第4节所述，已预留了足够的内存。

用于RTMR性能评估的系统是一台Linux机器，配备两个AMD Opteron 6272处理器，每个处理器具有16核，运行频率为2.1吉赫兹。每核心配有48千字节L1缓存和1兆字节L2缓存。此外，核心之间共享16兆字节L3缓存。在32核中，一个核心专用于实时调度器，另一个核心专门用于生成实时数据分析任务的周期性任务。剩余的30个核心用于处理生成的实时数据分析作业。该系统具有32吉字节内存。

使用微基准测试，我们对测试的基准程序（包括计算和数据访问延迟）的最大（观测到的）执行时间进行性能分析，基于最大执行时间离线执行实时数据管理任务的可调度性分析，并通过实验验证 使用微基准测试生成的多组实时数据分析任务是否能够满足截止时间。具体而言，一个基准程序使用 随机生成的数据离线运行20次，取20次运行中的最大延迟用于可调度性测试。

表 2显示了离线获取的基准测试的最大执行时间。随着用于处理实时数据分析任务的CPU核心数 m从1增加到30，HG、LR、MM和KM的最大执行时间分别减少了12倍、4.1倍、17.7倍和4.3倍以上。在HG和MM中，各核心之间的负载均衡较为简单，因此随着用于实时数据分析的核心数量增加，最大执行时间显著减少。值得注意的是，如表2所示，LR的最大执行时间仅在m ≥ 16之后才显著下降。当m ≤ 8时，所用CPU核心提供的硬件并行性不足以显著加快LR的执行速度。另一方面，如表2所示，当m ≥ 8时，KM的最大执行时间的下降变得微乎其微。在KM中，各个输入点通常会在不同的簇之间重新聚类和移动，直到每个点到最近均值的距离达到最优为止。因此，簇大小可能在连续的映射/归约阶段之间因输入点的分布而动态变化，导致线程可能出现负载不平衡。因此，使用更多的核心并不一定会显著降低KM的最大执行时间。

表2. 最大执行时间（秒）。
| m= 1 | m= 2 | m= 4 | m= 8 | m= 16 | m= 30 |
| — | — | — | — | — | — |
| HG 2.41 秒 | 1.67 秒 | 0.88 秒 | 0.56 秒 | 0.33 秒 | 0.2 秒 |
| LR 1.49 秒 | 1.3 秒 | 1.18 秒 | 0.95 秒 | 0.62 秒 | 0.37 秒 |
| MM 19.7 秒 | 11.2 秒 | 5.9 秒 | 3.73 秒 | 2.02 秒 | 1.11 秒 |
| KM 10.2 秒 | 7.5 秒 | 3.72 秒 | 3.09 秒 | 2.54 秒 | 2.36 秒 |

为了进行性能评估，我们计划设计具有尽可能短截止时间的任务集。我们考虑了表3中的六个任务集，其中相对截止时间从Γ1到 Γ6逐渐变短。我们考虑这些任务集，以分析在满足条件(8)和(9)的情况下，不同核心数量的可调度性。在每个任务集中，最大执行时间较大的任务被分配较长的截止时间。此外，在每个任务集中，我们选择任务周期（即相对截止时间），使得每个任务集中的最长周期不超过该任务集中最短周期的两倍，以模拟需要彼此相对接近执行的实时数据分析任务。在 Γ6中，在满足 这些约束以及(8)和(9)的条件下，选择了尽可能紧张的相对截止时间。对于30个核心， Γ6的最大执行 时间和相对截止时间分别显示在表2和3的最后一列和最后一行中。对于30个核心， Γ6的最大总利用 率为1，如(8)中所设定。在Γ6中为任务分配更短的截止时间或更大的数据会导致截止时间错失。

表3. 任务集（Γ1–Γ6）的相对截止时间（秒）。
| HG | LR | MM | KM |
| — | — | — | — |
| Γ1 23 s | 22 s | 30 s | 25 s |
| Γ2 13 s | 15 s | 22 s | 18 s |
| Γ3 7 s | 8 s | 12 s | 10 s |
| Γ4 4.5 秒 | 5 s | 7 s | 6 s |
| Γ5 3 s | 4 s | 5 s | 6 s |
| Γ6 2.6 秒 | 3 s | 4 s | 5 s |

表 4显示了 Γ1–Γ6）的可调度性测试结果。在表 4中，“是”表示对于运行HG、LR、MM和 KM所使用的特定核心数，该任务集是可调度的（即所有截止时间都能满足）。我们展示了 Γ6的性能 结果，其具有最短的截止时间，因此仅当 m= 30时才是可调度的，如表 4所示。中的四个周期性基 准任务，即HG、LR、KM和MM任务 Γ6，在时间0同时释放它们的第一个作业，并根据表 3最后一 行指定的周期持续生成作业，持续时间为1000秒。如图 8–11所示， Γ6中周期性实时数据分析任务的 所有截止时间均被满足。在一次1000秒的实验运行中，总共处理了超过0.72 TB的数据，预计可达62 TB/天以上。

表4. 任务集的可调度性。
| m= 1 | m= 2 | m= 4 | m= 8 | m= 16 | m= 30 |
| — | — | — | — | — | — |
| Γ1 yes | yes | yes | yes | yes | yes |
| Γ2 no | yes | yes | yes | yes | yes |
| Γ3 no | no | yes | yes | yes | yes |
| Γ4 no | no | no | yes | yes | yes |
| Γ5 no | no | no | no | yes | yes |
| Γ6 no | no | no | no | no | yes |

在本文中，Phoenix [20]被用作基准。它与其他主要基于Hadoop的方法（如第6节所述）不同， 是与RTMR最接近的最先进的内存中多核MapReduce系统。然而，由于多种原因，它未能满足 Γ6的 大部分截止时间（尽管在轻量级工作负载下能够满足截止时间，例如使用30个核心时的 Γ1）。首先， 它不考虑时间因素，仅支持先进先出调度，如前所述。此外，它从辅助存储读取输入数据并将输出写 入辅助存储，不支持将输入传感器数据流式传输到内存中。同时，它也不支持迭代任务的中间数据内 存流水线。因此，在测试的基准测试中，单次从磁盘读取输入数据（或将输出写入磁盘）操作耗时 38毫秒–1.35秒（71毫秒–1.14秒）。

在图8–11中，我们还观察到，由于需要采用悲观实时调度以满足时序约束，周期性实时数据分析 任务会在截止时间之前完成。值得注意的是，仅使用支持任务内并行性的先进实时调度技术，例如 [34,35],并不一定会提高利用率。例如，对于建模为并行有向无环图的任务，任何全局调度器的最佳 已知容量增强界限为 2。618[35]。因此，任务集的总利用率不应超过 m/2.618，且任务集中任意任务 τi（即当核心数为无限时， τi的最大执行时间）的最坏情况关键路径长度不得超过 Di的 1/2.618，才 能满足截止时间要求。

总体而言，我们的系统设计和实验结果为实时大数据传感器分析提供了概念验证。本文提出的工 作引发了许多研究问题，例如更先进的调度、负载均衡、执行时间分析和实时数据分析技术，以及时 高效地从大型传感器数据中提取增值信息。

任务的响应时间。蓝色水平条是截止时间(3秒)。每个红色圆点代表一个周期性 LR作业的响应时间)

6. 相关工作

关于无线网络中实时通信的早期工作的综合综述见于[19]。最近，针对工业信息物理系统的实时 无线调度给出了很好的综述，见于[18]。此外，为了支持实时无线传感与控制，已研究了一些介质访 问控制和调度的新方法，例如[18,40–44],。然而，这些方法中没有一种

项目考虑了基于数据重要性优化从物联网设备到边缘服务器的传感器数据传输总效用。

尽管数据重要性的概念已在各种背景下被考虑 [2,25–28,30],我们的工作与它们的不同之处在于： （1）通过基于数据重要性的自适应传感器数据传输，从物联网设备到边缘服务器提升总效用；（2） 在网络边缘提供实时传感器数据分析框架，同时支持通用数据重要性度量。

Hadoop[6]被广泛用于大数据分析。许多工作也致力于增强Hadoop[45]。然而，这些基于分布 式文件系统中数据批处理的方法既未考虑时序约束，也不支持对传感器数据流进行实时的周期性内存 处理。HaLoop[46]支持在Hadoop中运行迭代应用；然而，Hadoop及其大多数变体均不了解实时 数据分析的时序约束。

在[11–16]中研究了Hadoop中满足实时截止时间的问题。此外，在[17],中，准入控制被应用于基 于截止时间的批量数据分析任务。然而，这些方法主要关注归档数据的批处理，对传感器数据流式传 输或中间数据流水线支持有限，因此存在显著的I/O开销以及更长的延迟和截止时间（例如，数十分 钟）。在[47],中提出了一种基于速率单调算法[24]的固定优先级实时调度框架，并支持多种实时数据 分析模式。该工作与我们的研究互补，因为本文采用的EDF是一种动态优先级调度方法。此外，我们 支持从物联网设备到运行RTMR的边缘服务器之间的高性价比传感器数据传输与流式传输，以及映射‐ 归约阶段之间中间数据的内存预留和流水线处理，这与[11–17,47]不同。Phoenix[20]支持在多核系 统中高效地内存中执行Map/Reduce任务。还有其他内存MapReduce系统如[48,49]；然而，它们既 未考虑实时数据分析的时序约束，也不支持传感器数据流式传输或流水线。本文通过引入实时调度、 内存预留以及数据流式传输与流水线，扩展了内存中MapReduce的概念，以支持实时数据分析，同 时支持基于数据重要性的自适应传感器数据传输。由于目前没有标准实时大数据框架，且不同的方法 （例如[11–17,47]）使用不同的框架、截止时间和调度算法，我们几乎无法（即使可能也非常困难） 自行实现并实验比较所有与RTMR相关的方法。因此，我们选择与最接近我们工作的Phoenix[20]进 行性能对比，作为概念验证，同时如上所述，对我们的方法与先进的相关方法[11–17,47]进行定性比 较。

实时数据库（RTDBs）已被广泛研究，用于处理使用表示当前现实世界状态的新鲜时态数据的用 户事务。然而，基于机器学习或数据挖掘等的复杂数据分析在实时数据库中很少被考虑。它们也没有 提供易于使用的并行编程模型，例如MapReduce模型[4]。领先的流数据管理系统，例如Storm[8],、 Spark Streaming[10],和C‐MR[50],，支持近实时流数据处理。RAMCloud[51]始终将全部数据存 储在分布式内存中，并提供高速网络，以实现比基于磁盘的存储快1000倍的读/写操作。然而，它们并 未考虑实时数据分析的时序约束。未来，我们的方法可以与之结合，以实时处理更大的传感器数据。

在多处理器实时调度中，通常使用多个处理器或核心[52]来并发调度串行任务。新型调度算法 （例如[34,35],）被开发用于支持任务内并行性，使得单个实时任务可以同时使用多个核心（或处理 器）。通过这种方式，计算密集型任务能够满足严格的截止时间，而这些截止时间在其他情况下无法 满足。然而，这些研究并未考虑实时数据分析问题，例如实时MapReduce模型、数据流/流水线以及 传感器数据及时分析所需的内存预留。

7. 结论与未来工作

支持实时传感器数据分析是理想但具有挑战性的。大多数现有的大数据管理系统（如Hadoop） 对时间不敏感，仅关注在云中对先前存储的数据进行批处理，而不是处理从物联网设备到边缘服务器 的实时传感器数据传输以及在网络边缘进行的实时分析。为解决这一问题，我们设计了一个用于高性 价比的传感器数据传输和实时分析的新框架。我们还实现了一个原型系统并对其性能进行了评估。在 性能评估中，我们采用的自适应传输速率分配方法能有效跟踪真实值，同时显著提升效用。此外，我 们支持对实时数据分析任务的可调度性分析，并通过实验验证了在原型实时MapReduce框架（ RTMR）中满足时间约束。未来，我们将探索更高效的调度和资源管理技术，例如边缘服务器之间的 负载均衡，同时提供更先进的数据重要性估计和实时数据分析。