Flink入门学习

---

Flink是什么：

  Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行状态计算。

---

一、背景：

  Flink来自德国，Flink起源于Stratosphere项目，Stratosphere是在 2010~2014 年由3所地处柏林的大学和欧洲的一些其他的大学共同进行的研究项目，2014年4月Stratosphere 的代码被复制并捐赠给了Apache软件基金会，2014年12月，Flink一跃成为Apache软件基金会的顶级项目。
  在德语中，Flink一词表示快速和灵巧，项目采用一只松鼠的彩色图案作为logo，这不仅是因为松鼠具有快速和灵巧的特点，还因为柏林的松鼠有一种迷人的红棕色，而Flink 的松鼠 logo 拥有可爱的尾巴，尾巴的颜色与Apache 软件基金会的logo颜色相呼应，也就是说，这是一只Apache风格的松鼠。
  Flink的实时性强，是大数据分布式处理引擎，因此在人多，流量巨大，需要对每秒千亿次交易量做实时数据处理的中国市场，自然受到了阿里、今日头条、美团、滴滴等国内大厂的高度重视，中国已成为Flink社区中使用最火热贡献最大的国家。

正在使用Flink的中国大厂们：

---

二、为什么要用Flink

  对比Spark，Spark是批处理架构，数据需要攒一个微批次再处理，也就是说数据攒一批后或到一定程度下，再开始统一批次的处理，而Flink本身基于流处理，数据像水流一样源源不断来到本地，来一个数据处理一个，不需等待，直接处理，很符合数据的实际使用情况，这种数据处理更需常见，更体现实时性。比如：我们发信息，需要的是马上回复，不能我等别人把所有的话都说完，再统一回复：“你说的句子一、二、三，我的回答是一、二、三，不能这样“，你一言我一语更符合实际。所以流数据处理更真实地反映了我们生活的方式，急需应用。
  因此我们的目标是基于传统的数据架构的有限数据集，并要追求低延迟，高吞吐（不能单线程，需变成分布式架构），并且结果有良好的准确性和容错性，Flink都能满足！

• 流式处理：只要数据一直在产生，计算就持续地进行
• 批处理：在预先定义的时间内运行计算，当计算完成时释放计算机资源

---

三、应用场景

电商和市场营销：
数据报表、广告投放、业务流程需要
物联网（IOT）：
传感器实时数据采集和显示、实时报警，交通运输业
电信业：
基站流量的调配
银行和金融业：
实时计算和通知推送，实时检测异常行为

  我们现在在线浏览网站的次数在增多。网站的点击量、浏览量代表着营销数据，可以体现用户兴趣、产品销量、热门度等情况，但是网站获取用户浏览行为是大量、连续但不均匀的数据，一段时间内有大量数据通过，但时间却无法确定，有时候却少得可怜。什么时候多什么时候少是我们以前的技术很难解决的，也无法生成数据报表，进而一个公司也无法确定未来的营销目标，必须要等到所有数据到齐，跑离线任务做统计，这样耗时耗力，且没有效率，很不符合公司利益，最后可能导致陷入实时性不够或者牺牲准确性来获取实时性两难的局面。所以希望能让数据可以实时采集并做处理，方便最后的汇总。最后阶段的数据只需要在原来的数据上做增加即可。再比如工业上温度传感器，无人驾驶，银行结算，如果不能实时做出判断，很容易出现问题，轻则出现判断错误，重则可能出现生命危险或造成重大损失。以上的场景都是需要快速做出决断，追求实时性的。如果等待处理，数据就会失去价值，因此需要用流数据处理解决以上问题。

---

四、原理：（这里也进行数据处理架构演变的总结）

最开始：事务处理 联机事务处理OLTP

  最开始做数据的交互和运算处理时，分Compute计算层和Storage存储层两个部分来处理，计算层是业务服务器，各种各样的系统CRM客户关系管理系统、Order System订单系统、Web App服务器，用户那边有各种各样的操作（不同的事件）。来了一个事件进入客户系统中，用相应的处理逻辑做处理，其中也会需要其他数据进来结合起来做处理，最后返回用户一个Response响应，这其中额外的数据需要从传统的关系型数据库中进行提取调用。

特点： 基于事件实时响应 快速相应
问题： 数据量非常多，大量数据出现时，关系型数据库的存储压力会比较大。另外随着业务的拓展，希望将用户之前的点击行为都保存下来，去做统计分析处理，但是这阶段无法完成。

改变：分析处理（大数据架构） 联机分析处理OLAP

将数据从业务数据库复制到数据仓库，再进行分析和查询

  将数据库中不同的表，不同的来源，先提取出来做一个ETL(将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程)，再统一复制到数仓中去DataWarehouse（数据仓库），最后在数据仓库中做数据分析和查询，生成报表。

特点： 可以应付数据量大的情况，放到数据仓库中去，可以对大量数据做分析处理没问题。
问题： 这里的分析是离线分析。
需求： 急需要将以上两种模式（实时响应，可处理海量数据）的优点结合起来

有状态的流式处理

  还是应基于事件处理方式，但是要将源源不断的数据直接保存到本地内存存储，保存成本地的状态。如果需要用数据，直接从内存中拿取，非常快速（毫秒延迟），并且组成分布式系统，设置大量的节点，可处理大量数据，每个节点他们都是从内存拿取数据。为了避免容灾需要设置检查点（类似存盘保存机制），每次数据到来要做状态快照，保存到远端的存储空间，如果一个处理节点出错，内存中的数据丢失，就从远程的存储空间内重新获取数据，继续处理。

