大数据培训 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 函数，限定时间交易多少笔。

​