Flink 原理与项目实战

转存失败重新上传取消

一、Flink 是什么

       Flink 能解决什么问题

         如某业务服务性抽审逻辑： 按照窗口统计24小时内的接单数量，然后根据接单数量实时按照抽审比率进行抽审。

         实现方式一

               方案： 定时任务按照时间区间扫描表，统计接诊数量，按照比率抽审，校验抽审比率，防止超抽或少抽，记录抽审问题单。

               问题： 大量快递员，大量问题。扫码主表对业务压力过大。且实现逻辑复杂。

        实现方式二

              方案二   采用redis 的zset 按照时间排序，手动实现滑动窗口，进行统计。

              问题： 实现逻辑复杂，且redis 停机故障后，实时产生的数据无法统计。

        实现方式 more ?

           是否有一种实时窗口，能统计接诊量，并独立记录已经抽审的问题，避免主干业务压力，中间结果数据无执行记录 ？

       Flink 介绍

          Flink是新的stream计算引擎，用java实现。既可以处理stream data也可以处理batch data，可以同时兼顾Spark以及Spark streaming的功能，与Spark不同的是，Flink本质上只有stream的概念，batch被认为是special stream。Flink在运行中主要有三个组件组成，JobClient，JobManager 和 TaskManager。主要工作原理如下图   
       

     用户首先提交Flink程序到JobClient，经过JobClient的处理、解析、优化提交到JobManager，最后由TaskManager运行task。

     

二、Flink 特点

         

      2.1 批流一体

           处理有界数据、无界数据。

      2.2 可靠的容错能力

           集群级容错

                   集群管理器紧密集成。 如Hadoop YARN、Mesos或Kubernetes

                   高可用性设置。 消除单点故障。 HA 模式机遇Zookeeper。

           应用级容错

                一致性。 恢复机制基于应用程序状态的一致性检查点。支持Exactly-Once 语义。取保精确处理一次。

               轻量级 。检查点状态可能达到TB级，生成和保存成本高。Flink 提供了执行异步和增量检查点。

      2.3  高吞吐、低延迟。

      2.4 大规模复杂运算

      2.5 多平台部署。

三、Flink 架构

     3.1 技术架构

        Flink 主要由部署层、运行时层、API层、应用框架层、连接器组成。
                       

应用框架层

    Table&sql ， CEP（复杂事件处理），Gelly（图计算），ML（机器学习）等    

API层

    Flink基于流执行引擎，Flink提供了跟多高抽象层的API便于用户编写分布式任务。下面介绍常见的几种API；
  DataSet API: 对静态数据进行批处理作业，将静态数据抽象成分布式的数据集，用户可以方便的使用Flink提供的各种操作符对分布式数据集进行处理，支持Java,Scala和python；
  DataStream API：对数据流进行流处理作业，将流式的数据抽象成分布式的数据流，用户可以方面的对分布式数据流进行各种操作，支持Java，scala和python；
  Table API:对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过SQL的DSL对关系表进行各种查询操作，支持Java和Scala;
  SQL: SQL查询是使用TableEnvironment的sqlquery()方法执行的，该方法以SQL的形式返回SQL查询的结果。Table可以在后续的SQL和Table API查询中使用，可以转换诶DataSet和DataStream，也可以写入TableSink。SQL和Table API可以无缝的整合，进行整体优化并转换为单个程序。要访问SQL中查询的表，必须在TableEnvironment中注册他，可以从TableSource,Table,DataStream和DataSet注册表，用户也可以在TableEnvironment中注册外部目录以制定数据源的位置。Blink开源后，将使Flink SQL更加完善稳定。
  StateFul Stream Processing:最低级抽象只提供有状态流，通过Process Function嵌入到DataStream API中，它允许用户自由处理来自一个或者多个流的时间，并使用一致的容错状态，此外用户可以注册event time和processing time回调，允许程序实现复杂的计算。

       

  3.2 任务调度原理

                             

转存失败重新上传取消

            

      当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager，JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。