问题： 并发量大时需组分布式架构，但每个节点各自为政，当获取本地状态，无法保证获取的数据与最开始时的数据状态相同（先来的数据先获得结果，否则会出现乱序，造成混乱）最多只能保证本地数据不出现乱序，无法保证其他节点情况。计算准确性和处理一致性处理乱序的问题，并发性也无法做到吞吐性不够

第一代流数据问题： 牺牲吞吐量、结果准确性来获取更低的延迟。

更新：第二代流式处理 lambda架构

  用两套系统，同时保证低延迟和结果正确，多等一会儿，等数据收集齐了，再去统一做一个批处理来保证数据正确。
  Speed Layer实时流数据处理，时间快，但结果未必正确；Batch Layer批处理，实时性不强但是结果正确。处理后的结果分别放置到各自表中，应用程序结合两张表的数据得结果。先得到一个近似准确的数据，隔一段时间之后在更新成最终正确结果。

问题： 很麻烦，两套架构，编程API都不一样，实现一个目标维护两个系统，一旦有问题出现，需要改两个地方。

解决： 一套系统解决——Flink。

Flink整合所有

---

五、Flink架构：

从下至上：

1. 部署：Flink 支持本地运行（IDE 中直接运行程序）、能在独立集群（Standalone 模式）或者在被
   YARN、Mesos、K8s 管理的集群上运行，也能部署在云上。
2. 运行：Flink的核心是分布式流式数据引擎，意味着数据以一次一个事件的形式被处理。
3. API：DataStream、DataSet、Table、SQLAPI。
4. 扩展库：Flink 还包括用于 CEP（复杂事件处理）、机器学习、图形处理等场景。

---

六、Flink分布式运行:

1. Program Code：我们编写的 Flink 应用程序代码
2. Job Client：Job Client 不是 Flink程序执行的内部部分，但它是任务执行的起点。Job Client 负责接受用户的程序代码，然后创建数据流，将数据流提交给 JobManager 以便进一步执行。执行完成后，Job Client 将结果返回给用户 。
3. Job Manager：主进程（也称为作业管理器）协调和管理程序的执行。它的主要职责包括安排任务，管理 checkpoint，故障恢复等。机器集群中至少要有一个 master，master 负责调度 task，协调 checkpoints和容灾，高可用设置的话可以有多个 master，但要保证一个是 leader, 其他是 standby; Job Manager 包含Actor system、Scheduler、Check pointing 三个重要的组件。
4. Task Manager：从 JobManager 处接收需要部署的 Task。Task Manager 是在 JVM中的一个或多个线程中执行任务的工作节点。任务执行的并行性由每个 Task Manager 上可用的任务槽（Slot个数）决定。每个任务代表分配给任务槽的一组资源。例如，如果 Task Manager 有四个插槽，那么它将为每个插槽分配 25％的内存。可以在任务槽中运行一个或多个线程。同一插槽中的线程共享相同的 JVM。

  同一 JVM 中的任务共享 TCP 连接和心跳消息。Task Manager 的一个 Slot 代表一个可用线程，该线程具有固定的内存，注意 Slot 只对内存隔离，没有对 CPU 隔离。默认情况下，Flink 允许子任务共享 Slot，即使它们是不同 task 的 subtask，只要它们来自相同的 job。这种共享可以有更好的资源利用率。

---

七、Flink主要特点:

1.事件驱动:

2.基于流的世界观

在Flink的世界观中，一切都是由流组成的，离线数据是有界的流（有始有终bounded stream）；如果需要做批处理，就可将一条一条的数据，截取一批数据做处理或者截取窗口做处理；实时数据是一个没有界限的流（数据不停的进来，无法产生一个结果）。

3.分层API

越顶层越抽象，表达含义越简明，使用越方便（容易，简单，干的事情少）
越底层越具体，表达能力越丰富，使用灵活（复杂、难，干的事情越多）

• SQL Table API 最顶层API，更多的关心处理业务
• DataStream/DataSet API 核心API，主要处理流里的数据和窗口 经常使用的API
• DataStream做流处理 DataSet做批处理 （底层一致，API不同）
• ProcessFunction 不仅仅处理数据，可以定义状态，拿到事件、时间相关信息，可以做更多的事情。特别复杂的需求是使用。

4.Flink其他特点：

• 支持事件时间和处理时间语义（时间可以有不同的定义）
• 精确一次的状态一致性保证
• 低延迟性、每秒处理数百万个事件，毫秒级延迟
• 与众多常用存储系统的连接（Kafka、Redis 、Hive、HDFS）
• 高可用、动态扩展、实现7*24小时全天候运行

---

八、Flink基石：

• 强一致性——Checkpoint机制（见下）
• 托管状态(Managed state)，并提供api （更方便调用和管理）
• watermark机制，解决基于事件事件处理时候的数据乱序和延迟的问题
• 流计算中计算一般都有基于窗口，Flink提供开箱即用的窗口操作，包括滚动窗口、滑动窗口、会话窗口，灵活的自定义窗口

Flink强一致性原理——Chandy-Lamport算法

  把流计算看成是一个流式的拓扑，定期从拓扑的头部source点开始插入特殊的barriers，从上游开始不断的向下游广播这个barriers。每个节点收到这个barriers，会将state做一次快照，当每个节点都做完snapshot后，整个拓扑就算完整的做完一次Checkpoint。（分布式一致性完成）接下来不管出现任何故障，都会从最近的 Checkpoint进行恢复。