文摘
现代发展日益数字化生活导致数据的快速增长。这种多维数据集是珍贵的潜力挖掘新知识和发展决策的见解。分析这些大量来自多个来源的数据可以帮助组织未来的计划和预测不断变化的市场趋势和客户需求。虽然Hadoop框架是一种流行的平台处理更大的数据集,有很多其他的计算基础设施,可以使用在不同的应用领域。这项研究的重点是如何分类主要大数据资源管理系统在云计算环境中。我们确定一些关键特性描述大数据框架以及相关的挑战和问题。我们使用各种评价指标从不同方面来识别这些平台的使用场景。这项研究提出了一些有趣的发现是在矛盾在互联网上可用的文学。
1。介绍
我们生活在信息时代,现在的一个重要测量的数据量是我们周围生成的任何地方。数据变得越来越有价值。企业针对解锁数据隐藏的潜力,提供竞争优势(1]。Stratistics MRC预计,数据分析和Hadoop市场,占84.8亿美元,2015年预计将达到十亿到2022年(2]。全球大数据市场估计,它会跳十亿到2013年2018年(3]。Gartner预测,数据在未来5年内将增长800%和80%的将非结构化的数据(电子邮件、文档、音频、视频和社交媒体内容)和20%将结构化(电子商务交易和联系信息)1]。
今天最大的科研机构,欧洲核子研究中心,每年生产超过200 PB的数据在大型强子对撞机项目(2017年)。在互联网上生成的数据量已经超过了每天2.5艾字节。一分钟内,400小时的视频被上载到YouTube上,360万年谷歌搜索进行世界范围内的每一天,每分钟超过6.56亿条在推特上分享,650万多照片共享Instagram每一天。当数据集变得如此之大,其存储和处理成为挑战由于现有工具和资源的限制,数据集被称为大数据(4,5]。它是第一个提供决策的见解之旅的一部分。而是关注的人来说,这个过程使用一个更强大的和不断发展的技术,鉴于这一领域的最新突破,快速分析大量的数据流,从各种各样的来源,产生一个有用的知识流(6]。
大数据应用程序可能被视为进步的并行计算,但随着规模的重要例外。规模的必要性的性质所产生的目标问题:数据维度大大超过传统的存储单元,执行所需的水平的并行计算在一个严格的期限是高的,和获取最终结果需要聚合大量的部分结果。规模因素,在这种情况下,不仅有相同的效果,在经典并行计算,但它汹涌向维自动化资源管理和开发的重要的价值(7]。
成功的一个重要因素大数据分析项目资源的管理:这些平台使用大量的虚拟硬件资源来优化成本之间的权衡和结果。管理这些资源绝对是一个挑战。复杂性是植根于他们的体系结构:第一级的复杂性源于他们计算节点的性能要求:典型的大数据应用程序利用大规模并行计算资源,存储子系统和网络基础设施,因为结果是需要在未来一段时间内,或者他们可以随着时间的推移失去价值。异质性是一个技术需要:可发展性、可扩展性和可维护性的硬件层意味着系统将部分集成,更换,或扩展的新部分,根据市场上的可用性和技术的发展7]。现代应用程序的另一个重要的考虑因素是大量需要处理的数据量。这些数据通常来源于不同的设备(例如,公共网络,业务应用,卫星,或传感器)和程序(例如,案例研究、观察性研究或模拟)。因此,当务之急是开发与更好的性能计算架构,支持当前和未来的应用需求。从历史上看,这需要计算资源提供的高性能计算(HPC)环境比如计算机集群,超级计算机和网格。在传统owner-centric HPC环境、内部资源由一个管理域(19]。集群计算是最主要的建筑环境。在分布式高性能计算环境,如网格计算、虚拟组织管理资源的配置,内部和外部,满足应用需求20.]。然而,范式转向云计算被广泛讨论最近的研究(19,21),针对HPC在云计算环境中工作负载的执行。虽然内部组织通常倾向于把他们最敏感数据(本地),大量的大数据(由企业或由第三方)可能存储在外部;有些可能已经在一个云。保留所有数据源防火墙后面可能会导致严重的资源浪费。分析数据,它驻留在内部或公共云数据中心更有意义(1,22]。
即使云计算已经成为一个推动者大数据应用程序的增长,常见的云计算解决方案,而不同于大数据的应用程序。通常情况下,云计算解决方案提供细粒度的、松散耦合的应用程序,运行为大量用户服务,独立运作,从多个位置,可能是自己的,私人的,非共享数据,与大量的交互,而不是主要面向批处理的,一般适合搬迁与高度动态的资源需求。尽管有这些差异,云计算和大数据架构有许多共同的需求,如自动化(或自主)细粒度的资源管理和扩展相关问题(7]。
随着云计算开始成熟,大量的企业建立高效、敏捷的云环境,和云提供商继续扩大服务(1]。微软的云Hadoop提供包括Azure市场,负责Cloudera企业,MapR,和Hortonworks数据平台(黄芪丹参滴丸)在一个虚拟机,和Azure数据湖,其中包括Azure HDInsight湖湖数据分析和数据存储管理服务。平台提供了丰富的生产力套件数据库、数据仓库、云、电子表格、协作、商业智能、OLAP,和开发工具,提供Hadoop堆栈微软社区。亚马逊网络服务,笼罩着云计算和大数据解决方案的领导者。亚马逊EMR是可用的全球14个地区。Hadoop的AWS提供版本,火花,特斯,很快可以工作数据存储在Amazon S3和亚马逊的冰川。云Dataproc谷歌托管使用Hadoop集群和火花完全托管云服务,如谷歌BigQuery和Bigtable。IBM与端到端区分BigInsights还先进的分析。IBM BigInsights还运行在IBM的SoftLayer云基础设施,可以部署在全球30多个数据中心。IBM在火花进行重大投资,BigQuality BigIntegrate和IBM InfoSphere大赛,用纱线运行本地处理最棘手的Hadoop的用例(23]。
在本文中,我们概述的一些最受欢迎的和广泛使用的大数据框架,在云计算环境的背景下,为了应对上述资源管理和规模问题。这项研究的主要对象是如何分类不同的大数据资源管理系统。我们使用各种评价指标从不同方面流行的大数据框架。我们还确定一些关键特性的描述大数据框架以及相关的挑战和问题。我们限制我们的研究选择标准实证研究从现有文献报道的证据在大数据资源管理的绩效评估框架。我们所知,到目前为止还没有基于实证的绩效评估报告主要资源管理框架。我们研究了现有研究的有效性进行验证性研究。为此,标准的性能评估测试以及自定义负载测试用例进行集群t2.2xlarge Amazon AWS 10 + 1节点。对于实验和基准测试,我们遵循相同的过程中(在我们的早期研究24]。
这项研究提出了一些有趣的发现是在矛盾在互联网上可用的文学。新奇的研究包括基于云计算的海量数据资源管理框架的分类根据他们的关键特性,比较评价流行的大数据框架,使用大数据相关的最佳实践框架在云中。
包含和排除标准相关研究如下:(我)我们只选择那些资源管理框架,我们发现不同的云供应商提供的经验证据的。(2)一些供应商提供他们的专有解决方案进行大数据分析这可能是潜在的候选人进行比较分析。然而,这些框架没有选择基于两个原因。首先,这些解决方案是开源解决方案的扩展,因此这些展览在大多数情况下相同的执行结果。其次,我们的实证研究,研究者们大多喜欢开源解决方案文档,使用场景,源代码,和其他相关细节是免费的。因此,我们选择开源解决方案的性能评价。(3)我们不包括现在弃用或折扣的框架,例如Apache S4,支持其他资源管理系统。
本文组织如下。部分2综述了受欢迎的资源管理框架。大数据框架的比较提出了部分3。基于比较评价,我们分类这些系统4。相关工作提出了部分5最后,提出结论和未来可能的方向6。
2。大数据资源管理框架
大数据提供新兴趋势和机会发掘业务洞察力对数据管理。最具挑战性的问题组织往往是巨大的数据量,需要处理的最优速度合成相关的结果。分析这样的大量来自多个来源的数据可以帮助组织未来的计划和预测不断变化的市场趋势和客户需求。在许多情况下,大数据在批处理模式进行了分析。然而,在很多情况下,我们可能需要对数据或分析数据的当前状态的运动(数据不断进来,需要立即处理)。这些应用程序需要一个持续的经常要处理非结构化数据。因此,不断分析和数据缓存在内存中之前存储在二级存储设备。处理数据流,通过过滤内存表的数据在一个服务器集群。任何延迟的数据分析可以严重影响客户满意度或可能导致项目失败25]。
虽然Hadoop框架是一种流行的平台处理庞大的数据集使用商品计算资源并行批处理模式,有很多其他的计算基础设施,可用于不同的应用领域。本研究的主要目标是调查流行的大数据资源管理框架中常用的云计算环境。最受欢迎的大数据工具的云计算平台,包括Hadoop生态系统,可以在开源许可下使用。的一个关键上诉Hadoop和其他开源解决方案是较低的总拥有成本。而专有的解决方案有昂贵的许可费用和可能需要更为昂贵的专用硬件,这些开源解决方案没有许可费用,可以在行业标准的硬件上运行14]。图1展示了不同风格的分类处理架构的开源大数据资源管理框架。
在随后的部分,我们将讨论不同的开源大数据资源管理框架,结合云计算环境中被广泛使用。
2.1。Hadoop
Hadoop (26)是一种基于开源的分布式编程和存储基础设施实现MapReduce的模型(27]。MapReduce是第一个和当前实际编程环境为开发以数据为中心的并行应用程序解析和处理大型数据集。MapReduce是灵感来自Map和Reduce原语用于函数式编程。在MapReduce编程,用户只需要写的逻辑映射和减速器,洗牌的过程中,自动分区,排序是由执行引擎处理(14,27,28]。数据可以被保存在Hadoop文件系统作为非结构化数据或数据库中的结构化数据(14]。Hadoop分布式文件系统(HDFS)负责将大型数据文件分解成小块。块放在不同的数据节点,这是工作的NameNode注意块数据节点构成了完整的文件。NameNode是一名交警,处理所有访问文件,包括读、写、创建、删除和复制数据块的数据节点。管道是一个存在多个数据节点之间的联系来处理跨服务器的数据传输。用户应用程序将一块推到第一个数据节点的管道。节点接管和远期的数据块到下一个节点的管道;这个过程一直持续到所有的数据,所有的数据副本,保存到磁盘。后来,客户重复的过程文件中编写下一个块(25]。
两个主要组件的Hadoop MapReduce作业调度和跟踪。Hadoop的早期版本支持有限的工作和任务跟踪系统。特别是,前面的调度器不能管理non-MapReduce任务和不能够优化集群利用率。因此,一个新功能是为了解决这些缺点可能提供更大的灵活性,扩展,效率和性能。因为这些问题,介绍了Hadoop 2.0。与早些时候HDFS、资源管理和MapReduce模型,它引入了一个新的资源管理层称为另一个资源谈判代表(纱),负责更好的资源利用率(25]。
纱是Hadoop核心服务提供两个主要功能:全球资源管理(ResourceManager)和每个应用程序管理(ApplicationMaster)。ResourceManager主人服务控制NodeManager Hadoop集群的每个节点。它包括一个调度程序,其主要任务是将系统资源分配给特定的运行应用程序。所有必需的系统信息由资源容器跟踪监视CPU、存储、网络和其他重要的资源属性集群中执行应用程序所必需的。ResourceManager奴隶NodeManager服务监控应用程序使用情况统计数据。每个部署的应用程序是由一个相应ApplicationMaster服务。是否需要更多的资源来支持运行的应用程序,ApplicationMaster请求NodeManager和NodeManager与ResourceManager(调度器)谈判代表应用程序的额外容量(26]。
2.2。火花
Apache火花(29日),最初作为伯克利火花,开发提出了Hadoop作为替代。它可以通过使用内存中执行更快的并行计算操作原语。工作可以在本地内存或加载数据集群范围的共享内存和迭代查询它大得多的速度比基于磁盘系统,如Hadoop MapReduce (27]。引发了两个应用程序,在内存中保存数据可能显著提高性能:迭代机器学习算法和交互式数据挖掘。火花也旨在统一当前处理堆栈,执行批处理使用MapReduce,交互式查询使用HBase执行,执行流的实时分析处理使用其他框架(Twitter的风暴。火花为程序员提供了一个函数式编程范式以数据为中心的编程接口之上的一种新的数据模型称为弹性分布式数据集(抽样),这是一个对象集合分布在集群存储在内存或磁盘(28]。这些抽样应用火花可以加载到内存的集群的节点,让火花引擎自动管理分区的数据和它的位置在运行时。这个通用的迭代模型可以控制持久性和管理数据的分区。输入数据流可以分割成一系列的批次和序列的小批量的处理工作。流的火花框架允许这种无缝的结合和批处理在一个统一的系统。提供快速应用程序开发,火花提供干净、简洁的api在Scala中,Java、Python。火花可以从Scala和Python交互式shell使用大数据集的快速查询。
火花也是鲨鱼背后的引擎,一个完整的Apache Hive-compatible数据仓库系统,可以运行比蜂房快得多。火花从Hadoop还支持数据访问。火花在无缝符合Hadoop 2.0生态系统(图2MapReduce)作为替代,而使用相同的底层基础设施如纱和HDFS。火花也打栈的一个组成部分提供最受欢迎的原生云PaaS如物联网、预测分析和实时大数据的个性化。在打,Apache便集群管理器(而不是纱)用于集群资源的动态分配,不仅为运行Hadoop还处理异构工作负载的应用程序。
GraphX和MLlib库包括先进的图和机器学习算法,可以实时执行。BlinkDB是一种新型平行,sampling-based近似查询引擎运行交互式SQL查询,交易查询响应时间精度,通过有意义的误差结果注释。BlinkDB已经证明运行快200倍比蜂房内2 - 10%的错误率。此外,火花提供了一个交互式工具,称为火花壳可以利用实时集群的火花。一旦创建交互式应用程序,他们可能随后会被集群中交互式地执行。在图3,我们现在一般引发系统架构。
2.3。Flink
Apache Flink的火花是一个新兴的竞争对手提供了函数式编程接口,类似于火花。它分享了很多编程原语和转换什么火花一样的迭代开发、预测分析和图流处理。Flink开发来填补这一缺口留下的火花,它使用minibatch流处理而不是纯粹的流方法。Flink保证高加工性能在处理复杂的大数据结构如图。Flink程序是普通的应用程序是用一组丰富的转换操作(如映射、过滤、分组、聚合、和加入)的输入数据集。Flink数据集使用表格模型;因此,应用程序开发人员可以使用索引号来指定一个特定的数据集(27,28]。
Flink能够实现高吞吐量和低延迟,从而很快就处理一堆数据。Flink旨在大规模具有数千个节点的集群上运行,除了一个单独的集群模式,Flink为纱提供支持。在分布式环境中,Flink连锁店运营商子任务成任务。每个任务一个线程执行的(16]。Flink运行时包含两种类型的流程:至少有一个JobManager(也称为大师)的坐标分布执行。它计划任务,检查点,坐标和坐标复苏失败。一个高可用性的设置可能涉及多个JobManagers,哪一个总是领导者之一,其他的是备用的。TaskManagers(也称为工人)执行任务(或者,更具体地说,子任务)的数据流/缓冲和交换数据流。必须有至少一个TaskManager。JobManagers和TaskManagers可以开始以不同的方式:直接在机器上作为一个独立的集群,在容器,或者像纱或便由资源管理框架。TaskManagers连接JobManagers,宣布自己是可用的,和被分配的工作。图4演示了Flink框架的主要组件。
2.4。风暴
风暴(17)是一个免费的开源分布式流处理计算框架。需要几个特征从受欢迎的角色模型,可以用于几乎任何一种编程语言开发应用程序实时流分析等关键工作流程系统和数据交付服务。发动机可能处理数十亿元组每天的容错方法。它可以集成与流行的资源管理框架如纱,便和码头工人。Apache风暴集群是由两种类型的处理演员:滔滔不绝的和螺栓。(我)槽连接到外部数据流的来源和不断排放或收集新数据进行进一步处理。(2)螺栓是一个处理逻辑单元在一个流媒体处理拓扑结构;每个螺栓负责一个特定的加工任务,如转换、过滤、聚合和分区。
风暴将工作流定义为有向无环图(无进取心的人),称为拓扑与壶嘴和螺栓连接顶点。图中边定义螺栓和数据流之间的联系。与批处理作业只被执行一次,风暴工作一直运行下去,直到他们死亡。集群在暴风雨中有两种类型的节点:灵气(主节点)和主管(工作节点)。灵气,类似于Hadoop JobTracker, Apache风暴的核心组件,负责跨集群分布负载,排队,将任务分配给不同的处理单元,和监控执行状态。每个工人节点执行一个过程称为主管,可能有一个或多个工作进程。管理者代表工作进程的任务。工作进程然后创建拓扑的一个子集来运行的任务。Apache风暴并依靠内部分布式信息系统,称为网状的,灵气和主管之间的沟通。动物园管理员管理之间的通信实时工作追踪器(光轮)和主管(风暴工人)。 Figure5概述了风暴集群的高级视图。
2.5。Apache Samza
Apache Samza [18)是一个分布式流处理框架,主要用Scala和Java写的。总的来说,它有一个相对较高的吞吐量以及一定程度上增加了延迟相比风暴(8]。它使用Apache卡夫卡,最初是LinkedIn,开发消息流,而Apache Hadoop纱/便利用作为整体的执行平台资源管理。Samza依赖卡夫卡的语义定义流的处理方式。它的主要目的是收集和提供大量大量的事件数据,特别是低延迟的日志数据。卡夫卡系统的体系结构相对比较简单,只由一组个体的经纪人集群节点构成了卡夫卡。数据流是由主题,这是一个流相关的信息,消费者可以订阅。主题分为分区分布在代理实例的检索使用拉力机制相应的消息。作业执行的基本流程是呈现在图6。
表1和2现在简要比较分析这些框架基于一些共同的属性。如表所示,MapReduce计算数据流阶段没有循环链。在每个阶段,项目收益与前一个阶段的输出并生成一个输入为下一个阶段。虽然机器学习算法大多是循环数据流的形式设计,火花,风暴,Samza代表有向无环图优化执行计划。Flink支持在运行时控制循环依赖图来表示机器学习算法在一个非常有效的方法。Hadoop和风暴不提供任何默认的互动环境。Apache火花有命令行交互式shell使用应用程序的特性。Flink Scala提供了一个shell配置独立以及集群设置。Apache Hadoop是高度可伸缩的,它被用于雅虎在20纱生产42000个节点组成的集群。目前已知的最大的集群大小的火花是8000年计算节点,而风暴一直在测试300节点集群。 Apache Samza cluster, with around a hundred nodes, has been used in LinkedIn data flow and application messaging system. Apache Flink has been customized for Alibaba search engine with a deployment capacity of thousands of processing nodes.
3所示。大数据的比较评价框架
大数据在云计算中,一个受欢迎的研究趋势,对当前企业构成重要影响,行业,研究社区。有很多破坏性的变革,大数据技术和解决方案迅速发出和演变为了提供数据驱动的洞察力和创新能力。此外,现代云计算服务提供各种各样的大数据分析工具,技术,和计算基础设施加快数据分析过程在一个负担得起的成本。虽然现在有许多分布式资源管理框架,主要问题是如何选择一个合适的大数据框架。一个大数据平台的选择对别人会到特定的应用程序需求和约束可能包括几个权衡和应用程序使用场景。不过,我们可以确定一些关键因素需要满足之前部署一个大数据应用程序在云中。在本节中,根据可获得的一些经验证据文学,我们讨论每个资源管理框架的优点和缺点。
3.1。处理速度
处理速度是一个重要的性能测量,可用于评估不同的资源管理框架的有效性。这是一种常见的指标为I / O操作的最大数量磁盘或内存或计算单元之间的数据传输速率的集群在一个特定的时间。基于大数据的背景下,平均处理速度表示为 ,计算后迭代运行,最大内存/磁盘密集型操作可以在一个时间间隔 : Veiga et al。30.)进行了一系列的实验演示性能结果的多核集群设置Apache Hadoop,火花,Flink。Apache火花和Flink导致更有效的执行平台Hadoop在执行nonsort基准。进一步指出,火花显示结果等操作WordCount和更好的性能——(自然界中中央处理器受限),而Flink在网页排名算法取得更好的结果(内存绑定在本质上)。坐在和Karatza31日Apache Hadoop]实验相比性能统计数据和火花Okeanos IaaS云平台它。每组实验中,必要的统计数据与执行时间,节点工作,记录的数据集大小。火花性能被发现最优比Hadoop的病例。此外,火花在纱平台显示,次优的结果相比,在独立模式下执行的时候。一些类似的结果也观察到Zaharia et al。32在一个100 GB的数据记录。Vellaipandiyan和拉贾33]证明了绩效评估和比较的Hadoop和火花框架居民的记录数据集从100 GB 900 GB的大小。火花的规模之间的性能相对更好的数据集的大小是中小型(100 g - 750 g);后来,Hadoop相比其性能下降。性能下降的主要原因是明显的火花缓存大小的内存不能适应更大的数据集。Taran et al。34Hadoop的量化性能差异和火花使用WordCount数据集从100 KB到1 GB。观察到Hadoop框架是5倍火花评价时使用一个更大的组执行数据源。然而,对于较小的任务,火花表现出更好的性能结果。然而,这两个数据库的加速率减少输入数据集的增长。
Gopalani和Arora35)使用则算法在一些小型、中型和大型位置数据集比较Hadoop和火花框架。研究结果表明,火花三倍比执行MapReduce的病例。据et al。36)进行实验评估Apache Flink和风暴Amazon EC2云上使用大型基因组数据集数据。Apache Flink优于风暴而执行直方图和地图操作而风暴优于Flink虽然基因组加入应用程序部署。
3.2。容错
容错特性,使系统继续运作的一个或多个组件的失败。高性能计算应用程序涉及数百个节点相互连接,从而执行一个特定任务;失败应该零个或一个节点对整体计算的影响很小。系统的公差,表示为 ,满足其需求中断后的比值时间来完成任务没有观察故障事件的整体执行时间,一些故障事件检测和系统状态回归到一致状态: 在哪里是正确估计执行时间从一个程序运行假定是绝对没错的,或平均执行时间从几个应用程序运行时,产生一个已知的正确输出,然后呢代表了方差在程序执行的时间由于故障事件的发生。HPC应用程序由一组的计算密集型任务 由于为每个单独的计算任务 ,然后整个应用程序的弹性, ,不得计算(37] 陆et al。38]StreamBench工具包用于评估性能和容错能力的Apache火花,风暴,火花,Samza。发现,数据量增加,引发更稳定和容错风暴,但可能Samza相比,效率较低。此外,相比而言,处理大容量的数据,Samza和火花优于风暴。顾和李39)使用Hadoop PageRank算法进行对比实验,火花框架。观察到,对于较小的数据集,如wiki-Vote soc-Slashdot0902,火花优于Hadoop与一个更好的利润。然而,这种加速退化数据集的发展结果,对于大型数据集来说,Hadoop容易表现火花。此外,大量大型数据集,火花被报道与JVM堆例外而坠毁Hadoop仍执行其任务。洛佩兹et al。40)评估吞吐量和Apache风暴和Flink的容错机制。实验是基于Apache风暴威胁检测系统,展示了更好的吞吐量Flink相比。不同虚拟机容错,手动关闭来分析节点故障的影响。Apache Flink利用其内部子系统检测和失败的任务迁移到其他机器,因此导致损失很少的消息。另一方面,风暴花了更多的时间作为管理员,涉及一些性能开销,负责报告的灵气和其后处理失败的任务在其他节点上。
3.3。可伸缩性
可伸缩性是指能够容纳大量负载或改变的大小/工作负载在运行时通过提供资源。这可以进一步分为扩大(通过硬件强)或降低(通过添加额外的节点)。企业的关键需求之一是处理大量数据的及时解决高价值业务问题。动态资源的可扩展性允许业务实体执行大量并行计算,从而降低总体时间,复杂性,和努力。可伸缩性的定义来自阿姆和Gustafson定律(41]。让之前工作负载的大小的改善系统资源;执行工作负载的分数提高系统资源的好处和分数有关的部分不会受益于改善资源 。当使用一个处理器系统,用户工作负载比例 并行执行时间的工作负载在处理器被定义为scaled-workload加速所示 Garcia-Gil et al。42)执行的可伸缩性和性能比较,Apache火花和Flink使用特征选择框架组装多个信息到一个贪婪算法的理论标准。ECBDL14数据集被用来测量框架的可伸缩性因素。是观察火花可伸缩性性能比Flink快十倍。Jakovits和Srirama43]分析了基于四MapReduce框架包括Hadoop和火花基准Medoids分区,聚类大型应用程序,并使用MPI共轭梯度线性系统求解算法。所有实验进行33 Amazon EC2云大实例。对所有算法,火花表现更好的Hadoop相比,在性能和可伸缩性。博登et al。44]目的探讨可伸缩性对数据大小和维度为了证明一个公平和洞察力的基准反映真实的机器学习应用程序的要求。分布式优化算法的基准是由监督学习和无监督学习算法。监督学习,他们实现了机器学习算法通过使用风库,而对于无监督学习他们选择了流行聚类算法则为了评估两个资源管理框架的可伸缩性。Flink是相对较低的总体执行时间与数量有限的节点资源受限的设置,而引发了一次明显的优势足够的可用内存是由于添加新的计算节点。
3.4。机器学习和迭代任务的支持
大数据的应用程序在本质上是复杂的,通常包括任务和算法迭代。这些应用程序有不同的自然循环来实现所需的结果通过不断重复的一组任务,直到这些不能进一步大幅减少。
Spangenberg et al。45使用真实的数据集,包括四个算法,也就是说,WordCount,则,PageRank和关系查询,基准Apache Flink和风暴。这是观察到Apache风暴在批处理模式而Flink表现更好。然而,面对不断增加的复杂性,Apache Flink风暴性能优势,因而它是更适合迭代数据或图像处理。施等。46)重点分析Apache MapReduce和火花的批处理和迭代工作。对于较小的数据集,引发了一个更好的选择,但当实验进行更大的数据集,MapReduce是几倍的火花。对于迭代等操作则,火花变成了1.5倍比MapReduce的第一次迭代,当火花超过5倍在后续操作。
康和李47)检查5个资源管理框架包括Apache Hadoop和火花对性能开销(磁盘输入/输出、网络通信、调度,等等)在支持迭代计算。PageRank算法被用来评估这些性能问题。由于静态数据处理往往是更频繁的操作比动态数据用于MapReduce的每个迭代,它可能会导致显著的性能开销MapReduce。另一方面,Apache火花使用只读缓存版本的对象(弹性分布式数据集),可以重用并行操作,从而减少迭代计算期间的性能开销。李等人。48)评估五个系统包括Hadoop和火花在各种工作负载比较四迭代算法。实验是在亚马逊EC2的云。总的来说,火花显示最佳的性能在迭代操作在内存中执行。相比之下,Hadoop的表现明显差比其他资源管理系统。
3.5。延迟
大数据和低延迟息息相关。大数据的应用程序提供企业真实价值,但这些大多是至关重要的。如果云计算已经成功实现大数据平台,一个关键的要求将高速网络的供应减少通信延迟。此外,大数据的框架通常涉及集中设计的调度分配所有任务通过单个节点可能显著影响大小的数据时的延迟是巨大的。
让之间的运行时间程序的开始和完成时间在一个分布式架构,有效的执行时间,是总空闲单位的总和处理器从一组处理器。然后,平均延迟,表示为 对于工作负载的大小 ,被定义为每个处理器的平均所需的开销时间完成任务: Chintapalli et al。49)进行了详细的分析Apache的风暴,Flink和火花流引擎延迟和吞吐量。研究结果表明,高吞吐量,Flink和风暴相比显著降低延迟火花。然而,火花是能够处理高吞吐量相比其他流媒体引擎。陆et al。38]提出StreamBench基准框架来评估现代分布式流处理框架。框架包括数据选择、数据生成方法、程序集描述,工作负载套房设计,和公制的命题。两个真实数据集,AOL搜索数据和互联网CAIDA匿名跟踪数据集,被用来评估性能、可伸缩性和容错方面的流媒体框架。观察到风暴的延迟在大多数情况下是远远低于火花的除了在当工作负载和数据集的尺度是巨大的。
3.6。安全
而不是古典的高性能计算环境,信息存储内部,许多大数据应用程序现在越来越多地部署在云隐私信息可能由不同的数据访问或记录用户轻松。尽管数据隐私和安全问题并不是一个新话题在分布式计算领域,其重要性被广泛采用放大为大数据的云计算服务平台。数据集可能会接触到多个用户不同的目的可能导致安全和隐私风险。
让是一个安全类别列表,可能提供的安全机制。例如,框架可以使用加密机制提供数据安全性和访问控制列表进行身份验证和授权服务。让被分配到的最大重量安全类别的列表类别和是一个特定的资源管理框架的声誉评分。然后,框架可以表示成安全排名分数 Hadoop和风暴使用Kerberos身份验证协议计算节点来提供他们的身份(50]。火花采用基于密码的共享密钥配置以及访问控制列表(acl)来控制身份验证和授权机制。在Flink,流经纪人负责跨多个服务提供身份验证机制。Apache Samza /卡夫卡不提供内置的安全功能在系统水平。
3.7。数据集大小支持
许多科学应用扩大到数百个节点来处理大量的数据,可能超过几百字节。除非大数据应用程序正确地优化了更大的数据集,这可能导致性能下降的增长数据。此外,在许多情况下,这可能会导致软件崩溃,导致时间和金钱的损失。我们使用相同的方法来收集大数据支持统计信息正如前面提出的部分。
4所示。讨论大数据框架
每一个大数据框架已经进化以其独特的设计特点和特定于应用程序的需求。基于关键因素和他们的经验证据来评估大数据框架,作为讨论的部分3七,我们生产的总结结果评价因素的形式明星排名 ,在那里代表了最大的评价分数。的一般方程产生排名,每个资源框架(RF),给出 在哪里研究的总数为一组特定的评价指标, 分配给每个相对规范化的重量是文学研究基于实验的数量,然后呢框架试验台的分数计算从每个研究的实验结果。
Hadoop MapReduce有一个明显的优势在大规模部署和大数据集的处理。Hadoop是高度兼容和互操作与其他框架。它还提供了一个可靠的容错机制提供无故障机制在很长一段时间。Hadoop可以操作一个低成本的配置。但是,Hadoop是不适合实时应用程序。它有一个显著的缺点当延迟、吞吐量和迭代工作支持机器学习应用程序需求的关键因素。
Apache火花是设计为替代的批量Hadoop生态系统超过篇幅的静态和实时数据集。它非常适合高吞吐量流媒体应用延迟不是一个主要问题。火花是内存密集型和所有操作发生在内存中。因此,它可能会崩溃,如果没有足够的内存可用作进一步的操作(火花版本1.5的发布之前,它没有能力处理数据集比大小的内存和处理更大的数据集的问题仍然持续在更新版本具有不同性能开销)。一些研究工作,如钨项目,旨在解决引发应用程序的内存和CPU的效率。火花也缺乏自己的存储系统通过集成HDFS纱或使用便卡桑德拉是一个额外的开销集群配置。
Apache Flink是一个真正的流引擎。Flink既支持批处理和实时操作在一个共同的运行时实现λ架构的需求。然而,它也可能在批处理模式下工作,停止流源。像火花,Flink执行所有操作在内存中,但是在内存占用的情况下,它也可能使用磁盘存储,以避免应用程序失败。Flink Hadoop一些重大优势,引发了提供更好支持迭代处理高吞吐量低延迟的成本。
Apache风暴旨在提供一个可伸缩、容错、实时流数据分析引擎,Hadoop的批处理。然而,实证证据表明,Apache风暴被证明是低效的,以满足扩大/缩小的实时大数据应用的要求。此外,由于它使用microbath流处理,它并不是很有效的连续流过程是一个大问题,也没有提供一个简单的批处理的机制。容错,风暴使用管理员存储过程的状态,可能需要一些额外的开销,也可能造成信息损失。另一方面,风暴是一个理想的解决方案为近实时应用程序处理,可以处理工作负载最小延迟延迟有严格要求的。
Apache Samza,在卡夫卡的集成,提供了一些独特的功能,不提供其他流处理引擎。Samza提供了一个强大的基于检查点的容错机制以最小的数据丢失。Samza工作可以有高吞吐量和低延迟时,结合卡夫卡。然而,Samza缺乏一些重要特性作为数据处理引擎。此外,它并没有提供内置的数据访问控制的安全机制。
分类的选择最好的资源引擎基于一组特定的需求,我们使用钟等提出的框架。51]。匹配的框架提供了一个布局,排名,并选择一个系统基于一些特定的需求。匹配的标准是基于用户目标分为软、硬目标。软目标表示系统的非功能需求(如安全性、容错性和可扩展性)而努力目标是系统的功能方面(如机器学习和数据大小支持)。系统组件之间的关系和目标可以列为非常积极的(+ +),阳性(+)、负(−),非常消极的(−−)。从文学,提供基于证据的分类主要资源管理框架呈现在图7。
5。相关工作
我们的研究工作不同于其他努力因为主题的目标和研究对象并不相同,我们提供了一个深入的比较流行的资源引擎基于现有文献的经验证据。黑森州和洛伦兹8流处理系统进行了一个概念性的调查。然而,他们的讨论集中在一些基本的差异与实时数据处理引擎。辛格和Reddy9)提供了一个深入分析大数据分析平台,包括点对点网络,现场可编程门阵列(FPGA), Apache Hadoop生态系统,高性能计算(HPC)集群、多核CPU和图形处理单元(GPU)。我们的案例中是不同的在这里我们特别感兴趣的大数据处理引擎。最后,Landset et al。10)专注于机器学习库和评估基于易用性、可伸缩性和可扩展性。然而,我们的工作不同于他们的工作,这两项研究的主要重点是不相同的。
陈和张11讨论大数据问题,挑战,和相关的技能和技术,以解决这些问题。几个潜在的技术包括云计算、量子计算、细粒度的计算和生物计算研究和可能的机会去探索这些领域。然而,只讨论了绩效评价的理论依据。的分类和详细分析艺术的状态在[2.0大数据处理系统提出了12]。这项研究的重点是识别当前研究的挑战和强调创新和优化的机会为未来的研究和发展。Assuncao et al。13回顾了几代人的数据流处理框架,提供资源弹性机制匹配流处理服务的要求。研究调查了挑战与有效的资源管理决策和建议的解决方案来自现有的研究。然而,研究指标仅限于弹性/大数据流框架的可伸缩性方面。
如表所示3我们的工作不同于之前的研究,集中在资源管理框架的分类理论。与之前的方法相比,我们分类和分类大数据资源管理框架基于经验为由,来自多个评估/实验研究。此外,我们的评估/排名方法是基于全面的研究变量的列表没有解决的研究。
6。结论和未来的工作
有很多破坏性的变革,大数据技术和解决方案迅速发出和演变为了提供数据驱动的洞察力和创新能力。这项研究的主要对象是如何流行的大数据资源管理系统进行分类。本研究也针对解决候选资源提供者的选择基于特定的大数据应用需求。我们调查了不同的大数据资源管理框架和研究他们每个人的优点和缺点。我们进行资源管理引擎的性能评估基于七个关键因素和每一个框架排名基于文献的经验证据。
6.1。观察和发现
一些研究的主要结论如下:(我)在处理速度方面,Apache Flink优于其他资源管理框架为小型,中型和大型数据集(30.,36]。然而,在我们的实验在Amazon EC2上集群与多样的任务管理器设置每个节点)(1 - 4任务经理,Flink未能完成自定义尺寸小一点的JVM数据集工作由于Flink低效的内存管理,内存管理器。我们找不到任何报道的证据这一特定用例在这些相关文献研究。似乎大部分的绩效评估研究使用标准基准测试集数据集规模相对较大,因此这一特定用例没有在这些研究报道。进一步的研究需要阐明底层在这种特定情况下的特定因素。(2)大数据应用程序通常涉及到大量的数据。Apache火花支持容错机制的必要策略,但据报道崩溃更大的数据集。即使在我们的实验,Apache火花version 1.6(选择由于兼容性的原因与早期研究)撞几次数据集时超过500 GB。尽管火花排名更高的容错随着数据规模的增加几项研究[38,52),限制在处理较大的典型的大数据集应用程序,因此这类研究不能通用。(3)火花MLlib Flink-ML提供各种各样的机器学习算法和工具开发分布式和可伸缩的大数据应用程序。火花MLlib优于Flink-ML在大多数机器学习用例(42),除了在重复的情况下通过改变数据上执行。然而,这种绩效评估可能会进一步调查等研究[53),报道不同Flink比火花在足够大的情况下。(iv)等图像处理算法的PageRank, Flink使用葛里炸药库,提供本地闭环迭代运算符,使其成为适合大规模图分析的平台。火花,另一方面,使用GraphX图书馆有更长的预处理时间来建立图形和其他数据结构,使其性能更糟比Apache Flink。Apache Flink报道获得最好的结果进行图形处理数据集(3 x-5x [54和2 x-3x45])与火花。然而,一些研究如(55]报道火花为大1.7倍的速度比Flink图处理。这种不一致的行为可能会在未来进一步调查研究。
6.2。未来的工作
在大数据领域,仍有明显差距,需要更多的努力研究社区建设的深入理解大数据资源管理框架的性能特征。我们认为这项研究一步扩大我们的知识理解大数据世界,提供了一个努力改进的方向大视觉艺术的状态,实现在大数据领域。在早期的研究中,一个明确的排名无法建立作为研究参数大多是有限的几个问题如吞吐量、延迟和机器学习。此外,需要进一步调查等资源引擎Apache Samza相比与其他框架。此外,需要在多个领域开展研究工作如数据组织、平台特定的工具和技术问题在大数据领域为了创建下一代大数据基础设施。绩效评估因素也可能不同系统之间根据使用的算法。作为未来的工作,我们计划基准这些受欢迎的资源引擎满足资源需求和要求不同的科学应用。此外,可伸缩性能做分析。特别是添加动态的绩效评估工作节点和由此产生的性能分析的特殊利益。此外,可进行进一步的研究,以评估性能方面对就业之间的资源竞争等不同的研究调度器(纱和便),可用计算资源的波动。 Finally, most of the experimentations in earlier studies were performed using standard parameter configurations; however, each resource management framework offers domain specific tweaks and configuration optimization mechanisms for meeting application-specific requirements. The development of a benchmark suite that aims to find maximum throughput based on configuration optimization would be an interesting direction of future research.
的利益冲突
作者宣称没有利益冲突。