众安保险数据开发面试全复盘：从SQL数仓到Flink实时计算

上个月刚陪一个学弟复盘完众安保险的数据开发面试他回来的时候抱着厚厚一沓草稿纸嘴里反复念叨同一句话“问得太细了每一个点都能往下挖三层。”这句话基本概括了众安这场面试的调性。作为国内头部的互联网保险公司众安的数据开发岗面试不像传统企业那样只考“会不会写SQL”它更看重你对数据链路全流程的理解、对实时计算和离线数仓的落地能力以及面对保险业务场景时能不能把数据问题翻译成业务语言。这篇文章我就把整场面试的题目、背后的考点、以及我当时指导他准备的思路按模块完整拆出来。无论你是准备跳槽的数据开发还是刚转行想做大数据方向这份复盘都能直接拿去做模拟练习。1. 众安数据开发岗重点考察什么1.1 岗位画像与考察思路众安的数据开发和纯后端开发不一样。后端开发更关注接口、系统架构、高并发而数据开发的核心使命是“把业务数据变成可分析、可决策的资产”。这意味着面试官考察的维度会很立体既要懂SQL、懂数据仓库建模又要懂Spark/Flink这类计算引擎还得对保险业务的指标口径有感知。从实际面试反馈来看众安的数据开发面试整体分四轮左右第一轮技术面深挖基础第二轮侧重场景设计和项目细节第三轮通常是交叉面或Leader面第四轮是HR面。每一轮都会穿插手写SQL或伪代码面试官会围绕你写的每一行代码追问“为什么这么写”“数据量大了怎么办”。1.2 数据开发必备技能拆解根据猎聘等招聘平台的信息众安数据开发岗的任职要求通常包含以下要点。对照着这些要求你就知道面试题会往哪个方向出了。熟悉SQL熟练运用窗口函数、复杂Join、聚合统计这是底线能力。熟悉数据仓库建模方法论包括维度建模、数仓分层、缓慢变化维的处理。熟悉Hadoop生态尤其是Hive、Spark、Flink、Kafka这些核心组件。有实时计算经验者优先这是加分项也是众安作为互联网公司比较看重的能力。对数据质量、数据治理、数据血缘有基本认知。加分项包括熟悉ClickHouse、Doris等OLAP引擎以及有保险或金融行业经验。把这些要求翻译成面试语言就是面试官手里那张打分表。他问你的每一道题本质上都是在检验你有没有对应能力只不过包装成了一道道具体的题目。1.3 面试官真正想筛选的三种能力我在辅导学弟的时候反复跟他强调一个观点面试官不会因为你背熟了某个原理就给你高分他更在意你能不能把知识“用起来”。整场面试下来我觉得众安的面试官主要在看三种能力。第一种是抽象建模能力。给你一个保险业务场景你能不能从业务描述中提炼出事实表和维度表识别出度量值和粒度这是数仓工程师和SQL Boy的分水岭。第二种是链路排查能力。数据开发面对的是复杂的数据管道从采集、清洗、计算到服务任何一个环节出问题都会导致数据异常。面试官会抛出类似“某天订单量指标比平时跌了50%你怎么排查”这样的问题考察的就是你能不能系统地拆解一条数据链路。第三种是工程化意识。你自己写代码没问题还不够你还要考虑任务的稳定性、性能优化、可维护性。众安这种体量的公司每天处理的数据量都是亿级起步的代码跑得慢、跑不稳影响的是整条业务线的报表和策略所以面试官会特别关注你在“性能”和“稳定性”上的思考。2. SQL与数仓基础别在这些题上翻车2.1 高频SQL题专项拆解众安面试里的SQL题不会太偏门基本都是数据开发日常工作里最常用的场景但每一道都能延伸出好几层追问。我整理了三道出现频率最高的题目附上参考思路和代码。第一道是连续登录问题。题目大概是“给定用户登录表user_login(user_id, login_date)求连续登录3天及以上的用户”。这道题其实是在考窗口函数和日期差值的配合使用。WITH temp AS ( SELECT user_id, login_date, row_number() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM user_login ), temp2 AS ( SELECT user_id, date_sub(login_date, rn) AS diff FROM temp ) SELECT user_id FROM temp2 GROUP BY user_id, diff HAVING count(1) 3;这里的关键在于理解date_sub(login_date, rn)这个操作。如果用户是连续登录的那么登录日期减去行号会得到同一个基准日期。分组后统计条数就能筛出连续登录超过N天的用户。面试官经常会追问“如果用户一天有多条登录记录怎么办”“如果有重复日期怎么去重”所以写完之后一定要主动补充去重逻辑。第二道是留存率计算。这也是互联网公司面试的常客。比如“给定用户活跃表user_active(dt, user_id)求每日新增用户在次日、3日、7日的留存率”。考察点是自关联和日期差值的灵活运用。WITH new_users AS ( SELECT dt, user_id FROM user_active a WHERE NOT EXISTS ( SELECT 1 FROM user_active b WHERE b.user_id a.user_id AND b.dt a.dt ) ) SELECT n.dt, count(DISTINCT n.user_id) AS new_user_cnt, count(DISTINCT CASE WHEN a2.dt date_add(n.dt, 1) THEN n.user_id END) / count(DISTINCT n.user_id) AS retain_1d, count(DISTINCT CASE WHEN a3.dt date_add(n.dt, 3) THEN n.user_id END) / count(DISTINCT n.user_id) AS retain_3d FROM new_users n LEFT JOIN user_active a2 ON n.user_id a2.user_id AND a2.dt date_add(n.dt, 1) LEFT JOIN user_active a3 ON n.user_id a3.user_id AND a3.dt date_add(n.dt, 3) GROUP BY n.dt;这道题的坑点在于“新增用户”的定义要写清楚。有人用left join is null有人用not exists两种写法在数据量大的时候性能差异很明显。我在面试中一般会提一句“生产环境建议用left semi join或not exists避免子查询扫描全表”这会让面试官觉得你考虑过性能问题。第三道是TopN问题。比如“求每个品类销量前3的商品”。这道题是row_number()的典型应用属于送分题但容易在partition by的字段上出错。SELECT category, product_id, sales FROM ( SELECT category, product_id, sales, row_number() OVER (PARTITION BY category ORDER BY sales DESC) AS rn FROM product_sales ) t WHERE rn 3;这部分还有一个比较重要的延伸题就是“如何用SQL求中位数”。众安面试里出现过类似问题比如“求用户支付金额的中位数”。思路是用percentile函数Hive里是percentile(col, 0.5)Spark SQL里是percentile_approx(col, 0.5)。Hive的percentile只支持整数需要先用cast转换这个细节如果不说可能就被当成踩坑了。2.2 数仓建模理论题这么答才有层次面试官不会直接问“什么是维度建模”他会把理论藏在场景里。比如“假设众安要做一个保费收入的数仓你会怎么设计事实表和维度表”这种问题考察的是你的建模方法论是否成型。我建议的回答框架是先定业务过程再声明粒度然后确定维度最后确定事实。保费收入这个场景业务过程是“投保”粒度可以是“保单明细”维度包括投保人、产品、渠道、时间、机构事实是保费金额、保额。这样一层层讲下来面试官能看出你的思路是结构化的。接下来大概率会追问“为什么数仓要分层”。这个问题也有固定答法但关键在于答出分层的核心价值清晰的数据组织结构、统一的数据口径、屏蔽原始数据的变动影响、便于做权限管控和成本治理。不用背太花哨的词汇抓住“解耦、复用、统一口径”这三个关键词就能拿高分。还有一个容易翻车的是缓慢变化维。众安这种保险行业用户的投保人信息、被保人信息变动是很正常的。面试官可能会问“用户地址变了你在数仓里怎么处理”。参考做法是拉链表记录历史保留全量变化轨迹适用于需要回溯历史的场景。但如果用户维度变化不频繁也可以用直接覆盖的方式简单高效。最重要的是能说清楚每种策略的适用场景而不是只背概念。2.3 数据质量与血缘治理的基础题2024年之后的数仓面试数据质量和数据治理几乎成了必问项。众安的面试也不例外。面试官问过这样一个问题“如果上游业务库的表结构变更了你的数仓任务挂了怎么快速发现并且通知到责任人”这个问题考察的是你对数据质量监控体系的理解。我当时给学弟的参考回答分三层第一层是任务监控调度平台上的任务失败要能快速感知第二层是数据质量监控包括数据量的波动、空值率、主键唯一性等要设置阈值告警第三层是血缘关系。一旦表结构变更通过元数据管理系统里的血缘图能马上定位到受影响的下游任务从而知道该通知谁。血缘关系最近几年在面试里的出镜率越来越高。在很多公司数据资产平台里都会维护表级和字段级的血缘关系。面试官问这个其实是想知道你有没有“治理意识”。如果你只回答“我不知道”那就等于把这一分拱手让出去了。哪怕没实际做过也要能说出来血缘关系的核心作用影响分析、故障排查、数据溯源。3. 大数据组件原理别只会背概念3.1 Hive与Spark说清楚演进逻辑Hive相关的面试题传统问法是“Hive和传统数据库有什么区别”。但众安的面试官问得更刁钻“Hive为什么慢有哪些优化手段”回答Hive为什么慢要抓住本质Hive默认把SQL翻译成MapReduce作业中间结果要落盘大量IO开销导致执行慢。但这只是表层还要继续往深说。Hive慢的核心原因是MapReduce的编程模型太重每个Map和Reduce阶段都要读写HDFS而且没有充分利用内存。优化手段通常包括数据倾斜处理、小文件合并、分区裁剪、列式存储Parquet/ORC、以及选择更合适的计算引擎比如Spark on Hive或Tez。Spark相关的面试题多半围绕宽窄依赖和血统机制。面试官喜欢问“Spark宽依赖和窄依赖的区别是什么宽依赖为什么容易导致父RDD重算”这个问题比较基础但容易答不完整。推荐的答法是窄依赖是指父RDD的每个分区只被子RDD的一个分区使用比如map、filter宽依赖是指父RDD的每个分区可能被子RDD的多个分区使用典型操作是groupByKey、reduceByKey、join。宽依赖会导致父RDD的分区数据要跨节点进行shuffle所以一旦某个子分区计算失败它对应的多个父分区都要重新计算。这也是为什么Spark引入了checkpoint机制来切断血统链。3.2 Kafka高频考点的统一答题模板Kafka在数据开发面试里的地位非常高因为它几乎是所有实时数据链路的入口。众安面试中关于Kafka的题目出现了这些变体。“Kafka的消费者组是怎么回事为什么同一个消费者组里的消费者不会重复消费同一个分区”“Kafka如何保证消息不丢失”“Kafka怎么实现精确一次语义”这些题目看似零散其实都指向同一个底层机制分区和消费者组的绑定关系。我的建议是把Kafka相关的题串成一条线来记忆。消费者组里的每个消费者会负责若干个分区分区和消费者是强绑定的这是通过Kafka的协调器完成的。一个分区只能被同一个消费者组内的一个消费者消费但一个消费者可以消费多个分区。这样解释清楚了面试官问什么变体你都能绕回来说明白。关于不丢失有一个比较完整的回答框架生产端设置acksall配合retries参数确保消息被所有副本接收后才返回成功。服务端设置min.insync.replicas2要求至少两个副本同步成功才算写入成功。消费端先处理业务逻辑再提交offset避免处理失败但offset已经提交导致消息丢失。精确一次语义这个问题的核心在于跨系统的事务。单靠Kafka本身很难做到端到端的精确一次通常需要下游系统的配合。比如Flink的Kafka connector通过checkpoint机制保存offset配合两阶段提交two-phase commit来实现端到端精确一次。面试里能把这一层说出来就已经超过大部分候选人了。3.3 Flink状态、水位线、检查点答题思路Flink是近几年大数据面试的重头戏众安作为互联网保险公司实时风控、实时理赔这些场景都用得上Flink。面试官问Flink的题目方向很集中状态管理、水位线Watermark、检查点Checkpoint和精确一次语义。水位线这块很多候选人容易翻车。面试官会问“Flink里的Watermark是什么怎么处理乱序数据”参考思路是事件时间EventTime指的是数据产生的时间处理时间ProcessingTime指的是数据到达Flink算子的时间。由于网络延迟、数据乱序等原因事件时间的顺序和到达顺序不一定一致。Watermark就是一个“小于等于这个时间戳的数据都已经到达”的声明Flink用它来触发窗口计算。比如设置Watermark 当前最大事件时间 - 延迟时间相当于允许最多5秒的乱序数据。窗口计算的触发条件是Watermark超过窗口结束时间此时就会触发计算而不是等所有数据都到齐。关于Checkpoint面试官通常会问“Flink的Checkpoint机制是怎么实现的”。回答时把核心要素讲清楚就行定期对状态做快照快照内容包括算子状态和键控状态同时记录Kafka的offset保存到外部存储如HDFS。任务重启时从最近一次Checkpoint恢复实现故障恢复。这里顺带提一句“Barrier对齐”会显得更专业Flink通过插入屏障Barrier来保证快照的一致性分布式快照就是在所有算子收到同一个编号的Barrier之后触发一次全局状态快照。3.4 存储选型HDFS、对象存储、OLAP引擎怎么答众安作为互联网公司数据平台不会只依赖HDFS对象存储和OLAP引擎也很常见。面试官问过这样一个问题“你了解HDFS、对象存储OSS和ClickHouse的区别吗什么场景下用哪个”这道题的关键是不要背概念而是从成本和查询模式两个维度去回答。HDFS适合大规模离线批处理吞吐高但延迟高是数据湖的核心底座。对象存储适合存储非结构化数据和冷数据比如日志文件、图片、备份数据存储成本低。ClickHouse、Doris这类OLAP引擎适合高并发、多维度的即席查询比如BI报表、用户画像查询特点是查询响应快但单机存储容量有限往往需要和HDFS配合使用。延伸一步面试官还会问“为什么宽表在OLAP场景这么常用”或者“ClickHouse的MergeTree引擎有什么核心优势”。答MergeTree时重点说它的排序键和列式存储能大幅减少查询扫描的数据量同时它通过稀疏索引、主键索引、分区裁剪来加速查询。能答到这个层面说明你不只是知道ClickHouse的API而是研究过它的底层存储设计。4. 手写代码与场景题考察的是排查思路4.1 数据倾斜的定位与处理全流程数据倾斜是数据开发面试里的经典压轴题。众安的面试官几乎必问“你的Spark任务跑得很慢怎么判断是不是数据倾斜怎么定位怎么解决”这道题考察的是完整的排查和解决能力我的建议按照“如何判断、如何定位、如何解决”三步来答。定位阶段先看Spark UI上的Stage耗时和Shuffle读写量如果某个Stage特别慢而其他Stage正常就可以怀疑这个Stage里的数据分布不均匀。再看每个Task处理的数据量如果有某个Task的输入数据量远大于其他Task基本可以确认是倾斜。最后定位到具体的操作通常是join、groupBy、distinct产生的倾斜。解决阶段按场景分类。如果是groupBy导致的倾斜可以用两阶段聚合先加随机前缀打散再聚合去掉前缀。如果是join导致的倾斜可以分几种情况小表join大表用广播变量避免shuffle大表join大表可以把倾斜的key单独提取出来先过滤后打散再和另一份数据jion最后union结果。还有一种思路是使用Salting技术给倾斜key加随机后缀分散到多个分区去处理。这块内容信息量很大建议在回答时配合具体场景比如“我在某个日活统计任务中就遇到过某个渠道的用户量特别大导致一个task处理了80%的数据……”这种真实案例比干巴巴讲原理打动人得多。4.2 实时与离线一致性怎么答“实时数据不准”实时计算和离线计算的结果对不上是互联网数据团队最常见的问题也是众安面试官非常喜欢考的场景题。原题大概是“你负责设计一个实时指标跑出来的结果和离线T1的报表对不上你会怎么排查”这个问题考察的是数据一致性意识我建议从计算口径和数据链路两个维度来展开。计算口径层面的排查思路是先确认SQL的逻辑是否一致。实时计算里常用的去重方式和离线不同离线用count(distinct user_id)实时则可能要用去重状态比如Flink的MapState或Redis的Set。这两者的结果天然就有差异因为实时计算在窗口边界和状态过期策略上和离线计算不是完全一致的。所以第一件事就是核对口径定义确保比较的前提是一样的。数据链路层面的排查思路是核对上游数据源是否一致Kafka里的消息是否涵盖了离线表里的全部数据再核对实时任务里有没有丢消息比如offset提交策略、反压导致的延迟、以及Kafka消息堆积再看实时计算的重启恢复Checkpoint失败导致的状态回退也会造成数据不一致。能把这个题目答完整面试官基本就能判断出你是真做过实时数据还是只写过Demo。4.3 笔试手写题高频类型与参考实现除了场景题众安面试里还有手写代码环节不会太复杂但要求思路清晰、代码简洁。我把遇到过的题目类型整理成了一张表。题目类型考察核心参考解法连续N天登录窗口函数、日期差值row_number date_sub group byTopN问题窗口函数排名row_number partition by字符串解析正则、split函数split / regexp_extract数组展开lateral view explodelateral view explode 炸裂函数留存率计算自关联、日期函数left join date_add count distinct两个时间戳差时间函数、格式化unix_timestamp / from_unixtime如果遇到不会的题也不用慌关键是先说出思路面试官通常会引导你往下走。我学弟当时遇到一道“用SQL实现累加求和”的题其实用sum(amount) over (order by dt)就解决了他一开始不知道该写窗口函数讲了半天分组最后面试官递了个话头才反应过来。面试过程中卡壳不可怕可怕的是卡壳之后不说话。5. 业务理解与项目复盘别当成走过场5.1 保险核心业务指标的数仓表达众安是保险公司数据开发如果对保险业务一窍不通面试官很难放心把业务方交给你。面试里出现了几道业务理解题比如“保费收入、赔付率、综合成本率这几个保险术语你理解是什么意思吗”以及“如果业务方想看某产品线的日保费收入你的数仓模型怎么设计”保险业务的几个核心指标并不难理解。保费收入就是用户投保交的钱赔付率是赔款支出和已赚保费的比值综合成本率是赔付率和费用率的加总。作为数据开发你需要知道业务方关心什么指标并且能把指标落到数据模型里。比如计算日保费收入事实表中要有保费金额、保险起期、保险止期、投保日期、渠道、产品等字段维度和度量都要覆盖。业务方还经常会问“这个月到今天的累计保费是多少”这时就要考虑时间维度的语义是看缴费日期还是看保单生效日期不同口径结果差异很大。我的建议是面试前提前了解一下保险公司常用的指标口径不需要背得很细但至少知道名称和大致含义。这会让面试官觉得你有业务sense而不是一个只会写SQL的工具人。5.2 项目复盘的关键动作从“做了什么”到“解决了什么”项目复盘是面试中最重要的一环众安也不例外。很多候选人栽在项目介绍上是因为他只会说“我做了XX”说不出“我为什么要做XX”“XX有什么困难”“最后达到了什么效果”。我给学弟准备了一套项目复盘的模板。首先是项目背景一句话说清楚业务方当时遇到了什么问题比如“领导想知道各渠道的获客成本和保单质量”然后是技术方案说清楚你选择的技术栈和架构比如“我用了Hive做离线分层Flink做实时指标最终数据落ClickHouse”然后是落地细节这里要讲一个具体的难点比如数据倾斜怎么解决的、口径不统一怎么沟通的最后是结果用数据说话比如“查询时间从原来的5分钟降到30秒”“报表上线后业务方取数效率提升30%”。在面试场景里项目经历要有讲的节奏不要流水账。一般讲3-5分钟就要把核心讲完中间留出面试官追问的钩子。比如你提到“我用拉链表处理了历史数据”面试官一定会追问“为什么选拉链表不选全量快照”。这时候你的回答就能体现出真正的项目深度。5.3 没做过的业务怎么展现迁移能力众安的业务包括健康险、车险、航旅险、场景险等多种类型候选人很可能没接触过保险行业的特定业务面试官也清楚这一点。所以面试中会出现这种问题“你没做过保险怎么快速上手”这种问题你千万不要说“我不会”。正确的回答思路是展示你的方法体系先看数仓里的数据字典和指标口径文档建立对业务过程的感知再看现有的数据模型和核心表结构理解事实表和维度表的粒度然后找业务方沟通几个核心指标的口径确认他们对指标的定义最后选一两个核心指标手动跑数验证自己的理解是否正确。这套方法论可以被迁移到任何一个新业务场景面试官听到你有这样的上手路径就不会再纠结你有没有保险行业经验了。6. 面试避坑指南与高频问题速查表6.1 简历、自我介绍和提问环节的加分细节简历是面试的第一道关卡数据开发的简历要突出“量化结果”。比如“负责XX数仓建设”不如改成“负责XX数仓建设覆盖XX张核心表支撑XX条业务线的日常报表”“数据质量提升”不如改成“数据质量监控规则覆盖率达XX%核心指标异常发现时间从小时级缩短到分钟级”。自我介绍控制在2分钟以内核心是“核心技能代表性项目个人优势”。不用把每段工作经历都念一遍重点讲一个和岗位最匹配的项目并尽量在介绍里埋一个钩子比如“在XX项目里我重点解决了实时计算和离线计算数据不一致的问题”这样面试官大概率就会顺着你的钩子问下去你就能掌控面试节奏。面试提问环节也别放过。不要问薪资、加班这种问题多问岗位和业务相关的问题比如“团队当前的数据平台建设处于什么阶段”“实时计算的场景多不多”“数仓团队和业务方的协作模式是什么”。这些问题会让面试官觉得你是有备而来并且真心在考虑这个岗位。6.2 高频问题速查表为了方便你快速复习我把整场面试中高频出现的问题和核心回答要点整理成一张速查表。面试题回答核心要点数仓为什么分层解耦、复用、统一口径、屏蔽源头变动、成本治理维度建模四步走选业务过程、声明粒度、确认维度、确认事实Hive为什么慢MapReduce落地IO开销大改用Spark/Tez、列式存储Spark宽窄依赖宽依赖遇故障会父分区重算引入checkpoint切断血统Kafka消息不丢失生产端acksall消费端处理完再提交offsetFlink Watermark声明“小于等于该时间戳的数据都已到达”配合窗口延迟触发数据倾斜怎么解决两阶段聚合、广播变量、salting加盐拆key实时离线对不上先查口径再查数据链路重点看offset和状态项目复盘讲什么背景、方案、难点、结果四个环节缺一不可没做过保险业务数据字典指标口径核心表结构找业务确认快速上手6.3 面试后的复盘动作千万别省面完试不等于结束建议当天趁热打铁做一次复盘。把面试中被问到的问题全部记下来分类标注答得好的、答得一般的、完全不会的。答得好的不用再看答得一般的要查漏补缺完全不会的一定要及时补课因为下次面试大概率还会出现同类型的问题。我个人还有一个习惯就是把每一轮面试官追问的深度记录下来。如果面试官能在你的回答上继续往下追问好几层说明这个方向是面试官重点关注的领域下一次准备时就要对这个方向做更深的研究。这个动作看着简单坚持三轮面试之后你对自己知识体系薄弱点的认知会清晰很多。最后再分享一个小技巧面试前可以把上面所有速查表打印出来用30分钟快速过一遍重点看那些你平时不太注意的“口播表达”环节比如“介绍一下你这个项目”“你遇到过最大的技术挑战是什么”。这种问题虽然看起来简单但恰恰是最难答出彩的。把几个核心项目提前用语流顺畅的方式写下来你上了考场会发现整个人说话的状态完全不一样。