大数据框架对比.docx

文档介绍：该【大数据框架对比 】是由【非学无以广才】上传分享，文档一共【16】页，该文档可以免费在线阅读，需要了解更多关于【大数据框架对比 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。简介
大数据是收集、整顿、解决大容量数据集,并从中获得见解所需的非老式战略和技术的总称。虽然解决数据所需的计算能力或存储容量早已超过一台计算机的上限,但这种计算类型的普遍性、规模,以及价值在近来几年才经历了大规模扩展。
在之前的文章中,我们曾经简介过有关大数据系统的常规概念、解决过程,以及多种专门术语,本文将简介大数据系统一种最基本的组件:解决框架。解决框架负责对系统中的数据进行计算,例如解决从非易失存储中读取的数据,或解决刚刚摄入到系统中的数据。数据的计算则是指从大量单一数据点中提取信息和见解的过程。
下文将简介这些框架:
仅批解决框架:
ApacheHadoop
仅流解决框架:
ApacheStorm
ApacheSamza
混合框架:
ApacheSpark
Apache Flink
大数据解决框架是什么?
解决框架和解决引擎负责对数据系统中的数据进行计算。虽然“引擎”和“框架”之间的区别没有什么权威的定义,但大部分时候可以将前者定义为实际负责解决数据操作的组件,后者则可定义为承当类似作用的一系列组件。
例如ApacheHadoop可以看作一种以MapReduce作为默认解决引擎的解决框架。引擎和框架一般可以互相替代或同步使用。例如另一种框架ApacheSpark可以纳入Hadoop并取代MapReduce。组件之间的这种互操作性是大数据系统灵活性如此之高的因素之一。
虽然负责解决生命周期内这一阶段数据的系统一般都很复杂,但从广义层面来看它们的目的是非常一致的:通过对数据执行操作提高理解能力,揭示出数据蕴含的模式,并针对复杂互动获得见解。
为了简化这些组件的讨论,我们会通过不同解决框架的设计意图,按照所解决的数据状态对其进行分类。某些系统可以用批解决方式解决数据,某些系统可以用流方式解决持续不断流入系统的数据。此外尚有某些系统可以同步解决这两类数据。
在进一步简介不同实现的指标和结论之前,一方面需要对不同解决类型的概念进行一种简朴的简介。
批解决系统
批解决在大数据世界有着悠久的历史。批解决重要操作大容量静态数据集,并在计算过程完毕后返回成果。
批解决模式中使用的数据集一般符合下列特性...
有界:批解决数据集代表数据的有限集合
持久:数据一般始终存储在某种类型的持久存储位置中
大量:批解决操作一般是解决极为海量数据集的唯一措施
批解决非常适合需要访问全套记录才干完毕的计算工作。例如在计算总数和平均数时,必须将数据集作为一种整体加以解决,而不能将其视作多条记录的集合。这些操作规定在计算进行过程中数据维持自己的状态。
需要解决大量数据的任务一般最适合用批解决操作进行解决。无论直接从持久存储设备解决数据集,或一方面将数据集载入内存,批解决系统在设计过程中就充足考虑了数据的量,可提供充足的解决资源。由于批解决在应对大量持久数据方面的体现极为杰出,因此常常被用于对历史数据进行分析。
大量数据的解决需要付出大量时间,因此批解决不适合对解决时间规定较高的场合。
ApacheHadoop
ApacheHadoop是一种专用于批解决的解决框架。Hadoop是首个在开源社区获得极大关注的大数据框架。基于google有关海量数据解决所刊登的多篇论文与经验的Hadoop重新实现了有关算法和组件堆栈,让大规模批解决技术变得更易用。
新版Hadoop涉及多种组件,即多种层,通过配合使用可解决批数据:
HDFS:HDFS是一种分布式文献系统层,可对集群节点间的存储和复制进行协调。HDFS保证了无法避免的节点故障发生后数据仍然可用,可将其用作数据来源,可用于存储中间态的解决成果,并可存储计算的最后成果。
YARN:YARN是YetAnotherResourceNegotiator(另一种资源管理器)的缩写,可充当Hadoop堆栈的集群协调组件。该组件负责协调并管理底层资源和调度作业的运营。通过充当集群资源的接口,YARN使得顾客能在Hadoop集群中使用比以往的迭代方式运营更多类型的工作负载。
MapReduce:MapReduce是Hadoop的原生批解决引擎。
批解决模式
Hadoop的解决功能来自MapReduce引擎。MapReduce的解决技术符合使用键值对的map、shuffle、reduce算法规定。基本解决过程涉及:
从HDFS文献系统读取数据集
将数据集拆提成小块并分派给所有可用节点
针对每个节点上的数据子集进行计算(计算的中间态成果会重新写入HDFS)
重新分派中间态成果并按照键进行分组
通过对每个节点计算的成果进行汇总和组合对每个键的值进行“Reducing”
将计算而来的最后成果重新写入HDFS
优势和局限
由于这种措施严重依赖持久存储,每个任务需要多次执行读取和写入操作,因此速度相对较慢。但另一方面由于磁盘空间一般是服务器上最丰富的资源,这意味着MapReduce可以解决非常海量的数据集。同步也意味着相比其她类似技术,Hadoop的MapReduce一般可以在便宜硬件上运营,由于该技术并不需要将一切都存储在内存中。MapReduce具有极高的缩放潜力,生产环境中曾经浮现过涉及数万个节点的应用。
MapReduce的学****曲线较为陡峭,虽然Hadoop生态系统的其她周边技术可以大幅减少这一问题的影响,但通过Hadoop集群迅速实现某些应用时仍然需要注意这个问题。
环绕Hadoop已经形成了广阔的生态系统,Hadoop集群自身也常常被用作其她软件的构成部件。诸多其她解决框架和引擎通过与Hadoop集成也可以使用HDFS和YARN资源管理器。
总结
ApacheHadoop及其MapReduce解决引擎提供了一套久经考验的批解决模型,最适合解决对时间规定不高的非常大规模数据集。通过非常低成本的组件即可搭建完整功能的Hadoop集群,使得这一便宜且高效的解决技术可以灵活应用在诸多案例中。与其她框架和引擎的兼容与集成能力使得
Hadoop可以成为使用不同技术的多种工作负载解决平台的底层基本。
流解决系统
流解决系统会对随时进入系统的数据进行计算。相比批解决模式,这是一种截然不同的解决方式。流解决方式无需针对整个数据集执行操作,而是对通过系统传播的每个数据项执行操作。
流解决中的数据集是“无边界”的,这就产生了几种重要的影响:
完整数据集只能代表截至目前已经进入到系统中的数据总量。
工作数据集也许更有关,在特定期间只能代表某个单一数据项。
解决工作是基于事件的,除非明确停止否则没有“尽头”。解决成果立即可用,并会随着新数据的达到继续更新。
流解决系统可以解决几乎无限量的数据,但同一时间只能解决一条(真正的流解决)或很少量(微批解决,Micro-batchProcessing)数据,不同记录间只维持至少量的状态。虽然大部分系统提供了用于维持某些状态的措施,但流解决重要针对副作用更少,更加功能性的解决(Functionalprocessing)进行优化。
功能性操作重要侧重于状态或副作用有限的离散环节。针对同一种数据执行同一种操作会或略其她因素产生相似的成果,此类解决非常适合流解决,由于不同项的状态一般是某些困难、限制,以及某些状况下不需要的成果的结合体。因此虽然某些类型的状态管理一般是可行的,但这些框架一般在不具有状态管理机制时更简朴也更高效。
此类解决非常适合某些类型的工作负载。有近实时解决需求的任务很适合使用流解决模式。分析、服务器或应用程序错误日记,以及其她基于时间的衡量指标是最适合的类型,由于对这些领域的数据变化做出响应对于业务职能来说是极为核心的。
流解决很适合用来解决必须对变动或峰值做出响应,并且关注一段时间内变化趋势的数据。
ApacheStorm
ApacheStorm是一种侧重于极低延迟的流解决框架,也许是规定近实时解决的工作负载的最佳选择。该技术可解决非常大量的数据,通过比其她解决方案更低的延迟提供成果。
流解决模式
Storm的流解决可对框架中名为Topology(拓扑)的DAG(DirectedAcyclicGraph,有向无环图)进行编排。这些拓扑描述了当数据片段进入系统后,需要对每个传入的片段执行的不同转换或环节。
拓扑涉及:
Stream:一般的数据流,这是一种会持续达到系统的无边界数据。
Spout:位于拓扑边沿的数据流来源,例如可以是API或查询等,从这里可以产生待解决的数据。
Bolt:Bolt代表需要消耗流数据,对其应用操作,并将成果以流的形式进行输出的解决环节。Bolt需要与每个Spout建立连接,随后互相连接以构成所有必要的解决。在拓扑的尾部,可以使用最后的Bolt输出作为互相连接的其她系统的输入。
Storm背后的想法是使用上述组件定义大量小型的离散操作,随后将多种组件构成所需拓扑。默认状况下Storm提供了“至少一次”的解决保证,这意味着可以保证每条消息至少可以被解决一次,但某些状况下如果遇到失败也许会解决多次。Storm无法保证可以按照特定顺序解决消息。
为了实现严格的一次解决,即有状态解决,可以使用一种名为Trident的抽象。严格来说不使用Trident的Storm一般可称之为CoreStorm。Trident会对Storm的解决能力产生极大影响,会增长延迟,为解决提供状态,使用微批模式替代逐项解决的纯正流解决模式。
为避免这些问题,一般建议Storm顾客尽量使用Core Storm。然而也要注意,Trident对内容严格的一次解决保证在某些状况下也比较有用,例如系统无法智能地解决反复消息时。如果需要在项之间维持状态,例如想要计算一种小时内有多少顾客点击了某个链接,此时Trident将是你唯一的选择。尽管不能充足发挥框架与生俱来的优势,但Trident提高了Storm的灵活性。
Trident拓扑涉及:
流批(Streambatch):这是指流数据的微批,可通过度块提供批解决语义。
操作(Operation):是指可以对数据执行的批解决过程。
优势和局限
目前来说Storm也许是近实时解决领域的最佳解决方案。该技术可以用极低延迟解决数据,可用于但愿获得最低延迟的工作负载。如果解决速度直接影响顾客体验,例如需要将解决成果直接提供应访客打开的网站页面,此时Storm将会是一种较好的选择。
Storm与Trident配合使得顾客可以用微批替代纯正的流解决。虽然借此顾客可以获得更大灵活性打造更符合规定的工具,但同步这种做法会削弱该技术相比其她解决方案最大的优势。话虽如此,但多一种流解决方式总是好的。
CoreStorm无法保证消息的解决顺序。CoreStorm为消息提供了“至少一次”的解决保证,这意味着可以保证每条消息都能被解决,但也也许发生反复。Trident提供了严格的一次解决保证,可以在不同批之间提供顺序解决,但无法在一种批内部实现顺序解决。
在互操作性方面,Storm可与Hadoop的YARN资源管理器进行集成,因此可以很以便地融入既有Hadoop部署。除了支持大部分解决框架,Storm还可支持多种语言,为顾客的拓扑定义提供了更多选择。
总结
对于延迟需求很高的纯正的流解决工作负载,Storm也许是最适合的技术。该技术可以保证每条消息都被解决,可配合多种编程语言使用。由于Storm无法进行批解决,如果需要这些能力也许还需要使用其她软件。如果对严格的一次解决保证有比较高的规定,此时可考虑使用Trident。但是这种状况下其她流解决框架也许更适合。
ApacheSamza
Apache Samza是一种与ApacheKafka消息系统紧密绑定的流解决框架。虽然Kafka可用于诸多流解决系统,但按照设计,Samza可以更好地发挥Kafka独特的架构优势和保障。该技术可通过Kafka提供容错、缓冲,以及状态存储。
Samza可使用YARN作为资源管理器。这意味着默认状况下需要具有Hadoop集群(至少具有HDFS和YARN),但同步也意味着Samza可以直接使用YARN丰富的内建功能。
流解决模式
Samza依赖Kafka的语义定义流的解决方式。Kafka在解决数据时波及下列概念:
Topic(话题):进入Kafka系统的每个数据流可称之为一种话题。话题基本上是一种可供消耗方订阅的,由有关信息构成的数据流。
Partition(分区):为了将一种话题分散至多种节点,Kafka会将传入的消息划分为多种分区。分区的划分将基于键(Key)进行,这样可以保证涉及同一种键的每条消息可以划分至同一种分区。分区的顺序可获得保证。
Broker(代理):构成Kafka集群的每个节点也叫做代理。
Producer(生成方):任何向Kafka话题写入数据的组件可以叫做生成方。生成方可提供将话题划分为分区所需的键。
Consumer(消耗方):任何从Kafka读取话题的组件可叫做消耗方。消耗方需要负责维持有关自己分支的信息,这样即可在失败后懂得哪些记录已经被解决过了。
由于Kafka相称于永恒不变的日记,Samza也需要解决永恒不变的数据流。这意味着任何转换创立的新数据流都可被其她组件所使用,而不会对最初的数据流产生影响。
优势和局限
乍看之下,Samza对Kafka类查询系统的依赖似乎是一种限制,然而这也可觉得系统提供某些独特的保证和功能,这些内容也是其她流解决系统不具有的。
例如Kafka已经提供了可以通过低延迟方式访问的数据存储副本,此外还可觉得每个数据分区提供非常易用且低成本的多订阅者模型。所有输出内容,涉及中间态的成果都可写入到Kafka,并可被下游环节独立使用。
这种对Kafka的紧密依赖在诸多方面类似于MapReduce引擎对HDFS的依赖。虽然在批解决的每个计算之间对HDFS的依赖导致了某些严重的性能问题,但也避免了流解决遇到的诸多其她问题。
Samza与Kafka之间紧密的关系使得解决环节自身可以非常松散地耦合在一起。无需事先协调,即可在输出的任何环节中增长任意数量的订阅者,对于有多种团队需要访问类似数据的组织,这一特性非常有用。多种团队可以所有订阅进入系统的数据话题,或任意订阅其她团队对数据进行过某些解决后创立的话题。这一切并不会对数据库等负载密集型基本架构导致额外的压力。
直接写入Kafka还可避免回压(Backpressure)问题。回压是指当负载峰值导致数据流入速度超过组件实时解决能力的状况,这种状况也许导致解决工作停止并也许丢失数据。按照设计,Kafka可以将数据保存很长时间,这意味着组件可以在以便的时候继续进行解决,并可直接重启动而无需紧张导致任何后果。
Samza可以使用以本地键值存储方式实现的容错检查点系统存储数据。这样Samza即可获得“至少一次”的交付保障,但面对由于数据也许多次交付导致的失败,该技术无法对汇总后状态(例如计数)提供精确恢复。
Samza提供的高档抽象使其在诸多方面比Storm等系统提供的基元(Primitive)更易于配合使用。目前Samza只支持JVM语言,这意味着它在语言支持方面不如Storm灵活。
总结
对于已经具有或易于实现Hadoop和Kafka的环境,ApacheSamza是流解决工作负载一种较好的选择。Samza自身很适合有多种团队需要使用(但互相之间并不一定紧密协调)不同解决阶段的多种数据流的组织。Samza可大幅简化诸多流解决工作,可实现低延迟的性能。如果部署需求与目前系统不兼容,也许并不适合使用,但如果需要极低延迟的解决,或对严格的一次解决语义有较高需求,此时仍然适合考虑。
混合解决系统:批解决和流解决
某些解决框架可同步解决批解决和流解决工作负载。这些框架可以用相似或有关的组件和API解决两种类型的数据,借此让不同的解决需求得以简化。
如你所见,这一特性重要是由Spark和Flink实现的,下文将简介这两种框架。实现这样的功能重点在于两种不同解决模式如何进行统一,以及要对固定和不固定数据集之间的关系进行何种假设。