边缘计算急需解决的难题

目前边缘计算已经得到了各行各业的广泛重视，并且在很多应用场景下开花结果。根据边缘计算领域特定的特点，本文认为6个方向是未来几年迫切需要解决的问题：编程模型、软硬件选型、基准程序与标准、动态调度、与垂直行业的紧密结合以及边缘节点的落地。

1. 编程模型

编程模型可以使开发者快速上手开发应用产品，从而快速推动领域的发展.在云计算场景中，用户程序在目标平台上编写和编译，然后运行到云服务器，基础设施对于用户是透明的，例如亚马逊基于此编程模型推出的 Lambda 计算服务，可使用户无需预配置或者管理服务器即可运行代码，极大地方便了用户的使用。然而，边缘计算模型与云计算模型存在较大的区别，从功能角度讲，边缘计算是一种分布式的计算系统，具有弹性管理、协同执行和环境异构的特点，如图4所示：

从图4可知，边缘计算包含3个关键内容：

• 应用程序/服务功能可分割。边缘计算中的一个任务可以迁移到不同的边缘设备去执行，任务可分割包括仅能分割其自身或将一个任务分割成子任务，任务的执行需要满足可迁移性，即任务可迁移是实现在边 缘设备上进行数据处理的必要条件。
• 数据可分布。数据可分布既是边缘计算的特征也是边缘计算模型对待处理数据集合的要求。边缘数据的可分布性是针对不同数据源而言的，不同数据源来源于数据生产者所产生的大量数据。
• 资源可分布。边缘计算模型中的数据具有一定的可分布性，从而要求处理数据所需要的计算、存储和通信资源也具有可分布性.只有当边缘计算系统具备数据处理和计算所需要的资源，边缘设备才可以对数据进行处理。

因此，传统的编程模型并不适合边缘计算。边缘计算中的设备大多是异构计算平台，每个设备上的运行时环境、数据也不相同，且边缘设备的资源相对受限，在边缘计算场景下部署用户应用程序会有较大的困难。Li等人针对边缘设备资源受限的特性设计了一种轻量级的编程语言EveryLite，该工作将计算迁移任务中主体为接口调用的、时间和空间复杂度受限的计算任务称为微任务(micro task)， EveryLite能够在物端设备上处理边缘计算场景中微任务，经过实验对比可以发现EveryLite的执行时间分别比JerryScript和Lua低77%和74%，编译后内存占用量分别是JerryScript和Lua的18. 9% 和1. 4%。因此，针对边缘计算场景下的编程模型的研究具有非常大的空间，也十分紧迫。

2. 软硬件选型

边缘计算系统具有碎片化和异构性的特点。在硬件层面上，有CPU，GPU，FPGA，ASIC等各类计算单元，即便是基于同一类计算单元，也有不同的整机产品，例如基于英伟达GPU的边缘硬件产品，既有计算能力较强的DRIVEPX2，又有计算能力较弱 的Jetson TX2；在软件系统上，针对深度学习应用， 有 TensorFlow, Caffe, PyTorch 等各类框架.不同的软硬件及其组合有各自擅长的应用场景，这带来了一个问题：开发者不知道如何选用合适的软硬件产品以满足自身应用的需求。

在软硬件选型时，既要对自身应用的计算特性做深人了解，从而找到计算能力满足应用需求的硬件产品，又要找到合适的软件框架进行开发，同时还要考虑到硬件的功耗和成本在可接受范围内。因此，设计并实现一套能够帮助用户对边缘计算平台进行性能、功耗分析并提供软硬件选型参考的工具十分重要。

3. 基准程序和标准

随着边缘计算的发展，学术界和工业界开始推出越来越多的针对不同边缘计算场景设计的硬件或软件系统平台，那么我们会面临一个紧迫的问题，即如何对这些系统平台进行全面并公平的评测。传统的计算场景都有经典基准测试集(benchmark)，例如并行计算场景中的PARSEC、高性能计算场景中的 HPCC、大数据计算场景中的BigDataBench。

由于边缘计算仍然是较新的计算场景，业界仍然没有一个比较权威的用于评测系统性能的Benchmark出现，但是学术界已经开始有了一些探索工作SD-VBS和MEVBench均是针对移动端设备评测基于机器视觉负载的基准测试集。SD-VBS选取了28个机器视觉核心负载，并提供了C和Matlab的实现；MEVBench则提供了一些列特征提取、特征分类、物体检测和物体追踪相关的视觉算法负责，并提供单线程核多线程的C++实现。SLAMBench是一个针对移动端机器人计算系统设计的基准测试集，其使用RG&D SLAM作为评测负载，并且针对不同异构硬件提供C++，OpenMP， OpenCL 和 CUDA 版本的实现。CAVBench是第1个针对智能网联车边缘计算系统设计的基准测试集，其选择6个智能网联车上的典型应用作为评测负责，并提供标准的输人数据集和应用-系统匹配指标。

由于边缘计算场景覆盖面广，短期来看不会出现一个统一的基准测试集可以适应所有场景下的边缘计算平台，而是针对每一类计算场景会出现一个经典的基准测试集，之后各个基准测试集互相融合借鉴，找出边缘计算场景下的若干类核心负载，最终形成边缘计算场景中的经典基准测试集。

4. 动态调度

在云计算场景下，任务调度的一般策略是将计算密集型任务迁移到资源充足的计算节点上执行。但是在边缘计算场景下，边缘设备产生的海量数据无法通过现有的带宽资源传输到云计算中心进行集中式计算，且不同边缘设备的计算、存储能力均不 相同，因此，边缘计算系统需要根据任务类型和边缘设备的计算能力进行动态调度。调度包括2个层面：

• 云计算中心和边缘设备之前的调度;
• 边缘设备之间的调度。

云计算中心与边缘设备间的调度分为2种方式：自下而上和自上而下。自下而上是在网络边缘处将边缘设备采集或者产生的数据进行部分或者全部的预处理，过滤无用数据，以此降低传输带宽;自上而下是指将云计算中心所执行的复杂计算任务进行分割，然后分配给边缘设备执行，以此充分利用边缘设备的计算资源，减少整个计算系统的延迟和能耗。2017年，Kang等人设计了一个轻量级的调度器 Neurosurgeon,它可以将深度神经网络不同层的计算任务在移动设备和数据中心间自动分配，使得移动设备功耗最多降低了 94.7%，系统延迟最多加快了40.7倍，并且数据中心的吞吐量最多增加了6. 7倍。边缘设备间也需要动态调度。边缘设备的计算、存储能力本身是不同的，并且会随着时间的变化而变化，而它们承担的任务类型也是不一样的，因此需要动态调度边缘设备上的任务，提高整体系统性能，防止出现计算任务调度到一个系统任务过载情况下的设备.Zhang等人针对延迟敏感性的社会感知任务设计了一个边缘任务调度框架C〇GTA，实验证明该框架可以满足应用和边缘设备的需求。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!