• Client 为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境连通即可）。提交 Job 后，Client 可以结束进程（Streaming的任务），也可以不结束并等待结果返回。
• JobManager 主要负责调度 Job 并协调 Task 做 checkpoint，职责上很像 Storm 的 Nimbus。从 Client 处接收到 Job 和 JAR 包等资源后，会生成优化后的执行计划，并以 Task 的单元调度到各个 TaskManager 去执行。
• TaskManager 在启动的时候就设置好了槽位数（Slot），每个 slot 能启动一个 Task，Task 为线程。从 JobManager 处接收需要部署的 Task，部署启动后，与自己的上游建立 Netty 连接，接收数据并处理。

       可以看到 Flink 的任务调度是多线程模型，并且不同Job/Task混合在一个 TaskManager 进程中。虽然这种方式可以有效提高 CPU 利用率，但它这种方式不仅缺乏资源隔离机制，同时也不方便调试。类似 Storm 的进程模型，一个JVM 中只跑该 Job 的 Tasks 实际应用中更为合理。

       

JobClient
JobClient是Flink程序和JobManager交互的桥梁，主要负责接收程序、解析程序的执行计划、优化程序的执行计划，然后提交执行计划到JobManager。为了了解Flink的解析过程，需要简单介绍一下Flink的Operator，在Flink主要有三类Operator，

         Source Operator ，顾名思义这类操作一般是数据来源操作，比如文件、socket、kafka等，一般存在于程序的最开始
        Transformation Operator 这类操作主要负责数据转换，map，flatMap，reduce等算子都属于Transformation Operator，
         Sink Operator，意思是下沉操作，这类操作一般是数据落地，数据存储的过程，放在Job最后，比如数据落地到Hdfs、Mysql、Kafka等等。 
Flink会将程序中每一个算计解析成Operator，然后按照算子之间的关系，将operator组合起来，形成一个Operator组合成的Graph。如下面的代码解析之后形成的执行计划，
DataStream<String> data = env.addSource(...);
data.map(x->new Tuple2(x,1)).keyBy(0).timeWindow(Time.seconds(60)).sum(1).addSink(...)

           

            解析形成执行计划之后，JobClient的任务还没有完，还负责执行计划的优化，这里执行的主要优化是将相邻的Operator融合，形成OperatorChain，因为Flink是分布式运行的，程序中每一个算子，在实际执行中被分隔为多个SubTask，数据流在算子之间的流动，就对应到SubTask之间的数据传递，SubTask之间进行数据传递模式有两种一种是one-to-one的，数据不需要重新分布，也就是数据不需要经过IO，节点本地就能完成，比如上图中的source到map，一种是re-distributed，数据需要通过shuffle过程重新分区，需要经过IO，比如上图中的map到keyBy。显然re-distributed这种模式更加浪费时间，同时影响整个Job的性能。所以，Flink为了提高性能，将one-to-one关系的前后两类subtask，融合形成一个task。而TaskManager中一个task运行一个独立的线程中，同一个线程中的SubTask进行数据传递，不需要经过IO，不需要经过序列化，直接发送数据对象到下一个SubTask，性能得到提升，除此之外，subTask的融合可以减少task的数量，提高taskManager的资源利用率。图1.0中的执行计划，优化结果如下图，Flink的subTask融合规则可以参考官方文档。
               （1） 值得注意的是，并不是每一个SubTask都可以被融合，对于不能融合的SubTask会独立形成一个Task运行在TaskManager中。
               （2）改变operator的并行度，可能会导致不同的优化结果，同时这也是性能调优的一个重要方式，例如不显式设置operator的并行度的时候，默认所有算子的并行度是一样的，所以会有下图中的优化结果。

                   

         我们来分析一下默认情况下可能发生的问题，假如设置作业的并行度为10，source明确为kafka，对应topic只有一个topic，因为source默认会根据topic的分区数，决定自己的分区数，那么10个source subtask只有一个会工作，而且任务比较重。这样会导致后面的map实际也是有一个subTask在工作，处理所有的数据，假如map中的任务比较重，那么会导致数据倾斜，性能低下。在source不能改造的情况下，我们显式减少source的并行度（为了节省资源，设置1），提高map的并行度（增加处理速度，设为20）。第一眼看上去，感觉性能提升了不少，但是在实际情况中却不一定这样。因为调整source和map的并发度， 失去了原有one-to-one数据传递的优势，导致subTask不能融合，数据需要reblance，产生大量的IO，所以修改并行度也不一定可以提升性能。修改并行度之后，执行计划的优化结果如下图。所以在实际优化的过程中，还是要注意结合数据分布和执行计划调优，理解Flink执行计划的生成过程很有必要。

                       

         

