刨根问底系列---Flink概述

前言
大家好，我是那个英俊潇洒风流倜傥的DJ丶小哪吒。看清楚，是哪(ne)吒（zha），不是那托。~~~
今天我又来跟你们分享知识了，好久没更新博客。都快生疏了呢。今天要分享的是大数据热门框架之一，flink。那么，什么是flink呢？既然已经有了SparkStreaming和Store为什么还要有flink呢？看了下面这篇文章，你就懂了。更多谜题，请看小编为你揭晓谜底。

第 1 章 Flink 简介

1.1 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 的运算。首先，我们可以通过下面的性能测试初步了 解两个框架的性能区别，它们都可以基于内存计算框架进行实时计算，所以都拥有非常好的 计算性能。经过测试，Flink 计算性能上略好。
测试环境：
1.CPU：7000 个；
2.内存：单机 128GB；
3.版本：Hadoop 2.3.0，Spark 1.4，Flink 0.9
4.数据：800MB，8GB，8TB；
5.算法：K-means：以空间中 K 个点为中心进行聚类，对最靠近它们的对象归类。通过迭代的方法，逐次更新各聚类中心的值，直至得到最好的聚类结果。
6.迭代：K=10，3 组数据

Spark 和 Flink 全部都运行在 Hadoop YARN 上，性能为 Flink > Spark > Hadoop(MR)， 迭代次数越多越明显，性能上，Flink 优于 Spark 和 Hadoop 最主要的原因是 Flink 支持 增量迭代，具有对迭代自动优化的功能。

Flink 和 spark 的差异

1.2 什么是 Flink

Flink 起源于 Stratosphere 项目，Stratosphere 是在 2010~2014 年由 3 所地处柏 林的大学和欧洲的一些其他的大学共同进行的研究项目， 2014 年 4 月 Stratosphere 的 代码 被复制 并捐赠 给了 Apache 软件 基金会 ， 参加 这个孵 化项目 的初始成 员是 Stratosphere 系统的核心开发人员，2014 年 12 月， Flink 一跃成为 Apache 软件基金 会的顶级项目。在德语中， Flink 一词表示快速和灵巧， 项目采用一只松鼠的彩色图案作 为 logo， 这不仅是因为松鼠具有快速和灵巧的特点， 还因为柏林的松鼠有一种迷人的红 棕色， 而 Flink 的松鼠 logo 拥有可爱的尾巴， 尾巴的颜色与 Apache 软件基金会的 logo 颜色相呼应， 也就是说， 这是一只 Apache 风格的松鼠。

Flink 主页在其顶部展示了该项目的理念：“Apache Flink 是为分布式、高性能、随 时可用以及准确的流处理应用程序打造的开源流处理框架” 。 Apache Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。 Flink 被设计在所有常见的集群环境中运行，以内存执行速度和任意规模来执行计算。

1.3 Flink流处理特性

1. 支持高吞吐、 低延迟、 高性能的流处理
2. 支持带有事件时间的窗口（Window） 操作
3. 支持有状态计算的 Exactly-once 语义
4. 支持高度灵活的窗口（Window） 操作， 支持基于 time、 count、 session，以及 data-driven 的窗口操作
5. 支持具有 Backpressure 功能的持续流模型
6. 支持基于轻量级分布式快照（Snapshot） 实现的容错
7. 一个运行时同时支持 Batch on Streaming 处理和 Streaming 处理
8. Flink 在 JVM 内部实现了自己的内存管理
9. 支持迭代计算
10. 支持程序自动优化： 避免特定情况下 Shuffle、 排序等昂贵操作， 中间结果有 必要进行缓存

1.4 Flink 基石

Flink 之所以能这么流行，离不开它最重要的四个基石：Checkpoint、State、Time、 Window。

首 先 是 Checkpoint 机 制 ， 这 是 Flink 最 重 要 的 一 个 特 性 。 Flink 基 于 Chandy-Lamport 算法实现了一个分布式的一致性的快照， 从而提供了一致性的语义。 Chandy-Lamport 算法实际上在 1985 年的时候已经被提出来， 但并没有被很广泛的应用， 而 Flink 则把这个算法发扬光大了。Spark 最近在实现 Continue streaming， Continue streaming 的目的是为了降低它处理的延时，其也需要提供这种一致性的语义， 最终采用 Chandy-Lamport 这个算法， 说明 Chandy-Lamport 算法在业界得到了一定的肯定。

提供了一致性的语义之后， Flink 为了让用户在编程时能够更轻松、 更容易地去管理 状态，还提供了一套非常简单明了的 State API， 包括里面的有 ValueState、 ListState、 MapState，近期添加了 BroadcastState， 使用 State API 能够自动享受到这种一致性的 语义。

