Flink介绍
流处理并不是一个新概念，但是要做好并不是一件容易的事情。提到流处理，我们最先想到的可能是金融交易、信号检测以及地图导航等领域的应用。但是近年来随着信息技术的发展，除了前面提到的三个领域，其它方向对数据时效性的要求也越来越高。随着 Hadoop 生态的崛起，Storm、Spark Streaming、Samza、MillWheel 等一众流处理技术开始走入大众视野，但是我们最熟悉的应该还是 Storm 和 Spark Streaming。
我们知道，“高吞吐”、“低延迟”和”exactly-once“是衡量一个流处理框架的重要指标。 Storm 虽然提供了低延迟的流处理，但是在高吞吐方面的表现并不算佳，可以说基本满足不了日益暴涨的数据量，而且也没办法保证精准一次消费。Spark Streaming 中通过微批次的批处理来模拟流处理，只要将批处理的批次分的足够小，那么从宏观上来看就是流处理，这也是 Spark Streaming 的核心思想。通过微观批处理的方式，Spark Streaming 也实现了高吞吐和 exactly-once 语义，时效性也有了大幅提升，在很长一段时间里占据流处理榜首。但是受限于其实现方式，依然存在几秒的延迟，对于那些实时性要求较高的领域来说依然不够完美。 在这样的背景下，Flink 应运而生，接下来我们正式进入 Flink 的学习。
Apache Flink 是为分布式、高性能、随时可用以及准确 的流处理应用程序打造的开源流处理框架，用于对无界和有界数据流进行有状态计算。Flink 最早起源于在 2010 ~ 2014 年，由 3 所地处柏林的大学和欧洲的一些其它大学共同进行研究的名为 Stratosphere 的项目。2014 年 4 月 Stratosphere 将其捐赠给 Apache 软件基 金会， 初始成员是 Stratosphere 系统的核心开发人员，2014 年 12 月，Flink 一跃成为 Apache 软件基金会的顶级项目。在 2015 年，阿里也加入到了 Flink 的开发工作中，并贡献了至少 150 万行代码。
Flink 一词在德语中有着“灵巧”、“快速”的意思，它的 logo 原型也是柏林常见的一种松鼠，以身材娇小、灵活著称，为该项目取这样的名字和选定这样的 logo 也正好符合 Flink 的特点和愿景。
注意，虽然我们说 Flink 是一个流处理框架，但是它同样可以进行批处理。因为在 Flink 的世界观里，批处理是流处理的一种特殊形式，这和 Spark 不同，在 Spark 中，流处理是通过大批量的微批处理实现的。
Apache Flink 是一个海量数据计算框架和分布式处理引擎，用于在无边界和有边界数据流（离线、流式）上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。
那么如何来理解有边界和无边界的数据流呢？
无界流
有定义流的开始，但没有定义流的结束。它们会无休止地产生数据。无界流的数据必须持续处理，即数据被摄取后需要立刻处理。我们不能等到所有数据都到达再处理，因为输入是无限的，在任何时候输入都不会完成。处理无界数据通常要求以特定顺序摄取事件，例如事件发生的顺序，以便能够推断结果的完整性。
有界流
有定义流的开始，也有定义流的结束。有界流可以在摄取所有数据后再进行计算。有界流所有数据可以被排序，所以并不需要有序摄取。有界流处理通常被称为批处理。
小结
Apache Flink 擅长处理无界和有界数据集 精确的时间控制和状态化使得 Flink 的运行时(runtime)能够运行任何处理无界流的应用。有界流则由一些专为固定大小数据集特殊设计的算法和数据结构进行内部处理，产生了出色的性能。
部署应用到任意地方
Apache Flink 是一个分布式系统，它需要计算资源来执行应用程序。Flink 集成了所有常见的集群资源管理器，例如 Hadoop YARN、 Apache Mesos 和 Kubernetes，但同时也可以作为独立集群运行。
Flink 被设计为能够很好地工作在上述每个资源管理器中，这是通过资源管理器特定(resource-manager-specific)的部署模式实现的。Flink 可以采用与当前资源管理器相适应的方式进行交互。
部署 Flink 应用程序时，Flink 会根据应用程序配置的并行性自动标识所需的资源，并从资源管理器请求这些资源。在发生故障的情况下，Flink 通过请求新资源来替换发生故障的容器。提交或控制应用程序的所有通信都是通过 REST 调用进行的，这可以简化 Flink 与各种环境中的集成。
运行任意规模应用
Flink 旨在任意规模上运行有状态流式应用。因此，应用程序被并行化为可能数千个任务，这些任务分布在集群中并发执行。所以应用程序能够充分利用无尽的 CPU、内存、磁盘和网络 IO。而且 Flink 很容易维护非常大的应用程序状态。其异步和增量的检查点算法对处理延迟产生最小的影响，同时保证精确一次状态的一致性。
Flink 用户报告了其生产环境中一些令人印象深刻的扩展性数字
- 处理每天处理数万亿的事件
- 应用维护几TB大小的状态
- 应用在数千个内核上运行
利用内存性能
有状态的 Flink 程序针对本地状态访问进行了优化。任务的状态始终保留在内存中，如果状态大小超过可用内存，则会保存在能高效访问的磁盘数据结构中。任务通过访问本地（通常在内存中）状态来进行所有的计算，从而产生非常低的处理延迟。Flink 通过定期和异步地对本地状态进行持久化存储来保证故障场景下精确的状态一致性。
故障恢复
Apache Flink 是一个针对无界和有界数据流进行有状态计算的框架。由于许多流应用程序旨在以最短的停机时间连续运行，因此流处理器必须提供出色的故障恢复能力，以及在应用程序运行期间进行监控和维护的工具。
它(这类流处理器)不仅能在服务出现故障时候能够重启服务，而且当故障发生时，保证能够持久化服务内部各个组件的当前状态，保证在故障恢复时候，服务能够继续正常运行，好像故障就没有发生过一样。
检查点的一致性
Flink的故障恢复机制是通过建立分布式应用服务状态一致性检查点实现的，当有故障产生时，应用服务会在重启后，再重新加载上一次成功备份的状态检查点信息。结合可重放的数据源，该特性可保证精确一次（exactly-once）的状态一致性。
高效的检查点
如果一个应用要维护一个TB级的状态信息，对此应用的状态建立检查点服务的资源开销是很高的，为了减小因检查点服务对应用的延迟性（SLAs服务等级协议）的影响，Flink采用异步及增量的方式构建检查点服务。
端到端的只执行一次（End-to-End Exactly-Once）
Flink 为某些特定的存储支持了事务型输出的功能，及时在发生故障的情况下，也能够保证精确一次的输出。
集成多种集群管理服务
Flink已与多种集群管理服务紧密集成，如 Hadoop YARN, Mesos, 以及 Kubernetes。当集群中某个流程任务失败后，一个新的流程服务会自动启动并替代它继续执行。
内置高可用服务
Flink内置了为解决单点故障问题的高可用性服务模块，此模块是基于Apache ZooKeeper 技术实现的，Apache ZooKeeper是一种可靠的、交互式的、分布式协调服务组件。
用户
阿里巴巴、华为、腾讯、小米、快手、亚马逊等
本文由 liyunfei 创作，采用 知识共享署名4.0
国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Jun 24,2022