JobManager
       JobManager是一个进程，主要负责申请资源，协调以及控制整个job的执行过程，具体包括，调度任务、处理checkpoint、容错等等，在接收到JobClient提交的执行计划之后，针对收到的执行计划，继续解析，因为JobClient只是形成一个operaor层面的执行计划，所以JobManager继续解析执行计划（根据算子的并发度，划分task），形成一个可以被实际调度的由task组成的拓扑图，如上图被解析之后形成下图的执行计划，最后向集群申请资源，一旦资源就绪，就调度task到TaskManager。
       

   

       为了保证高可用，一般会有多个JobManager进程同时存在，它们之间也是采用主从模式，一个进程被选举为Leader，其他进程为follower。Job运行期间，只有Leader在工作，follower在闲置，一旦Leader挂掉，随即引发一次选举，产生新的Leader继续处理Job。JobManager除了调度任务，另外一个主要工作就是容错，主要依靠checkpoint进行容错，checkpoint其实是stream以及executor（TaskManager中的Slot）的快照，一般将checkpoint保存在可靠的存储中（比如hdfs），为了容错Flink会持续建立这类快照。当Flink作业重新启动的时候，会寻找最新可用的checkpoint来恢复执行状态，已达到数据不丢失，不重复，准确被处理一次的语义。一般情况下，都不会用到checkpoint，只有在数据需要积累或处理历史状态的时候，才需要设定checkpoint，比如updateStateByKey这个算子，默认会启用checkpoint，如果没有配置checkpoint目录的话，程序会抛异常。

     TaskManager
TaskManager是一个进程，及一个JVM（Flink用java实现）。主要作用是接收并执行JobManager发送的task，并且与JobManager通信，反馈任务状态信息，比如任务分执行中，执行完等状态，上文提到的checkpoint的部分信息也是TaskManager反馈给JobManager的。如果说JobManager是master的话，那么TaskManager就是worker主要用来执行任务。在TaskManager内可以运行多个task。多个task运行在一个JVM内有几个好处，首先task可以通过多路复用的方式TCP连接，其次task可以共享节点之间的心跳信息，减少了网络传输。TaskManager并不是最细粒度的概念，每个TaskManager像一个容器一样，包含一个多或多个Slot，如图1.2。
     

       Slot是TaskManager资源粒度的划分，每个Slot都有自己独立的内存。所有Slot平均分配TaskManger的内存，比如TaskManager分配给Solt的内存为8G，两个Slot，每个Slot的内存为4G，四个Slot，每个Slot的内存为2G，值得注意的是，Slot仅划分内存，不涉及cpu的划分。同时Slot是Flink中的任务执行器（类似Storm中Executor），每个Slot可以运行多个task，而且一个task会以单独的线程来运行。Slot主要的好处有以下几点：
可以起到隔离内存的作用，防止多个不同job的task竞争内存。
Slot的个数就代表了一个Flink程序的最高并行度，简化了性能调优的过程
       允许多个Task共享Slot，提升了资源利用率，举一个实际的例子，kafka有3个partition，对应flink的source有3个task，而keyBy我们设置的并行度为20，这个时候如果Slot不能共享的话，需要占用23个Slot，如果允许共享的话，那么只需要20个Slot即可（Slot的默认共享规则计算为20个）。

      

四、核心原理

Apache Flink 之所以能越来越受欢迎，我们认为离不开它最重要的四个基石：Checkpoint、State、Time、Window。

  

Window&Time

Window

Flink 中 Window 可以将无限流切分成有限流，是处理有限流的核心组件，现在Flink 中 Window 可以是时间驱动的（Time Window），也可以是数据驱动的（Count Window），如下图所示：

     

窗口类型：

• tumbling window（滚动窗口）：窗口间的元素无重复

上图中，基于时间的窗口操作，在每个相同的时间间隔对Stream中的记录进行处理，通常各个时间间隔内的窗口操作处理的记录数不固定；而基于数据驱动的窗口操作，可以在Stream中选择固定数量的记录作为一个窗口，对该窗口中的记录进行处理。

       

滚动窗口的概念：

• 滚动窗口能将数据流切分成不重叠的窗口，每一个事件只能属于一个窗口
• 滚动窗具有固定的尺寸，不重叠。

滚动窗口的划分，可以基于时间戳来进行划分窗口，也可以基于到来的事件元素数量来划分窗口。

因为我们这里考虑的是TimeWindow，所以这里考虑基于时间戳来进行窗口划分。

滚动窗口适用场景：

适用场景：适合做每个时间段的聚合计算，BI分析。例如统计某页面每分钟点击的pv。

场景1：我们需要统计每一分钟中用户购买的商品的总数，需要将用户的行为事件按每一分钟进行切分，这种切分被成为翻滚时间窗口（Tumbling Time Window）。

     

