新一代大数据处理赏罚引擎 Apache Flink
大数据计较引擎的成长这几年大数据的飞速成长,呈现了许多热点的开源社区,个中闻名的有 Hadoop、Storm,以及其后的 Spark,他们都有着各自专注的应用场景。Spark 翻开了内存计较的先河,也以内存为赌注,赢得了内存计较的飞速成长。Spark 的火热或多或少的袒护了其他漫衍式计较的体系身影。就像 Flink,也就在这个时辰冷静的成长着。 在海外一些社区,有许多人将大数据的计较引擎分成了 4 代,虽然,也有许多人不会认同。我们先暂时这么以为和接头。 起首第一代的计较引擎,无疑就是 Hadoop 承载的 MapReduce。这里各人应该都不会对 MapReduce 生疏,它将计较分为两个阶段,别离为 Map 和 Reduce。对付上层应用来说,就不得不想方想法去拆分算法,乃至于不得不在上层应用实现多个 Job 的串联,以完成一个完备的算法,譬喻迭代计较。 因为这样的破绽,催生了支持 DAG 框架的发生。因此,支持 DAG 的框架被分别为第二代计较引擎。如 Tez 以及更上层的 Oozie。这里我们不去细究各类 DAG 实现之间的区别,不外对付其时的 Tez 和 Oozie 来说,大多照旧批处理赏罚的使命。 接下来就是以 Spark 为代表的第三代的计较引擎。第三代计较引擎的特点首要是 Job 内部的 DAG 支持(不超过 Job),以及夸大的及时计较。在这里,许多人也会以为第三代计较引擎也可以或许很好的运行批处理赏罚的 Job。 跟着第三代计较引擎的呈现,促进了上层应用快速成长,譬喻各类迭代计较的机能以及对流计较和 SQL 等的支持。Flink 的降生就被归在了第四代。这应该首要示意在 Flink 对流计较的支持,以及更一步的及时性上面。虽然 Flink 也可以支持 Batch 的使命,以及 DAG 的运算。 或者会有人差异意以上的分类,我认为其拭魅这并不重要的,重要的是领会各个框架的差别,以及更得当的场景。并举办领略,没有哪一个框架可以美满的支持全部的场景,也就不行能有任何一个框架能完全代替另一个,就像 Spark 没有完全代替 Hadoop,虽然 Flink 也不行能代替 Spark。本文将致力描写 Flink 的道理以及应用。 回页首 Flink 简介许多人也许都是在 2015 年才听到 Flink 这个词,着实早在 2008 年,Flink 的前身已经是柏林理工大学一个研究性项目, 在 2014 被 Apache 孵化器所接管,然后敏捷地成为了 ASF(Apache Software Foundation)的顶级项目之一。Flink 的最新版本今朝已经更新到了 0.10.0 了,在许多人感应 Spark 的快速成长的同时,或者我们也该为 Flink 的成长速率点个赞。 Flink 是一个针对流数据和批数据的漫衍式处理赏罚引擎。它首要是由 Java 代码实现。今朝首要照旧依赖开源社区的孝顺而成长。对 Flink 而言,其所要处理赏罚的首要场景就是流数据,批数据只是流数据的一个极限特例罢了。再换句话说,Flink 会把全部使命当成流来处理赏罚,这也是其最大的特点。Flink 可以支持当地的快速迭代,以及一些环形的迭代使命。而且 Flink 可以定制化内存打点。在这点,假如要比拟 Flink 和 Spark 的话,Flink 并没有将内存完全交给应用层。这也是为什么 Spark 相对付 Flink,更轻易呈现 OOM 的缘故起因(out of memory)。就框架自己与应用场景来说,Flink 更相似与 Storm。假如之前相识过 Storm 可能 Flume 的读者,也许会更轻易领略 Flink 的架构和许多观念。下面让我们先来看下 Flink 的架构图。 图 1. Flink 架构图如图 1 所示,我们可以相识到 Flink 几个最基本的观念,Client、JobManager 和 TaskManager。Client 用来提交使命给 JobManager,JobManager 分发使命给 TaskManager 去执行,然后 TaskManager 会意跳的讲述使命状态。看到这里,有的人应该已经有种回到 Hadoop 一代的错觉。确实,从架构图去看,JobManager 很像昔时的 JobTracker,TaskManager 也很像昔时的 TaskTracker。然而有一个最重要的区别就是 TaskManager 之间是是流(Stream)。其次,Hadoop 一代中,只有 Map 和 Reduce 之间的 Shuffle,而对 Flink 而言,也许是许多级,而且在 TaskManager 内部和 TaskManager 之间城市稀有据转达,而不像 Hadoop,是牢靠的 Map 到 Reduce。 回页首
Flink 中的调治简述在 Flink 集群中,计较资源被界说为 Task Slot。每个 TaskManager 会拥有一个或多个 Slots。JobManager 会以 Slot 为单元调治 Task。可是这里的 Task 跟我们在 Hadoop 中的领略是有区此外。对 Flink 的 JobManager 来说,其调治的是一个 Pipeline 的 Task,而不是一个点。举个例子,在 Hadoop 中 Map 和 Reduce 是两个独立调治的 Task,而且城市去占用计较资源。对 Flink 来说 MapReduce 是一个 Pipeline 的 Task,只占用一个计较资源。类同的,假若有一个 MRR 的 Pipeline Task,在 Flink 中其也是一个被整体调治的 Pipeline Task。在 TaskManager 中,按照其所拥有的 Slot 个数,同时会拥有多个 Pipeline。 在 Flink StandAlone 的陈设模式中,这个还较量轻易领略。由于 Flink 自身也必要简朴的打点计较资源(Slot)。当 Flink 陈设在 Yarn 上面之后,Flink 并没有弱化资源打点。也就是嗣魅这时辰的 Flink 在做一些 Yarn 该做的工作。从计划角度来讲,我以为这是不太公道的。假如 Yarn 的 Container 无法完全断绝 CPU 资源,这时辰对 Flink 的 TaskManager 设置多个 Slot,应该会呈现资源不公正操作的征象。Flink 假如想在数据中心更好的与其他计较框架共享计较资源,应该只管不要过问计较资源的分派和界说。 必要深度进修 Flink 调治读者,可以在 Flink 的源码目次中找到 flink-runtime 这个文件夹,JobManager 的 code 根基都在这里。 回页首
Flink 的生态圈一个计较框架要有久远的成长,必需打造一个完备的 Stack。否则就跟纸上谈兵一样,没有任何意义。只有上层有了详细的应用,并能很好的施展计较框架自己的上风,那么这个计较框架才气吸引更多的资源,才会更快的前进。以是 Flink 也在全力构建本身的 Stack。 Flink 起首支持了 Scala 和 Java 的 API,Python 也正在测试中。Flink 通过 Gelly 支持了图操纵,尚有呆板进修的 FlinkML。Table 是一种接口化的 SQL 支持,也就是 API 支持,而不是文本化的 SQL 理会和执行。对付完备的 Stack 我们可以参考下图。 图 2. Flink 的 StackFlink 为了更普及的支持大数据的生态圈,其下也实现了许多 Connector 的子项目。最认识的,虽然就是与 Hadoop HDFS 集成。其次,Flink 也公布支持了 Tachyon、S3 以及 MapRFS。不外对付 Tachyon 以及 S3 的支持,都是通过 Hadoop HDFS 这层包装实现的,也就是说要行使 Tachyon 和 S3,就必需有 Hadoop,并且要变动 Hadoop 的设置(core-site.xml)。假如赏识 Flink 的代码目次,我们就会看到更多 Connector 项目,譬喻 Flume 和 Kafka。 回页首
Flink 的陈设Flink 有三种陈设模式,别离是 Local、Standalone Cluster 和 Yarn Cluster。对付 Local 模式来说,JobManager 和 TaskManager 会公用一个 JVM 来完成 Workload。假如要验证一个简朴的应用,Local 模式是最利便的。现实应用中大多行使 Standalone 可能 Yarn Cluster。下面我首要先容下这两种模式。 Standalone 模式在搭建 Standalone 模式的 Flink 集群之前,我们必要先下载 Flink 安装包。这里我们必要下载 Flink 针对 Hadoop 1.x 的包。下载并解压后,进到 Flink 的根目次,然后查察 conf 文件夹,如下图。 图 3. Flink 的目次布局我们必要指定 Master 和 Worker。Master 呆板会启动 JobManager,Worker 则会启动 TaskManager。因此,我们必要修改 conf 目次中的 master 和 slaves。在设置 master 文件时,必要指定 JobManager 的 UI 监听端口。一样平常环境下,JobManager 只需设置一个,Worker 则须设置一个或多个(以举动单元)。示譬喻下: micledeMacBook-Pro:conf micle$ cat masters localhost:8081 micledeMacBook-Pro:conf micle$ cat slaves localhost 在 conf 目次中找到文件 flink-conf.yaml。在这个文件中界说了 Flink 各个模块的根基属性,如 RPC 的端口,JobManager 和 TaskManager 堆的巨细等。在不思量 HA 的环境下,一样平常只必要修改属性 taskmanager.numberOfTaskSlots,也就是每个 Task Manager 所拥有的 Slot 个数。这个属性,一样平常配置成呆板 CPU 的 core 数,用来均衡呆板之间的运算机能。其默认值为 1。设置完成后,行使下图中的呼吁启动 JobManager 和 TaskManager(启动之前,必要确认 Java 的情形是否已经停当)。 图 4. 启动 StandAlone 模式的 Flink启动之后我们就可以登岸 Flink 的 GUI 页面。在页面中我们可以看到 Flink 集群的根基属性,在 JobManager 和 TaskManager 的页面中,可以看到这两个模块的属性。今朝 Flink 的 GUI,只提供了简朴的查察成果,无法动态修改设置属性。一样平常在企业级应用中,这是很难被接管的。因此,一个企颐魅真正要应用 Flink 的话,预计也不得不增强 WEB 的成果。 图 5. Flink 的 GUI 页面Yarn Cluster 模式在一个企业中,为了最大化的操作集群资源,一样平常城市在一个集群中同时运行多种范例的 Workload。因此 Flink 也支持在 Yarn 上面运行。起首,让我们通过下图相识下 Yarn 和 Flink 的相关。 图 6. Flink 与 Yarn 的相关在图中可以看出,Flink 与 Yarn 的相关与 MapReduce 和 Yarn 的相关是一样的。Flink 通过 Yarn 的接话柄现了本身的 App Master。当在 Yarn 中陈设了 Flink,Yarn 就会用本身的 Container 来启动 Flink 的 JobManager(也就是 App Master)和 TaskManager。 相识了 Flink 与 Yarn 的相关,我们就简朴看下陈设的步调。在这之前必要先陈设好 Yarn 的集群,这里我就不做先容了。我们可以通过以下的呼吁查察 Yarn 中现有的 Application,而且来搜查 Yarn 的状态。 yarn application –list
假如呼吁正确返回了,就声名 Yarn 的 RM 今朝已经在启动状态。针对差异的 Yarn 版本,Flink 有差异的安装包。我们可以在 Apache Flink 的下载页中找到对应的安装包。我的 Yarn 版本为 2.7.1。再先容详细的步调之前,我们必要先相识 Flink 有两种在 Yarn 上面的运行模式。一种是让 Yarn 直接启动 JobManager 和 TaskManager,另一种是在运行 Flink Workload 的时辰启动 Flink 的模块。前者相等于让 Flink 的模块处于 Standby 的状态。这里,我也首要先容下前者。 在下载息争压 Flink 的安装包之后,必要在情形中增进情形变量 HADOOP_CONF_DIR 可能 YARN_CONF_DIR,其指向 Yarn 的设置目次。如运行下面的呼吁: export HADOOP_CONF_DIR=/etc/hadoop/conf
这是由于 Flink 实现了 Yarn 的 Client,因此必要 Yarn 的一些设置和 Jar 包。在设置好情形变量后,只需简朴的运行如下的剧本,Yarn 就会启动 Flink 的 JobManager 和 TaskManager。 yarn-session.sh –d –s 2 –tm 800 –n 2
上面的呼吁的意思是,向 Yarn 申请 2 个 Container 启动 TaskManager(-n 2),每个 TaskManager 拥有两个 Task Slot(-s 2),而且向每个 TaskManager 的 Container 申请 800M 的内存。在上面的呼吁乐成后,我们就可以在 Yarn Application 页面看到 Flink 的记载。如下图。 图 7. Flink on Yarn假若有些读者在假造机中测试,也许会碰着错误。这里必要留意内存的巨细,Flink 向 Yarn 会申请多个 Container,可是 Yarn 的设置也许限定了 Container 所能申请的内存巨细,乃至 Yarn 自己所打点的内存就很小。这样很也许无法正常启动 TaskManager,尤其当指定多个 TaskManager 的时辰。因此,在启动 Flink 之后,必要去 Flink 的页面中搜查下 Flink 的状态。这里可以从 RM 的页面中,直接跳转(点击 Tracking UI)。这时辰 Flink 的页面如图 8。 图 8. Flink 的页面对付 Flink 安装时的 Trouble-shooting,也许更多时辰必要查察 Yarn 相干的 log 来说明。这里就不多做先容,读者可以到 Yarn 相干的描写中查找。 回页首
Flink 的 HA对付一个企业级的应用,不变性是主要要思量的题目,然后才是机能,因此 HA 机制是必不行少的。其它,对付已经相识 Flink 架构的读者,也许会更担忧 Flink 架构背后的单点题目。和 Hadoop 一代一样,从架构中我们可以很明明的发明 JobManager 有明明的单点题目(SPOF,single point of failure)。 JobManager 负担着使命调治以及资源分派,一旦 JobManager 呈现不测,其效果可想而知。Flink 对 JobManager HA 的处理赏罚方法,道理上根基和 Hadoop 一样(一代和二代)。 起首,我们必要知道 Flink 有两种陈设的模式,别离是 Standalone 以及 Yarn Cluster 模式。对付 Standalone 来说,Flink 必需依靠于 Zookeeper 来实现 JobManager 的 HA(Zookeeper 已经成为了大部门开源框架 HA 必不行少的模块)。在 Zookeeper 的辅佐下,一个 Standalone 的 Flink 集群会同时有多个在世的 JobManager,个中只有一个处于事变状态,其他处于 Standby 状态。当事变中的 JobManager 失去毗连后(如宕机或 Crash),Zookeeper 会从 Standby 中推举新的 JobManager 来经受 Flink 集群。 对付 Yarn Cluaster 模式来说,Flink 就要依赖 Yarn 自己来对 JobManager 做 HA 了。其拭魅这里完满是 Yarn 的机制。对付 Yarn Cluster 模式来说,JobManager 和 TaskManager 都是被 Yarn 启动在 Yarn 的 Container 中。此时的 JobManager,着实应该称之为 Flink Application Master。也就说它的妨碍规复,就完全依赖着 Yarn 中的 ResourceManager(和 MapReduce 的 AppMaster 一样)。因为完全依靠了 Yarn,因此差异版本的 Yarn 也许会有渺小的差别。这里不再做穷究。 回页首
Flink 的 Rest API 先容Flink 和其他大多开源的框架一样,提供了许多有效的 Rest API。不外 Flink 的 RestAPI,今朝还不是很强盛,只能支持一些 Monitor 的成果。Flink Dashboard 自己也是通过其 Rest 来查询各项的功效数据。在 Flink RestAPI 基本上,可以较量轻易的将 Flink 的 Monitor 成果和其他第三方器材相集成,这也是其计划的初志。 在 Flink 的历程中,是由 JobManager 来提供 Rest API 的处事。因此在挪用 Rest 之前,要确定 JobManager 是否处于正常的状态。正常环境下,在发送一个 Rest 哀求给 JobManager 之后,Client 就会收到一个 JSON 名目标返回功效。因为今朝 Rest 提供的成果还不多,必要加强这块成果的读者可以在子项目 flink-runtime-web 中找到对应的代码。个中最要害一个类 WebRuntimeMonitor,就是用来对全部的 Rest 哀求做分流的,假如必要添加一个新范例的哀求,就必要在这里增进对应的处理赏罚代码。下面我例举几个常用 Rest API。 1.查询 Flink 集群的根基信息: /overview。示例呼吁行名目以及返回功效如下: $ curl http://localhost:8081/overview{"taskmanagers":1,"slots-total":16,"slots-available":16,"jobs-running":0,"jobs-finished":0,"jobs-cancelled":0,"jobs-failed":0}
2.查询当前 Flink 集群中的 Job 信息:/jobs。示例呼吁行名目以及返回功效如下: $ curl http://localhost:8081/jobs{"jobs-running":[],"jobs-finished":
["f91d4dd4fdf99313d849c9c4d29f8977"],"jobs-cancelled":[],"jobs-failed":[]}
3.查询一个指定的 Job 信息: /jobs/jobid。这个查询的功效会返回出格多的具体的内容,这是我在赏识器中举办的测试,如下图: 图 9. Rest 查询详细的 Job 信息想要相识更多 Rest 哀求内容的读者,可以去 Apache Flink 的页面中查找。因为篇幅有限,这里就纷歧一罗列。 回页首
运行 Flink 的 WorkloadWordCount 的例子,就像是计较框架的 helloworld。这里我就以 WordCount 为例,先容下如安在 Flink 中运行 workload。 在安装好 Flink 的情形中,找到 Flink 的目次。然后找到 bin/flink,它就是用来提交 Flink workload 的器材。对付 WordCount,我们可以直接行使已有的示例 jar 包。如运行如下的呼吁: ./bin/flink run ./examples/WordCount.jar hdfs://user/root/test hdfs://user/root/out
上面的呼吁是在 HDFS 中运行 WordCount,假如没有 HDFS 用当地的文件体系也是可以的,只必要将“hdfs://”换成“file://”。这里我们必要夸大一种陈设相关,就是 StandAlone 模式的 Flink,也是可以直接会见 HDFS 平漫衍式文件体系的。 回页首
竣事语Flink 是一个比 Spark 起步晚的项目,可是并不代表 Flink 的前程就会惨淡。Flink 和 Spark 有许多相同之处,但也有许多明明的差别。本文并没有较量这两者之间的差别,这是将来我想与各人切磋的。譬喻 Flink 怎样更高效的打点内存,怎样进一步的停止用户措施的 OOM。在 Flink 的天下里统统都是流,它更专注处理赏罚流应用。因为其起步晚,加上社区的活泼度并没有 Spark 那么热,以是其在一些细节的场景支持上,并没有 Spark 那么完美。譬喻今朝在 SQL 的支持上并没有 Spark 那么滑腻。在企业级应用中,Spark 已经开始落地,而 Flink 也许还必要一段时刻的打磨。在后续文章中,我会具体先容怎样开拓 Flink 的措施,以及更多有关 Flink 内部实现的内容。 (编辑:湖南网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |