大数据培训Flink面试宝典

以下文章来源于数字化点评

Flink商业价值和应用场景

1、商业价值：

数据基础设施经过数十年的发展，如今发生了根本性改变。

数据量爆发式增长，数据存储结构越来越灵活，传统数据计算和存储方式已无法满足实时性分析、快速扩展等新需求。

需要从Hadoop、Hive、Spark的离线计算架构，升级为基于Flink的实时架构。

把之前T+1（天）的分析时间缩短为T+0的实时分析，提升业务响应的敏锐度，实现数据驱动，提升业务价值。

满足企业对数据应用的实时响应、敏捷开发、智能分析需求。

2、典型场景：

新零售，打通线上和线下各渠道，人货场，用户、商品、门店、区域、渠道等的主数据、交易数据、外部数据。

实现数据服务由T+1升级缩短为T+0服务，提升数据时效性。

满足实时业务场景需求，实时推荐、实时分析、实时检索，实现精细化运营。

Flink技术面试常见问题

1、Flink是什么？

Flink是面向流处理和批处理的分布式数据计算引擎。

Flink中，一切都由流组成，离线数据是有界的流，实时数据是没有界限的流。

2、Flink与Hadoop的关系。

Flink可以完全独立于Hadoop，在不依赖Hadoop组件下运行。

Flink也可以集成Hadooop众多组件，例如YARN、HDFS、HBase。

Flink可以使用Yarn做资源调度，使用HDFS作为存储，使用HDFS做检查点。

3、Flink集群运行架构。

 

Flink运行时由两种进程组成：JobManager，TaskManager。

可以通过多种方式启动：standalone集群启动、通过YARN资源框架管理并启动，通过Kubernetes云原生框架管理并启动。

JobManager：

JobManager协调Flink应用程序的分布式执行。

调度task，对task的完成或失败做出反应，协调checkpoint并从失败中恢复。

ResourceManager：

ResourceManager负责Flink集群中的资源提供、回收、分配。

TaskManager：

TaskManager执行作业流的 task，并且缓存和交换数据流。

TaskManager中资源调度的最小单位是task slot。

TaskManager中task slot的数量表示并发处理task的数量。

一个task slot中可以执行多个算子。

Client：

Client不是运行时和程序执行的一部分，而是用于准备数据流并将其发送给 JobManager。

4、Flink与Spark区别。

Flink和Spark都能提供流处理和批处理的功能，都能用来实现流批一体。

（1）Spark本质是批处理。

可通过Spark streaming实现准实时流处理，但实际上是微批，所以本质上是批处理。

Spark streaming将输入的数据分割为一些微小的数据单元，每次处理一个小的数据单元，看起来和流处理一样_大数据培训。

（2）Flink本质是流处理。

Flink是真正的流处理。Flink处理任务时一切都是由流组成，实时数据是没有界限的流，离线数据是有界的流。

Flink的批处理是把批处理的数据看作一个有限的流计算。

5、Flink容错机制checkpoint。

Checkpoint机制是Flink可靠性的基石。

用来保证Flink集群在某个算子出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保证应用流图状态的一致性。

每个需要Checkpoin的应用在启动时，JobManager为其创建一个CheckpointCoordinator（检查点协调器）。

CheckpointCoordinator负责本应用的快照制作。

CheckpointCoordinator周期性的向该流应用的所有source算子发送barrier；

source算子暂停数据处理过程，将自己的当前状态制作成快照，保存到指定的持久化存储中，向CheckpointCoordinator报告自己快照制作情况，同时向所有下游算子广播该barrier，恢复数据处理；

每个下游按此步骤不断制作快照并向下游广播；直到最后barrier传递到sink算子，快照制作完成。

6、Flink如何保证Exactly-once。

Flink的Exactly-once实现了端到端的精准一次处理。

包括Source端、Flink内部端、Sink端。

（1）Source端：

消费Kafka中数据，保证消息精准一次消费。

Flink保存消费数据的偏移量，如果后续任务出现了故障，恢复时由连接器重置偏移量，重新消费数据，保证一致性。

（2）Flink内部端：

利用Checkpoint 机制，把状态存盘，发生故障的时候可以恢复，保证内部的状态一致性。

（3）Sink端：

将处理完的数据发送到下一阶段时，需要保证数据能够准确无误发送到下一阶段。

Flink使用两阶段提交协议2PC，包括pre-commit和commit。通过两阶段分布式事务保证数据提交要么全部成功执行，要么被终止然后回滚。

两阶段提交协议（Two-Phase Commit，2PC）是常用的解决分布式事务问题的方式，它可以保证在分布式事务中，要么所有参与进程都提交事务，要么被终止然后回滚。

7、Flink反压问题。

Flink使用producer-consumer 模型的分布式阻塞队列，下游消费者消费变慢，上游就会阻塞。

现象：

（1）短时间内流量陡增，造成数据堆积和消费速度变慢，数据消费速度小于数据生产速度。

（2）任务延时高。

（3）导致checkpoint超时，最终导致数据不一致发生。

