边缘计算与大数据处理技术的对比研究

发表时间:2020/11/18   来源:《基层建设》2020年第20期   作者:余海峰
[导读] 摘要:边缘计算与大数据处理都是为了解决计算任务而引入,并由于各自的计算任务特殊性而差异化发展,但在系统架构层二者是相通的。
        天津精赛科技有限公司  天津  300000
        摘要:边缘计算与大数据处理都是为了解决计算任务而引入,并由于各自的计算任务特殊性而差异化发展,但在系统架构层二者是相通的。本文先分别概括二者的系统模型和范型,然后从计算特征和数据存储两个核心问题出发,分析二者的异同,为这两个领域的研究成果做深度对比分析提供新的研究思路。
        关键词:边缘计算;计算卸载;边缘缓存;大规模数据处理;人工智能
        从互联网时代的数据爆炸,到即将大规模铺开的5G通信支撑下的物联网时代的大数据浩海,基于大规模数据的计算方法论成为大数据智能的重要推动力,反过来,这类计算方法论也助推数据终端设备的应用,物联网的发展正是借力于大数据与人工智能技术而蓬勃发展。这其中,智能终端设备设计技术的快速发展演进正变革大数据计算技术,而边缘计算正是在这样的背景下得到重视与发展。随着智能终端设备感知能力的不断增强,数据规模的爆炸式增长,这对大规模数据处理速度和能力提出了更高的要求,现有的云计算数据处理模式已经无法满足物联网数据计算的需求,因此,将计算服务卸载到与用户终端距离较近的位置,即边缘计算范型,成为逻辑上集中式云计算的有效替代方案。所以从计算这个角度上看,边缘计算主要涉及两个方面:承载计算任务的基础设施网络架构以及运行在这个基础设施之上的计算优化技术,如果说前者是硬件基础设施建设,那么后者则是软件层面的计算资源调度。其中,在边缘计算领域,前面提及的计算优化技术常称之为边缘计算资源优化技术。
        而大规模数据处理技术的发展则经历了更长时间的发展演进。在谷歌公司发表的三篇划时代论文(分别介绍MapReduce、GFS和BigTable)的推动下,开源项目Hadoop横空出世,并于2008年1月正式成为Apache的顶级项目;此后,Hadoop迅速建立起大数据生态体系,并由此衍生出一系列大数据处理的理论和与之对应的大数据处理框架:从批处理到流处理,从Hadoop到Storm/Spark,到Flink[1],以及能融合异构大数据计算系统的大数据湖。从更高层次看,这些发展解决的是两个层次的问题:数据的分布式存储与适配这种大容量分布式数据存储的计算编排。除数据湖外,这些技术所解决的问题还是集中式大容量数据计算问题,因为这里提及的分布式数据大体上是分布在一个机房的多台计算节点上;而边缘计算则网络结构动态变化的智能终端的计算任务。
        因此,在逻辑上,边缘计算与大数据处理技术存在极高的相似性,本文着重研究二者的异同,为两个领域的研究者快速相互借鉴对方优秀研究成果提供不同的分析视角。
        1 边缘计算
        (1)雾计算。雾计算概念由思科公司于2012年提出,是一个系统级边缘计算架构。雾计算可以看做是云计算延伸和拓展,以拉近计算需求节点与计算承载节点之间的距离换取计算服务质量体验的[2]。此后,IEEE采用OpenFog参考架构作为雾计算的正式标准,以提供行业认可的框架,在实现性能和安全性的同时加速物联网、5G 和人工智能方面的创新和市场发展。OpenFog参考架构的核心技术原则包括八个方面,分别是安全性、可扩展性、开放性、自主性、RAS(可靠性、可用性和可维护性)、敏捷性、层次性和可编程性,这些原则用以满足用于云到物(cloud-to-things)统一体可互操作的端到端数据连接需求。根据OpenFog的雾计算模型,我们可以很容易看出TCP/IP协议层次模型的影子,这也印证了不同研究领域的优秀研究成果可以相互借鉴这一科研方法论,
       
        图1 OpenFog雾计算参考模型[3]
        从上图可以看出,雾计算核心思想是将具有强大计算能力的服务器前移至网络关键接入点,为网络距离较近的移动终端设备提供计算与存储资源服务,其突出特点是支持低延迟的实时应用与位置感知能力。但雾计算的计算与存储资源并没有跟随通信网络统一规划,而是根据应用场景的需求事后集成,如智能交通、智能电网等,这显然不适用于移动终端用户的边缘计算需求,特别是当移动用户频繁跨区域移动时。
        (2)移动边缘计算(MobileEdgeComputing,简称MEC)。通过对雾计算在移动边缘计算应用场景的分析可得出结论,如果将边缘计算基础设施集成到移动网络节点中,则移动用户跨区域移动时,边缘计算服务仍可以保障计算服务质量,因此,不难理解移动边缘计算是由移动运营商推动的。欧洲电信标准化协会制定了移动边缘计算框架,共包括三层,分别为网络层、移动边缘主机层、移动边缘系统层,如下图所示,
        (3)计算卸载。终端设备、特别是移动终端设备的中央处理器(CPU)性能无法满足实时/准实时计算任务的需要;而且频繁的计算任务往往带来较大的耗电量,这会造成移动终端设备需要频繁充电,因此将计算从终端设备端卸载并将计算迁移至边缘服务器是边缘计算提供的解决方案。以移动边缘计算为例,计算卸载会面临诸多挑战:网络带宽受限且网络带宽是动态变化的;多租户共享边缘服务器的计算资源与信道资源,这些用户在提交计算任务时存在竞争关系,而且多租户是动态变化的,这增加计算服务端的资源调度优化难度;当用户的计算任务异常复杂,如业务工作流,而且这种计算任务还会具备终端的跨域移动特征,这要求计算服务端需要考虑计算的时序特征。因此,如何权衡边缘服务端与移动终端之间的计算任务分配、边缘服务端如何有效地将移动终端卸载的计算调度到整个边缘节点上,成为计算卸载研究的出发点。
       
        图2 欧洲电信标准化协会制定的移动边缘计算框架[4]
        (4)边缘缓存。人工智能的计算任务往往需要大量历史数据,大数据的计算思路是将计算拆分到数据所在的节点上,这要求边缘计算模型具备数据缓存能力。边缘计算的目的是延伸云计算而不是替代云计算,因此边缘计算模型不会考虑将云计算端的数据全量搬移至边缘计算端,缓存部分云计算端数据以提升边缘计算服务质量是边缘缓存的研究重心。
        2 大规模数据处理技术
        2003年,谷歌的工程师便开始构建各种定制化数据处理系统,以解决大规模数据处理的几大难题:大规模数据处理特别困难(Data Processing is hard),这里的难有很多个方面,仅仅是在大规模数据上构建一个处理程序也不是一件容易的事;保证可伸缩性很难(Scalability is hard),让处理程序在不同规模的集群上运行,或者更进一步,让程序根据计算资源状况自动调度执行,也不是一件容易的事;容错很难(Fault-tolerance is hard),让处理程序在由廉价机器组成的集群上可靠地运行,更不是一件容易的事情。这些困难促使MapReduce(不是Hadoop中的MapReduce)诞生。MapReduce将处理抽象成Map+Shuffle+Reduce的过程,这种抽象对大数据处理理论变革有着深远的影响。
        经过一段时间的应用实践,MapReduce的缺陷也逐渐暴露,最让人诟病的是Map+Shuffle+Reduce编程模型导致计算作业效率低下。为此,2007年,谷歌发起了Flume项目。Flume将数据处理过程抽象成计算图(有向无环图),数据处理逻辑被编译成Map+Shuffle+Reduce的组合,并加入物理执行计划优化,而不是简单地将Map+Shuffle+Reduce串联。其中,Flume引入的管道(Pipeline)、动态负载均衡(谷歌内部称为液态分片)和流语义思想成为大数据处理技术变革的宝贵理论财富。
        产生于处理推特信息流的流式数据处理框架Storm以牺牲强一致性换取实时性,并在一些场景下取得了成功。为了让数据处理程序兼备强一致性和实时性,工程师们将强实时性的Storm和强一致性的Hadoop批处理系统融合在一起,即Lambda架构。其中,Storm负责实时生成近似结果,Hadoop负责计算最终精准结果。Lambda架构需要部署两套队列集群,数据要持久化存放两份,这会导致数据冗余,增加系统维护成本。
        MapReduce模型严重依赖分布式文件系统,如Map将计算结果临时写入文件系统,而Shuffle从文件系统中读入该结果,这往往会产生较大的计算性能损耗,因此基于内存的计算是另一个选择,这就是Spark成功的秘诀。此外,Spark还支持流式数据处理,即Spark Streaming,其原理是将多个微批处理任务串接起来构建流式数据处理任务。但是这种采用微批重复运行的机制牺牲了低延迟和高吞吐的优势,引起了Spark Streaming是不是真正流式数据处理引擎的争议。
        这期间,流式数据处理继续发展,出现了MillWheel、Kafka、DataFlow和Flink。exactly-once语义、数据源端的持久化和可重放、动态表理论,以及时间、窗口、水印、触发器、轻量级快照机制等流式数据处理核心理论的提出,加快了流式数据处理框架的发展步伐。
        3 边缘计算与大数据处理技术对比分析
        边缘计算和大数据处理技术的核心都是计算,并且这些计算的对象主要是大数据集,因此二者不可避免的会涉及数据的高效存储,所以本文将从两个方面入手,对比分析边缘计算和大数据处理技术在理论层次上的异同。
        (1)数据存储。大数据模型将数据存储在预定义的集群中,尽管集群的节点可以动态扩充,但通常在数据存入前是定义好的、即静态的;这些节点是通过高速局域网络互连,网络传输质量可以得到有效保证。边缘计算模型并不会将全量数据集中存储在边缘节点上,而是根据需要缓存部分热点数据;边缘计算服务端和移动终端之间的网络传输不能保证高带宽、高可靠。但是,从计算的角度看,两种模型都会在分布式的本地数据集上调度计算任务,因此从数据和计算的关系上看,二者是相似的。
        (2)计算特征。大数据模型的计算特征是高负荷的全量数据计算,在实时大数据处理应用场景下,这种计算要在实时性的基础上确保最终一致性;计算任务由计算图定义,然后将拆分后的计算任务调度到距离数据节点上执行,最后将这些计算归并到一起。边缘计算则权衡边缘服务端与移动终端的计算任务分配,由二者协作完成计算任务;计算和边缘服务端不存在强绑定关系。两种模型都会借助复杂的算法解决计算任务的编排与调度问题,而这些算法之间存在着理论的一致性。
        结论:
        综上所述,边缘计算与大数据处理都是为了解决计算任务而引入,并由于各自的计算任务特殊性而差异化发展,但其模型的本质是相通的,而且由于大数据的发展历程长于边缘计算,大数据的研究成果得到了工业界的验证,亟待将两个领域的研究成果做深度对比分析,为两个领域的快速发展提供新的研究思路。
        参考文献:
        [1]The Evolution of Massive-Scale Data Processing,Tyler Akidau,Strata + Hadoop World London 2016.
        [2]余韵,连晓灿,朱宇航,谭国平.增强现实场景下移动边缘计算资源分配优化方法[J].计算机应用,2019,39(01):22-25.
        [3]Dastjerdi A V,Gupta H,Calheiros R N,et al.Fog computing:Principles,architectures,and applications[J].arXiv preprint arXiv:1601.02752,2016.[13]Davis A,Parikh J,Weihl W E.Edge computing:extending enterprise applications to the edge.
        [4]ETSI - GS MEC 003 Mobile Edge Computing(MEC);Framework and Reference Architecture.
        [5]李虎.基于移动边缘计算的超密集网络任务卸载策略研究[D].重庆邮电大学,2019.
        [6]张海波,李虎,陈善学,贺晓帆.超密集网络中基于移动边缘计算的任务卸载和资源优化[J].电子与信息学报,2019,41(05):1194-1201.
        [7]李雨晴.移动边缘计算网络中任务调度与资源配置的协同优化研究[D].上海交通大学,2019.
        [8]余海峰,深入理解Flink:实时大数据处理实践[M],电子工业出版社,2020.
投稿 打印文章 转寄朋友 留言编辑 收藏文章
  期刊推荐
1/1
转寄给朋友
朋友的昵称:
朋友的邮件地址:
您的昵称:
您的邮件地址:
邮件主题:
推荐理由:

写信给编辑
标题:
内容:
您的昵称:
您的邮件地址: