**摘要：**本文整理了一份面向金融数仓方向的面试高频题库，覆盖 SQL 基础、离线数仓 Hive、Flink 实时计算、金融业务专项（1104 监管报表、对公账务）以及项目综合问答五大模块。每个问题均按「标准答案 → 面试官深挖追问 → 追问参考答案」的结构展开，既适合面试前快速背诵，也便于顺着追问深入理解底层原理，是一份可直接用于实战演练的面试备战手册。
适配背景：金融数仓、Hive、SQL、Flink 实时、Flink CDC、1104 监管报表
结构：主问题 → 标准答案 → 面试官深挖追问 → 追问参考答案 可以直接背，面试官顺着往下问你都能接住
一、SQL 模块（必考，第一轮必问）
Q1：union 和 union all 的区别
答 union all 直接拼接两个结果集，不做去重、不排序 ，性能好；union 会对合并后的结果全局去重并排序，开销很大。生产环境优先使用 union all，去重尽量提前在子查询完成。
深挖追问 1：什么时候必须用 union？
答：必须全局去重且数据集不大的场景。大数据场景基本不用 union，数据量大时会产生很重的 shuffle，极易数据倾斜。
深挖追问 2：union all 会产生笛卡尔积吗？
答：不会。union/union all 是纵向拼接（行叠加）；join 才是横向关联，才会产生笛卡尔积。
Q2：left join、inner join、full outer join 区别
答
- inner join：只返回左右表 on 条件匹配成功的数据；
- left join：保留左表全部记录，右表匹配不上时，右表字段填充 null；
- full outer join：左右两边全部保留，任意一侧匹配不到，对应字段为 null。
深挖追问 1：left join 之后 where 里过滤右表字段不为 null，会变成什么？
答：等价 inner join。因为 where 是 join 完成后过滤，右表 null 行会被直接剔除。如果只想过滤右表，条件写在 on 后面。
深挖追问 2：left join 出现行数膨胀是什么原因？
答：右表存在一对多。一条左表记录匹配多条右表记录，行就会被复制膨胀。排查：检查右表关联键是否唯一，提前对右表去重。
Q3：where 和 having 的区别
答 where 在 group by 分组之前 过滤原始数据，不能使用聚合函数 ； having 在 group by 分组聚合之后，对聚合结果过滤，可以写 sum/count 等聚合。
深挖追问：where 里能不能写子查询？having 里能不能写普通字段过滤？
答：where 可以带子查询；having 虽然语法支持普通字段，但不推荐。过滤原始数据尽量前置到 where，减少 shuffle 传输的数据量。
Q4：row_number /rank/dense_rank 窗口函数区别
答 假设有数据：100,100,90
- row_number()：
1,2,3相同值序号也不重复，连续编号 - rank()：
1,1,3同分同排名，后面序号跳号 - dense_rank()：
1,1,2同分同排名，序号不跳号，紧密排列
深挖追问 1：窗口函数执行顺序？能不能放在 where 里？
答：窗口函数在 from、where、group by、聚合之后执行，不能直接写在 where，需要套一层子查询或者 CTE。
深挖追问 2：over () 里 partition by 和 order by 作用？
答：partition by 分组，相当于开窗的分区；order by 分区内排序。不写 order by，聚合就是整个 partition 内全部数据。
Q5：开窗函数 over () 原理，和 group by 的差异
答 group by：多行压缩合并成一行，丢失明细； over 开窗：保留原始明细行，在每行附加分组内的聚合统计值，不会压缩行数。
深挖追问：over 里 rows between 和 range between 窗口帧是什么？
答：窗口帧限定分区内参与计算的数据范围。rows 是物理行数；range 是值范围，例如
rows between unbounded preceding and current row，就是从分区第一条到当前行，做累计求和。
Q6：笛卡尔积如何产生，怎么避免？
答 笛卡尔积：A 表 m 行，B 表 n 行，关联后 m*n 行。 产生原因：缺少 on 关联条件；on 条件是恒真；一对多关联未去重。 避免：必须写 on 关联条件，关联前先校验维度表主键唯一，提前去重。
深挖追问：业务什么场景允许笛卡尔积？
答：维度很小的字典表（如性别、类型码表），维度只有几条数据，做全量笛卡尔积做维度补码。
二、离线数仓 Hive 模块
Q1：数仓分层 ODS、DWD、DWS、ADS 每层作用
答
- ODS 原始层：原样接入源数据，不清洗，保留最原始快照，用于回溯；
- DWD 明细层：清洗、过滤脏数据、去重、补空，保留最细业务明细；
- DWS 汇总层：轻度聚合，按业务维度汇总，减少重复计算；
- ADS 应用层：报表、指标、监管报送（如 1104），直接对外输出。
深挖追问 1：为什么分层？不分层直接 ODS 算报表行不行？
答：分层目的：解耦、复用、便于口径管理、故障回溯。不分层会造成 SQL 臃肿，口径散在各处，源表变更全部报表都要改，出问题无法回溯原始数据。
深挖追问 2：DWD 和 DWS 怎么选择粒度？
答：DWD 保留最细粒度（一条借据、一笔交易）；DWS 按业务实体聚合，如按客户、机构、日汇总。
Q2：Hive 分区和分桶区别
答 分区：HDFS 文件夹级别，按时间 / 地区拆分，查询时分区剪枝，跳过无关文件夹，减少文件扫描； 分桶：文件内部，按字段 hash 拆分成多个文件，用于抽样、优化大表 join。
深挖追问 1：分区剪枝失效的场景？
答：分区字段函数运算（如
year(dt)）、隐式类型转换、动态分区未开、分区值字符串不匹配。
深挖追问 2：分桶优化 join 原理？
答：两个表用同一个字段分桶，相同 key 落在同一个桶，join 时只匹配对应桶，不需要全局 shuffle。
Q3：Hive 数据倾斜，现象、原因、解决方案
答 现象：大部分 map/reduce 任务很快跑完，少数 task 长时间卡在 99%。 原因：某个 key 数据量远大于其他 key（热 key）。 方案：
- 过滤无效大 key；
- 加盐打散热 key；
- 热点 key 预聚合；
- map 端预聚合。
深挖追问：加盐打散原理是什么？
答：对热点 key 拼接随机后缀打散，分成多份并行计算，最后再聚合合并结果。非热点 key 不加盐。
Q4：Hive 内部表和外部表区别
答 内部表（管理表）：drop table，元数据 + HDFS 数据文件一起删除 ； 外部表：drop table只删除元数据，HDFS 原始数据保留。生产几乎全部使用外部表，防止误删源数据。
深挖追问：生产建表为什么推荐外部表？
答：数仓数据很宝贵，误删表不会丢失原始数据；支持多表共用同一份 HDFS 数据。
三、Flink 实时（重点！面试官最爱深挖）
Q1：Flink 核心特性
答 流批一体、事件时间处理、有状态计算、Checkpoint/Savepoint 容错、支持 Exactly-Once、低延迟、支持 SQL/Table API。
深挖追问：流批一体怎么理解？
答：同一套 API，既可以跑流式实时任务，也可以跑离线批处理，底层统一执行引擎，不用维护两套代码。
Q2：什么是 State 状态，KeyedState 和 OperatorState 区别
答 State 是算子保存的历史中间数据，是有状态计算的基础。
- KeyedState：按 key 隔离，每个 key 独立一份状态，只能在 KeyedStream 使用，如分组聚合；
- OperatorState：算子全局状态，不区分 key，常用在 Source（CDC Source、Kafka Source）。
深挖追问 1：状态后端有哪些？各自适用场景？
答：MemoryStateBackend（测试）、FsStateBackend（文件系统，中小状态）、RocksDBStateBackend（生产大状态，支持增量 checkpoint）。生产大数据量状态推荐 RocksDB。
深挖追问 2：状态 TTL 作用？
答：设置状态过期时间，自动清理过期状态，防止状态无限膨胀导致 OOM。
Q3：Checkpoint 和 Savepoint 区别
答 Checkpoint：自动定时触发 ，作业故障后自动恢复，轻量快照； Savepoint：手动触发，用于作业升级、版本变更、迁移、扩缩容，生成的快照是用户管理。
深挖追问 1：Checkpoint 的 exactly-once 原理？
答：两段提交 2PC，barrier 屏障对齐，快照保存状态，失败从最近 checkpoint 恢复，保证数据不重不漏。
深挖追问 2：Checkpoint 失败会怎么样？
答：任务不会立刻失败，会尝试重试；多次重试失败，作业失败。
Q4：Watermark 水印是什么？解决什么问题
答 水印是事件时间的进度标记，用来处理乱序数据，判断窗口的数据是否全部到达，触发窗口计算。水印延迟就是允许迟到数据等待的时间。
深挖追问 1：水印单调递增吗？迟到数据超过水印延迟怎么处理？
答：水印只能向前推进，不会回退。超过允许延迟的迟到数据默认丢弃；也可以配置侧输出流收集迟到数据单独处理。
深挖追问 2：水印生成策略？
固定延迟水印、单调递增水印、单调递增非严格水印。
Q5：四种 Flink Join：Regular / Interval / Window / Lookup (快照 Join)
答
- Regular Join：双流 inner/left join，状态无限增长，必须配置 TTL，不然 OOM；两条流的数据会一直保存在状态，任何时间匹配都会输出。
- Interval Join：双流 join，限定事件时间区间，超出区间状态自动清理，状态可控，生产常用。
- Window Join：只有落在同一个窗口内的数据才关联，窗口结束释放状态。
- Lookup Join（快照 Join）：流关联外部维度表（MySQL） ，流数据到达，查询维表当前快照做关联，维表数据不进 Flink 状态。语法
FOR SYSTEM_TIME AS OF。
深挖追问 1：Lookup Join 的缓存策略？
答：LRU 缓存，缓存维表热点数据，减少数据库查询压力；可以设置缓存过期时间。缓存失效会重新查库。
深挖追问 2：Regular Join 为什么状态无限涨？
答：没有时间边界，Flink 不知道这条 key 后续会不会再来匹配数据，所以左右流数据会永久保存在状态，不加 TTL 会持续膨胀。
Q6：Flink 四类 UDF
答
- ScalarFunction 标量函数：一对一，输入一行字段，输出单个值；eval ()
- TableFunction 表函数：一对多，输入一行，输出多行，collect () 输出；SQL 调用 LATERAL TABLE
- AggregateFunction 聚合 UDAGG：多对一，多行聚合输出一个值；createAccumulator、accumulate、getValue
- TableAggregateFunction 表聚合 UDTAGG：多对多，多行聚合输出多行；典型场景 TOP-N，emitValue 输出结果。
深挖追问：UDF 什么时候需要类型注解 @DataTypeHint？
答：复杂类型 Row、自定义对象，Flink 类型推断识别不了，需要手动标注数据类型。
Q7：什么是反压 Backpressure
答 下游算子处理速度跟不上上游发送数据的速度，压力向上游传递，上游降低生产速率，避免缓冲区打爆、内存 OOM。
深挖追问：怎么排查反压？
答：Flink WebUI 看 Backpressure 指标。高反压：看是下游算子瓶颈、外部数据库 sink 慢、GC 频繁。
Q8：Flink CDC 是什么？原理
答 CDC=Change Data Capture 变更数据捕获。Flink CDC 可以直接读取 MySQL Binlog，捕获数据库 insert/update/delete 变更，支持全量快照读取 + 增量 binlog 无缝切换一体化同步，不需要触发器、不需要轮询。
深挖追问 1：全量阶段和增量阶段切换机制？
答：先读全量快照，全量读取过程中持续记录 binlog 位点；全量读完后，从记录位点开始消费 binlog，把全量期间的变更补上，做到无缝切换。
深挖追问 2：CDC 同步遇到主键冲突怎么办？
答：一般是全量阶段重复数据；可以设置主键去重，或者业务上保证主键唯一，调整并行度。
深挖追问 3：binlog 格式要求？
答：MySQL 必须开启 binlog，格式推荐 ROW 行模式。statement 模式无法拿到变更前后字段值。
Q9：Changelog 流、回撤流是什么
答 动态表持续查询，表会不断更新，变更会转为 changelog 流。 类型：+I 新增、-U 更新前旧数据、+U 更新后新数据、-D 删除。 聚合计算产生结果更新时，会先发送撤回旧结果（-U），再下发新结果（+U），就是回撤流。
深挖追问：sink 到 Kafka 的时候回撤流有什么问题？
答：普通 Kafka sink 只支持追加流，回撤数据无法处理；需要使用支持 changelog 的连接器，或者把 changelog 写入底层存储做合并。
四、金融业务专项（你的亮点，1104 / 对公账务）
Q1：表内业务、表外业务
答 表内业务：业务形成银行资产或负债，计入资产负债表。典型：存款、贷款、债券投资。银行承担资金信用风险。 表外业务：不计入资产负债主表，在报表附注披露，大多属于或有事项。银行不直接动用自有资金，赚手续费。例子：银行承兑汇票、保函、信用证、未支用授信。一旦客户违约，银行兜底，这笔业务就会转入表内。
深挖追问：中间业务和表外业务区别？
答：中间业务是广义，银行提供服务收手续费（代销理财、结算），大多无风险；狭义表外业务是带或有风险的担保 / 承诺类业务，存在潜在兑付风险。
Q2：1104 报表是什么
答 1104 是银保监会监管报送报表体系。银行按周期上报信贷、同业、资产负债、风险指标。口径校验极其严格，勾稽关系多，数据质量要求高。
深挖追问 1：1104 报表开发难点？
答：指标口径复杂、大量跨表勾稽校验、数据追溯要求高，需要明细层支撑指标计算，便于监管核查。
深挖追问 2：勾稽关系是什么？
答：报表内部、报表之间指标必须满足的等式逻辑，例如汇总值 = 明细之和，校验数据是否正确。报送前必须校验，不通过无法上报。
Q3：借据、贴现业务
答 借据是一笔贷款的核心合同单据，记录客户、金额、利率、起止日期、还款计划，是对公贷款最细粒度。 票据贴现：企业把未到期票据转让银行，银行扣除利息，提前兑付现金；属于信贷业务。
深挖追问：贴现属于表内还是表外？
答：贴现放款后属于表内资产；未贴现票据属于表外。
Q4：指标口径不一致，排查思路
答
- 核对指标定义：统计范围、统计时间、过滤条件；
- 核对数据源：源表是否一致；
- 核对关联条件、join 顺序；
- 核对是否有去重逻辑、空值处理差异；
- 核对计算逻辑、统计粒度。
深挖追问：两份报表差值很小，怎么定位差异明细？
答：做差值 diff，拉明细对比，定位差异的主键，看单条数据计算逻辑。
五、项目综合问答（必问，自我介绍之后）
Q1：项目中遇到最大的问题，怎么解决
推荐回答模板 项目中遇到 Flink 实时任务状态膨胀，长时间运行 OOM。 现象：任务跑几天内存持续上涨，最后 OOM 重启。 排查：使用 Flink UI 观察状态大小，定位是双流 Regular Join，没有设置 TTL，状态无限保存历史数据。 方案：给 join 状态配置 TTL，过期自动清理；同时评估业务，改成 Interval Join 减少状态。优化后任务稳定长时间运行。
深挖追问 1：线上任务出问题排查流程？
答：看告警 → 查看 Flink UI：反压、状态、Checkpoint、异常日志 → 定位算子 → 看业务数据（脏数据、热 key）→ 修复逻辑 / 调参 → 重跑任务。
深挖追问 2：实时任务和离线任务的数据怎么对齐？
答：离线 T+1 做核对校验，选取业务主键，对比指标；差异定位明细，排查延迟、迟到数据、回撤逻辑。
Q2：实时和离线数仓区别
答 离线：批量调度，T+1，高延迟；数据一次性读取计算，无状态。适合大汇总、监管报表、全量指标。 实时：流处理，秒级延迟；依赖状态、水印、checkpoint。适合监控、实时大屏、实时账务。
深挖追问：金融场景，实时数据和离线数据，哪个更难做？
答：实时更难，需要处理乱序、状态管理、故障恢复，数据一致性保障难度更高。
🎁 附赠：面试官高频连环追问万能话术
- 问：你项目里 Flink 版本是什么？
答：1.14/1.17（按你实际项目写），使用 RocksDB 状态后端，开启增量 checkpoint。
- 问：生产并行度怎么确定？
答：根据数据量、单 task 处理能力，同时考虑 key 分布，避免热 key。
- 问：数据质量怎么做？
答：空值校验、主键唯一性、指标勾稽校验、异常告警。