除此之外，Flink 还实现了 Watermark 的机制，能够支持基于事件的时间的处理，或 者说基于系统时间的处理， 能够容忍数据的延时、 容忍数据的迟到、 容忍乱序的数据。 另外流计算中一般在对流数据进行操作之前都会先进行开窗， 即基于一个什么样的窗口上 做这个计算。 Flink 提供了开箱即用的各种窗口， 比如滑动窗口、 滚动窗口、 会话窗口 以及非常灵活的自定义的窗口。

1.5 批处理与流处理

批处理的特点是有界、 持久、 大量， 批处理非常适合需要访问全套记录才能完成的 计算工作，一般用于离线统计。 流处理的特点是无界、 实时， 流处理方式无需针对整个 数据集执行操作， 而是对通过系统传输的每个数据项执行操作， 一般用于实时统计。

在 Spark 生态体系中， 对于批处理和流处理采用了不同的技术框架， 批处理由 SparkSQL 实现， 流处理由 Spark Streaming 实现， 这也是大部分框架采用的策略， 使 用独立的处理器实现批处理和流处理， 而 Flink 可以同时实现批处理和流处理。

Flink 是如何同时实现批处理与流处理的呢？ 答案是， Flink 将批处理（ 即处理有 限的静态数据）视作一种特殊的流处理。Flink 的核心计算架构是下图中的 Flink Runtime
执行引擎， 它是一个分布式系统， 能够接受数据流程序并在一台或多台机器上以容错方式 执行。

Flink Runtime 执行引擎可以作为 YARN（ Yet Another Resource Negotiator） 的应 用程序在集群上运行， 也可以在 Mesos 集群上运行， 还可以在单机上运行（这对于调试 Flink 应用程序来说非常有用）。

上图为 Flink 技术栈的核心组成部分， 值得一提的是， Flink 分别提供了面向流式 处理的接口（DataStream API） 和面向批处理的接口（DataSet API） 。 因此， Flink 既 可以完成流处理，也可以完成批处理。 Flink 支持的拓展库涉及机器学习（FlinkML） 、 复 杂事件处理（CEP） 、 以及图计算（Gelly） ， 还有分别针对流处理和批处理的 Table API。

能被 Flink Runtime 执行引擎接受的程序很强大， 但是这样的程序有着冗长的代码， 编写起来也很费力， 基于这个原因， Flink 提供了封装在 Runtime 执行引擎之上的 API， 以帮助用户方便地生成流式计算程序。 Flink 提供了用于流处理的 DataStream API 和用 于批处理的 DataSetAPI。值得注意的是，尽管 Flink Runtime 执行引擎是基于流处理的， 但是 DataSet API 先于 DataStream API 被开发出来， 这是因为工业界对无限流处理的需 求在 Flink 诞生之初并不大。DataStream API 可以流畅地分析无限数据流， 并且可以用 Java 或者 Scala 来实现。 开发人员需要基于一个叫 DataStream 的数据结构来开发， 这 个数据结构用于表示永不停止的分布式数据流。

Flink 的分布式特点体现在它能够在成百上千台机器上运行， 它将大型的计算任务分 成许多小的部分， 每个机器执行一部分。 Flink 能够自动地确保发生机器故障或者其他错 误时计算能够持续进行， 或者在修复 bug 或进行版本升级后有计划地再执行一次。 这种 能力使得开发人员不需要担心运行失败。 Flink 本质上使用容错性数据流， 这使得开发人 员可以分析持续生成且永远不结束的数据（ 即流处理）。

扩展1：有了sparkStreaming和Storm为什么还要有Flink

sprkStreaming是批量处理，保证了数据处理顺序。并非真正意义上的实时。延迟较高。
storm延迟低，但是他牺牲了高吞吐，和数据处理顺序。来达到低延迟效果。
而flink就结合了两者的优点。达到低延迟，高吞吐，还保证了数据的有序。

扩展2：流处理演变

lambda架构：

Batch Layer批处理，数据准确且有序，但是延迟高。
Speed Layer流处理，数据乱序，但是延迟低。
Application(应用程序)读取数据，会合并最终的结果(Batch Table + Speed Table)，他会先快速得到一个近似准确的数据，隔一段时间再更新成最新的数据。

但是lambda架构使用起来麻烦，两套架构，不同的处理引擎，编程模式不一样使用的API不同。不利于开发。

后来flink完美的结合了两套框架，使用相同的编程模型，同样的API。

flink降低了开发难度，也实现了高吞吐，数据正确和保证了数据的时效性。

扩展3：基于流的世界观

在Flink的世界观中，一切都是由流组成的，离线数据是有界限的流；实时数据是一个没有界限的流；这就是所谓的有界流和无界流

---

好了，以上内容就到这里。下期更精彩哦。 敬请关注。欢迎路过的朋友关注小编哦。各位朋友关注点赞是小编坚持下去的动力。小编会继续为大家分享更多的知识哦~~~。

我是DJ丶小哪吒。是一名互联网行业的工具人，“我不生产代码，我只做代码的搬运工”…哈哈哈，我们下期见哦，Bye~

别指望伯乐从天而降，拜你为上卿。能力是干出来的。