• sliding window（滑动窗口）：窗口间的元素可能重复

      

滑动窗口概念：

滑动窗口也是一种比较常见的窗口类型，其特点是在滚动窗口基础之上增加了窗口滑动时间（Slide Time），且允许窗口数据发生重叠。

当 Windows size 固定之后，窗口并不像滚动窗口按照 Windows Size 向前移动，而是根据设定的 Slide Time 向前滑动。

窗口之间的数据重叠大小根据 Windows size 和 Slide time 决定，

• 当 Slide time 小于 Windows size便会发生窗口重叠，
• Slide size 大于 Windows size 就会出现窗口不连续，数据可能不能在任何一个窗口内计算，
• Slide size 和 Windows size 相等时，Sliding Windows 其实就是Tumbling Windows。

滑动窗口是滚动窗口的更广义的一种形式，滑动窗口由固定的窗口长度和滑动间隔组成

特点：

• 窗口长度固定，可以有重叠，可以有空隙。
• 一个元素可以对应多个窗口，也可以不属于任意一个窗口，看slide size而定。

滑动窗口适用场景：

适用场景：对最近一段时间段内进行统计(如某接口近几分钟的失败调用率)

比如：每隔3秒计算最近5秒内，每个基站的日志数量

每30秒计算一次最近一分钟用户购买的商品总数。

• session window（会话窗口）

会话窗口的概念：

会话窗口（Session Windows）主要是将某段时间内活跃度较高的数据聚合成一个窗口进行计算，窗口的触发的条件是 Session Gap，是指在规定的时间内如果没有数据活跃接入，则认为窗口结束，然后触发窗口计算结果。

需要注意的是如果数据一直不间断地进入窗口，也会导致窗口始终不触发的情况。

与滑动窗口、滚动窗口不同的是，Session Windows 不需要有固定 windows size 和 slide time，只需要定义 session gap，来规定不活跃数据的时间上限即可。

特点：

• 会话窗口根据会话的间隔来把数据分配到不同的窗口。
• 会话窗口不重叠，没有固定的开始时间和结束时间。
• 与翻滚窗口和滑动窗口相反, 当会话窗口在一段时间内(session gap)没有接收到元素时会关闭会话窗口。后续的元素将会被分配给新的会话窗口

该类窗口的特点：

• 时间无对齐
• 当前系统时间-分组内最后一次的时间如果超时，则进行触发计算

会话窗口分配器可以直接配置一个静态常量会话间隔，也可以通过函数来动态指定会话间隔时间。

我们可以设置定长的Session gap，也可以使用SessionWindowTimeGapExtractor动态地确定Session gap的长度。

适用场景：

在这种用户交互事件流中，我们首先想到的是将事件聚合到会话窗口中（一段用户持续活跃的周期），由非活跃的间隙分隔开。

场景一：如上图所示，就是需要计算每个用户在活跃期间总共购买的商品数量，如果用户30秒没有活动则视为会话断开（假设raw data stream是单个用户的购买行为流）。

场景二：3秒内如果没有数据进入，则计算每个基站的日志数量

场景三：比如音乐 app 听歌的场景，我们想统计一个用户在一个独立的 session 中听了多久的歌曲（如果超过15分钟没听歌，那么就是一个新的 session 了）

• global window（全局窗口）

       

全局串口概念：

   全局窗口分配器会将具有相同key值的所有元素分配在同一个窗口。这种窗口模式下需要我们设置一个自定义的Trigger，否则将不会执行任何计算，

这是因为全局窗口中没有一个可以处理聚合元素的自然末端。所有相同keyed的元素分配到一个窗口里，这种窗口很少使用。

Time

Time的分类

       

Event-Time ：事件时间是每个事件在其生产设备上发生的时间。此时间通常在进入Flink之前嵌入记录中，并且 可以从每个记录中提取该事件时间戳。
Ingestion-Time ：摄取时间是事件进入Flink的时间。在源算子处，每个记录将源的当前时间作为时间戳，并且基于时间的 算子操作（如时间窗口）引用该时间戳。
Processing-Time ： 处理时间是指执行相应算子操作的机器的系统时间。

五、Flink 典型应用

Flink 主要应用场景有三类：

1.Event-driven Applications【事件驱动】

