业务数据从 Kafka 进入 Flink经过清洗、关联、聚合和状态计算实时写入 Kafka、Iceberg、Doris/ClickHouse 等下游最终服务用户画像和实时分析。一、最可能问的 Flink 基础题1. Flink 的架构是什么可以这样回答Flink 主要由 JobManager 和 TaskManager 组成。JobManager 负责作业提交、资源调度、任务协调、Checkpoint 和故障恢复TaskManager 负责真正执行算子、处理数据和保存本地状态。用户程序会经过 StreamGraph、JobGraph、ExecutionGraph最终被拆分成多个并行 SubTask 执行。Flink 通过 Operator Chain 减少不必要的网络传输通过 Checkpoint 实现故障恢复和一致性处理。面试官可能继续问JobManager 和 TaskManager 分别做什么什么是并行度什么是 Task Slot什么是算子链哪些操作会引起 Shuffle2. Flink 和 Spark Streaming 有什么区别可以这样答Flink 以流处理为核心采用逐条处理或微批结合的方式实时性通常更好Spark Structured Streaming 以 DataFrame 和批处理执行引擎为基础开发和 SQL 生态比较成熟。Flink 在事件时间、乱序处理、窗口、状态管理和长时间运行的实时任务方面比较有优势Spark 在离线数仓、批流一体和大规模 SQL 分析场景中使用广泛。不要简单说“Flink 一定比 Spark 快”应该结合场景回答。3. 什么是事件时间、处理时间和摄入时间这是高频题。Processing Time数据被 Flink 处理时的机器时间Event Time事件真正发生的时间Ingestion Time数据进入 Flink 的时间实时数仓一般更关注Event Time因为数据可能存在网络延迟和乱序。例如用户 10:00 下单 数据 10:00:05 才到 Flink如果使用处理时间订单会被当成 10:00:05 的数据如果使用事件时间仍然按照 10:00 参与窗口计算。4. 什么是 Watermark有什么作用推荐回答Watermark 用来表示系统认为某个事件时间之前的数据基本已经到达。它主要用于处理乱序数据和触发事件时间窗口。Watermark 通常不是某条数据的时间而是当前系统对数据完整性的一个判断。例如 Watermark 为10:05通常表示时间戳小于等于 10:05 的数据大部分已经到达可以考虑关闭对应窗口。常见追问Watermark 越大越好吗数据迟到怎么办Watermark 为什么不推进多个输入分区时 Watermark 如何计算多个输入分区时整体 Watermark 通常取各分区 Watermark 的最小值。只要某个分区没有数据或 Watermark 不推进就可能拖慢下游窗口。5. Flink 中的窗口有哪些常见窗口滚动窗口 Tumbling Window窗口之间不重叠滑动窗口 Sliding Window窗口之间可能重叠会话窗口 Session Window根据用户活动间隔划分计数窗口按照数据条数划分Flink SQL 示例SELECTuser_id,COUNT(*)ASorder_count,SUM(amount)AStotal_amountFROMordersGROUPBYuser_id,TUMBLE(order_time,INTERVAL5MINUTE);这表示按照事件时间每 5 分钟统计一次用户订单量和金额。6. 数据迟到怎么处理可以回答首先通过 Watermark 给乱序数据留出等待时间。对于超过允许迟到时间的数据可以使用 allowed lateness、迟到数据侧输出或者重新计算机制处理。实际生产中还要根据业务是否允许修正历史结果来决定可以丢弃、写入旁路表或者更新下游结果。重点是说明三种处理方式等待一段时间迟到数据单独输出对结果进行更新或补偿二、Flink 状态和容错这是必须准备的部分7. 什么是 State为什么需要 State例如统计每个用户累计消费金额收到订单 1用户 A 累计 100 收到订单 2用户 A 累计 250 收到订单 3用户 A 累计 420Flink 必须记住用户 A 之前的累计值这就是状态。常见状态ValueState保存一个值ListState保存一组值MapState保存键值映射ReducingState聚合状态AggregatingState更灵活的聚合状态回答时可以说状态用于保存跨事件、跨窗口或跨处理调用的数据是实时去重、聚合、关联和用户画像计算的基础。8. Keyed State 和 Operator State 有什么区别Keyed State与 Key 绑定只能在keyBy()之后使用例如每个用户的订单数、最后登录时间Operator State与算子实例绑定例如 Kafka Source 的分区消费位点面试中的简单例子用户画像中的“用户最近一次活跃时间”适合使用 Keyed State因为它是按照user_id维度维护的。9. 什么是 CheckpointSavepoint 有什么区别可以这样记Checkpoint系统自动容错周期性触发主要用于故障恢复生命周期通常由 Flink 管理Savepoint人工运维快照通常手动触发用于升级、迁移、修改作业、版本切换需要长期保存和管理标准回答Checkpoint 解决的是作业失败后自动恢复的问题Savepoint 更多用于有计划的作业升级和迁移。两者都可以保存算子状态但使用目的和生命周期不同。10. Flink 如何实现 Exactly-Once不要直接说“Flink 能保证所有场景严格 Exactly-Once”更准确的说法是Flink 通过 Checkpoint 保存一致性状态并结合两阶段提交 Sink可以实现端到端 Exactly-Once。但前提是 Source 能够重放或恢复消费位点Flink 状态能够正确恢复下游 Sink 也必须支持幂等写入或事务提交。需要记住Flink 内部状态一致性 Source 可重放 Sink 幂等或事务 端到端 Exactly-Once 的基础例如Kafka Source通常可以根据 offset 恢复数据库 Sink需要幂等写入或事务普通 HTTP 接口通常很难真正保证 Exactly-Once三、这份岗位最可能问的 Flink SQL11. Flink SQL 的执行流程是什么可以这样回答Flink SQL 会先经过 SQL 解析、验证和优化生成逻辑执行计划再转换成 Flink 的执行计划最后由 TaskManager 执行。SQL 底层仍然会使用 Source、算子、状态、窗口和 Sink 等运行时能力。常见 SQL 结构CREATETABLEuser_behavior(user_id STRING,behavior STRING,event_timeTIMESTAMP(3),WATERMARKFORevent_timeASevent_time-INTERVAL5SECOND)WITH(connectorkafka,topicuser_behavior,formatjson);12. Flink SQL 中 Watermark 怎么写示例WATERMARKFORevent_timeASevent_time-INTERVAL5SECOND含义是允许最多 5 秒的乱序数据Watermark 相对于当前已观察到的最大事件时间延迟 5 秒。注意字段一般需要是TIMESTAMP(3)而且时间字段必须正确解析否则 Watermark 不会正常推进。13. Flink SQL 中普通 Join 和 Interval Join 有什么区别普通 Join通常需要保存较多数据可能导致状态不断增长适合有边界或维表场景。Interval Join用时间范围限制两边数据的匹配SELECT*FROMorders oJOINpayments pONo.order_idp.order_idANDp.event_timeBETWEENo.event_time-INTERVAL5MINUTEANDo.event_timeINTERVAL5MINUTE;实际面试中可能问两条流怎么关联订单流和支付流如何判断支付成功Join 状态会不会无限增长如何控制状态 TTL核心就是流流 Join 必须关注时间范围和状态清理。14. Flink SQL 中 Lookup Join 是什么Lookup Join 常用于实时流和维表关联实时订单流 MySQL 用户表例如订单流里只有user_id需要查询用户标签、地区、会员等级。回答Lookup Join 通常在处理事实流数据时按照 Key 查询外部维表。它适合变化频繁、数据量相对可控的维表但需要关注外部数据库压力、缓存、连接池和查询延迟。15. Flink SQL 如何做实时去重常见写法SELECT*FROM(SELECT*,ROW_NUMBER()OVER(PARTITIONBYuser_id,event_idORDERBYevent_timeDESC)ASrnFROMevents)WHERErn1;这表示同一个user_id event_id只保留最新的一条。面试官可能继续问去重状态会不会无限增长如何设置 TTL事件时间和处理时间应该用哪个数据重复来自哪里四、用户画像场景可能怎么问岗位明确写了“用户画像系统”因此你至少要准备这个系统设计题。16. 如何设计一个用户画像系统可以按下面的架构回答业务埋点 / 订单 / 登录 / 浏览 | v Kafka | Flink 清洗、去重、聚合 | ------------ | | 实时画像结果 明细数据 | | Redis / Doris Iceberg / Hive | 查询和标签服务画像标签可以分为事实标签性别、地区、注册时间统计标签近 7 天购买次数、近 30 天消费金额偏好标签偏好品类、偏好品牌规则标签高价值用户、沉睡用户、活跃用户实时处理逻辑接收用户行为数据校验和清洗按user_id分组使用状态保存用户历史信息使用窗口统计近期行为生成标签写入 Iceberg、Doris、Redis 等下游面试官可能问如果用户画像标签越来越多Flink 状态会不会很大可以回答会所以需要控制状态规模。可以设置 State TTL使用合理的标签模型避免把所有历史明细永久放在 Flink 状态中。长期明细应落到 Iceberg/HiveFlink 只保存实时计算所需的窗口数据、聚合值和必要的去重信息。五、Hive、Spark SQL、Iceberg 可能与 Flink 一起问17. Hive 和 Iceberg 有什么区别可以这样回答Hive 更像是基于文件和目录组织的传统数据仓库方案依赖分区和元数据管理Iceberg 是面向数据湖的表格式支持快照、Schema Evolution、Partition Evolution、Time Travel 和更可靠的并发读写。对于实时数仓Iceberg 更适合承接持续写入和增量更新的数据。18. Iceberg 为什么适合实时数仓重点记这几个词SnapshotUpsertSchema EvolutionPartition EvolutionTime Travel增量读取ACID 语义可直接回答Flink 可以将实时处理结果持续写入 IcebergIceberg 通过快照管理数据版本支持更新、回溯和增量读取适合作为实时明细层或部分结果层。实际使用中要关注小文件、提交频率、分区设计和 Compaction。19. Iceberg 小文件问题怎么解决回答实时任务如果频繁提交会产生大量小文件影响查询性能和元数据管理。通常可以通过调整 checkpoint 或提交间隔、增大写入缓冲、合理设置并行度以及使用 Compaction 合并小文件来解决。同时分区字段不能设计得过细否则也会放大小文件问题。六、性能优化场景题20. Flink 任务延迟越来越高你怎么排查建议按顺序说看 Flink Web UI 的算子指标找busyTime高、backPressured高的算子判断是否数据倾斜检查是否存在大状态或状态访问慢检查窗口、Join 是否导致状态增长检查下游 Sink 是否写入变慢检查 Checkpoint 是否频繁失败或耗时过长根据瓶颈调整并行度、资源、缓存和算子逻辑常见原因Kafka 某个分区数据量特别大keyBy出现热点 Key维表查询过慢下游写入吞吐不足Checkpoint 阻塞状态过大序列化或反序列化效率低21. 什么是反压 Backpressure可以这样回答反压表示下游处理速度跟不上上游发送速度导致数据在网络缓冲区中堆积最终上游也被迫降低发送速度。反压通常是整个链路中最慢的算子导致的。排查方向哪个算子处理最慢Sink 是否限流是否存在数据倾斜是否有外部接口调用是否需要增加并行度是否需要批量写入或异步 IO22. 数据倾斜怎么处理典型场景大多数 user_id 数据量正常 某个 user_id 或 null 数据量特别大解决思路检查热点 Key 和空 Key对热点 Key 做随机前缀打散两阶段聚合将异常 Key 单独处理提高下游并行度避免不必要的全局聚合不过要注意随机打散之后通常需要第二阶段重新聚合。七、你可以直接背的项目介绍模板面试官问“你做过 Flink 项目吗”可以按照真实情况修改我参与过一个实时用户画像和数据处理流程。数据主要来自 Kafka包括用户登录、浏览、点击和订单等行为。Flink 负责数据清洗、事件去重、按用户维度聚合以及基于事件时间的窗口计算生成用户近期活跃、购买次数和消费金额等标签。处理结果一部分写入实时查询系统另一部分写入 Iceberg供 Hive 和 Spark SQL 做离线分析。过程中重点关注了 Watermark、Checkpoint、状态 TTL、数据迟到、数据倾斜和 Sink 幂等问题。如果你实际上没有做过不要说成“我独立负责上线”。可以改成我目前对 Flink 的理解主要集中在实时数仓常见场景能够理解并编写基础 Flink SQL正在补充状态、Checkpoint、流流 Join 和生产故障排查方面的实践。这比被追问后答不上来更稳妥。八、优先级你现在先学哪些第一优先级必须掌握Flink 架构Source、Transformation、Sink并行度和算子链Event TimeWatermark窗口StateCheckpointExactly-OnceFlink SQL 基础第二优先级结合岗位准备Kafka 和 Flink 的关系流流 JoinLookup Join实时去重用户画像标签计算Iceberg 写入小文件和 CompactionFlink 反压和延迟排查第三优先级有时间再准备RocksDB 状态后端两阶段提交Checkpoint BarrierCEP异步 IOFlink 与 Kubernetes/YARN 的部署Flink SQL 优化器和执行计划九、最容易被连续追问的一道题题目用 Flink 实时统计每个用户近 7 天的消费金额怎么设计回答框架从 Kafka 读取订单数据按事件时间设置 Watermark按user_id做keyBy使用 7 天滑动窗口聚合消费金额设置允许迟到时间将结果幂等写入 Doris/ClickHouse开启 Checkpoint对状态设置 TTL 或使用窗口自动清理监控延迟、反压、Checkpoint 和数据质量SQL 大致是SELECTuser_id,window_start,window_end,SUM(amount)AStotal_amountFROMTABLE(HOP(TABLEorders,DESCRIPTOR(event_time),INTERVAL1DAY,INTERVAL7DAY))GROUPBYuser_id,window_start,window_end;你面试时不一定要一次讲得特别深入重要的是能把这条链路说完整数据从哪里来按什么时间处理按什么 Key 聚合状态怎么保存迟到怎么办结果写到哪里故障怎么恢复。