2018年秋季那阵子字节跳动的校招在大数据方向连续放出了好几批笔试我是后来参加第三批的那波人。说实话前两批的题目我已经在牛客和应届生论坛上蹲了很久把能搜到的面经都翻了个遍结果拿到第三批试卷的时候还是愣了一下——题目风格跟前两批明显不一样更细、更偏实战而且好几道题都在同一个知识点上往下钻钻到让你没法靠背题蒙混过关。这篇文章不打算给你复述原题毕竟严格来说笔试题目本身是有保密要求的。我想做的是把第三批这套题背后考察的知识体系、我当时是怎么思考的、以及哪些地方最容易丢分完整拆开讲一遍。不管你是准备大数据方向的校招还是已经在做离线数仓、实时计算、数据平台相关的工作这篇文章里提到的这些考察点和排查思路应该都能用得上。1. 2018年这批题到底在考什么样的人第三批题目给我的第一感受是字节跳动那时候并不指望招进来的人马上就能干活但非常在意你有没有完整地接触过一套数据链路。什么叫“完整接触过”就是你至少应该知道数据从业务端产生之后经过采集、传输、存储、计算、调度、应用最终落到报表或算法特征里这个过程中每个环节大概会遇到什么问题。那批笔试里有一个很明显的信号题目没有堆砌特别冷门的知识点反而是围绕主流的Hadoop生态组件来出题HDFS、MapReduce、Spark、Hive、Kafka基本都覆盖到了。但考察方式不是让你背概念而是给一个场景让你判断用什么组件、为什么用、可能出现什么问题。比如给你一个实时性要求不是特别高的日志分析场景问你选Spark Streaming还是Storm然后让你说明理由。这种题没有标准答案但能看出你有没有真正做过选型而不是只会在博客上复制别人的技术对比。另外我注意到一个细节第三批题目里对“数据质量”和“数据一致性”的考察比重比前两批高。这其实也符合字节跳动当时业务快速扩张的现实——数据量大、口径多、业务迭代快一旦数据算错影响的是产品决策和运营策略所以他们对候选人的数据敏感度要求很高。有一道题大概是问离线任务每天凌晨跑某一天发现结果数据比前一天少了10%你会怎么排查。这种题没有标准答案关键看你能不能说出一个完整的排查链路先看调度是否正常再看上游数据是否完整然后看是否有数据倾斜最后看代码逻辑是否被改过。第三批还有一个特点就是时间很紧。整张卷子题量不算特别大但每道题都要写不少字尤其是场景设计题和排查题需要你组织语言、分步骤描述。我印象里身边有同学在SQL题上抠了太久导致后面的大题时间不够最后草草写了两行就交了。所以后面我会专门讲一下时间分配这件事这虽然不是知识点但在笔试里往往比知识点更致命。1.1 当时大数据校招的竞争格局2018年是大数据岗位校招开始变得拥挤的一年。前几年大数据还算是比较新的方向会写个Hive SQL、能跑通MapReduce就能拿到不错的offer。但到了2018年科班出身的人已经批量涌进来加上不少做Java后端的人也在往大数据方向转竞争一下子就激烈了。在这种情况下第三批笔试的定位就很微妙。第一批是抢跑用来锁定最优秀的那批人题目相对常规第二批开始加大难度加入了一些实时计算和架构设计的内容到第三批基本就是“从剩下的人里挑潜力股”了所以题目会更看重思维方式和基础功底而不是纯粹的知识面宽度。这也解释了为什么第三批会出现不少“看似入门、实则考察深度”的题。比如HDFS写流程这种题表面上是让你讲讲Client、NameNode、DataNode之间怎么交互但如果你只是背过“客户端先请求NameNode然后创建文件再写入DataNode”这种话是拿不到高分的。真正能拿分的是你说得出写副本时Pipeline是怎么建立的、宕机时副本数不足会怎么处理、什么时候会触发租约过期、为什么读数据的时候不需要走NameNode。这些细节只有真正部署过集群、处理过实际故障的人才会去关注。1.2 试卷结构和我的整体感受从题型分布来看第三批的卷子大致可以分成四块基础知识选择填空题、SQL和算法题、场景设计题、排查与优化题。选择填空覆盖了Java基础、网络协议、操作系统、数据结构这部分跟普通后端岗的笔试差别不大但后面几块就是明显的“大数据”味道了。SQL题大概有两到三道要求手写Hive SQL或者Spark SQL考察点是连续登录、留存率、TopN这一类经典问题。场景设计题一般会给你一个偏字节跳动风格的业务场景比如短视频的播放日志分析、推荐系统的特征数据准备让你设计数据链路。排查优化题则更直接基本上就是给你一个“任务跑得很慢”或“数据对不上”的困境让你描述排查思路。我的整体感受是这套题更像是一份“技术体检报告”考察的不是你背了多少个框架而是你脑子里有没有一套完整的、自洽的大数据知识体系。你不需要每个组件都用过但至少要知道它们解决什么问题、边界在哪里、彼此之间怎么配合。2. SQL题考点永远是那几类但出题角度会有变化先说SQL题因为这是大部分候选人花时间最多、也最容易拉开差距的部分。2018年那批SQL题核心考点仍然是连续登录、留存率、会话划分、TopN、行列转换这些经典场景。但第三批有个变化是它会把考点藏在更复杂的业务语义里比如“算出每个用户在某个时间窗口内的活跃天数并统计活跃天数大于等于3天的用户占比”这就不是单纯查一张表了而是要拆分步骤。我建议遇到这类题先别急着写代码花一两分钟把逻辑拆清楚。第一步拿到原始数据后先做过滤和去重确定“一次活跃”的粒度是什么——是用户每天只记一次还是每次播放都记一次。如果原始表是用户行为流水那一个用户一天可能有多条记录务必先去重。第二步确定时间窗口的边界比如“最近30天”是按自然日算还是按截至今天的滚动窗口算题目里通常会明确但如果没明确考试时可以写清楚自己的假设这反而能体现你的思考严谨性。第三步才是写SQL而且写完一定要检查边界条件。2.1 连续登录问题的三种写法连续登录问题在2018年的大数据笔试里几乎是必考的第三批也不例外。题目大概是给你一张用户登录日志表包含用户ID和登录日期让你找出连续登录超过N天的用户。这类题的解法其实非常固定核心思想就是“日期减去序号或排名得到一个分组标识”然后按这个分组标识聚合统计天数。我比较推荐的做法是用ROW_NUMBER()。逻辑是先按用户分组、按日期排序然后给每行分配一个从1开始的序号接着用登录日期减去这个序号得到一个日期偏移量最后按用户和这个偏移量分组统计组内记录数天数大于等于N的就是答案。SELECT user_id, group_date, COUNT(*) AS continuous_days FROM ( SELECT user_id, login_date, DATE_SUB(login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)) AS group_date FROM user_login_log ) t GROUP BY user_id, group_date HAVING COUNT(*) N如果你当时只写出了这种答案能拿基础分但拿不到高分。面试官更希望看到你补充说明几个隐含条件。比如用户一天内多次登录算不算多条记录如果算先做去重如果跨月连续登录DATE_SUB是否还能正确计算这个写法可以处理跨月因为DATE_SUB是按实际日期运算的再比如如果登录日期列是STRING类型且格式不统一怎么保证排序正确这就涉及数据清洗了。我当时在博客上看过另一个解法用LAG()窗口函数去判断当前行与上一行日期是否相差1天然后做累加标记。这种写法的好处是不用依赖ROW_NUMBER对于“判断连续”的语义更直观但写起来会复杂一些而且逻辑容易出错。笔试中我建议用最稳妥的“日期减序号”写法不容易翻车。2.2 留存率计算的注意事项留存率在2018年校招SQL题里出现频率也很高。第三批那道留存题我记得是给了一张用户活跃表让你算新用户次日留存率。这个题看着简单但很多人会栽在“分母”和“分子”的口径上。正确的逻辑是先定义一个时间基点比如某个日期D找出当天新增的用户集合然后看这批用户在D1天有多少人活跃D1天的活跃人数除以D天的新增人数就是次日留存率。也就是说分母是“某日新增且当天有活跃记录的用户”分子是“这批人在次日仍然有活跃记录的用户”这个“次日”一定要在新增用户集合内做关联而不是去全表里找活跃用户。一个常见的错法是直接拿“全量活跃用户”做分母这样算出来的根本不是留存率。另一个常见错法是没用DISTINCT去重导致一个用户当天多次活跃产生了重复计数。这些坑都很基础但在笔试那种紧张环境下很多人就是会踩。2.3 TopN问题窗口函数的正确打开方式TopN也是大数据笔试的常客而且是唯一一个我不太建议用纯SQL老写法去解的题。传统用GROUP BY加ORDER BY LIMIT的写法在很多场景下拿不到正确结果尤其是要求“每个分组内的TopN”时必须用窗口函数的ROW_NUMBER()或RANK()。比如题目问“统计每个类目下播放量排名前10的视频”正确写法是先按类目分组、按播放量排序给每组内分配排名然后过滤排名小于等于10的记录。写的时候注意用ROW_NUMBER()还是DENSE_RANK()取决于题目是否要求并列名次占用名额。大多数情况下ROW_NUMBER()就够用因为它的语义是“物理顺序”每个视频只有一个排名。我当时还专门练习过一种稍复杂的TopN变体要求取“每个用户播放时间最长的前两条视频且这两条视频的播放来源不能相同”。这种题考察的是在窗口函数之后再做一次条件过滤难度不大但很容易漏掉“来源不能相同”这个条件少写一个过滤就会出大问题。做这类题我的建议是先按用户分组排序加行号然后在这个结果集上再按来源去重或过滤必要时可以拆成多个子查询。3. 计算引擎题MapReduce与Spark考察的重点不是API而是原理第三批笔试里有一类题目让我印象很深它不直接问“Spark的transformation和action有什么区别”这种基础题而是给一个具体任务问你怎么用Spark实现然后再追问一句“如果数据量扩大100倍你会怎么优化”。这种题考察的其实是你对Spark运行原理尤其是Shuffle、分区、内存管理的理解。在2018年那个时间点Spark已经是大数据离线计算的事实标准MapReduce虽然还在考纲里但更多是作为一种“底层原理”来考。字节跳动那批题目里也延续了这个思路MapReduce的基础题会出但占比不大Spark的原理和调优才是重点。3.1 MapReduce题从流程记忆到故障理解MapReduce相关的题目如果你只是背过“InputFormat - Map - Shuffle - Reduce - OutputFormat”这个流程最多拿一半分。第三批的题目更倾向于让你描述某个环节的具体行为比如Map端输出的键值对是怎么分区、排序和合并的当Partitioner默认用HashPartitioner时如果Reduce数量变了对结果有什么影响这里有一个我觉得特别能体现水平的考点Map端和Reduce端Shuffle的区别。Map端Shuffle是先把结果写到内存缓冲区默认是100MB当缓冲区达到阈值默认80%时开始溢写溢写前会做分区排序和合并Reduce端Shuffle则是从多个Map任务拉取属于自己的分片边拉取边合并排序全部拉完后才作为Reduce函数的输入。很多候选人能画出这条链路但问“为什么缓冲区要设置阈值、为什么80%而不是100%”就答不上来了。其实答案很简单防止数据写满内存导致阻塞留出余量给正在进行的序列化和排序操作。这种“临界值设计逻辑”恰恰是考官想看到的。3.2 Spark题数据倾斜的排查思路是核心Spark相关的题目里数据倾斜几乎一定会出现。第三批那道题大概是给你一个Join操作说某个Task运行特别慢其他Task都跑完了就它一直卡着让你分析原因并给出解决办法。数据倾斜的本质是Key分布不均导致大量数据被分到同一个分区。最常见的原因有两种一是业务本身的Key就有热点比如某个大V的ID在流量表里出现的次数远超其他人二是Join操作中多个大表关联时某些Key在两张表里都特别多导致笛卡尔积爆炸。排查思路应该分几步走。第一步先确认是不是数据倾斜看Spark UI里各个Task的Shuffle Read量如果某一个Task的读入量比中位数大了一个数量级以上基本可以判定。第二步定位倾斜的Key可以通过采样或者跑一个简单的count group by把TopN的Key打出来。第三步根据Key的类型选择优化手段。常见的优化手段有这么几种。如果只是单Key倾斜可以把大Key加上随机前缀然后拆成两阶段聚合即先加随机数打散聚合一次再去掉前缀聚合一次如果是Join倾斜可以先把大表里倾斜的Key过滤出来单独做广播或单独处理剩余数据走正常Join如果倾斜不严重也可以直接调整并行度或开启AQE如果Spark版本支持。我比较推崇的应答结构是先说明“为什么会有这个问题”再给“定位方法”最后给“解决方案”这样显得你在真实场景里处理过问题而不是只背了几条优化建议。3.3 为什么第三批对“Spark Streaming vs Flink”的考察出现了第三批有一道题让我意识到字节跳动当时已经在认真考虑实时计算的选型了。题目大概问一个需要秒级延迟的数据处理场景你会选Spark Streaming还是Flink为什么在2018年Spark Streaming还处于微批处理模式Micro-batch它天然是把一段时间的批次数据统一处理所以延迟下限一般是几百毫秒到几秒而Flink是真正的流式计算引擎逐条处理数据延迟可以做到毫秒级。如果你的场景真的需要秒级甚至毫秒级响应Flink是更合适的选择。但Spark Streaming也有它的优势生态统一离线、实时都能用Spark、部署维护简单如果一个团队已经维护了一套Spark离线体系引入Spark Streaming的边际成本更低。我当时在笔试里写的是选择哪个引擎取决于你对“实时性”的定义如果业务容忍几秒延迟Spark Streaming完全够用而且更稳定如果业务需要严格的事件时间处理、精确一次语义那Flink更合适。这种回答思路的好处是不直接站队而是展示你对技术选型的判断力这在场景题里非常重要。4. 数据仓库与建模题分层设计的细节最能拉开差距第三批笔试里让我比较意外的是数据仓库设计类的题目占了不小的比例。很多候选人把精力都放在SQL和Spark原理上对数仓建模相对轻视觉得“数仓不就是建几张表嘛”但字节跳动的题目偏偏要在这方面做文章。有一道题我现在还记得大概给你一个内容平台的业务包括内容发布、用户观看、广告曝光等行为数据让你设计一套数仓分层结构并说明每一层的职责。这道题看着很开放但真正能拿高分的答案一定是能清晰地说出ODS、DWD、DWS、ADS每一层做了什么、为什么需要这一层、层与层之间的数据流转如何保证。4.1 数仓分层的价值不止是“清晰”数仓为什么要分层网上最常见的回答是“为了清晰、为了复用”这个回答太泛了。从工程角度说分层的核心价值有三个方面第一隔离原始数据与业务数据ODS层保留最原始、不可变的数据避免业务逻辑变更导致无法回溯原始事实第二复用公共逻辑DWD层做明细清洗和标准化DWS层做主题汇总这样多张报表可以共享同一份预处理后的数据不用重复开发第三控制数据流向规范“数据只能从下层流向上层”出问题时可以快速定位是哪一层出了问题。第三批题目里还问到了“ODS层要不要做清洗”这种细节点。我的观点是ODS层原则上只做增量/全量同步和最小限度的格式规范化比如统一日期格式、编码格式不该做业务逻辑清洗因为ODS层的定位是还原原始数据一旦引入过多清洗逻辑数据就不再“原始”了后续如果发现清洗规则有误很难追溯。DWD层才是做质量过滤、标准化、维度退化的地方。4.2 维度建模星型模型与雪花模型的选择依据维度建模的题目在那批笔试里也出现过考的是星型模型和雪花模型的区别以及选型依据。星型模型是维度表直接连接事实表查询时需要Join的层次少性能好雪花模型是维度表进一步规范化拆分消除冗余但查询时要多Join几层性能相对差。如果你只是答到这个层面只能算中规中矩。那个问题真正的加分点是在大数据场景下你为什么倾向于选择星型模型因为大数据环境重吞吐、延迟敏感度相对较低但数据量极大减少Join可以显著降低计算成本而雪花模型节省的那点存储在分布式存储面前根本不值一提。所以在字节跳动这种数据量级的场景星型模型几乎是默认选择。此外星型模型的维度表更宽、更扁平对于BI工具和即席查询也更友好。4.3 数据质量题的答题套路从被动救火到主动预防第三批有一道题让我印象特别深因为它直接问“如果业务方早上发现昨天的核心报表数据为0你怎么快速定位”。这道题考察的不只是技术还有工程协作能力和判断优先级。我当时给的思路分两条线并行。第一条线是看上游昨天任务的调度是否正常上游源表是否有数据数据采集任务是否在某个环节断了先确认数据是不是根本没进来。第二条线是看任务本身跑数任务是否成功有没有重试机制SQL逻辑是否在上线新版本时被改动有没有可能是分区字段配错导致读到了空分区这道题最有意思的部分是“怎么快速”。我当时的回答是不要按顺序挨个排查而是先看最可疑的环节。以我做过数仓的经验90%的情况是因为调度依赖没有配好、上游任务失败导致下游跑了个“假成功”。所以要第一时间打开调度平台看任务状态的上游依赖如果没有问题再去捞昨天的源表数据量确认有没有数据入口再往后才是SQL逻辑的排查。这个先后顺序本身就是经验。5. 底层系统基础HDFS与Kafka考察的是你碰过多少真实问题第三批笔试里关于HDFS和Kafka的题目不算少但都不是让你写配置文件或命令行而是考察机制理解。对于没有真正搭过集群的候选人来说这部分是最容易失分的因为光靠背八股文很难应对“如果某台DataNode宕机了正在写的文件会怎样”这种问题。5.1 HDFS写流程的隐藏考点HDFS写流程是经典面试题客户端先调用DistributedFileSystem.create()NameNode检查权限和路径后创建文件元数据返回输出流客户端按块写入第一个DataNode收到后建立Pipeline依次复制给第二个、第三个DataNode写完一个块后客户端继续写下一个块全部写完关闭流。这个流程大部分人都能说上来但第三批的追问方式不太一样。比如它问如果Pipeline中某一个DataNode写入失败会发生什么正确理解是DataNode会关闭管道把已写入的块信息上报NameNodeNameNode标记该副本异常并安排其他DataNode补充副本。客户端也会收到异常响应然后从队列里移除故障节点继续向剩余节点写入副本。整个过程对外表现为“写入可能短暂卡顿但不会失败”除非所有可用节点都挂了。这种细节只有在实际运维过集群、看到过DataNode单点故障时日志的人才能讲得清楚。还有一个隐藏考点是“副本放置策略”。默认策略是第一个副本放在客户端所在节点如果客户端不在集群内则随机选一个节点第二个副本放在不同机架的节点第三个副本放在与第二个相同机架的另一个节点。这个策略的考量是第一副本就近写入加快速度第二副本跨机架保证容灾第三副本跟第二副本同机架是为了减少跨机架的流量消耗。这个知识点不算难但如果在笔试里写出来会显得你对分布式系统的设计约束有真实理解。5.2 Kafka的offset管理和语义保障Kafka在大数据链路里几乎是标配了第三批笔试里也出现了关于它的题目。考得比较多的是Consumer的offset管理方式老版本默认存储在ZooKeeper中新版本默认存储在一个内部Topic__consumer_offsets中。问你为什么这样改能答出“ZooKeeper不适合高并发的offset读写且会引入额外的网络开销”才能拿到分。更深一层的是消息语义的问题At Most Once、At Least Once、Exactly Once有什么区别Kafka怎么实现Exactly Once。大部分人都知道At Least Once靠的是“生产端重试消费端手动提交offset”但Exactly Once要答到“幂等Producer 事务API”这层才能体现你真的研究过。在笔试里遇到这种题一定要从“为什么需要”的角度去答因为单纯背概念太容易被识破了。5.3 系统设计题一个完整的日志采集链路怎么设计场景设计题通常是笔试的大头第三批也不例外。其中一道题大概是让你设计一个日PV过亿的日志采集分析系统要求吞吐量大、稳定性高、允许分钟级延迟。这种题没有标准答案但有标准思路答得对不对全看你的链路是否完整、选型是否合理。我的回答思路是日志先通过Agent比如Filebeat采集到KafkaKafka作为削峰填谷的缓冲层然后由Flink或Spark Streaming消费经过清洗和聚合后写入HDFS或ClickHouse供下游分析查询使用。之所以用Kafka做缓冲是因为日志的写入速度是突刺式的半夜可能没人写、白天可能瞬间暴增如果直接写入存储很容易被流量峰值打挂Kafka作为缓冲层可以把“突刺流量”变成“均匀流量”。接下来一定要讲“怎么保证不丢数据”。这里可以提到三个层面Agent端采用“读后删除”的提交策略只有确认发到Kafka后才更新文件读取偏移量Kafka端设置副本因子大于1并让Producer开启acksall消费端采用手动提交offset处理完一批数据后再提交禁止自动提交。如果你能把这三个层面完整说出来评分一定不低。6. 算法题与机器学习基础大数据岗的必备底料第三批笔试里还有一部分算法题和机器学习基础题。这部分题量不大但很关键因为如果你算法部分挂掉即使前面的大数据知识答得再好也基本没戏。字节跳动对候选人的编码能力要求一直很高这在2018年就已经很明显了。我当时拿到的卷子里有手写代码的部分难度大概在LeetCode Medium到Hard之间主要涉及数组、链表、二叉树和动态规划。虽然没有特别偏难怪的题但要求你在有限时间内写出一份完整、能跑、边界条件都处理好的代码对非科班同学来说压力不小。6.1 手写代码边界条件和复杂度分析同样重要手写代码部分最容易丢分的不是算法思路不对而是代码风格和边界条件处理不到位。比如写二分查找时很多人忘了考虑数组为空或目标值不在数组内的情况写链表反转时没有处理空链表和单节点链表写动态规划时初始化数组大小搞错一位导致越界。我的经验是笔试写代码时必须把边界条件写在最前面哪怕你觉得题目给定数据一定满足某个条件也要写防御性判断。面试官看代码不会只看正确性还会看你思考问题是否全面。一个能把数组为空、长度为1、目标值在最前/最后这些边界情况都考虑到的候选人在实际工作中写数据处理逻辑时也不容易出bug。6.2 机器学习基础特征工程比调参更重要机器学习基础题在第三批也有出现但考察的不是深度学习那些前沿内容而是LR、GBDT、特征工程、评估指标这些基础。有一道题问“特征工程中如何处理缺失值”看起来很简单但如果只回答“填充均值/中位数”得分一定不高。完整的回答应该包括如何处理缺失值取决于缺失机制和业务含义。如果缺失率很低可以直接删除如果缺失有业务含义比如“用户没有填写”本身就是一个信号需要单独编码如果特征是连续值、缺失率中等可以用均值/中位数/众数填充也可以考虑用模型预测缺失值如果特征是分类值需要新增一个“未知”类别。此外填充时要特别注意训练集和测试集使用相同的填充值避免数据泄露。这种多层次回答才能体现你对机器学习流程的综合理解。6.3 算法岗与开发岗的题目差异我身边同时期投字节跳动的同学里有人面的是大数据开发岗有人面的是数据分析岗还有人面的是算法岗。这三个方向在第三批笔试中的侧重点完全不同。开发岗更看重Hadoop、Spark、Kafka这些工具的落地能力和代码能力数据分析岗更看重SQL、统计检验、AB实验、业务指标口径算法岗则几乎全是机器学习、深度学习和数据结构题。如果你投的是大数据开发岗我建议还是把重心放在“数据处理链路”和“分布式计算原理”上算法题保持到LeetCode Medium水平就够用没必要为了几道Hard题浪费大量刷题时间。反过来如果投的是算法岗那Hadoop生态的细节可以适当放松但模型原理和手推公式必须熟练。7. 笔试中的实战策略时间分配、答题顺序与易错点很多人把笔试复习的重心全放在知识储备上忽略了应试策略结果就是会的题没时间写、不会的题浪费了大量时间。第三批笔试时间有限我的亲身体会特别深如果一张卷子有8道大题前两道比较基础的SQL题花太多时间推敲细节后面两道需要大段文字描述的场景设计题就只能匆匆收尾这非常遗憾因为场景设计题往往是分值大户。所以我后来总结了一套笔试时间分配和答题顺序的方法在这里分享给大家。7.1 拿到卷子先做“三分钟扫描”开考后先不要急着动笔用三分钟时间把所有题目浏览一遍。这个动作有两个作用第一对全局难度有数知道哪些题是“送分区”、哪些题是“拉分区”第二识别出哪些题考查的知识点是有重叠的比如一道HDFS的题和一道Kafka的题可能都涉及到数据一致性这时候你应该把最熟悉的那个先做建立信心。三分钟扫描之后我会做一个简单的优先级排序先做自己有把握的题尤其是那种“只需要写SQL或代码片段”的题因为这类题得分稳定且耗时可控再做需要文字分析的场景设计题和排查题因为这类题虽然耗时但只要你思路清晰、步骤完整即使结论不完美也能拿大部分分最后做完全没有头绪的题这类题先用常识判断写一个方向不要留白因为笔试阅卷时踩点给分的可能性很高。7.2 场景设计题的“三段式”回答结构笔试里的场景设计题或排查题最忌讳的是想到什么写什么逻辑混乱。我给这种题总结了一个“三段式”回答结构这几年凡是按这个结构写的基本都能拿到不错的分数。第一段明确需求和约束。先复述或转述题目场景指出核心需求是哪几个比如“需要分钟级延迟”“数据量日增过亿”“需要保证精确一次语义”。这不是废话而是告诉阅卷人你读懂了题也说明你后续的设计是围绕这些约束展开的。第二段给出主链路设计。画一个大致的流程图文字描述即可说明数据从采集、传输、计算到存储的完整路径。这个环节要给出选型并简要说明为什么选择某个组件比如“选Kafka做缓冲是因为峰值削峰、离线/实时双链路共用一份数据”等。第三段讲关键风险和兜底方案。比如“数据重复怎么处理”“任务失败怎么重试”“延迟超标怎么监控告警”。这个环节是拉开分数差距的关键因为大部分候选人只会描述正常流程不会主动思考异常情况。如果你能主动补充故障场景和兜底方案阅卷人会觉得你有真实工程经验。7.3 容易丢分的三类“非技术”错误除了知识储备和解题思路笔试里还有三类非技术错误特别容易让人丢分我放在一起说。第一类是审题不细。比如题目要求“用Spark SQL实现”你写了Hive SQL的语法题目要求“计算次日留存率”你算成了当日留存率题目要求“至少给出两种方案”你只写了一种。这类错误不是因为不会而是因为太紧张、读题太快。我的办法是每道题动笔前先圈出题目里的关键词——“至少”“只能”“任意”“不超过”这些限定词再开始作答。第二类是答案没有结构。很多人在写场景题时喜欢用一大段话从头写到尾没有分点、没有序号。但笔试阅卷和实际工作是两码事阅卷人精力有限一篇密密麻麻的长文很容易被漏看关键点。我的建议是只要是3个以上的要点就分点写每一点用加粗或小标题先亮出结论然后再展开一两句话解释。这样即使内容不够深入至少阅卷人一眼就知道你覆盖了哪些点。第三类是代码/伪代码的格式混乱。如果题目要求写代码或SQL一定要注意缩进和关键字大小写规范就算不要求完全可运行也要尽可能让代码拿到IDE里就能读懂。我见过不少同学在笔试里写SQL不写分号、字段名乱用别名、join条件写反这些都说明平时练习不够考前一定要多加训练。8. 基于第三批真题的准备路线与复盘心得写到这里我把第三批笔试考察的各个知识模块都拆开讲了一遍。最后这部分我想基于这套题的整体画像给准备大数据校招的朋友们一条实际可行的准备路线顺便复盘一下我自己的教训。8.1 知识优先级排序不是所有内容都要平均用力如果你现在才开始准备时间有限那一定要做好优先级排序。我的建议是SQL的熟练度排第一因为这是性价比最高的技能Hive SQL和Spark SQL都要能写连续登录、留存率、TopN、行列转换、窗口函数这些场景必须达到“闭着眼睛也能写”的程度。第二优先级是Hadoop生态的核心组件原理重点是HDFS读写流程、MapReduce/Spark的Shuffle机制、数据倾斜定位与优化、Kafka的消息语义这些是笔试的高频区。第三优先级才是机器学习和算法题如果是开发岗保持平刷力就行不需要在Hard题上死磕。8.2 动手练工程别只刷八股文2018年那批笔试给我的最大教训是八股文背得再熟没有实际动手经验很多题你还是答不透。我第一次做第三批的模拟题时觉得HDFS写流程、Spark数据倾斜这些知识点我都知道但真正让我描述“某台DataNode宕机后会发生什么”时我讲得磕磕绊绊因为我从来没有在真实集群上看到过这个故障。后来我花了一周时间在自己电脑上用Docker搭了一个一主两从的Hadoop集群往里灌了1000万条测试日志专门做各种“破坏性实验”kill掉一个DataNode、给某个ReduceTask制造数据倾斜、把Kafka的副本因子改成1看看数据丢失长什么样。做完这些实验之后笔试里凡是涉及“故障”“优化”“排查”的题我都有画面感了答起来自然比纯背教材要丰满得多。8.3 现在回头看哪些知识点直到今天依然是重点距离2018年已经过去好几年了大数据技术栈又发生了不少变化Flink的地位已经稳固Spark也迭代了很多版本数据湖、实时数仓成为新的热门方向。但回头看第三批那套题有几个知识点直到今天依然是面试和笔试中的“钉子户”SQL里的窗口函数、数据倾斜的处理方法、Kafka的消息一致性保障、数仓分层设计的思路。这些知识点之所以长盛不衰是因为它们不是某个框架的API用法而是大数据工程中的“底层逻辑”。不管你未来用Flink还是Spark用Iceberg还是Hudi只要你还在和数据打交道你就逃不开Shuffle、分区、一致性、分层建模这些问题。所以准备笔试时不要只盯着“今年考什么新技术”而是要把那些经典的、底层的知识理解透把底层逻辑弄明白了新技术学起来也会快很多。最后再说一点实际经验如果目标是字节跳动这种大厂的大数据岗位笔试只是第一关后面还有面试、终面每一轮都会比笔试更深入。笔试考的是你“知道多少”面试考的是你“做过什么”和“能不能讲清楚为什么这么做”。所以准备笔试的过程中一定要为每一道题多准备一个“为什么”的答案这样后续面试时才不会慌。能在笔试里答得既有细节又有体系你就已经比很多人走得更远了。