字节跳动日常实习的“广告大数据研发”初面我上个月刚面完。投之前翻了不少面经发现大多数帖子都在讲“字节算法多难”“手写题多变态”但真正聚焦到广告大数据研发这个具体方向、还停留在初面阶段的经验分享其实很少。所以我自己把这一场面试完整复盘了一遍从前期准备、面试现场、到卡壳的问题和后续改进全都整理出来。如果你也在准备大数据研发类的实习面试这篇文章应该能帮你少走不少弯路尤其是“怎么让一个普通项目看起来符合大数据岗位的胃口”这一点。1. 先搞清楚“广告大数据研发”这个岗到底要什么人1.1 岗位坐标广告业务的“数据中间层”面试之前我花了两天时间想明白一个问题广告大数据研发和普通的大数据开发到底有什么区别。现在很多公司的大数据岗位都叫“数据研发”或者“数据平台开发”但贴到广告业务下之后做的事情会非常具体。广告数据研发在整个广告链路里承担的是“数据中间层”的角色。上游是广告曝光、点击、转化这些埋点日志中游要做日志接入、清洗、过滤、会话拼接、指标计算下游要支撑业务看板、报表、实时投放策略、模型特征。大量工作离不开这几类任务离线ETL算T1的消耗和转化数据、实时链路用Flink做分钟级或者秒级的指标统计、数据仓库分层设计、以及大量数据质量监控任务。所以初面面试官大概率不会揪着你问“你了解我们公司的什么业务”而是会反复确认你能不能理解一条完整的数据链路。比如日志从产生到最后落到报表上经过哪几个环节每个环节的延迟是多少某个字段缺失了会从哪一层开始暴雷我当时给自己画了一张链路图把采集、消息队列、实时计算、离线数仓、OLAP查询这几个环节全部串了一遍后面面试过程中很多问题其实都能归到这张图上。1.2 初面这三个维度基础、项目、排查思路初面通常是由团队里的一线工程师或者组长来面时长在四十分钟到一个小时之间整体节奏非常紧凑。我面下来的体感是它主要看三件事。第一是基础功底。数据结构、Java并发、SQL这些属于硬通货如果这些答不利索简历上写的“熟悉大数据组件”基本会被打问号。第二是项目真实性。面试官会通过追问细节来验证你简历上的项目是不是自己做的做过和听说过在回答里是两种状态后者撑不过三轮追问。第三是排查问题的思路。这一点很关键初面非常喜欢抛一些“线上任务失败了怎么办”“实时和离线对不上怎么办”的场景题重点不在标准答案而在你有没有一套清晰的排查路径。搞清楚这三点之后我的准备重心就完全转移了简历项目往数据链路上靠组件复习抓Hadoop生态的主干算法反而只做了热手训练没有花太多时间刷难题。2. 投递前的准备简历、项目、组件复习怎么排优先级2.1 简历里的项目要改成“大数据味”我的项目经历其实不算特别硬核一个数据平台的课程项目加上一段在传统企业里做报表开发的实习。一开始我简历里写的是“负责订单报表开发”“使用Java和MySQL”“参与xx管理系统”这投出去大概率连初筛都过不了。后来我换了思路不改造项目本身而是改造项目的描述方式。每一个项目都要回答清楚四个问题数据量级是多少延迟要求是什么用到了哪些存算组件你在其中具体负责了什么。比如原来一段“用Spring Boot做报表后台”改成了“处理每日百万级订单数据使用Hive完成离线ETL将结果同步至MySQL通过XX报表平台提供查询”味道完全不一样。我还刻意把项目往“疑似广告场景”上靠了靠。面试官看到“用户行为日志”“点击流”“转化漏斗”这类关键词时会天然觉得你和岗位更匹配。哪怕只是做了一次数据清洗也要把过程讲清楚数据从哪来、有多少字段、坏数据怎么处理、质量指标怎么设。这些细节才是初面深挖的素材。2.2 组件复习先抓Hadoop生态主干再补Flink和Kafka大数据组件范围太广如果每个都想要覆盖最后什么都记不牢。我给自己的复习顺序做了一个优先级分层。第一梯队是Hadoop生态的核心HDFS读写机制、NameNode和DataNode的职责、MapReduce的执行流程、Yarn的资源调度模型。第二梯队是SparkRDD依赖关系、shuffle过程、join类型、内存管理。第三梯队是Hive分区表、分桶表、数据倾斜、动态分区。第四梯队才是Kafka和FlinkKafka重点看分区消费者组、offset、消息不丢不重Flink重点看窗口、状态、checkpoint、exactly-once。实际面试中Java、HDFS、Spark、Hive这四块被问到的概率极高Kafka和Flink通常以场景题出现。我面完之后最大的感受是组件原理千万别只背概念一定要能讲出“数据从进入到输出底层到底发生了什么”。比如RDD依赖关系和shuffle的关系你要是只背“宽依赖会产生shuffle”面试官下一句可能就是“那你知道shuffle过程中数据落到本地磁盘的是什么格式吗”这时候光靠八股就撑不住了。2.3 算法和SQL初面不卷难度但卷规范初面的算法题整体难度不大以数组、链表、字符串、哈希、二叉树这些基础类型为主常见的有反转链表、合并两个有序数组、Two Sum、判断括号合法之类。我没有花大量时间刷Hard题而是把中等难度题的手感保持住每天三到五道并刻意练习在白板或者在线编辑器里写代码的节奏。SQL反而比算法更重要因为大数据研发每天都要写SQL。建议把窗口函数练熟row_number、rank、dense_rank、lag、lead、sum over高频到几乎必考。分组去重、连续登录、留存率、PV/UV统计这些都是广告数据分析里最常用的场景。3. 初面现场全流程复盘每个环节都发生了什么3.1 自我介绍三句话把重点说清面试一开始就让我做自我介绍。我准备了大概两分钟的内容但真正说的时候被缩短到四十秒左右。我的框架是第一句话介绍自己的学校和专业背景第二句话讲两个项目的核心内容重点放在数据量级和组件使用上第三句话说明对什么方向感兴趣。别把自我介绍变成履历复述把亮点抛出来面试官会顺着你的亮点去挖后面的话题基本就在你掌控范围内了。我大概是这么说的“我叫XXXX学校计算机专业在读。之前做过两个数据方向的项目一个是用户行为日志分析平台处理五百万级用户行为数据用Hive做离线清洗Spark做用户路径统计结果存在ClickHouse里供可视化查询另一个是在一家传统企业实习负责订单ETL和报表开发。我对离线数仓和实时计算都比较感兴趣最近在看Flink相关的项目。”这一段说完面试官就顺着“日志分析平台”开始问了等于我自己引导了话题方向。3.2 项目深挖每个项目都被追问到底项目深挖环节大概占了十五到二十分钟问的问题一个接一个基本是追问式。“日志数据从哪里采集的格式是什么样的”“数据量大概多少每天新增多少行”“脏数据是怎么处理的”“用户路径统计怎么做的用了哪几个判断条件”“如果给你十倍的数据量现在这个方案还能撑住吗”我被问得比较深的一个问题是“你说你用了Spark做用户路径统计你能讲讲你是怎么做session划分的吗”我当时确实做过session划分把同一用户、相邻事件间隔不超过30分钟的那批事件归成一个session然后用窗口函数分类计算。但面试官继续追问“30分钟这个阈值你是怎么定的如果业务方想改成5分钟你会怎么设计才能不重跑全部数据”这个问题把我问住了。我心里知道应该把session阈值做成可配置的参数但当时项目里确实是写死的所以只能如实说“项目里阈值是固定的如果要改可能会考虑把配置拆分到线上新增参数解析逻辑这样只需要对新进日志生效”。面试官没有否定而是点了点头说“这个思路可以”然后跳到下一题了。事后复盘我觉得这种问题重点不是你有没有预判到所有场景而是能不能快速给出一个“可落地的实现路径”。3.3 Java基础与并发快问高频且直接初面的大数据岗基本都会带一点Java基础题因为团队里大量代码都是Java生态。面试官节奏很快问题都是短平快。被问到的问题我回忆了一下大致包括HashMap的底层结构、什么时候树化、为什么树化阈值是8ArrayList和LinkedList的区别线程池核心线程数和最大线程数的关系任务队列满了之后会发生什么synchronized和ReentrantLock的区别volatile关键字保证了什么不保证什么。这些问题对于认真复习过Java并发的人来说都不难但回答时要注意一个坑别只背结论。比如“HashMap为什么树化阈值是8”这个问题除了说“为了平衡查询性能和树化开销”之外最好还能补一点“在随机哈希下泊松分布里链表长度达到8的概率极低”这个统计学背景。这会让面试官觉得你是真的理解而不是背了博客。我在并发这块被追加了一个问题“线程池里的核心线程数一般怎么设置”我说了CPU密集型和IO密集型的两种通用估算方式面试官继续追问“如果核心线程设小了任务队列又特别长你会怎么办”。我回答的思路是先看队列堆积的原因是任务本身慢还是下游依赖慢再决定是调大工作线程数、分流还是做背压控制。虽然不完美但面试官认可了我先定位再做处理的思路。3.4 组件原理问答从“会背”到“会讲”这一轮实际上和项目深挖是连在一起的面试官问组件问题时几乎都会带一个场景。“用Spark处理日志任务跑得很慢你会从哪里入手排查”“用Hive建表会把数据量很大的历史表直接设置成动态分区吗为什么”这些问题不是让你背组件定义而是考察你在真实生产里有没有碰过坑。我在Hive这里被问到“你知道Hive的Map端聚合和Reduce端聚合分别对应什么吗数据倾斜时你会怎么处理”我回答了常见的数据倾斜场景比如热点key、空值过多、join小表不合适然后针对热点key提出加随机前缀做两阶段聚合针对空值提前过滤。面试官追了一句“加随机前缀会影响最终结果正确性吗”我说只要第二次聚合时再做一次去前缀就能保证结果一致这里我说得比较小心因为确实有些聚合场景加前缀会改变语义比如去重就不能随便这么做。Spark那边问了“RDD的宽窄依赖区别”和“哪些算子会产生宽依赖”然后顺着shuffle问了一句“shuffle阶段的数据落地是什么时机”。说实话这个细节我复习的时候扫过一眼但没专门记当时靠逻辑推了一下shuffle write发生在map阶段输出之后要等所有结果分区计算完才会落盘shuffle read在reduce阶段拉取数据。面试官没有打断我说明这个回答方向基本是对的。3.5 手写SQL和算法难度不大但要求严谨这个环节有两道题一道SQL一道算法。SQL题是这样的给定一张广告点击日志表ad_click_log字段包括log_date、device_id、ad_id、click_time统计连续3天都有点击记录的用户。这题其实就是连续N天问题核心是在按用户分组后对日期排序然后用日期减行号获得分组标识。SELECT device_id FROM ( SELECT device_id, log_date, row_number() OVER(PARTITION BY device_id ORDER BY log_date) AS rn FROM ad_click_log GROUP BY device_id, log_date ) t GROUP BY device_id, date_sub(log_date, rn) HAVING COUNT(*) 3;这里有一个容易踩的坑必须先把同一个用户的同一天日志去重否则用row_number会产生错误的分组标识导致把本来不连续的天数算成连续。我在写的时候提前做了GROUP BY device_id, log_date这一步在现场没有被打断但复盘的时候觉得这个细节很加分因为面试官大概率就是想看你会不会处理重复日期。算法题是经典的合并区间给定若干区间合并有重叠的部分。面试官明确说可以用Java或者Python。我选了Java先按左端点排序然后逐个合并。public int[][] merge(int[][] intervals) { Arrays.sort(intervals, (a, b) - a[0] - b[0]); Listint[] res new ArrayList(); for (int[] interval : intervals) { if (res.isEmpty() || res.get(res.size() - 1)[1] interval[0]) { res.add(interval); } else { res.get(res.size() - 1)[1] Math.max(res.get(res.size() - 1)[1], interval[1]); } } return res.toArray(new int[res.size()][]); }写完后面试官没有让我跑样例而是问“如果你返回的是一个新数组原来的数组会被影响吗”我说不会因为新数组的对象是新建的但里面的区间对象如果直接引用原数组的元素就会有影响所以for循环里最好new一个新的int数组放进去。面试官对这个问题看起来比较满意。3.6 反问环节别放弃展示思考的机会反问环节我开始没太当回事只打算问一下“团队主要做什么”。但后来觉得初面的反问其实是展示你思考深度的机会问题可以这么问不要问“加班多吗”这种和面试无关的问题也不要问“你们用什么技术栈”这种网上能查到的信息。比较好的问题方向是“团队目前实时计算的业务场景多还是离线场景多”“实习生一般会参与到哪一层任务的开发”“你对实习生的期待是哪些能力”。我当时问了两个问题“团队里离线和实时的比例大概是多少”“如果实习进来前期会主要接触哪部分链路”第一个问题是想确认团队方向第二个问题是想让面试官觉得我已经在考虑入职后怎么快速上手了。面试官也很直接地告诉我目前实时方向需求更大希望实习生能理解数据实时计算的整体流程这也验证了我前面复习Flink的判断。4. 复盘我卡住的问题比回答更重要的是排查思路4.1 卡壳问题一Hive的小文件问题怎么答才不虚面试官问“在实际使用Hive的过程中如果小文件特别多你会怎么处理”我第一反应是“用小文件合并参数”但回答得很零散。现在复盘这个问题应该从“产生原因-危害-解决方案-落地参数”四个层次回答。小文件的产生主要有几个来源过分区数、动态分区写入的时候生成很多碎片、Reduce数量设置过多、Spark写Hive时每个task都输出一个文件。危害一句话总结就是给NameNode内存带来压力同时每个文件在MapReduce里都对应一个InputSplit启动任务的开销会远大于执行本身。解决方案可以分场景谈如果是离线合并可以用INSERT OVERWRITE重写表数据或者用Hive的ALTER TABLE CONCATENATE合并orc/parquet如果是Spark任务写Hive可以在写之前用coalesce或repartition控制最终文件数并按动态分区字段适当控制并行度如果是一个持续写入的实时任务需要定时做小文件合并任务。这样答下来远比说“我设置合并参数”要有内容。4.2 卡壳问题二实时指标和离线指标对不上怎么排查这个问题我现场确实有点卡住了。面试官问“广告业务里通常离线算一遍消耗和转化实时算一遍给投放策略看两边数字对不上你觉得可能是什么原因”我之前没有认真想过对账这个问题。复盘后我觉得这个问题可以从时间口径、计算逻辑、数据质量三个维度拆。做离线统计的时候我们通常切分自然日取的是当天0点到24点的数据实时统计经常用最近5分钟、最近1小时这种滚动窗口或者使用事件时间而离线用处理时间。如果两边口径不一致算出来的指标对不上非常正常。其次离线任务可以做到精确去重和精确计数实时任务为了延迟往往会用近似算法比如HyperLogLog算UV结果有误差。最后数据本身的质量问题比如日志重复上报、还没完成的清洗逻辑、实时任务重启导致重复消费等都会让数字不一样。所以回答这个问题的思路应该是先校准时间口径和去重逻辑再核对计算引擎的语义最后再用数据质量监控来兜底。如果面试官继续追问“你打算怎么监控”可以说在离线结果和实时结果各算出一个中间指标每天定时对账差值超过阈值就报警这样才能尽早发现问题。4.3 卡壳问题三Spark任务跑一半挂掉怎么定位这个问题是在反问之前面试官突然插进来问的我回答得比较笼统只说了“看日志和看Spark UI”。但复盘后我觉得这个问题其实有非常标准的排查路径面试官想听的是你有没有真正处理过线上任务。完整思路应该是第一步用Spark History Server看整个Application的Executor、Task状态找出失败的stage。第二步看失败task的报错类型是OOM还是数据倾斜是找不到文件还是连接超时。第三步具体看数据分布比如repartition后有没有出现某个task处理的数据量远超其他task如果是那就是典型的数据倾斜。第四步针对原因做处理OOM调大executor内存并检查是否存在内存缓存过大的逻辑数据倾斜可以使用加盐双重聚合或广播join找不到文件则检查分区字段的时区偏移和数据产出延迟。最后别忘了提一句如果是调度平台上的任务重跑之前要确认幂等性和下游依赖状态防止重复计算。4.4 面试官想从卡壳里看到什么这几道卡壳题让我想明白了一个道理初面问的很多问题并不是真的要你用标准答案来砸他而是想看到你把一个陌生问题拆解开的能力。即使回答不全只要有清晰的思维链条面试官就会给你继续往下说的机会。我在回答“实时和离线对不上”的时候虽然当时没有给出完美的三层次答案但我先说的是“我会先看两边是不是用同一个维度和时间范围去算”这句话让面试官知道我不是直接从代码层开始瞎猜而是有一个合理切入点。后来面试官才愿意继续引导我。所以如果你在面试中被问题卡住别慌先说出一个你觉得最可能的原因再一步步展开肯定比你憋着不说强得多。5. 备考自查表与一个月冲刺建议5.1 知识点自查表哪些必须做到脱口而出我根据自己的面试经历整理了一张自查表分享给你。如果你能对每个问题都给出一个相对完整的回答初面的概率就会高很多。知识块必须能脱口而出的点HDFS文件读写流程、副本机制、NameNode宕机会造成什么MapReduceMap到Reduce的过程、shuffle阶段发生了什么SparkRDD依赖关系、宽窄依赖、shuffle落盘时机、数据倾斜处理Hive分区表和分桶表区别、数据倾斜场景和解决手段、小文件合并Kafka分区策略、消费者组、offset提交、消息不重不丢方案Flink窗口类型、checkpoint机制、状态存储、exactly-once语义Java基础HashMap原理、线程池参数、synchronized与ReentrantLockSQL窗口函数、连续登录、留存率、分组去重这张表不需要背答案关键是能对着每一条用自己的话讲三分钟。讲不出来就说明还不够回去继续查。5.2 四周冲刺时间怎么安排如果你打算投类似岗位我给一个比较普适的时间安排适合业余时间准备的情况。前两周重点搞定项目描述和组件主干。把简历上每个项目按照数据量、组件、职责、结果四要素重写确保每一个技术名词都能被追问。组件复习先啃HDFS和MapReduce再转Spark这两块必须形成完整认知链。第三周复习Hive和SQL把窗口函数练到条件是“每天都要写几段SQL”。同时开始做算法热手。第四周集中看Flink和Kafka这两个组件如果项目里没用过至少要能讲清楚基础原理和典型应用。最后几天做模拟面试可以找同学互相问问题重点锻炼“把一件事讲清楚”的能力。5.3 过来人的几个提醒最后说几个我在准备和面试过程中真实踩过的坑你也可以提前避开。第一别在简历里堆砌一堆“熟悉”但经不起追问的词。你写“熟悉Flink”面试官就默认你可以回答checkpoint执行过程如果答不上来反而不如不写。第二自我介绍一定要精心排练这是唯一一个你可以完全掌控的环节把话题引到你最有把握的项目上。第三SQL题宁可多写两步也不要省略关键细节比如去重、为空判断这些细节在面试官眼里比算法题更显project经验。第四面试结束后立刻把问题整理成文档不然后面复盘全靠记忆很容易丢掉细节。这次初面整体下来我的体感是字节初面面试官非常务实不玩虚的他们对大数据的考察更多落在“你真正动手解决问题”上。希望这篇复盘能帮到正在准备广告大数据研发实习面试的同学。如果觉得自己在某个知识块上还有缺口就按上面的自查表一项一项补最怕的不是不会而是明明不会却不知道从哪里开始查。 字节广告大数据研发实习初面复盘：项目准备、组件原理与排查思路
字节跳动日常实习的“广告大数据研发”初面我上个月刚面完。投之前翻了不少面经发现大多数帖子都在讲“字节算法多难”“手写题多变态”但真正聚焦到广告大数据研发这个具体方向、还停留在初面阶段的经验分享其实很少。所以我自己把这一场面试完整复盘了一遍从前期准备、面试现场、到卡壳的问题和后续改进全都整理出来。如果你也在准备大数据研发类的实习面试这篇文章应该能帮你少走不少弯路尤其是“怎么让一个普通项目看起来符合大数据岗位的胃口”这一点。1. 先搞清楚“广告大数据研发”这个岗到底要什么人1.1 岗位坐标广告业务的“数据中间层”面试之前我花了两天时间想明白一个问题广告大数据研发和普通的大数据开发到底有什么区别。现在很多公司的大数据岗位都叫“数据研发”或者“数据平台开发”但贴到广告业务下之后做的事情会非常具体。广告数据研发在整个广告链路里承担的是“数据中间层”的角色。上游是广告曝光、点击、转化这些埋点日志中游要做日志接入、清洗、过滤、会话拼接、指标计算下游要支撑业务看板、报表、实时投放策略、模型特征。大量工作离不开这几类任务离线ETL算T1的消耗和转化数据、实时链路用Flink做分钟级或者秒级的指标统计、数据仓库分层设计、以及大量数据质量监控任务。所以初面面试官大概率不会揪着你问“你了解我们公司的什么业务”而是会反复确认你能不能理解一条完整的数据链路。比如日志从产生到最后落到报表上经过哪几个环节每个环节的延迟是多少某个字段缺失了会从哪一层开始暴雷我当时给自己画了一张链路图把采集、消息队列、实时计算、离线数仓、OLAP查询这几个环节全部串了一遍后面面试过程中很多问题其实都能归到这张图上。1.2 初面这三个维度基础、项目、排查思路初面通常是由团队里的一线工程师或者组长来面时长在四十分钟到一个小时之间整体节奏非常紧凑。我面下来的体感是它主要看三件事。第一是基础功底。数据结构、Java并发、SQL这些属于硬通货如果这些答不利索简历上写的“熟悉大数据组件”基本会被打问号。第二是项目真实性。面试官会通过追问细节来验证你简历上的项目是不是自己做的做过和听说过在回答里是两种状态后者撑不过三轮追问。第三是排查问题的思路。这一点很关键初面非常喜欢抛一些“线上任务失败了怎么办”“实时和离线对不上怎么办”的场景题重点不在标准答案而在你有没有一套清晰的排查路径。搞清楚这三点之后我的准备重心就完全转移了简历项目往数据链路上靠组件复习抓Hadoop生态的主干算法反而只做了热手训练没有花太多时间刷难题。2. 投递前的准备简历、项目、组件复习怎么排优先级2.1 简历里的项目要改成“大数据味”我的项目经历其实不算特别硬核一个数据平台的课程项目加上一段在传统企业里做报表开发的实习。一开始我简历里写的是“负责订单报表开发”“使用Java和MySQL”“参与xx管理系统”这投出去大概率连初筛都过不了。后来我换了思路不改造项目本身而是改造项目的描述方式。每一个项目都要回答清楚四个问题数据量级是多少延迟要求是什么用到了哪些存算组件你在其中具体负责了什么。比如原来一段“用Spring Boot做报表后台”改成了“处理每日百万级订单数据使用Hive完成离线ETL将结果同步至MySQL通过XX报表平台提供查询”味道完全不一样。我还刻意把项目往“疑似广告场景”上靠了靠。面试官看到“用户行为日志”“点击流”“转化漏斗”这类关键词时会天然觉得你和岗位更匹配。哪怕只是做了一次数据清洗也要把过程讲清楚数据从哪来、有多少字段、坏数据怎么处理、质量指标怎么设。这些细节才是初面深挖的素材。2.2 组件复习先抓Hadoop生态主干再补Flink和Kafka大数据组件范围太广如果每个都想要覆盖最后什么都记不牢。我给自己的复习顺序做了一个优先级分层。第一梯队是Hadoop生态的核心HDFS读写机制、NameNode和DataNode的职责、MapReduce的执行流程、Yarn的资源调度模型。第二梯队是SparkRDD依赖关系、shuffle过程、join类型、内存管理。第三梯队是Hive分区表、分桶表、数据倾斜、动态分区。第四梯队才是Kafka和FlinkKafka重点看分区消费者组、offset、消息不丢不重Flink重点看窗口、状态、checkpoint、exactly-once。实际面试中Java、HDFS、Spark、Hive这四块被问到的概率极高Kafka和Flink通常以场景题出现。我面完之后最大的感受是组件原理千万别只背概念一定要能讲出“数据从进入到输出底层到底发生了什么”。比如RDD依赖关系和shuffle的关系你要是只背“宽依赖会产生shuffle”面试官下一句可能就是“那你知道shuffle过程中数据落到本地磁盘的是什么格式吗”这时候光靠八股就撑不住了。2.3 算法和SQL初面不卷难度但卷规范初面的算法题整体难度不大以数组、链表、字符串、哈希、二叉树这些基础类型为主常见的有反转链表、合并两个有序数组、Two Sum、判断括号合法之类。我没有花大量时间刷Hard题而是把中等难度题的手感保持住每天三到五道并刻意练习在白板或者在线编辑器里写代码的节奏。SQL反而比算法更重要因为大数据研发每天都要写SQL。建议把窗口函数练熟row_number、rank、dense_rank、lag、lead、sum over高频到几乎必考。分组去重、连续登录、留存率、PV/UV统计这些都是广告数据分析里最常用的场景。3. 初面现场全流程复盘每个环节都发生了什么3.1 自我介绍三句话把重点说清面试一开始就让我做自我介绍。我准备了大概两分钟的内容但真正说的时候被缩短到四十秒左右。我的框架是第一句话介绍自己的学校和专业背景第二句话讲两个项目的核心内容重点放在数据量级和组件使用上第三句话说明对什么方向感兴趣。别把自我介绍变成履历复述把亮点抛出来面试官会顺着你的亮点去挖后面的话题基本就在你掌控范围内了。我大概是这么说的“我叫XXXX学校计算机专业在读。之前做过两个数据方向的项目一个是用户行为日志分析平台处理五百万级用户行为数据用Hive做离线清洗Spark做用户路径统计结果存在ClickHouse里供可视化查询另一个是在一家传统企业实习负责订单ETL和报表开发。我对离线数仓和实时计算都比较感兴趣最近在看Flink相关的项目。”这一段说完面试官就顺着“日志分析平台”开始问了等于我自己引导了话题方向。3.2 项目深挖每个项目都被追问到底项目深挖环节大概占了十五到二十分钟问的问题一个接一个基本是追问式。“日志数据从哪里采集的格式是什么样的”“数据量大概多少每天新增多少行”“脏数据是怎么处理的”“用户路径统计怎么做的用了哪几个判断条件”“如果给你十倍的数据量现在这个方案还能撑住吗”我被问得比较深的一个问题是“你说你用了Spark做用户路径统计你能讲讲你是怎么做session划分的吗”我当时确实做过session划分把同一用户、相邻事件间隔不超过30分钟的那批事件归成一个session然后用窗口函数分类计算。但面试官继续追问“30分钟这个阈值你是怎么定的如果业务方想改成5分钟你会怎么设计才能不重跑全部数据”这个问题把我问住了。我心里知道应该把session阈值做成可配置的参数但当时项目里确实是写死的所以只能如实说“项目里阈值是固定的如果要改可能会考虑把配置拆分到线上新增参数解析逻辑这样只需要对新进日志生效”。面试官没有否定而是点了点头说“这个思路可以”然后跳到下一题了。事后复盘我觉得这种问题重点不是你有没有预判到所有场景而是能不能快速给出一个“可落地的实现路径”。3.3 Java基础与并发快问高频且直接初面的大数据岗基本都会带一点Java基础题因为团队里大量代码都是Java生态。面试官节奏很快问题都是短平快。被问到的问题我回忆了一下大致包括HashMap的底层结构、什么时候树化、为什么树化阈值是8ArrayList和LinkedList的区别线程池核心线程数和最大线程数的关系任务队列满了之后会发生什么synchronized和ReentrantLock的区别volatile关键字保证了什么不保证什么。这些问题对于认真复习过Java并发的人来说都不难但回答时要注意一个坑别只背结论。比如“HashMap为什么树化阈值是8”这个问题除了说“为了平衡查询性能和树化开销”之外最好还能补一点“在随机哈希下泊松分布里链表长度达到8的概率极低”这个统计学背景。这会让面试官觉得你是真的理解而不是背了博客。我在并发这块被追加了一个问题“线程池里的核心线程数一般怎么设置”我说了CPU密集型和IO密集型的两种通用估算方式面试官继续追问“如果核心线程设小了任务队列又特别长你会怎么办”。我回答的思路是先看队列堆积的原因是任务本身慢还是下游依赖慢再决定是调大工作线程数、分流还是做背压控制。虽然不完美但面试官认可了我先定位再做处理的思路。3.4 组件原理问答从“会背”到“会讲”这一轮实际上和项目深挖是连在一起的面试官问组件问题时几乎都会带一个场景。“用Spark处理日志任务跑得很慢你会从哪里入手排查”“用Hive建表会把数据量很大的历史表直接设置成动态分区吗为什么”这些问题不是让你背组件定义而是考察你在真实生产里有没有碰过坑。我在Hive这里被问到“你知道Hive的Map端聚合和Reduce端聚合分别对应什么吗数据倾斜时你会怎么处理”我回答了常见的数据倾斜场景比如热点key、空值过多、join小表不合适然后针对热点key提出加随机前缀做两阶段聚合针对空值提前过滤。面试官追了一句“加随机前缀会影响最终结果正确性吗”我说只要第二次聚合时再做一次去前缀就能保证结果一致这里我说得比较小心因为确实有些聚合场景加前缀会改变语义比如去重就不能随便这么做。Spark那边问了“RDD的宽窄依赖区别”和“哪些算子会产生宽依赖”然后顺着shuffle问了一句“shuffle阶段的数据落地是什么时机”。说实话这个细节我复习的时候扫过一眼但没专门记当时靠逻辑推了一下shuffle write发生在map阶段输出之后要等所有结果分区计算完才会落盘shuffle read在reduce阶段拉取数据。面试官没有打断我说明这个回答方向基本是对的。3.5 手写SQL和算法难度不大但要求严谨这个环节有两道题一道SQL一道算法。SQL题是这样的给定一张广告点击日志表ad_click_log字段包括log_date、device_id、ad_id、click_time统计连续3天都有点击记录的用户。这题其实就是连续N天问题核心是在按用户分组后对日期排序然后用日期减行号获得分组标识。SELECT device_id FROM ( SELECT device_id, log_date, row_number() OVER(PARTITION BY device_id ORDER BY log_date) AS rn FROM ad_click_log GROUP BY device_id, log_date ) t GROUP BY device_id, date_sub(log_date, rn) HAVING COUNT(*) 3;这里有一个容易踩的坑必须先把同一个用户的同一天日志去重否则用row_number会产生错误的分组标识导致把本来不连续的天数算成连续。我在写的时候提前做了GROUP BY device_id, log_date这一步在现场没有被打断但复盘的时候觉得这个细节很加分因为面试官大概率就是想看你会不会处理重复日期。算法题是经典的合并区间给定若干区间合并有重叠的部分。面试官明确说可以用Java或者Python。我选了Java先按左端点排序然后逐个合并。public int[][] merge(int[][] intervals) { Arrays.sort(intervals, (a, b) - a[0] - b[0]); Listint[] res new ArrayList(); for (int[] interval : intervals) { if (res.isEmpty() || res.get(res.size() - 1)[1] interval[0]) { res.add(interval); } else { res.get(res.size() - 1)[1] Math.max(res.get(res.size() - 1)[1], interval[1]); } } return res.toArray(new int[res.size()][]); }写完后面试官没有让我跑样例而是问“如果你返回的是一个新数组原来的数组会被影响吗”我说不会因为新数组的对象是新建的但里面的区间对象如果直接引用原数组的元素就会有影响所以for循环里最好new一个新的int数组放进去。面试官对这个问题看起来比较满意。3.6 反问环节别放弃展示思考的机会反问环节我开始没太当回事只打算问一下“团队主要做什么”。但后来觉得初面的反问其实是展示你思考深度的机会问题可以这么问不要问“加班多吗”这种和面试无关的问题也不要问“你们用什么技术栈”这种网上能查到的信息。比较好的问题方向是“团队目前实时计算的业务场景多还是离线场景多”“实习生一般会参与到哪一层任务的开发”“你对实习生的期待是哪些能力”。我当时问了两个问题“团队里离线和实时的比例大概是多少”“如果实习进来前期会主要接触哪部分链路”第一个问题是想确认团队方向第二个问题是想让面试官觉得我已经在考虑入职后怎么快速上手了。面试官也很直接地告诉我目前实时方向需求更大希望实习生能理解数据实时计算的整体流程这也验证了我前面复习Flink的判断。4. 复盘我卡住的问题比回答更重要的是排查思路4.1 卡壳问题一Hive的小文件问题怎么答才不虚面试官问“在实际使用Hive的过程中如果小文件特别多你会怎么处理”我第一反应是“用小文件合并参数”但回答得很零散。现在复盘这个问题应该从“产生原因-危害-解决方案-落地参数”四个层次回答。小文件的产生主要有几个来源过分区数、动态分区写入的时候生成很多碎片、Reduce数量设置过多、Spark写Hive时每个task都输出一个文件。危害一句话总结就是给NameNode内存带来压力同时每个文件在MapReduce里都对应一个InputSplit启动任务的开销会远大于执行本身。解决方案可以分场景谈如果是离线合并可以用INSERT OVERWRITE重写表数据或者用Hive的ALTER TABLE CONCATENATE合并orc/parquet如果是Spark任务写Hive可以在写之前用coalesce或repartition控制最终文件数并按动态分区字段适当控制并行度如果是一个持续写入的实时任务需要定时做小文件合并任务。这样答下来远比说“我设置合并参数”要有内容。4.2 卡壳问题二实时指标和离线指标对不上怎么排查这个问题我现场确实有点卡住了。面试官问“广告业务里通常离线算一遍消耗和转化实时算一遍给投放策略看两边数字对不上你觉得可能是什么原因”我之前没有认真想过对账这个问题。复盘后我觉得这个问题可以从时间口径、计算逻辑、数据质量三个维度拆。做离线统计的时候我们通常切分自然日取的是当天0点到24点的数据实时统计经常用最近5分钟、最近1小时这种滚动窗口或者使用事件时间而离线用处理时间。如果两边口径不一致算出来的指标对不上非常正常。其次离线任务可以做到精确去重和精确计数实时任务为了延迟往往会用近似算法比如HyperLogLog算UV结果有误差。最后数据本身的质量问题比如日志重复上报、还没完成的清洗逻辑、实时任务重启导致重复消费等都会让数字不一样。所以回答这个问题的思路应该是先校准时间口径和去重逻辑再核对计算引擎的语义最后再用数据质量监控来兜底。如果面试官继续追问“你打算怎么监控”可以说在离线结果和实时结果各算出一个中间指标每天定时对账差值超过阈值就报警这样才能尽早发现问题。4.3 卡壳问题三Spark任务跑一半挂掉怎么定位这个问题是在反问之前面试官突然插进来问的我回答得比较笼统只说了“看日志和看Spark UI”。但复盘后我觉得这个问题其实有非常标准的排查路径面试官想听的是你有没有真正处理过线上任务。完整思路应该是第一步用Spark History Server看整个Application的Executor、Task状态找出失败的stage。第二步看失败task的报错类型是OOM还是数据倾斜是找不到文件还是连接超时。第三步具体看数据分布比如repartition后有没有出现某个task处理的数据量远超其他task如果是那就是典型的数据倾斜。第四步针对原因做处理OOM调大executor内存并检查是否存在内存缓存过大的逻辑数据倾斜可以使用加盐双重聚合或广播join找不到文件则检查分区字段的时区偏移和数据产出延迟。最后别忘了提一句如果是调度平台上的任务重跑之前要确认幂等性和下游依赖状态防止重复计算。4.4 面试官想从卡壳里看到什么这几道卡壳题让我想明白了一个道理初面问的很多问题并不是真的要你用标准答案来砸他而是想看到你把一个陌生问题拆解开的能力。即使回答不全只要有清晰的思维链条面试官就会给你继续往下说的机会。我在回答“实时和离线对不上”的时候虽然当时没有给出完美的三层次答案但我先说的是“我会先看两边是不是用同一个维度和时间范围去算”这句话让面试官知道我不是直接从代码层开始瞎猜而是有一个合理切入点。后来面试官才愿意继续引导我。所以如果你在面试中被问题卡住别慌先说出一个你觉得最可能的原因再一步步展开肯定比你憋着不说强得多。5. 备考自查表与一个月冲刺建议5.1 知识点自查表哪些必须做到脱口而出我根据自己的面试经历整理了一张自查表分享给你。如果你能对每个问题都给出一个相对完整的回答初面的概率就会高很多。知识块必须能脱口而出的点HDFS文件读写流程、副本机制、NameNode宕机会造成什么MapReduceMap到Reduce的过程、shuffle阶段发生了什么SparkRDD依赖关系、宽窄依赖、shuffle落盘时机、数据倾斜处理Hive分区表和分桶表区别、数据倾斜场景和解决手段、小文件合并Kafka分区策略、消费者组、offset提交、消息不重不丢方案Flink窗口类型、checkpoint机制、状态存储、exactly-once语义Java基础HashMap原理、线程池参数、synchronized与ReentrantLockSQL窗口函数、连续登录、留存率、分组去重这张表不需要背答案关键是能对着每一条用自己的话讲三分钟。讲不出来就说明还不够回去继续查。5.2 四周冲刺时间怎么安排如果你打算投类似岗位我给一个比较普适的时间安排适合业余时间准备的情况。前两周重点搞定项目描述和组件主干。把简历上每个项目按照数据量、组件、职责、结果四要素重写确保每一个技术名词都能被追问。组件复习先啃HDFS和MapReduce再转Spark这两块必须形成完整认知链。第三周复习Hive和SQL把窗口函数练到条件是“每天都要写几段SQL”。同时开始做算法热手。第四周集中看Flink和Kafka这两个组件如果项目里没用过至少要能讲清楚基础原理和典型应用。最后几天做模拟面试可以找同学互相问问题重点锻炼“把一件事讲清楚”的能力。5.3 过来人的几个提醒最后说几个我在准备和面试过程中真实踩过的坑你也可以提前避开。第一别在简历里堆砌一堆“熟悉”但经不起追问的词。你写“熟悉Flink”面试官就默认你可以回答checkpoint执行过程如果答不上来反而不如不写。第二自我介绍一定要精心排练这是唯一一个你可以完全掌控的环节把话题引到你最有把握的项目上。第三SQL题宁可多写两步也不要省略关键细节比如去重、为空判断这些细节在面试官眼里比算法题更显project经验。第四面试结束后立刻把问题整理成文档不然后面复盘全靠记忆很容易丢掉细节。这次初面整体下来我的体感是字节初面面试官非常务实不玩虚的他们对大数据的考察更多落在“你真正动手解决问题”上。希望这篇复盘能帮到正在准备广告大数据研发实习面试的同学。如果觉得自己在某个知识块上还有缺口就按上面的自查表一项一项补最怕的不是不会而是明明不会却不知道从哪里开始查。