定位：

通过Flink Web UI，在Flink 后台管理页面看每个Task 处理数据大小。

HIGH: 0.5 < Ratio <= 1，表示要处理。

0.01：100次有1次阻塞在内部调用。

解决：

（1）数据倾斜原因：KeyBy等分组聚合函数导致；解决方案：将热点Key预处理。

（2）代码原因：错误使用算子。

（3）GC原因：TaskManager垃圾回收参数不合理。

8、Flink的状态存储

Flink计算过程中存储中间状态，用来避免数据丢失和状态恢复。

三种状态存储方式：MemoryStateBackend、FsStateBackend、RocksDBStateBackend。

（1）MemoryStateBackend：为默认配置。将状态（state）数据作为对象保存在TaskManager内存，通过checkpoint机制，将状态进行快照并保存在Jobmanager（master）内存。适用场景：开发测试环境，本地调试，Flink任务状态数据量较小。

（2）FsStateBackend：将状态数据保存在Taskmanger内存，通过checkpoint机制，将状态快照写入配置好的文件系统或目录中，最小元数据保存在JobManager内存。适用场景：生产环境，大状态、长窗口、大key/value状态的的任务，高可用。

（3）RocksDBStateBackend：将状态保存在RocksDB数据库（位置在TaskManager数据目录）。通过checkpoint，RocksDB数据库被复制到配置的文件系统或目录中，最小元数据保存在JobManager内存。适用场景：生产环境，非常大的状态，长窗口，大键值状态的任务，对状态读写性能要求不高的作业。

9、Flink数据倾斜问题。

现象：

（1）任务节点频繁出现反压。

（2）增加并行度也不能解决问题。

（3）部分节点出现OOM异常。

原因：

业务原因：有严重数据热点，大量数据集中在某个节点，导致该节点内存爆满，任务失败重启。例如滴滴打车在北上深的订单数据量远超其他城市。

技术原因：KeyBy、GroupBy等操作，错误分组Key。

解决：

业务上避免热点key 的设计，例如将北上深等热点城市分成不同区域，单独处理；

技术上调整key，二次聚合等。

10、Flink的Time有哪几种类型。

Flink的Time有三种类型：

（1）Event Time：事件创建的时间。例如采集的日志数据中，每一条日志记录自己的生成时间。在Flink的流式处理中，绝大部分的业务使用eventTime。

（2）Ingestion Time：数据进入Flink的时间。

（3）Processing Time：执行算子的本地系统时间，默认为Processing Time。

对于业务来说，通常Event Time时间最有意义，因为要根据日志生成时间进行统计。

11、Flink如何解决延迟乱序的数据问题。

Flink用WaterMark和window机制解决流式数据的延迟乱序问题。

eventTime：对于因为延迟而顺序有误的数据，可以根据eventTime进行业务处理。

WaterMark：对于延迟的数据，给定一个允许延迟的时间，在该时间范围内仍可以接受处理延迟数据。

12、Flink的window数据倾斜问题。

Flink的window数据倾斜是数据在不同窗口内堆积的数据量相差过多。

原因是数据源头发送的数据量速度不同导致的。

解决：

（1）在数据进入窗口前，做预聚合。

（2）重新设计窗口聚合key。

13、Flink中Task如何数据交换

Flink Job中，数据需要在不同的task 进行交换，由TaskManager负责数据交换。

TaskManager的网络组件从缓冲buffer中收集 records，然后发送。

Records不是一个一个被发送，而是积累一个批次再发送，可以更加高效利用网络资源。

14、Flink数据去重。

去重的意义：统计UV，消除不可靠数据源产生的脏数据即重复上报或重复投递数据的影响，使流式计算产生结果更加准确。

（1）基于布隆过滤器，简单但不能做到100%精确。例如子订单日志模型，用三个元素分别代表站点ID、子订单ID和数据负载内容。

按照站点ID为key分组，然后在每个分组内创建存储子订单ID的布隆过滤器。

（2）基于RocksDB状态后端。可以更精确。RocksDB是类似于HBase的嵌入式K-V数据库。

（3）基于外部K-V数据库（Redis、HBase之类）存储去重。

15、Flink并行度。

Flink程序的执行具有并行、分布式的特性。

每个worker（TaskManager）是一个JVM进程。

worker通过task slot来控制接收多少个task。

例如1个TaskManager有3个slot，将其管理的内存分成3份给各个slot。

多个slot为多个线程，多个subtask共享同一个JVM，提高了并行度。

16、Flink CEP。

CEP是Complex Event Processing（复杂事件处理）。

Flink CEP用于解决对连续传入事件进行模式匹配的问题。

CEP查询应用于无限数据流。系统看到匹配序列的所有事件，结果会立即发出。

CEP可用于股票市场趋势、信用卡欺诈检测等金融应用。

例子：银行卡在短时间内，多地刷卡，1小时内同一个卡刷了50笔交易，会被判断为被盗刷。

可使用pattern构成模式匹配的逻辑表达。

使用within和time函数，限定时间交易多少笔。