上图包含两块：Traditional transaction Application（传统事务应用）和Event-driven Applications（事件驱动应用）。

 Traditional transaction Application执行流程：比如点击流Events可以通过Application写入Transaction DB（数据库），同时也可以通过Application从Transaction DB将数据读出，并进行处理，当处理结果达到一个预警值就会触发一个Action动作，这种方式一般为事后诸葛亮。

 Event-driven Applications执行流程：比如采集的数据Events可以不断的放入消息队列，Flink应用会不断ingest（消费）消息队列中的数据，Flink 应用内部维护着一段时间的数据（state），隔一段时间会将数据持久化存储（Persistent sstorage），防止Flink应用死掉。Flink应用每接受一条数据，就会处理一条数据，处理之后就会触发（trigger）一个动作（Action），同时也可以将处理结果写入外部消息队列中，其他Flink应用再消费。

典型的事件驱动类应用：

1.欺诈检测(Fraud detection)

2.异常检测(Anomaly detection)

3.基于规则的告警(Rule-based alerting)

4.业务流程监控(Business process monitoring)

5.Web应用程序(社交网络)

2.Data Analytics Applications【分析】

Data Analytics Applications包含Batch analytics（批处理分析）和Streaming analytics（流处理分析）。

 Batch analytics可以理解为周期性查询：比如Flink应用凌晨从Recorded Events中读取昨天的数据，然后做周期查询运算，最后将数据写入Database或者HDFS，或者直接将数据生成报表供公司上层领导决策使用。

Streaming analytics可以理解为连续性查询：比如实时展示双十一天猫销售GMV，用户下单数据需要实时写入消息队列，Flink 应用源源不断读取数据做实时计算，然后不断的将数据更新至Database或者K-VStore，最后做大屏实时展示。

3.Data Pipeline Applications【管道式ETL】

   

Data Pipeline Applications包含Periodic （周期性）ETL和Data Pipeline（管道）

 Periodic ETL：比如每天凌晨周期性的启动一个Flink ETL Job，读取传统数据库中的数据，然后做ETL，最后写入数据库和文件系统。

 Data Pipeline：比如启动一个Flink 实时应用，数据源（比如数据库、Kafka）中的数据不断的通过Flink Data Pipeline流入或者追加到数据仓库（数据库或者文件系统），或者Kafka消息队列

4. 典型活动流处理例子

 需求1：  

        新年感恩7天回馈活动。给过年法定假日期间依然在派送快递员红包奖励。    

预估数据：

     预计有10万个快递员参与活动，活动日订单预计每日有100万个。活动预算700万。    

需求详情：         

  1. 过年期间对接单数量大于3单，5单，10单的快递员。给予18元，88元，188元红包奖励。当快递员接诊单数达到时，立即发放奖励，并弹框与短信提醒，及时满足快递员成就感和幸福感。先完成先得奖励，同等级奖励不能重复发放，每天100万发放完结束当天活动。          

  2. 能参与的快递员必须去年12月份接诊量达到100单，好评率80%，dsr平均分达到4.5， 且是一线和二线城市的快递员。          

  3. 快递员必须是实名认证，当天人脸认证通过，且频繁异地登录、刷单等异常操作没有触发用户封控规则。       

注意：           

    1.  奖励券配置需使用奖励中台配置，便于以后开展类似活动和调整活动规则。           

    2.  数据分析小组近能提供参与快递员，实时奖励发放，活动订单数量的近实时报表分析图。     

    3.  运营要能根据数据分析图，判断活动活跃程度， 能及时调整活动规则并立即生效。如调整3，5，10单量等级，快递员参与条件限制等。

需求2: 

      日常活动。对于每天分享快递员邀新链接或快递员文章达到1，3，5个，实时发放1,3,5元优惠券。 

设计方案：

参考

1. Apache Flink 1.11 Documentation: Apache Flink 文档
2. Apache Flink 1.3-SNAPSHOT 中文文档: Windows     
3. 大数据和AI体验教程_实时计算 Flink版-阿里云帮助中心
4. 一文弄懂Flink基础理论_HaiwiSong的博客-CSDN博客
5. Flink 基本工作原理_flink原理_sxiaobei的博客-CSDN博客
6. Flink应用场景_dbLenis的博客-CSDN博客
7. Flink部署及作业提交（On Flink Standalone） - 简书
8. https://blog.csdn.net/lifetragedy/category_12037122.html
9. https://www.cnblogs.com/frankdeng/p/9760015.html
10. flink在企业IT架构中如何定位-在选型流批一体技术与大数据架构时的避坑指南_TGITCIC的博客-CSDN博客