fink介绍

flink
1.Flink概述
1.1.Flink是一个批处理和流处理结合的统一计算框架，其核心是一个提供了数据分发以及并行化计算的流数据处理引擎。它的最大亮点是流处理，是业界最顶级的开源流处理引擎。
1.2.Flink与Storm类似，属于事件驱动型实时流系统。
2.Flink特点
2.1.Performance
2.2.性能，高吞吐量，低延迟
2.3.Scalable
2.4.可扩展性，1000节点以上
2.5.Fault-tolerant
2.6.容错，可靠性，checkpoint
2.7.Streaming-first
2.8.流处理引擎
3.Flink应用场景
3.1.Flink最适合的应用场景是低时延的数据处理场景：高并发处理数据，时延毫秒级，且兼具可靠性。
3.2.典型应用场景有：
3.3.互联网金融业务。
3.4.点击流日志处理。
3.5.舆情监控。
4.Flink关键特性
4.1.低时延
4.2.提供ms级时延的处理能力。
4.3.Exactly Once
4.4.提供异步快照机制，保证所有数据真正只处理一次。
4.5.HA
4.6.JobManager支持主备模式，保证无单点故障。
4.7.水平扩展能力
4.8.TaskManager支持手动水平扩展。
5.Hadoop兼容性
5.1.Flink能够支持Yarn，能够从HDFS和HBase中获取数据；
5.2.能够使用所有的Hadoop的格式化输入和输出；
5.3.能够使用Hadoop原有的Mappers和Reducers，并且能与Flink的操作混合使用；
5.4.能够更快的运行Hadoop的作业。
6.流式计算框架的性能对比
6.1.上图中蓝色柱形为单线程 Storm 作业的吞吐，橙色柱形为单线程 Flink 作业的吞吐。Identity 逻辑下，Storm 单线程吞吐为 8.7 万条/秒，Flink 单线程吞吐可达 35 万条/秒。当 Kafka Data 的 Partition 数为 1 时，Flink 的吞吐约为 Storm 的 3.2 倍;当其 Partition 数为 8 时，Flink 的吞吐约为 Storm 的 4.6 倍。由此可以看出，Flink 吞吐约为 Storm 的 3-5 倍。
7.Flink架构
7.1.Data storage底层是数据存储
7.2.Single node execution表示的是部署方式
7.3.Local Environment等表示的是不同的运行环境
7.4.Flink Local Runtime表示是运行线程
7.5.Flink Optimizer，Flink Stream Builder等表示的是优化器
7.6.Common API表示的是Flink平台的API
7.7.Scala API和Java API表示的是对外提供的API
8.Flink技术栈
8.1.Flink提供了三种部署方案local，Cluster，Cloud即：本地部署，集群部署和云部署。
8.2.Runtime层是Flink流处理以及批处理时共用的一个引擎，以JobGraph形式接收程序。JobGraph即为一个一般化的并行数据流图（data flow），它拥有任意数量的Task来接收和产生data stream。
8.3.DataStream API和DataSet API都会使用单独编译的处理方式生成JobGraph。DataSet API使用optimizer来决定针对程序的优化方法，而DataStream API则使用stream builder来完成该任务。
8.4.Libraries层对应的是Flink不同的API对应的一些功能：处理逻辑表查询的Table，机器学习的FlinkML，图像处理的Gelly，复杂事件处理的CEP。
9.Flink核心概念 - DataStream
9.1.DataStream：Flink用类DataStream来表示程序中的流式数据。用户可以认为它们是含有重复数据的不可修改的集合(collection)，DataStream中元素的数量是无限的。
9.2.这里主要介绍了DataStream之间的算子操作
9.3.含有Window的是窗口操作，与后面的窗口操作相关连，之间的关系可以通过reduce，fold，sum，max函数进行管关联。
9.4.connect：进行Stream之间的连接，可以通过flatmap，map函数进行操作。
9.5.JoinedStream ：进行Stream之间的join操作，类似于数据库中的join，可以通过join函数等进行关联。
9.6.CoGroupedStream：Stream之间的联合，类似于关系数据库中的group操作，可以通过coGroup函数进行关联。
9.7.KeyedStream：主要是对数据流依据key进行处理，可以通过keyBy函数进行处理。
10.DataStream
10.1.Data source：流数据源的接入，支持HDFS文件、kafka、文本数据等。
10.2.Transformations：流数据转换。
10.3.Data sink：数据输出，支持HDFS、kafka、文本等。
10.4.Data source：流数据源的接入，支持HDFS文件、kafka、文本数据等
11.Flink数据源
11.1.批处理
11.2.Files
11.3.HDFS，Local file system，MapR file system
11.4.Text，Csv，Avro，Hadoop input formats
11.5.JDBC
11.6.HBase
11.7.Collections
11.8.流处理
11.9.Files
11.10.Socket streams
11.11.Kafka
11.12.RabbitMQ
11.13.Flume
11.14.Collections
11.15.Implement your own
11.16.SourceFunction.collect
12.DataStream Transformation
12.1.数据流转换流程与Spark类似：
12.2.从HDFS读取数据到DataStream中
12.3.接下来进行相关算子操作，如flatMap,Map,keyBy
12.4.接下来是窗口操作或算子操作
12.5.最后处理结果sink到HDFS
13.Flink应用运行流程 - 关键角色
13.1.TaskManager：
13.2.负责实际计算工作，一个应用会分拆给多个TaskManager来进行计算。
13.3.Yarn的ResourceManager：
13.4.资源管理部门，负责整个集群的资源统一调度和分配。
13.5.JobManager：
13.6.负责应用的资源管理，根据应用的需要，
13.7.向资源管理部门（ResourceManager）申请资源
13.8.Client：
13.9.需求提出方，负责提交需求（应用），构造流图
14.Flink作业运行流程
14.1.Client：Flink Client主要给用户提供向Flink系统提交用户任务（流式作业）的能力。
14.2.TaskManager：Flink系统的业务执行节点，执行具体的用户任务。TaskManager可以有多个，各个TaskManager都平等。
14.3.JobManager：Flink系统的管理节点，管理所有的TaskManager，并决策用户任务在哪些Taskmanager执行。JobManager在HA模式下可以有多个，但只有一个主JobManager。
14.4.TaskSlot（任务槽）类似yarn中的container用于资源隔离，但是该组件只包含内存资源，不包含cpu资源。每一个TaskManager当中包含3个Task Slot，TaskManager最多能同时并发执行的任务是可以控制的，那就是3个,因为不能超过slot的数量。 slot有独占的内存空间，这样在一个TaskManager中可以运行多个不同的作业，作业之间不受影响。slot之间可以共享JVM资源, 可以共享Dataset和数据结构，也可以通过多路复用（Multiplexing） 共享TCP连接和心跳消息（Heatbeat Message）。
14.5.Task任务执行的单元。
15.Flink on YARN
15.1.Flink YARN Client首先会检验是否有足够的资源来启动YARN集群，如果资源足够的话，会将jar包、配置文件等上传到HDFS。
15.2.Flink YARN Client首先与YARN Resource Manager进行通信，申请启动ApplicationMaster（以下简称AM）。在Flink YARN的集群中，AM与Flink JobManager在同一个Container中。
15.3.AM在启动的过程中会和YARN的RM进行交互，向RM申请需要的Task ManagerContainer，申请到Task Manager Container后，在对应的NodeManager节点上启动TaskManager进程。
15.4.AM与Fink JobManager在同一个container中，AM会将JobManager的RPC地址通过HDFS共享的方式通知各个TaskManager，TaskManager启动成功后，会向JobManager注册。
15.5.等所有TaskManager都向JobManager注册成功后，Flink基于YARN的集群启动成功，Flink YARN Client就可以提交Flink Job到Flink JobManager，并进行后续的映射、调度和计算处理
16.Flink原理 (1)
16.1.用户实现的Flink程序是由Stream数据和Transformation算子组成。
16.2.Stream是一个中间结果数据，而Transformation是算子，它对一个或多个输入Stream进行计算处理，输出一个或多个结果Stream。
17.Flink原理 (2)
17.1.Source操作符载入数据，通过map()、keyBy()、apply()等Transformation 操作符处理stream。数据处理完成后，调用sink写入相关存储系统，如hdfs、hbase、kafka等。
17.2.Flink程序执行时，它会被映射为Streaming Dataflow。一个Streaming Dataflow是由一组Stream和Transformation Operator组成，它类似于一个DAG图，在启动的时候从一个或多个Source Operator开始，结束于一个或多个Sink Operator。
17.3.Source：流数据源的接入，支持HDFS文件、kafka、文本数据等。
17.4.Sink：数据输出，支持HDFS、kafka、文本等。
17.5.Stream是Flink计算流程中产生的中间数据。Flink是按event驱动的，每个event都有一个event time就是事件的时间戳，表明事件发生的时间，这个时间戳对Flink的处理性能很重要，后面会讲到Flink处理乱序数据流时，就是靠时间戳来判断处理的先后顺序。
18.Flink并行数据流
18.1.一个Stream可以被分成多个Stream分区（Stream Partitions），一个Operator可以被分成多个Operator Subtask，每一个Operator Subtask是在不同的线程中独立执行的。一个Operator的并行度，等于Operator Subtask的个数，一个Stream的并行度等于生成它的Operator的并行度。
18.2.One-to-one模式
18.3.比如从Source[1]到map()[1]，它保持了Source的分区特性（Partitioning）和分区内元素处理的有序性，也就是说map()[1]的Subtask看到数据流中记录的顺序，与Source[1]中看到的记录顺序是一致的。
18.4.Redistribution模式
18.5.这种模式改变了输入数据流的分区，比如从map()[1]、map()[2]到keyBy()/window()/apply()[1]、keyBy()/window()/apply()[2]，上游的Subtask向下游的多个不同的Subtask发送数据，改变了数据流的分区，这与实际应用所选择的Operator有关系。 Subtask的个数，一个Stream的并行度总是等于生成它的Operator的并行度。
19.Flink操作符链
19.1.Flink内部有一个优化的功能，根据上下游算子的紧密程度来进行优化。紧密度高的算子可以进行优化，优化后可以将多个Operator Subtask串起来组成一个Operator Chain，实际上就是一个执行链，每个执行链会在TaskManager上一个独立的线程中执行。
19.2.上半部分表示的是将两个紧密度高的算子优化后串成一个Operator Chain，实际上一个Operator Chain就是一个大的Operator的概念。途中的Operator Chain表示一个Operator，keyBy表示一个Operator，Sink表示一个Operator，他们通过Stream连接，而每个Operator在运行时对应一个Task，也就是说图中的上半部分3个Operator对应的是3个Task。
19.3.下半部分是上半部分的一个并行版本，对每一个Task都并行华为多个Subtask，这里只是演示了2个并行度，sink算子是1个并行度。
20.Flink窗口
20.1.Flink支持基于时间窗口操作，也支持基于数据的窗口操作：
20.2.按分割标准划分：timeWindow、countWindow。
20.3.按窗口行为划分：Tumbling Window、Sliding Window、自定义窗口。
20.4.窗口按驱动的类型分为时间窗口（timeWindow）和事件窗口（countWindow）。窗口可以是时间驱动的（Time Window，例如：每30秒钟），也可以是数据驱动的（Count Window，例如：每一百个元素）。
20.5.窗口按照其想要实现的功能分为：翻滚窗口（Tumbling Window，无时间重叠，固定时间划分或者固定事件个数划分），滚动窗口（Sliding Window，有时间重叠），和会话窗口（Session Window，将事件聚合到会话窗口中，由非活跃的间隙分隔开）。
21.Flink常用窗口类型 (1)
21.1.按照固定的时间来划分窗口，叫做时间滚动窗口。
21.2.按照固定的事件发生数量来划分窗口，叫做事件滚动窗口。
21.3.Tumbling Windows：滚动窗口，窗口之间时间点不重叠。
22.Flink常用窗口类型 (2)
22.1.滑动窗口，窗口之间时间点存在重叠
22.2.对于某些应用，它们需要的窗口是不间断的，需要平滑地进行窗口聚合。比如，我们可以每30秒计算一次最近一分钟用户购买的商品总数。这个就是时间滑动窗口。
22.3.比如我们可以每10个客户点击购买，计算一次最近100个客户购买商品的总和，这个就是事件滑动窗口。
23.Flink常用窗口类型 (3)
23.1.Session Windows：会话窗口，经过一段设置时间无数据认为窗口完成。
23.2.将事件聚合到会话窗口中，由非活跃的间隙分隔开
24.Flink容错功能
24.1.checkpoint机制是Flink运行过程中容错的重要手段。
24.2.checkpoint机制不断绘制流应用的快照，流应用的状态快照被保存在配置的位置（如：JobManager的内存里，或者HDFS上）。
24.3.Flink分布式快照机制的核心是barriers，这些barriers周期性插入到数据流中，并作为数据流的一部分随之流动。
24.4.barrier是一个特殊的元组，这些元组被周期性注入到流图中并随数据流在流图中流动。每个barrier是当前快照和下一个快照的分界线。
24.5.在同一条流中barriers并不会超越其前面的数据，严格的按照线性流动。一个barrier将属于本周期快照的数据与下一个周期快照的数据分隔开来。每个barrier均携带所属快照周期的ID，barrier并不会阻断数据流，因此十分轻量。
25.Checkpoint机制 (1)
25.1.Checkpoint机制是Flink可靠性的基石，可以保证Flink集群在某个算子因为某些原因（如异常退出）出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保证应用流图状态的一致性。
25.2.该机制可以保证应用在运行过程中出现失败时，应用的所有状态能够从某一个检查点恢复，保证数据仅被处理一次（Exactly Once）。另外，也可以选择至少处理一次(at least once)。
26.Checkpoint机制 (2)
26.1.每个需要checkpoint的应用在启动时，Flink的JobManager为其创建一个CheckpointCoordinator，CheckpointCoordinator全权负责本应用的快照制作。用户通过CheckpointConfig中的setCheckpointInterval()接口设置checkpoint的周期。
26.2.CheckPoint机制
26.3.CheckpointCoordinator周期性的向该流应用的所有source算子发送barrier。
26.4.当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理。
26.5.下游算子收到barrier之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自身快照情况，同时向自身所有下游算子广播该barrier，恢复数据处理。
26.6. 每个算子按照步骤3不断制作快照并向下游广播，直到最后barrier传递到sink算子，快照制作完成。
26.7.当CheckpointCoordinator收到所有算子的报告之后，认为该周期的快照制作成功；否则，如果在规定的时间内没有收到所有算子的报告，则认为本周期快照制作失败。
27.Checkpoint机制 (3)
27.1.多source源checkpoint机制，本页以双source源为例。
27.2.假设算子C有A和B两个输入源。
27.3.在第i个快照周期中，由于某些原因（如处理时延、网络时延等）输入源A发出的barrier先到来，这时算子C暂时将输入源A的输入通道阻塞，仅接收输入源B的数据。
27.4.当输入源B发出的barrier到来时，算子C制作自身快照并向CheckpointCoordinator报告自身的快照制作情况，然后将两个barrier合并为一个，向下游所有的算子广播。
27.5.当由于某些原因出现故障时，CheckpointCoordinator通知流图上所有算子统一恢复到某个周期的checkpoint状态，然后恢复数据流处理。分布式checkpoint机制保证了数据被处理且仅被处理一次（Exactly Once）。
28.Flink在FusionInsight产品的位置
28.1.FusionInsight HD 提供大数据处理环境，基于社区开源软件增强，按照场景选择业界最佳实践。Flink是批处理和流处理结合的统一计算框架 ,用于高并发pipeline处理数据，时延毫秒级的场景响应，且兼具可靠性。
29.Flink的WebUI呈现
29.1.FusionInsight HD平台为Flink服务提供了管理监控的可视化界面接口，通过Yarn的Web UI界面，可查看Flink任务运行。
30.Flink与其他组件交互
30.1.在FusionInsight HD集群中，Flink主要与以下组件进行交互：
30.2.HDFS：Flink在HDFS文件系统中读写数据(必选)。
30.3.YARN：Flink任务的运行依赖Yarn来进行资源的调度管理(必选)。
30.4.Zookeeper：Flink的checkpoint的实现依赖于Zookeeper(必选)。
30.5.Kafka：Flink可以接收Kafka发送的数据流(可选)。
30.6.