1 - Flink基础课程.docx

第一章 Flink基础 课程目标 l 了解什么是流式计算 l 了解Flink的简介 l 掌握Flink的架构体系 l 掌握Flink环境的搭建 l 掌握Flink的运行架构 1. 课程说明 1.1 框架版本 https://flink.apache.org/blog/ 本课程基于2021年05月28日最新发布的Flink1.13.1版本进行讲解，Flink 1.13 包括了超过 200 名贡献者所提交的 1000 多项修复和优化。 这一版本中，Flink 的一个主要目标取得了重要进展，即让流处理应用的使用和普通应用一样简单和自然。Flink 1.13 新引入的被动扩缩容使得流作业的扩缩容和其它应用一样简单，用户仅需要修改并发度即可。 这个版本还包括一系列重要改动使用户可以更好的理解流作业的性能。当流作业的性能不及预期的时候，这些改动可以使用户可以更好的分析原因。这些改动包括用于识别瓶颈节点的负载和反压可视化、分析算子热点代码的 CPU 火焰图和分析 State Backend 状态的 State 访问性能指标。 Flink1.13.1其中一些比较重要的修改包括： l 被动扩缩容 l 分析应用的性能 n 瓶颈检测与反压监控 n Web UI 中的 CPU 火焰图 n State 访问延迟指标 l 通过Savepoint来切换Sate Backend。 l K8s部署时使用用户指定的Pod模式 l 生产可用的Unaligned Checkpoint l 机器学习迁移到单独的仓库 SQL / Table API 进展： l 通过 Table-valued 函数来定义时间窗口 l 提高 DataStream API 与 Table API / SQL 的互操作能力 l SQL Client: 初始化脚本和语句集合 （Statement Sets） l 配置简化和代码共享 l 通过语句集合来支持多查询 l Hive 查询语法兼容性 l 优化的 SQL 时间函数 PyFlink 核心优化： l Python DataStream API 中的有状态算子 l PyFlink DataStream API 中的用户自定义窗口 l PyFlink Table API 中基于行的操作 l PyFlink DataStream API 支持 Batch 执行模式 其它优化： l Web UI 支持历史异常 l 优化失败 Checkpoint 的异常和失败原因的汇报 l 提供『恰好一次』一致性的 JDBC Sink l PyFlink Table API 在 Group 窗口上支持用户自定义的聚合函数 l Batch 执行模式下 Sort-merge Shuffle 优化 l HBase 连接器支持异步维表查询和查询缓存 1.2 编程语言 Flink官方提供了Java、Scala、Python语言接口用以开发Flink应用程序，但是Flink的源码是使用Java语言进行开发的，且Flink被阿里收购后，未来的主要编程语言都一直会是Java（因为阿里是Java重度使用者！），且GitHub上关于Flink的项目，大多数是使用Java语言编写的。所以课程中以Java语言为主进行Flink的学习讲解，但会扩展讲解使用其他语言进行Flink开发 https://ci.apache.org/projects/flink/flink-docs-release-1.13/ 2. [了解] -流式计算简介 2.1 数据的时效性 日常工作中，我们一般会先把数据存储在表，然后对表的数据进行加工、分析。既然先存储在表中，那就会涉及到时效性概念。 如果我们处理以年，月为单位级别的数据处理，进行统计分析，个性化推荐，那么数据的的最新日期离当前有几个甚至上月都没有问题。但是如果我们处理的是以天为级别，或者一小时甚至更小粒度的数据处理，那么就要求数据的时效性更高了。比如： l 对网站的实时监控 l 对异常日志的监控 这些场景需要工作人员立即响应，这样的场景下，传统的统一收集数据，再存到数据库中，再取出来进行分析就无法满足高时效性的需求了。 2.2 流式计算和批量计算 上面说到的：统一收集数据->存储到DB->对数据进行批量处理，就是我们说到的批量计算。而流式计算，顾名思义，就是对数据流进行处理，是实时计算 主要原理是： l 与批量计算那样慢慢积累数据不同，流式计算立刻计算，数据持续流动，计算完之后就丢弃。 l 批量计算是维护一张表，对表进行实施各种计算逻辑。流式计算相反，是必须先定义好计算逻辑，提交到流式计算系统，这个计算作业逻辑在整个运行期间是不可更改的。 l 计算结果上，批量计算对全部数据进行计算后传输结果，流式计算是每次小批量计算后，结果可以立刻实时化展现。 l 左边是Batch Analytics，右边是 Streaming Analytics。Batch Analysis 就是传统意义上使用类似于 Map Reduce、Hive、Spark Batch 等，对作业进行分析、处理、生成离线报表 l Streaming Analytics 使用流式分析引擎如 Storm，Flink 实时处理分析数据，应用较多的场景如实时大屏、实时报表。 2.3 流式计算流程和特性 l 流程： n 提交流计算作业 n 等待流式数据触发流计算作业 n 计算结果持续不断对外写出 l 特性： n 实时，低延迟 n 无界，数据是不断输出无终止的 n 连续，计算连续进行，计算之后数据就会被丢弃 2.4 实时即未来 如今的我们正生活在新一次的信息革命浪潮中，5G、物联网、智慧城市、工业4.0、新基建……等新名词层出不穷，唯一不变的就是变化！对于我们所学习的大数据来说更是这样：数据产生的越来越快、数据量越来越大，数据的来源越来越千变万化，数据中隐藏的价值规律更是越来越被重视！数字化时代的未来正在被我们创造！ 历史的发展从来不会一帆风顺，随着大数据时代的发展，海量数据和多种业务的实时处理需求激增，比如：实时监控报警系统、实时风控系统、实时推荐系统等，传统的批处理方式和早期的流式处理框架因其自身的局限性，难以在延迟性、吞吐量、容错能力，以及使用便捷性等方面满足业务日益苛刻的要求。在这种形势下，Flink 以其独特的天然流式计算特性和更为先进的架构设计，极大地改善了以前的流式处理框架所存在的问题。 l 扩展阅读:为什么说流处理即未来？ 3. [了解] - Flink简介 3.1 Flink的引入 这几年大数据的飞速发展，出现了很多热门的开源社区，其中著名的有 Hadoop、Storm，以及后来的 Spark，他们都有着各自专注的应用场景。Spark 掀开了内存计算的先河，也以内存为赌注，赢得了内存计算的飞速发展。Spark 的火热或多或少的掩盖了其他分布式计算的系统身影。就像 Flink，也就在这个时候默默的发展着。 在国外一些社区，有很多人将大数据的计算引擎分成了 4 代，当然，也有很多人不会认同。我们先姑且这么认为和讨论。 l 第1代——Hadoop MapReduce 首先第一代的计算引擎，无疑就是 Hadoop 承载的 MapReduce。它将计算分为两个阶段，分别为 Map 和 Reduce。对于上层应用来说，就不得不想方设法去拆分算法，甚至于不得不在上层应用实现多个 Job 的串联，以完成一个完整的算法，例如迭代计算。 n 批处理 n Mapper、Reducer l 第2代——DAG框架（Tez） + MapReduce 由于这样的弊端，催生了支持 DAG 框架的产生。因此，支持 DAG 的框架被划分为第二代计算引擎。如 Tez 以及更上层的 Oozie。这里我们不去细究各种 DAG 实现之间的区别，不过对于当时的 Tez 和 Oozie 来说，大多还是批处理的任务。 n 批处理 n 1个Tez = MR(1) + MR(2) + ... + MR(n) n 相比MR效率有所提升 l 第3代——Spark 接下来就是以 Spark 为代表的第三代的计算引擎。第三代计算引擎的特点主要是 Job 内部的 DAG 支持（不跨越 Job），以及强调的实时计算。在这里，很多人也会认为第三代计算引擎也能够很好的运行批处理的 Job。 n 批处理、流处理、SQL高层API支持 n 自带DAG n 内存迭代计算、性能较之前大幅提升 l 第4代——Flink 随着第三代计算引擎的出现，促进了上层应用快速发展，例如各种迭代计算的性能以及对流计算和 SQL 等的支持。Flink 的诞生就被归在了第四代。这应该主要表现在 Flink 对流计算的支持，以及更一步的实时性上面。当然 Flink 也可以支持 Batch 的任务，以及 DAG 的运算。 n 批处理、流处理、SQL高层API支持 n 自带DAG n 流式计算性能更高、可靠性更高 3.2 什么是Flink l Flink诞生背景 n Flink起源于Stratosphere项目，Stratosphere是在2010~2014年由地处柏林的大学和欧洲的一些其他的大学共同进行的研究项目 n 2014年4月捐赠给了Apache软件基金会 n 2014年12月成为Apache软件基金会的顶级项目。 l LOGO介绍 在德语中，Flink一词表示快速和灵巧，项目采用松鼠的彩色图案作为logo，Flink的松鼠logo尾巴的颜色与Apache软件基金会的logo颜色相呼应，也就是说，这是一只Apache风格的松鼠。 图 Flink Logo l 官网地址: https://flink.apache.org/ l Flink概述 Flink主页在其顶部展示了该项目的理念：“Apache Flink是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架”。 Flink是一款分布式的计算引擎，它可以用来做流处理;也可以用来做批处理 l 哪些公司在使用Flink 3.3 富二代Flink 随着人工智能时代的降临，数据量的爆发，在典型的大数据的业务场景下数据业务最通用的做法是：选用批处理的技术处理全量数据，采用流式计算处理实时增量数据。在绝大多数的业务场景之下，用户的业务逻辑在批处理和流处理之中往往是相同的。但是，用户用于批处理和流处理的两套计算引擎是不同的。因此，用户通常需要写两套代码。毫无疑问，这带来了一些额外的负担和成本。阿里巴巴的商品数据处理就经常需要面对增量和全量两套不同的业务流程问题，所以阿里就在想，我们能不能有一套统一的大数据引擎技术，用户只需要根据自己的业务逻辑开发一套代码。这样在各种不同的场景下，不管是全量数据还是增量数据，亦或者实时处理，一套方案即可全部支持，这就是阿里选择 Flink 的背景和初衷。 2015 年阿里巴巴开始使用 Flink 并持续贡献社区(阿里内部还基于Flink做了一套Blink)，2019年1月8日，阿里巴巴以 9000 万欧元(7亿元人民币)收购了创业公司 Data Artisans。从此Flink开始了新一轮的乘风破浪！ 3.4 Flink中的批和流 批处理的特点是有界、持久、大量，非常适合需要访问全部记录才能完成的计算工作，一般用于离线统计。 流处理的特点是无界、实时, 无需针对整个数据集执行操作，而是对通过系统 传输的每个数据项执行操作，一般用于实时统计。 而在Flink中，一切都是由流组成的，Flink认为有界数据集是无界数据流的一种特例，离线数据是有界限的流，实时数据是一个没有界限的流，这就是所谓的有界流和无界流。 无界流：意思很明显，只有开始没有结束。必须连续的处理无界流数据，也即是在事件注入之后立即要对其进行处理。不能等待数据到达了再去全部处理，因为数据是无界的并且永远不会结束数据注入。处理无界流数据往往要求事件注入的时候有一定的顺序性，例如可以以事件产生的顺序注入，这样会使得处理结果完整。 有界流：也即是有明确的开始和结束的定义。有界流可以等待数据全部注入完成了再开始处理。注入的顺序不是必须的了，因为对于一个静态的数据集，我们是可以对其进行排序的。有界流的处理也可以称为批处理。 3.5 性能比较 首先，我们可以通过下面的性能测试初步了解两个框架的性能区别，它们都可以基于内存计算框架进行实时计算，所以都拥有非常好的计算性能。经过测试，Flink计算性能上略好。 l 测试环境：  n CPU：7000个；  n 内存：单机128GB；  n 版本：Hadoop 2.3.0，Spark 1.4，Flink 0.9  n 数据：800MB，8GB，8TB；  n 算法：K-means：以空间中K个点为中心进行聚类，对最靠近它们的对象归类。通过迭代的方法，逐次更新各聚类中心的值，直至得到最好的聚类结果。  n 迭代：K=10，3组数据  l 测试结果: 纵坐标是秒，横坐标是次数 Spark和Flink全部都运行在Hadoop YARN上，性能为Flink > Spark > Hadoop(MR)，迭代次数越多越明显，性能上，Flink优于Spark和Hadoop最主要的原因是Flink支持增量迭代，具有对迭代自动优化的功能 3.6 Flink流处理特性 l 支持高吞吐、低延迟、高性能的流处理 l 支持带有事件时间的窗口（Window）操作 l 支持有状态计算的Exactly-once语义 l 支持高度灵活的窗口（Window）操作，支持基于time、count、session，以及data-driven的窗口操作 l 支持具有Backpressure功能的持续流模型 l 支持基于轻量级分布式快照（Snapshot）实现的容错 l 一个运行时同时支持Batch on Streaming处理和Streaming处理 l Flink在JVM内部实现了自己的内存管理 l 支持迭代计算 l 支持程序自动优化：避免特定情况下Shuffle、排序等昂贵操作，中间结果有必要进行缓存 3.7 发展历史 l 2008年，Flink 的前身已经是柏林理工大学一个研究性项目，原名 StratoSphere。 l 2014-04-16，Flink成为 ASF（Apache Software Foundation）的顶级项目之一，从Stratosphere 0.6开始，正式更名为Flink。由Java语言编写； l 2014-11-04，Flink 0.7.0发布，介绍了最重要的特性：Streaming API l 2016-03-08，Flink 1.0.0，支持Scala l 2019-01-08，阿里巴巴以9000万欧元的价格收购了总部位于柏林的初创公司Data Artisans，也就是Flink的母公司 l 最新版本已经到了1.13.1 本次课程基于flink-1.13.1开发 3.8 Flink的优势 flink 通过实现了 Google Dataflow 流式计算模型实现了高吞吐、低延迟、高性能兼具实时流式计算框架。 同时 flink 支持高度容错的状态管理，防止状态在计算过程中因为系统异常而丢失，flink 周期性地通过分布式快照技术 Checkpoints 实现状态的持久化维护，使得即使在系统停机或者异常情况下都能计算出正确的结果。 具体的优势有以下几点 l 同时支持高吞吐、低延迟、高性能 l 支持事件时间（Event Time）概念 l 支持有状态计算 l 支持高度灵活的窗口（Window）操作 l 基于轻量级分布式快照（Snapshot）实现的容错 l 基于 JVM 实现的独立的内存管理 l Save Points 保存点 3.9 Flink用武之地 https://flink.apache.org/zh/usecases.html 从很多公司的应用案例发现，其实Flink主要用在如下三大场景： 3.9.1 Event-driven Applications【事件驱动】 事件驱动型应用是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作。 事件驱动型应用是在计算存储分离的传统应用基础上进化而来。 在传统架构中，应用需要读写远程事务型数据库。 相反，事件驱动型应用是基于状态化流处理来完成。在该设计中，数据和计算不会分离，应用只需访问本地(内存或磁盘)即可获取数据。 系统容错性的实现依赖于定期向远程持久化存储写入 checkpoint。下图描述了传统应用和事件驱动型应用架构的区别。 从某种程度上来说，所有的实时的数据处理或者是流式数据处理都应该是属于Data Driven，流计算本质上是Data Driven 计算。应用较多的如风控系统，当风控系统需要处理各种各样复杂的规则时，Data Driven 就会把处理的规则和逻辑写入到Datastream 的API 或者是ProcessFunction 的API 中，然后将逻辑抽象到整个Flink 引擎，当外面的数据流或者是事件进入就会触发相应的规则，这就是Data Driven 的原理。在触发某些规则后，Data Driven 会进行处理或者是进行预警，这些预警会发到下游产生业务通知，这是Data Driven 的应用场景，Data Driven 在应用上更多应用于复杂事件的处理。 典型实例： l 欺诈检测(Fraud detection) l 异常检测(Anomaly detection) l 基于规则的告警(Rule-based alerting) l 业务流程监控(Business process monitoring) l Web应用程序(社交网络) 3.9.2 Data Analytics Applications【数据分析】 数据分析任务需要从原始数据中提取有价值的信息和指标。 如下图所示，Apache Flink 同时支持流式及批量分析应用。 Data Analytics Applications包含Batch analytics(批处理分析)和Streaming analytics(流处理分析) Batch analytics可以理解为周期性查询：Batch Analytics 就是传统意义上使用类似于Map Reduce、Hive、Spark Batch 等，对作业进行分析、处理、生成离线报表。比如Flink应用凌晨从Recorded Events中读取昨天的数据，然后做周期查询运算，最后将数据写入Database或者HDFS，或者直接将数据生成报表供公司上层领导决策使用。 Streaming analytics可以理解为连续性查询：比如实时展示双十一天猫销售GMV(Gross Merchandise Volume成交总额)，用户下单数据需要实时写入消息队列，Flink 应用源源不断读取数据做实时计算，然后不断的将数据更新至Database或者K-VStore，最后做大屏实时展示。 典型实例 l 电信网络质量监控 l 移动应用中的产品更新及实验评估分析 l 消费者技术中的实时数据即席分析 l 大规模图分析 3.9.3 Data Pipeline Applications【数据管道】 什么是数据管道？ 提取-转换-加载(ETL)是一种在存储系统之间进行数据转换和迁移的常用方法。 ETL 作业通常会周期性地触发，将数据从事务型数据库拷贝到分析型数据库或数据仓库。 数据管道和 ETL 作业的用途相似，都可以转换、丰富数据，并将其从某个存储系统移动到另一个。 但数据管道是以持续流模式运行，而非周期性触发。 因此数据管道支持从一个不断生成数据的源头读取记录，并将它们以低延迟移动到终点。 例如：数据管道可以用来监控文件系统目录中的新文件，并将其数据写入事件日志；另一个应用可能会将事件流物化到数据库或增量构建和优化查询索引。 和周期性 ETL 作业相比，持续数据管道可以明显降低将数据移动到目的端的延迟。 此外，由于它能够持续消费和发送数据，因此用途更广，支持用例更多。 下图描述了周期性ETL作业和持续数据管道的差异。 Periodic ETL：比如每天凌晨周期性的启动一个Flink ETL Job，读取传统数据库中的数据，然后做ETL，最后写入数据库和文件系统。 Data Pipeline：比如启动一个Flink 实时应用，数据源(比如数据库、Kafka)中的数据不断的通过Flink Data Pipeline流入或者追加到数据仓库(数据库或者文件系统)，或者Kafka消息队列。 Data Pipeline 的核心场景类似于数据搬运并在搬运的过程中进行部分数据清洗或者处理，而整个业务架构图的左边是Periodic ETL，它提供了流式ETL 或者实时ETL，能够订阅消息队列的消息并进行处理，清洗完成后实时写入到下游的Database或File system 中。 典型实例 l 电子商务中的持续 ETL(实时数仓) 当下游要构建实时数仓时，上游则可能需要实时的Stream ETL。这个过程会进行实时清洗或扩展数据，清洗完成后写入到下游的实时数仓的整个链路中，可保证数据查询的时效性，形成实时数据采集、实时数据处理以及下游的实时Query。 l 电子商务中的实时查询索引构建(搜索引擎推荐) 搜索引擎这块以淘宝为例，当卖家上线新商品时，后台会实时产生消息流，该消息流经过Flink 系统时会进行数据的处理、扩展。然后将处理及扩展后的数据生成实时索引，写入到搜索引擎中。这样当淘宝卖家上线新商品时，能在秒级或者分钟级实现搜索引擎的搜索。 3.10 扩展阅读：Flink发展现状 3.10.1 Flink在全球 Flink近年来逐步被人们所熟知,不仅是因为Flink提供同时支持高吞吐/低延迟和Exactly-Once语义的实时计算能力,同时Flink还提供了基于流式计算引擎处理批量数据的计算能力,真正意义上实现批流统一 同时随着阿里对Blink的开源,极大地增强了Flink对批计算领域的支持.众多优秀的特性,使得Flink成为开源大数据处理框架中的一颗新星,随着国内社区的不断推动,越来越多的公司开始选择使用Flink作为实时数据处理技术,在不久的将来,Flink也将会成为企业内部主流的数据处理框架,最终成为下一代大数据处理的标准. 3.10.2 Flink在中国 Flink在很多公司的生产环境中得到了使用, 例如: ebay, 腾讯, 阿里, 亚马逊, 华为等 3.10.3 Flink在阿里 阿里自15年起开始调研开源流计算引擎，最终决定基于Flink打造新一代计算引擎，阿里贡献了数百个commiter，并对Flink进行高度定制，并取名为Blink， 阿里是Flink SQL的最大贡献者，一半以上的功能都是阿里的工程师开发的，基于Apache Flink在阿里巴巴搭建的平台于2016年正式上线，并从阿里巴巴的搜索和推荐这两大场景开始实现。 2019年Flink的母公司被阿里7亿元全资收购，阿里一直致力于Flink在国内的推广使用，目前阿里巴巴所有的业务，包括阿里巴巴所有子公司都采用了基于Flink搭建的实时计算平台。 同时Flink计算平台运行在开源的Hadoop集群之上，采用Hadoop的YARN做为资源管理调度，以 HDFS作为数据存储。因此，Flink可以和开源大数据软件Hadoop无缝对接。 目前，这套基于Flink搭建的实时计算平台不仅服务于阿里巴巴集团内部，而且通过阿里云的云产品API向整个开发者生态提供基于Flink的云产品支持。 l 主要包含四个模块：实时监控、实时报表、流数据分析和实时仓库 n 实时监控： - 用户行为预警、app crash 预警、服务器攻击预警 - 对用户行为或者相关事件进行实时监测和分析，基于风控规则进行预警、复杂事件处理 n 实时报表： - 双11、双12等活动直播大屏 - 对外数据产品：生意参谋等 - 数据化运营 n 流数据分析： - 实时计算相关指标反馈及时调整决策 - 内容投放、无线智能推送、实时个性化推荐等 n 实时仓库/ETL： - 数据实时清洗、归并、结构化 - 数仓的补充和优化 l Flink在阿里巴巴的大规模应用表现如何？ n 规模：一个系统是否成熟，规模是重要指标，Flink最初上线阿里巴巴只有数百台服务器，目前规模已达上万台，此等规模在全球范围内也是屈指可数； n 状态数据：基于Flink，内部积累起来的状态数据已经是PB级别规模； n Events：如今每天在Flink的计算平台上，处理的数据已经超过十万亿条; n TPS：在峰值期间可以承担每秒超过17亿次的访问，最典型的应用场景是阿里巴巴双11大屏； 3.10.4 Flink在腾讯 3.10.5 Flink在美团 3.11 扩展阅读：为什么选择Flink？ l 主要原因 n Flink 具备统一的框架处理有界和无界两种数据流的能力 n 部署灵活，Flink 底层支持多种资源调度器，包括Yarn、Kubernetes 等。Flink 自身带的Standalone 的调度器，在部署上也十分灵活。 n 极高的可伸缩性，可伸缩性对于分布式系统十分重要，阿里巴巴双11大屏采用Flink 处理海量数据，使用过程中测得Flink 峰值可达17 亿条/秒。 n 极致的流式处理性能。Flink 相对于Storm 最大的特点是将状态语义完全抽象到框架中，支持本地状态读取，避免了大量网络IO，可以极大提升状态存取的性能。 l 其他更多的原因: n 同时支持高吞吐、低延迟、高性能 Flink 是目前开源社区中唯一一套集高吞吐、低延迟、高性能三者于一身的分布式流式数据处理框架。 Spark 只能兼顾高吞吐和高性能特性，无法做到低延迟保障,因为Spark是用批处理来做流处理 Storm 只能支持低延时和高性能特性，无法满足高吞吐的要求 下图显示了 Apache Flink 与 Apache Storm 在完成流数据清洗的分布式任务的性能对比。 n 支持事件时间(Event Time)概念 在流式计算领域中，窗口计算的地位举足轻重，但目前大多数框架窗口计算采用的都是系统时间(Process Time)，也就是事件传输到计算框架处理时，系统主机的当前时间。 Flink 能够支持基于事件时间(Event Time)语义进行窗口计算 这种基于事件驱动的机制使得事件即使乱序到达甚至延迟到达，流系统也能够计算出精确的结果，保持了事件原本产生时的时序性，尽可能避免网络传输或硬件系统的影响。 n 支持有状态计算 Flink1.4开始支持有状态计算 所谓状态就是在流式计算过程中将算子的中间结果保存在内存或者文件系统中，等下一个事件进入算子后可以从之前的状态中获取中间结果，计算当前的结果，从而无须每次都基于全部的原始数据来统计结果，极大的提升了系统性能，状态化意味着应用可以维护随着时间推移已经产生的数据聚合 n 支持高度灵活的窗口(Window)操作 Flink 将窗口划分为基于 Time 、Count 、Session、以及Data-Driven等类型的窗口操作，窗口可以用灵活的触发条件定制化来达到对复杂的流传输模式的支持，用户可以定义不同的窗口触发机制来满足不同的需求 n 基于轻量级分布式快照(Snapshot/Checkpoints)的容错机制 Flink 能够分布运行在上千个节点上，通过基于分布式快照技术的Checkpoints，将执行过程中的状态信息进行持久化存储，一旦任务出现异常停止，Flink 能够从 Checkpoints 中进行任务的自动恢复，以确保数据处理过程中的一致性 Flink 的容错能力是轻量级的，允许系统保持高并发，同时在相同时间内提供强一致性保证。 n 基于 JVM 实现的独立的内存管理 Flink 实现了自身管理内存的机制，通过使用散列，索引，缓存和排序有效地进行内存管理，通过序列化/反序列化机制将所有的数据对象转换成二进制在内存中存储，降低数据存储大小的同时，更加有效的利用空间。使其独立于 Java 的默认垃圾收集器，尽可能减少 JVM GC 对系统的影响。 n SavePoints 保存点 对于 7 * 24 小时运行的流式应用，数据源源不断的流入，在一段时间内应用的终止有可能导致数据的丢失或者计算结果的不准确。 比如集群版本的升级，停机运维操作等。 值得一提的是，Flink 通过SavePoints 技术将任务执行的快照保存在存储介质上，当任务重启的时候，可以从事先保存的 SavePoints 恢复原有的计算状态，使得任务继续按照停机之前的状态运行。 Flink 保存点提供了一个状态化的版本机制，使得能以无丢失状态和最短停机时间的方式更新应用或者回退历史数据。 n 灵活的部署方式，支持大规模集群 Flink 被设计成能用上千个点在大规模集群上运行 除了支持独立集群部署外，Flink 还支持 YARN 和Mesos 方式部署。 n Flink 的程序内在是并行和分布式的 数据流可以被分区成 stream partitions， operators 被划分为operator subtasks; 这些 subtasks 在不同的机器或容器中分不同的线程独立运行； operator subtasks 的数量就是operator的并行计算数，不同的 operator 阶段可能有不同的并行数； 如下图所示，source operator 的并行数为 2，但最后的 sink operator 为1； n 丰富的库 Flink 拥有丰富的库来进行机器学习，图形处理，关系数据处理等。 3.12 扩展阅读：大数据框架发展史 这几年大数据的飞速发展，出现了很多热门的开源社区，其中著名的有 Hadoop、Storm，以及后来的 Spark，他们都有着各自专注的应用场景。Spark 掀开了内存计算的先河，也以内存为赌注，赢得了内存计算的飞速发展。Spark 的火热或多或少的掩盖了其他分布式计算的系统身影。就像 Flink，也就在这个时候默默的发展着。 在国外一些社区，有很多人将大数据的计算引擎分成了 4 代，当然，也有很多人不会认同。我们先姑且这么认为和讨论。 l 第1代——Hadoop MapReduce 首先第一代的计算引擎，无疑就是 Hadoop 承载的 MapReduce。它将计算分为两个阶段，分别为 Map 和 Reduce。对于上层应用来说，就不得不想方设法去拆分算法，甚至于不得不在上层应用实现多个 Job 的串联，以完成一个完整的算法，例如迭代计算。 n 批处理 n Mapper、Reducer l 第2代——DAG框架（Tez） + MapReduce 由于这样的弊端，催生了支持 DAG 框架的产生。因此，支持 DAG 的框架被划分为第二代计算引擎。如 Tez 以及更上层的 Oozie。这里我们不去细究各种 DAG 实现之间的区别，不过对于当时的 Tez 和 Oozie 来说，大多还是批处理的任务。 n 批处理 n 1个Tez = MR(1) + MR(2) + ... + MR(n) n 相比MR效率有所提升 l 第3代——Spark 接下来就是以 Spark 为代表的第三代的计算引擎。第三代计算引擎的特点主要是 Job 内部的 DAG 支持（不跨越 Job），以及强调的实时计算。在这里，很多人也会认为第三代计算引擎也能够很好的运行批处理的 Job。 n 批处理、流处理、SQL高层API支持 n 自带DAG n 内存迭代计算、性能较之前大幅提升 l 第4代——Flink 随着第三代计算引擎的出现，促进了上层应用快速发展，例如各种迭代计算的性能以及对流计算和 SQL 等的支持。Flink 的诞生就被归在了第四代。这应该主要表现在 Flink 对流计算的支持，以及更一步的实时性上面。当然 Flink 也可以支持 Batch 的任务，以及 DAG 的运算。 n 批处理、流处理、SQL高层API支持 n 自带DAG n 流式计算性能更高、可靠性更高 3.13 扩展阅读：流批统一 在大数据处理领域，批处理任务与流处理任务一般被认为是两种不同的任务，一个大数据框架一般会被设计为只能处理其中一种任务： MapReduce只支持批处理任务； Storm只支持流处理任务； Spark Streaming采用micro-batch架构，本质上还是基于Spark批处理对流式数据进行处理 Flink通过灵活的执行引擎，能够同时支持批处理任务与流处理任务 在执行引擎这一层，流处理系统与批处理系统最大不同在于节点间的数据传输方式： l 对于一个流处理系统，其节点间数据传输的标准模型是：当一条数据被处理完成后，序列化到缓存中，然后立刻通过网络传输到下一个节点，由下一个节点继续处理 l 对于一个批处理系统，其节点间数据传输的标准模型是：当一条数据被处理完成后，序列化到缓存中，并不会立刻通过网络传输到下一个节点，当缓存写满，就持久化到本地硬盘上，当所有数据都被处理完成后，才开始将处理后的数据通过网络传输到下一个节点 这两种数据传输模式是两个极端，对应的是流处理系统对低延迟的要求和批处理系统对高吞吐量的要求 Flink的执行引擎采用了一种十分灵活的方式，同时支持了这两种数据传输模型： Flink以固定的缓存块为单位进行网络数据传输，用户可以通过设置缓存块超时值指定缓存块的传输时机。 如果缓存块的超时值为0，则Flink的数据传输方式类似上文所提到流处理系统的标准模型，此时系统可以获得最低的处理延迟 如果缓存块的超时值为无限大/-1，则Flink的数据传输方式类似上文所提到批处理系统的标准模型，此时系统可以获得最高的吞吐量 同时缓存块的超时值也可以设置为0到无限大之间的任意值。缓存块的超时阈值越小，则Flink流处理执行引擎的数据处理延迟越低，但吞吐量也会降低，反之亦然。通过调整缓存块的超时阈值，用户可根据需求