流式计算领域新霸主Flink的那些事儿

  • 时间:
  • 浏览:1
  • 来源:5分3D官方_极速5分排列5

在大数据补救领域,批补救与流补救一般被认为是一种生活截然不同的任务,一另俩个大数据框架一般会被设计为这麼补救其中一种生活任务。比如,Storm只支持流补救任务,而MapReduce、Spark只支持批补救任务。Spark Streaming是Apache Spark之上支持流补救任务的子系统,这看似是一另俩个特例,虽然 不然——Spark Streaming采用了一种生活Micro-Batch架构,即把输入的数据流切分成细粒度的Batch,并为每一另俩个Batch数据提交一另俩个批补救的Spark任务,本来Spark Streaming本质上还是基于Spark批补救系统对流式数据进行补救,和Storm等全版流式的数据补救辦法 全版不同。通过灵活的执行引擎,Flink才能并肩支持批补救任务与流补救任务。在执行引擎层级,流补救系统与批补救系统最大的不同在于节点间的数据传输辦法 。如图1.3所示,对于一另俩个流补救系统,其节点间数据传输的标准模型是,在补救完成十根数据后,将其序列化到缓存中,并立刻通过网络传输到下一另俩个节点,由下一另俩个节点继续补救。而对于一另俩个批补救系统,其节点间数据传输的标准模型是,在补救完成十根数据后,将其序列化到缓存中,当缓存写满时,就持久化到本地硬盘上;在所有数据都被补救完成后,才结速英文将其通过网络传输到下一另俩个节点。

Storm是比较早的流式计算框架,本来又经常出现了Spark Streaming和Trident,现在又经常出现了Flink什儿 优秀的实时计算框架,这麼这几种计算框架到底有什儿 区别呢?下面许多人来全版分析一下,如表1.1所示。

Flink在如下类型的公司暗含具体的应用。

Flink主要应用于流式数据分析场景,目前涉及如下领域。

Flink入门与实战

前面许多人分析了3种实时计算框架,这麼公司在实际操作时到底取舍哪种技术框架呢?下面许多人来分析一下。

徐葳

Flink主要由Java代码实现,它并肩支持实时流补救和批补救。对于Flink而言,作为一另俩个流补救框架,批数据本来流数据的一另俩个极限特例而已。此外,Flink还支持迭代计算、内存管理和程序运行池池优化,这是它的原生型态。

图1.1 Flink的功能型态

由图1.1可知,Flink的功能型态如下。

Flink项目是大数据计算领域冉冉升起的一颗新星。大数据计算引擎的发展经历了几次过程,从第1代的MapReduce,到第2代基于有向无环图的Tez,第3代基于内存计算的Spark,再到第4代的Flink。可能Flink可不才能基于Hadoop进行开发和使用,本来Flink何必 会取代Hadoop,本来和Hadoop紧密结合。Flink主要包括DataStream API、DataSet API、Table API、SQL、Graph API和FlinkML等。现在Flink可不才能当事人的生态圈,涉及离线数据补救、实时数据补救、SQL操作、图计算和机器学习库等。

Flink是一另俩个开源的流补救框架,它具有以下特点。

本来人是在2015年才听到Flink什儿 词的,虽然 早在60 8年,Flink的前身就可能是柏林理工大学的一另俩个研究性项目,在2014年什儿 项目被Apache孵化器所接受后,Flink这麼快成为ASF(Apache Software Foundation)的顶级项目之一。截至目前,Flink的版本经过了多次更新,本书基于1.6版本写作。

表1 流式计算框架对比

在这里解释一下,高吞吐表示单位时间内可不才能补救的数据量很大,低延迟表示数据产生后来可不才能在很短的时间内对其进行补救,也本来Flink可不才能支持快速占据 理海量数据。

Flink架构可不才能分为4层,包括Deploy层、Core层、API层和Library层,如图1.2所示。

官网中Flink和Storm的吞吐量对比如图1.4所示。

图1.2 Flink架构

从图1.2可知, Flink对底层的许多操作进行了封装,为用户提供了DataStream API和DataSet API。使用什儿 API可不才能很方便地完成许多流数据补救任务和批数据补救 任务。

Flink入门与实战

图1.4 Flink和Storm的吞吐量对比

本书旨在帮助读者从零结速英文快速掌握Flink的基本原理与核心功能。本书首先介绍了Flink的基本原理和安装部署,并对Flink中的许多核心API进行了全版分析。本来配套对应的案例分析,分别使用Java代码和Scala代码实现案例。最后通过另俩个项目演示了Flink在实际工作中的许多应用场景,帮助读者快速掌握Flink开发。

本来,后来组装一另俩个Flink Job,大慨可不才能什儿 个组件。Flink Job=DataSource+Transformation+DataSink

图1.3 Flink的3种数据传输模型

什儿 种生活数据传输模式是另俩个极端,对应的是流补救系统对低延迟和批补救系统对高吞吐的要求。Flink的执行引擎采用了一种生活十分灵活的辦法 ,并肩支持了什儿 种生活数据传输模型。Flink以固定的缓存块为单位进行网络数据传输,用户可不才能通过设置缓存块超时值指定缓存块的传输时机。可能缓存块的超时值为0,则Flink的数据传输辦法 同类于前面所提到的流补救系统的标准模型,此时系统可不才能获得最低的补救延迟;可能缓存块的超时值为无限大,则Flink的数据传输辦法 同类于前面所提到的批补救系统的标准模型,此时系统可不才能获得最高的吞吐量。缓存块的超时值也可不才能设置为0到无限大之间的任意值,缓存块的超时阈值越小,Flink流补救执行引擎的数据补救延迟就越低,但吞吐量也会降低,反之亦然。通过调整缓存块的超时阈值,用户可根据需求灵活地权衡系统延迟和吞吐量。

读者应该对Hadoop和Storm程序运行池池有所了解,在Hadoop中实现一另俩个MapReduce可不才能另俩个阶段——Map和Reduce,而在Storm中实现一另俩个Topology则可不才能Spout和Bolt组件。本来,可能许多人想实现一另俩个Flink任务话语,也可不才能有同类的逻辑。Flink中提供了俩个组件,包括DataSource、Transformation和DataSink。

在这里对这几种框架进行对比。