网易2020校招大数据开发工程师正式批这场笔试我到现在还留着一份印象题量不算变态但覆盖面很广选择题、编程题、问答题都有而且很多题目不是单纯考“会不会”而是考“有没有真做过”。网上能搜到不少零散的真题回忆但大多是“题目答案”式的流水账很少有人说清楚“为什么这样考”“每一类题到底该花多少精力”。这篇就把我了解到的考情和复习思路掰开揉碎讲一遍给准备投递这个岗位的同学做个参考。先说结论大数据开发工程师的校招笔试和普通后端开发笔试有一个明显的差异——它不追求你把算法题写到最优解而是想看你在“海量数据”的背景下能不能选对方案、写对代码、说清原理。同一个TopK问题后端岗可能考堆排大数据岗则更希望你想到“分治哈希小顶堆”的组合同一个SQL题后端岗可能只考join大数据岗会追问数据倾斜怎么办。这种“数据规模感”才是整场笔试的灵魂。1. 这场笔试要怎么准备先看网易想招什么人1.1 大数据开发工程师的日常决定了笔试的考点分布想要搞懂笔试为什么这么出题最直接的办法是倒推岗位工作内容。网易的大数据开发岗内部一般会分几条线离线数仓、实时计算、数据平台与工具开发。不同组侧重点不一样但校招生进去之后前半年大概率都要做同一件事——理解公司的数据链路。所谓数据链路从日志采集开始经过消息队列、离线或实时计算引擎最终落到数据仓库或OLAP引擎里再被报表、推荐、风控等业务方消费。这条链路上的每一环都会在笔试里出现HDFS、Kafka、Spark、Flink、Hive、HBase再加上调度、元数据管理、权限控制这些平台侧的东西。你把这些组件的工作机制弄明白了笔试的选择题和简答题基本就稳了。另外不要忽视SQL。在真实工作中离线数仓开发写Hive SQL或Spark SQL的频率可能比你写Java代码还高。所以笔试里SQL的占比往往不小而且难度不会停留在“会查”的层面窗口函数、多表关联优化、数据去重口径这些业务实战会碰到的东西都会被拿来出题。1.2 从岗位招聘信息里反推考察权重网易这类大厂的校招笔试通常是在统一的在线笔试系统里完成题型大致由三部分组成单选题/多选题、编程题、问答题/系统设计题。虽然每年的具体题目会变但考察权重相对稳定。根据我了解的情况可以粗略分成这样三档第一档SQL题和编程题单题分值高且容易拉开差距需要优先保证。第二档大数据组件原理题属于“背了就能拿分”的部分性价比极高。第三档计算机基础题网络、操作系统、Java/Python基础覆盖面广但单题分值低不需要花太多时间深挖。有个容易被忽视的点网易的笔试有时间限制普遍在2小时左右。很多人不是不会做而是时间分配出了问题——在选择题上纠结太久导致后面的SQL和编程题没时间写。这一点后面我会专门讲怎么做时间管理。2. 编程题不是纯考算法是在考你处理数据的直觉2.1 常考的算法类型以及它们和大数据之间的隐秘关联我在看各种真题回忆时发现编程题的风格和LeetCode“热题100”有明显区别。网易这类大厂的校招笔试不会出特别冷门的偏题怪题但会在题目背景里塞入大数据场景。以下是出现频率最高的几类海量数据TopK问题比如“给定100亿个整数找出最大的100个”。表面是算法题实际是想考你有没有处理超内存数据的基本功。常规思路是维护一个大小为K的小顶堆时间复杂度O(N log K)但如果把数据规模放大到单机内存装不下就需要先哈希分桶到多台机器每台机器算局部TopK再合并全局TopK。字符串处理与哈希比如URL去重、敏感词统计、日志中IP出现次数TopN。这类题在大数据场景里非常常见考察的是对哈希分桶、布隆过滤器的理解。布隆过滤器那个“可能存在、一定不存在”的特性很多同学背过但一放到“如何降低误判率”的场景里就懵了。动态规划这类题和“数据规模感”的关系不大但笔试里偶尔会出现一道中低难度的DP比如最长公共子序列、背包问题变形。它考察的是基本功不算是大数据岗的重点但不能完全放弃。链表和树的遍历这类题属于保底题出现频率不高但一旦出现基本就是送分题比如反转链表、二叉树层序遍历。不要在这种题上丢分。2.2 一道典型的“数据规模题”应该怎么想我拿一道我印象中很能代表网易风格的题目来模拟一下思路。题目大概是给定一个非常大的日志文件每一行是一个用户的访问记录需要统计每个用户的访问次数并按访问次数从高到低输出前100个用户。第一反应可能是“用HashMap统计”但注意到“非常大”这个前提HashMap在单机内存里可能根本装不下。正确的打开方式是分治将大文件按用户ID哈希取模分成若干个小文件使得每个小文件都能被单机或单进程处理每个小文件内部用HashMap统计得到局部结果最后把所有局部结果合并用大小为100的小顶堆选出Top100。这种分治思路其实就是MapReduce的雏形——map阶段做哈希分桶和局部统计reduce阶段做合并和全局排序。笔试的时候把这个思路写在注释里比单纯贴一段代码更能让阅卷人看出你的数据直觉。2.3 我见过的一些翻车现场有同学在准备这类题时容易陷入“只刷LeetCode”的误区。有人能把一道困难级别的树形DP写得滴水不漏但碰到“100亿个数找Top100”这种题居然在纠结用快排还是归并——完全没有“内存放不下”的意识。这就是典型的缺乏数据规模感。另一个常见的翻车点是不审题。题目明确说“数据可能重复需要去重统计”结果代码里没做去重白白丢分。大数据场景的编程题里去重、排序、TopN、窗口这几种需求是高频中的高频写代码之前先画一下数据流输入长什么样中间需要哪几步变换输出是什么格式。哪怕代码写得不够精炼只要逻辑清晰也能拿到大部分分数。3. SQL和数据仓库题是整场笔试的隐形大头3.1 为什么大数据岗笔试特别爱考SQL说SQL是隐形大头是因为它在卷面上的出现形式可能只是两道小题但对最终录用决策的影响比很多选择题大得多。原因很简单这是岗位日常工作最直接的映射。数仓开发要写大量的Hive SQL做ETL实时计算虽然主要写Flink代码但维也经常要写SQL。我在了解面试反馈时注意到一个共性网易的面试官很喜欢在简历里看到“熟练使用SQL”这句话之后追问一句“那你写一个连续登录3天的用户数”。如果笔试阶段SQL就翻车了面试这一轮大概率也躲不过去。所以SQL一定要早点练。3.2 一类高频题的完整推导过程以“用户连续登录N天”为例这是数仓面试题里的经典款笔试也常以变形出现。先给一个典型的表结构login_log(user_id, login_date)要求统计连续登录3天及以上的用户数。第一步用窗口函数row_number()按user_id分组、按login_date排序得到每个用户登录日期的排名SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM login_log第二步是精妙之处用login_date减去rn得到一个日期。如果用户连续登录这个日期是相同的如果中间断开了这个日期就会变化。这是因为连续登录时日期递增1、排名也递增1两者之差保持不变。WITH temp AS ( SELECT user_id, login_date, DATE_SUB(login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)) AS grp FROM login_log ) SELECT user_id FROM temp GROUP BY user_id, grp HAVING COUNT(*) 3然后按user_id和grp分组统计每组的天数大于等于3的就是连续登录3天及以上的用户。最后如果需要用户数再套一层COUNT(DISTINCT user_id)就行了。这道题的变体很多连续登录的最大天数、连续活跃N天以上的用户数、按照省份分组统计连续活跃用户等。核心逻辑都一样核心就是“日期减排名构造连续组”这个技巧建议一定要练熟。3.3 比SQL语法更重要的“口径”问题很多同学SQL语法很熟窗口函数用得飞起但一碰到“口径”题就露馅。举个例子题目问“统计每日活跃用户数DAU”表里有一份用户登录日志。常规写法是SELECT login_date, COUNT(DISTINCT user_id) FROM login_log GROUP BY login_date。但如果题目补一句“一个用户一天内多次登录只算一次”上面的写法仍然成立因为COUNT(DISTINCT user_id)天然去重。真正容易翻车的是这类一个用户一天内多次登录但登录方式有App、小程序、Web题目问你“各端的去重用户数”和“总体去重用户数”分别是多少。如果只按端分组然后COUNT(DISTINCT user_id)再对分组结果求和就会“重复计算”——因为同一个用户可能在App和小程序都登录了。正确答案是SQL先按user_id去重再统计端分布或者使用COUNT(DISTINCT CASE WHEN ... THEN user_id END)这类条件去重写法。这种“业务口径”的坑比语法更难防但恰恰是大数据开发日常一定会遇到的问题。笔试里如果出现这类题本质上是在看你能不能从业务角度理解数据而不只是会写代码。4. 大数据组件的简答与选择题考的是理解而不是背概念4.1 一张图理清组件的考察范围网易大数据开发的笔试组件相关题目非常稳定基本不会超出下面这个范围组件在数据链路中的位置笔试常考点HDFS分布式存储副本机制、机架感知、NameNode与DataNode职责MapReduce批处理计算Shuffle过程、分区与排序、Combiner的作用Hive数据仓库工具内部表与外部表区别、分区表与分桶表、SQL转MapReduce原理Spark批处理/内存计算RDD依赖关系、宽窄依赖、Stage划分、持久化策略Flink实时计算窗口类型、Exactly-Once语义、Checkpoint机制Kafka消息队列分区与消费组、消息不丢失与不重复、ISR机制HBaseNoSQL数据库RowKey设计原则、LSM树、Region分裂不要指望把每个组件的源码都读一遍笔试考的是“理解”而不是“源码细节”。比如Spark的宽窄依赖你知道“窄依赖是指父RDD每个分区只被子RDD的一个分区使用不需要shuffle宽依赖是指多个子分区依赖同一个父分区需要shuffle”就够了。至于ShuffleManager具体怎么实现面试可能考笔试一般不会。4.2 一个高频考点为什么宽依赖要单独拿出来考我印象中网易笔试的选择题里出现过不止一次“关于Spark宽窄依赖的说法正确的是”。这个知识点不冷门但错误率很高原因是很多同学把“宽依赖”和“发生shuffle”划等号这是不严谨的。宽依赖一定发生shuffle但shuffle不一定只发生在宽依赖里。比如repartition操作也会触发shuffle但它的依赖关系需要具体分析。更常见的误区是把“窄依赖”理解成“没有网络传输”其实窄依赖在分布式计算里也可能有数据传递只是不会跨Stage。笔试的选项往往就在这里做文章。理解宽窄依赖的实际意义在于Stage划分DAG调度器会把窄依赖尽量合并到同一个Stage因为不需要等待shuffle落盘每遇到一个宽依赖就切分出一个新的Stage。这个逻辑搞清楚了比单纯背“宽依赖shuffle”有用得多。4.3 结合热词“集群部署策略”说说这类实操向考点的出题角度在笔试里“集群部署策略”不会直接问“请部署一套Hadoop集群”但会以选择题或简答题的方式出现比如“在物理机上部署HDFS时NameNode和DataNode应该如何规划”考察点是NameNode是单点或依赖QJM实现高可用不要和DataNode混布在同一台机器避免资源竞争。“机架感知的作用是什么”考察点是备份节点选择策略让副本分布在不同机架提高容错性。“Spark on YARN时Driver应该部署在哪”考察点是cluster模式和client模式的区别。这些问题背后有一个共同逻辑大数据组件不是装好就行还要考虑高可用、资源隔离、容错。如果平时只是用云服务商提供的EMR或托管Kafka这些概念会被隐藏掉但笔试不管你有没有用过概念必须清楚。建议准备时不要只盯命令多问自己一个“为什么这样部署”把原理和部署策略连起来记效果要好得多。5. 系统设计题不是让你写架构是让你把链路说清楚5.1 从日志采集到实时报表一类典型的链路设计题网易笔试的问答题里系统设计考得不多一旦出现就很有区分度。我见到过一道印象深刻的题“请设计一个实时用户行为分析系统支持统计每小时的活跃用户数数据源是客户端上报的埋点日志。”很多同学一看到“设计系统”就开始画微服务架构图其实在大数据岗笔试里系统设计题的骨架是“数据链路”不是“微服务”。正确的答题框架应该是数据接入客户端埋点日志通过HTTP或SDK上报经过Nginx或Flume采集写入Kafka。这里要强调Kafka的作用是削峰填谷缓冲流量波动对下游的冲击。实时计算Flink消费Kafka中的日志数据按事件时间分配窗口做去重和聚合计算每小时的UV和PV。这里要提到watermark和allowedLateness的处理因为埋点日志乱序是常态。结果存储聚合结果写入KV存储或OLAP引擎比如HBase、ClickHouse、Doris。查询侧按小时维度读取结果展示到报表系统或大屏。容错与监控Kafka的offset管理和Flink的Checkpoint机制保证不丢不重消费延迟、checkpoint失败等指标要接入监控告警。按照这个顺序写哪怕细节不够深逻辑链路是清晰的就能拿到大部分分数。设计题评分看重的是“你有没有完整闭环的思维”而不是“你有没有用过Doris”。5.2 数据倾斜设计题里的隐形高分点大数据的系统设计题几乎必有一个隐藏考察点——数据倾斜。刚才那道实时行为分析的题如果某个热门 App 的某个接口访问量特别大同一个 key比如接口ID在Flink里会堆积到同一个子任务上导致其他子任务空闲、整体延迟走高。笔试里不一定要求你写出完整解决方案但如果在设计题的答案里主动提到“考虑数据倾斜”会给阅卷人留下“有实战经验”的印象。常用的几种解法需要能说清楚局部聚合全局聚合对于count、sum之类可结合的操作先给key加随机后缀拆散到多个子任务做局部聚合再去掉后缀做全局聚合。这个思路在MapReduce和Spark里都适用。单独处理热点key如果热点key只有那么几个可以单独提取出来走一条特殊链路不参与普通key的聚合。提高并行度对倾斜的算子单独设置并行度但要结合数据分布判断盲目调大并行度不一定有效。有些同学设计题里写得头头是道一追问“如果倾斜了怎么办”就卡壳。所以准备系统设计题的时候不要只准备“正常链路”一定要把异常情况数据倾斜、延迟、数据重复、服务宕机的应对方案也一起准备这才是笔试拉开差距的地方。5.3 设计类题目里阅卷人最反感的三件事第一只画架构图不写说明。有的同学能画出一个很完整的架构图但每个组件为什么这样选型、组件之间怎么衔接一字不写。这样的答案阅卷人只能靠猜。正确做法是图简单画重点是文字说明每个环节的输入、输出、存储选型理由。第二存储选型脱离场景。比如实时UV统计有人写“最终结果存入MySQL”。不是不行但如果你能说一句“HBASE适合高并发点查ClickHouse适合聚合分析这里按小时预聚合的结果量不大用HBase或MySQL都能满足”就能体现出你是有意识地做选型而不是随手写一个名字。第三指标口径模糊。设计“每小时活跃用户数”时没有说明“一个用户一小时多次访问只算一次”也没有说明“跨小时边界的事件怎么归属”。这些细节不写方案看起来完整实际不可落地。把口径问题逼自己先想清楚写进答案里就能超过一半的竞争者。6. 计算机基础和其他考点最后的拿分点和时间分配技巧6.1 Java/Python、网络、操作系统怎么分配精力网易大数据开发的笔试选择题里会混入一些计算机基础知识题范围包括但不限于Java集合类源码级别的特性比如HashMap的扩容机制、JVM内存分区、TCP三次握手、进程与线程的区别、Linux常用命令等。这部分内容的特点是多而杂单题分值低。我不建议花大块时间系统复习优先级如下最高优先级Java集合类特性和JVM内存模型。大数据组件的源码大量使用Java集合面试聊源码时也躲不开掌握HashMap的put流程、ConcurrentHashMap如何保证线程安全、JVM堆内存如何分区性价比极高。中等优先级Linux常用命令。比如查看端口占用netstat/ss、查看磁盘空间df/du、查看进程ps/top、日志检索grep/awk/sed。这些在笔试和实际工作中都会用到。低优先级TCP/IP、HTTP、操作系统调度、数据库索引原理。这部分如果时间紧张简单过一遍知识点即可不要深挖。6.2 常见的冷门考点字符编码、时区、日志格式有个让我印象很深的细节某年选择题里出现了一道关于Linux下日志文件中\r\n和\n处理的题目。很多人一眼懵但这在真实的大数据处理里太常见了——windows上生成的日志文件传到Linux里解析时不做处理数据就会带上\r导致去重和统计结果出错。类似这种“脏数据”问题在笔试选择题里偶尔会以换行符、编码UTF-8 vs GBK、时区UTC vs 本地时间的形式出现。这类题没有系统性的复习路径建议在准备SQL题的时候顺带记一下date_sub、from_unixtime、to_date这些常用函数的边界行为多看几道题就能补齐。6.3 我对“选择题纠结症”的建议在在线笔试里最浪费时间的不是不会做的题而是“好像会又拿不准”的题。一道选择题如果在心里纠结超过两分钟建议先随便选一个并标记进入下一题等所有题目做完后再回来看。很多在线笔试系统支持题号跳转一定要利用这个功能。另一个很实用的策略单选题拿不准时优先排除明显错误的选项。大厂笔试的出题质量整体不错但偶尔会混入一个“一看就是凑数”的选项先把它删掉正确率就能提高不少。多选题尽量选自己确定的少选比错选好——大部分笔试的多选题是“少选得部分分错选不得分”不确定的选项宁可不选。7. 备考路线不同时间预算的复习方案7.1 一个月系统准备版按周拆解复习任务如果距离笔试还有一个月左右我建议按下面的节奏来第一周补齐SQL和算法基础。SQL重点练窗口函数、多表join、去重、分组统计算法刷LeetCode的“高频面试题”分类重点练字符串、哈希表、链表、二叉树、动态规划前30道常见题。每天2道SQL题2道算法题是最低量。**第二周大数据组件原理一轮。**Hadoop生态HDFS、MapReduce、YARN、Spark、Flink、Kafka、HBase的原理过一遍重点记忆各组件的架构角色、核心机制、常见问题。每天至少梳理一个组件的思维导图式笔记。**第三周系统设计和场景题专项。**找一些常见的数仓/实时计算设计题练手比如实时UV统计、离线数仓分层设计、用户画像标签加工。每天写一道设计题重点关注链路完整性和异常处理。**第四周模拟笔试查漏补缺。**严格按照真实考试的时间限制完整做1-2套模拟卷。做完后不要只看对错要把错题对应的知识点回补到笔记里。最后三天以复习笔记为主不再做新题。7.2 一周快速冲刺版只做高性价比的事如果只剩下一个星期别慌按下面优先级来第一天到第二天SQL窗口函数专项。把row_number、rank、dense_rank、lag、lead、sum() over()这些常用函数各练几个例子。SQL是最容易短期提升拿分的点。第三天Spark和Flink核心概念。重点看宽窄依赖、Stage划分、窗口类型、Checkpoint、Watermark。这些概念在选择题里出现频率高背住就有分。第四天Kafka和HBase核心机制。消费组、ISR、消息不丢失RowKey设计、LSM树。记关键词不用读源码。第五天到第六天完整做一套模拟题严格计时。找找在时间压力下做题的感觉然后针对错题回补知识点。第七天翻笔记不学新知识。重点是那些容易记混的概念比如“Spark的transform和action的区别”“Hive内部表和外部表的区别”“Kafka的at-least-once和exactly-once”。7.3 一些实操中的体会写到最后前面讲的都是方法和框架最后说几个自己亲身感受过、也见过别人踩坑的点。模拟笔试真的很重要。在线笔试和本地做题是两个完全不同的场景——倒计时一直跳、长时间盯屏幕眼睛会酸、不会做的题会带来额外焦虑。我见过有同学平时刷题时正确率很高但第一次做模拟卷时直接懵了原因就是没适应这种高压环境。至少完整模拟一次比多做十道题更有用。复盘时不要只记答案要记“错因”。是因为知识点没掌握还是因为时间分配不合理还是因为题目审偏了三类错因对应的改进方向完全不同。如果发现是时间分配的问题下次做题就要强制自己“先做分高的、先做会做的”。最后“大数据开发工程师”这个岗位在笔试阶段考核的深度并不算深更看重的是知识面的宽度和逻辑的完整性。把SQL练到条件反射把Spark、Flink、Kafka、HBase的原理梳理清楚再把数据规模和数据类型这两件事内化成思考习惯笔试通过只是时间问题。希望这篇梳理能帮你少走一些弯路。 网易大数据开发工程师笔试考什么？考情分析与高效备考攻略
网易2020校招大数据开发工程师正式批这场笔试我到现在还留着一份印象题量不算变态但覆盖面很广选择题、编程题、问答题都有而且很多题目不是单纯考“会不会”而是考“有没有真做过”。网上能搜到不少零散的真题回忆但大多是“题目答案”式的流水账很少有人说清楚“为什么这样考”“每一类题到底该花多少精力”。这篇就把我了解到的考情和复习思路掰开揉碎讲一遍给准备投递这个岗位的同学做个参考。先说结论大数据开发工程师的校招笔试和普通后端开发笔试有一个明显的差异——它不追求你把算法题写到最优解而是想看你在“海量数据”的背景下能不能选对方案、写对代码、说清原理。同一个TopK问题后端岗可能考堆排大数据岗则更希望你想到“分治哈希小顶堆”的组合同一个SQL题后端岗可能只考join大数据岗会追问数据倾斜怎么办。这种“数据规模感”才是整场笔试的灵魂。1. 这场笔试要怎么准备先看网易想招什么人1.1 大数据开发工程师的日常决定了笔试的考点分布想要搞懂笔试为什么这么出题最直接的办法是倒推岗位工作内容。网易的大数据开发岗内部一般会分几条线离线数仓、实时计算、数据平台与工具开发。不同组侧重点不一样但校招生进去之后前半年大概率都要做同一件事——理解公司的数据链路。所谓数据链路从日志采集开始经过消息队列、离线或实时计算引擎最终落到数据仓库或OLAP引擎里再被报表、推荐、风控等业务方消费。这条链路上的每一环都会在笔试里出现HDFS、Kafka、Spark、Flink、Hive、HBase再加上调度、元数据管理、权限控制这些平台侧的东西。你把这些组件的工作机制弄明白了笔试的选择题和简答题基本就稳了。另外不要忽视SQL。在真实工作中离线数仓开发写Hive SQL或Spark SQL的频率可能比你写Java代码还高。所以笔试里SQL的占比往往不小而且难度不会停留在“会查”的层面窗口函数、多表关联优化、数据去重口径这些业务实战会碰到的东西都会被拿来出题。1.2 从岗位招聘信息里反推考察权重网易这类大厂的校招笔试通常是在统一的在线笔试系统里完成题型大致由三部分组成单选题/多选题、编程题、问答题/系统设计题。虽然每年的具体题目会变但考察权重相对稳定。根据我了解的情况可以粗略分成这样三档第一档SQL题和编程题单题分值高且容易拉开差距需要优先保证。第二档大数据组件原理题属于“背了就能拿分”的部分性价比极高。第三档计算机基础题网络、操作系统、Java/Python基础覆盖面广但单题分值低不需要花太多时间深挖。有个容易被忽视的点网易的笔试有时间限制普遍在2小时左右。很多人不是不会做而是时间分配出了问题——在选择题上纠结太久导致后面的SQL和编程题没时间写。这一点后面我会专门讲怎么做时间管理。2. 编程题不是纯考算法是在考你处理数据的直觉2.1 常考的算法类型以及它们和大数据之间的隐秘关联我在看各种真题回忆时发现编程题的风格和LeetCode“热题100”有明显区别。网易这类大厂的校招笔试不会出特别冷门的偏题怪题但会在题目背景里塞入大数据场景。以下是出现频率最高的几类海量数据TopK问题比如“给定100亿个整数找出最大的100个”。表面是算法题实际是想考你有没有处理超内存数据的基本功。常规思路是维护一个大小为K的小顶堆时间复杂度O(N log K)但如果把数据规模放大到单机内存装不下就需要先哈希分桶到多台机器每台机器算局部TopK再合并全局TopK。字符串处理与哈希比如URL去重、敏感词统计、日志中IP出现次数TopN。这类题在大数据场景里非常常见考察的是对哈希分桶、布隆过滤器的理解。布隆过滤器那个“可能存在、一定不存在”的特性很多同学背过但一放到“如何降低误判率”的场景里就懵了。动态规划这类题和“数据规模感”的关系不大但笔试里偶尔会出现一道中低难度的DP比如最长公共子序列、背包问题变形。它考察的是基本功不算是大数据岗的重点但不能完全放弃。链表和树的遍历这类题属于保底题出现频率不高但一旦出现基本就是送分题比如反转链表、二叉树层序遍历。不要在这种题上丢分。2.2 一道典型的“数据规模题”应该怎么想我拿一道我印象中很能代表网易风格的题目来模拟一下思路。题目大概是给定一个非常大的日志文件每一行是一个用户的访问记录需要统计每个用户的访问次数并按访问次数从高到低输出前100个用户。第一反应可能是“用HashMap统计”但注意到“非常大”这个前提HashMap在单机内存里可能根本装不下。正确的打开方式是分治将大文件按用户ID哈希取模分成若干个小文件使得每个小文件都能被单机或单进程处理每个小文件内部用HashMap统计得到局部结果最后把所有局部结果合并用大小为100的小顶堆选出Top100。这种分治思路其实就是MapReduce的雏形——map阶段做哈希分桶和局部统计reduce阶段做合并和全局排序。笔试的时候把这个思路写在注释里比单纯贴一段代码更能让阅卷人看出你的数据直觉。2.3 我见过的一些翻车现场有同学在准备这类题时容易陷入“只刷LeetCode”的误区。有人能把一道困难级别的树形DP写得滴水不漏但碰到“100亿个数找Top100”这种题居然在纠结用快排还是归并——完全没有“内存放不下”的意识。这就是典型的缺乏数据规模感。另一个常见的翻车点是不审题。题目明确说“数据可能重复需要去重统计”结果代码里没做去重白白丢分。大数据场景的编程题里去重、排序、TopN、窗口这几种需求是高频中的高频写代码之前先画一下数据流输入长什么样中间需要哪几步变换输出是什么格式。哪怕代码写得不够精炼只要逻辑清晰也能拿到大部分分数。3. SQL和数据仓库题是整场笔试的隐形大头3.1 为什么大数据岗笔试特别爱考SQL说SQL是隐形大头是因为它在卷面上的出现形式可能只是两道小题但对最终录用决策的影响比很多选择题大得多。原因很简单这是岗位日常工作最直接的映射。数仓开发要写大量的Hive SQL做ETL实时计算虽然主要写Flink代码但维也经常要写SQL。我在了解面试反馈时注意到一个共性网易的面试官很喜欢在简历里看到“熟练使用SQL”这句话之后追问一句“那你写一个连续登录3天的用户数”。如果笔试阶段SQL就翻车了面试这一轮大概率也躲不过去。所以SQL一定要早点练。3.2 一类高频题的完整推导过程以“用户连续登录N天”为例这是数仓面试题里的经典款笔试也常以变形出现。先给一个典型的表结构login_log(user_id, login_date)要求统计连续登录3天及以上的用户数。第一步用窗口函数row_number()按user_id分组、按login_date排序得到每个用户登录日期的排名SELECT user_id, login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS rn FROM login_log第二步是精妙之处用login_date减去rn得到一个日期。如果用户连续登录这个日期是相同的如果中间断开了这个日期就会变化。这是因为连续登录时日期递增1、排名也递增1两者之差保持不变。WITH temp AS ( SELECT user_id, login_date, DATE_SUB(login_date, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date)) AS grp FROM login_log ) SELECT user_id FROM temp GROUP BY user_id, grp HAVING COUNT(*) 3然后按user_id和grp分组统计每组的天数大于等于3的就是连续登录3天及以上的用户。最后如果需要用户数再套一层COUNT(DISTINCT user_id)就行了。这道题的变体很多连续登录的最大天数、连续活跃N天以上的用户数、按照省份分组统计连续活跃用户等。核心逻辑都一样核心就是“日期减排名构造连续组”这个技巧建议一定要练熟。3.3 比SQL语法更重要的“口径”问题很多同学SQL语法很熟窗口函数用得飞起但一碰到“口径”题就露馅。举个例子题目问“统计每日活跃用户数DAU”表里有一份用户登录日志。常规写法是SELECT login_date, COUNT(DISTINCT user_id) FROM login_log GROUP BY login_date。但如果题目补一句“一个用户一天内多次登录只算一次”上面的写法仍然成立因为COUNT(DISTINCT user_id)天然去重。真正容易翻车的是这类一个用户一天内多次登录但登录方式有App、小程序、Web题目问你“各端的去重用户数”和“总体去重用户数”分别是多少。如果只按端分组然后COUNT(DISTINCT user_id)再对分组结果求和就会“重复计算”——因为同一个用户可能在App和小程序都登录了。正确答案是SQL先按user_id去重再统计端分布或者使用COUNT(DISTINCT CASE WHEN ... THEN user_id END)这类条件去重写法。这种“业务口径”的坑比语法更难防但恰恰是大数据开发日常一定会遇到的问题。笔试里如果出现这类题本质上是在看你能不能从业务角度理解数据而不只是会写代码。4. 大数据组件的简答与选择题考的是理解而不是背概念4.1 一张图理清组件的考察范围网易大数据开发的笔试组件相关题目非常稳定基本不会超出下面这个范围组件在数据链路中的位置笔试常考点HDFS分布式存储副本机制、机架感知、NameNode与DataNode职责MapReduce批处理计算Shuffle过程、分区与排序、Combiner的作用Hive数据仓库工具内部表与外部表区别、分区表与分桶表、SQL转MapReduce原理Spark批处理/内存计算RDD依赖关系、宽窄依赖、Stage划分、持久化策略Flink实时计算窗口类型、Exactly-Once语义、Checkpoint机制Kafka消息队列分区与消费组、消息不丢失与不重复、ISR机制HBaseNoSQL数据库RowKey设计原则、LSM树、Region分裂不要指望把每个组件的源码都读一遍笔试考的是“理解”而不是“源码细节”。比如Spark的宽窄依赖你知道“窄依赖是指父RDD每个分区只被子RDD的一个分区使用不需要shuffle宽依赖是指多个子分区依赖同一个父分区需要shuffle”就够了。至于ShuffleManager具体怎么实现面试可能考笔试一般不会。4.2 一个高频考点为什么宽依赖要单独拿出来考我印象中网易笔试的选择题里出现过不止一次“关于Spark宽窄依赖的说法正确的是”。这个知识点不冷门但错误率很高原因是很多同学把“宽依赖”和“发生shuffle”划等号这是不严谨的。宽依赖一定发生shuffle但shuffle不一定只发生在宽依赖里。比如repartition操作也会触发shuffle但它的依赖关系需要具体分析。更常见的误区是把“窄依赖”理解成“没有网络传输”其实窄依赖在分布式计算里也可能有数据传递只是不会跨Stage。笔试的选项往往就在这里做文章。理解宽窄依赖的实际意义在于Stage划分DAG调度器会把窄依赖尽量合并到同一个Stage因为不需要等待shuffle落盘每遇到一个宽依赖就切分出一个新的Stage。这个逻辑搞清楚了比单纯背“宽依赖shuffle”有用得多。4.3 结合热词“集群部署策略”说说这类实操向考点的出题角度在笔试里“集群部署策略”不会直接问“请部署一套Hadoop集群”但会以选择题或简答题的方式出现比如“在物理机上部署HDFS时NameNode和DataNode应该如何规划”考察点是NameNode是单点或依赖QJM实现高可用不要和DataNode混布在同一台机器避免资源竞争。“机架感知的作用是什么”考察点是备份节点选择策略让副本分布在不同机架提高容错性。“Spark on YARN时Driver应该部署在哪”考察点是cluster模式和client模式的区别。这些问题背后有一个共同逻辑大数据组件不是装好就行还要考虑高可用、资源隔离、容错。如果平时只是用云服务商提供的EMR或托管Kafka这些概念会被隐藏掉但笔试不管你有没有用过概念必须清楚。建议准备时不要只盯命令多问自己一个“为什么这样部署”把原理和部署策略连起来记效果要好得多。5. 系统设计题不是让你写架构是让你把链路说清楚5.1 从日志采集到实时报表一类典型的链路设计题网易笔试的问答题里系统设计考得不多一旦出现就很有区分度。我见到过一道印象深刻的题“请设计一个实时用户行为分析系统支持统计每小时的活跃用户数数据源是客户端上报的埋点日志。”很多同学一看到“设计系统”就开始画微服务架构图其实在大数据岗笔试里系统设计题的骨架是“数据链路”不是“微服务”。正确的答题框架应该是数据接入客户端埋点日志通过HTTP或SDK上报经过Nginx或Flume采集写入Kafka。这里要强调Kafka的作用是削峰填谷缓冲流量波动对下游的冲击。实时计算Flink消费Kafka中的日志数据按事件时间分配窗口做去重和聚合计算每小时的UV和PV。这里要提到watermark和allowedLateness的处理因为埋点日志乱序是常态。结果存储聚合结果写入KV存储或OLAP引擎比如HBase、ClickHouse、Doris。查询侧按小时维度读取结果展示到报表系统或大屏。容错与监控Kafka的offset管理和Flink的Checkpoint机制保证不丢不重消费延迟、checkpoint失败等指标要接入监控告警。按照这个顺序写哪怕细节不够深逻辑链路是清晰的就能拿到大部分分数。设计题评分看重的是“你有没有完整闭环的思维”而不是“你有没有用过Doris”。5.2 数据倾斜设计题里的隐形高分点大数据的系统设计题几乎必有一个隐藏考察点——数据倾斜。刚才那道实时行为分析的题如果某个热门 App 的某个接口访问量特别大同一个 key比如接口ID在Flink里会堆积到同一个子任务上导致其他子任务空闲、整体延迟走高。笔试里不一定要求你写出完整解决方案但如果在设计题的答案里主动提到“考虑数据倾斜”会给阅卷人留下“有实战经验”的印象。常用的几种解法需要能说清楚局部聚合全局聚合对于count、sum之类可结合的操作先给key加随机后缀拆散到多个子任务做局部聚合再去掉后缀做全局聚合。这个思路在MapReduce和Spark里都适用。单独处理热点key如果热点key只有那么几个可以单独提取出来走一条特殊链路不参与普通key的聚合。提高并行度对倾斜的算子单独设置并行度但要结合数据分布判断盲目调大并行度不一定有效。有些同学设计题里写得头头是道一追问“如果倾斜了怎么办”就卡壳。所以准备系统设计题的时候不要只准备“正常链路”一定要把异常情况数据倾斜、延迟、数据重复、服务宕机的应对方案也一起准备这才是笔试拉开差距的地方。5.3 设计类题目里阅卷人最反感的三件事第一只画架构图不写说明。有的同学能画出一个很完整的架构图但每个组件为什么这样选型、组件之间怎么衔接一字不写。这样的答案阅卷人只能靠猜。正确做法是图简单画重点是文字说明每个环节的输入、输出、存储选型理由。第二存储选型脱离场景。比如实时UV统计有人写“最终结果存入MySQL”。不是不行但如果你能说一句“HBASE适合高并发点查ClickHouse适合聚合分析这里按小时预聚合的结果量不大用HBase或MySQL都能满足”就能体现出你是有意识地做选型而不是随手写一个名字。第三指标口径模糊。设计“每小时活跃用户数”时没有说明“一个用户一小时多次访问只算一次”也没有说明“跨小时边界的事件怎么归属”。这些细节不写方案看起来完整实际不可落地。把口径问题逼自己先想清楚写进答案里就能超过一半的竞争者。6. 计算机基础和其他考点最后的拿分点和时间分配技巧6.1 Java/Python、网络、操作系统怎么分配精力网易大数据开发的笔试选择题里会混入一些计算机基础知识题范围包括但不限于Java集合类源码级别的特性比如HashMap的扩容机制、JVM内存分区、TCP三次握手、进程与线程的区别、Linux常用命令等。这部分内容的特点是多而杂单题分值低。我不建议花大块时间系统复习优先级如下最高优先级Java集合类特性和JVM内存模型。大数据组件的源码大量使用Java集合面试聊源码时也躲不开掌握HashMap的put流程、ConcurrentHashMap如何保证线程安全、JVM堆内存如何分区性价比极高。中等优先级Linux常用命令。比如查看端口占用netstat/ss、查看磁盘空间df/du、查看进程ps/top、日志检索grep/awk/sed。这些在笔试和实际工作中都会用到。低优先级TCP/IP、HTTP、操作系统调度、数据库索引原理。这部分如果时间紧张简单过一遍知识点即可不要深挖。6.2 常见的冷门考点字符编码、时区、日志格式有个让我印象很深的细节某年选择题里出现了一道关于Linux下日志文件中\r\n和\n处理的题目。很多人一眼懵但这在真实的大数据处理里太常见了——windows上生成的日志文件传到Linux里解析时不做处理数据就会带上\r导致去重和统计结果出错。类似这种“脏数据”问题在笔试选择题里偶尔会以换行符、编码UTF-8 vs GBK、时区UTC vs 本地时间的形式出现。这类题没有系统性的复习路径建议在准备SQL题的时候顺带记一下date_sub、from_unixtime、to_date这些常用函数的边界行为多看几道题就能补齐。6.3 我对“选择题纠结症”的建议在在线笔试里最浪费时间的不是不会做的题而是“好像会又拿不准”的题。一道选择题如果在心里纠结超过两分钟建议先随便选一个并标记进入下一题等所有题目做完后再回来看。很多在线笔试系统支持题号跳转一定要利用这个功能。另一个很实用的策略单选题拿不准时优先排除明显错误的选项。大厂笔试的出题质量整体不错但偶尔会混入一个“一看就是凑数”的选项先把它删掉正确率就能提高不少。多选题尽量选自己确定的少选比错选好——大部分笔试的多选题是“少选得部分分错选不得分”不确定的选项宁可不选。7. 备考路线不同时间预算的复习方案7.1 一个月系统准备版按周拆解复习任务如果距离笔试还有一个月左右我建议按下面的节奏来第一周补齐SQL和算法基础。SQL重点练窗口函数、多表join、去重、分组统计算法刷LeetCode的“高频面试题”分类重点练字符串、哈希表、链表、二叉树、动态规划前30道常见题。每天2道SQL题2道算法题是最低量。**第二周大数据组件原理一轮。**Hadoop生态HDFS、MapReduce、YARN、Spark、Flink、Kafka、HBase的原理过一遍重点记忆各组件的架构角色、核心机制、常见问题。每天至少梳理一个组件的思维导图式笔记。**第三周系统设计和场景题专项。**找一些常见的数仓/实时计算设计题练手比如实时UV统计、离线数仓分层设计、用户画像标签加工。每天写一道设计题重点关注链路完整性和异常处理。**第四周模拟笔试查漏补缺。**严格按照真实考试的时间限制完整做1-2套模拟卷。做完后不要只看对错要把错题对应的知识点回补到笔记里。最后三天以复习笔记为主不再做新题。7.2 一周快速冲刺版只做高性价比的事如果只剩下一个星期别慌按下面优先级来第一天到第二天SQL窗口函数专项。把row_number、rank、dense_rank、lag、lead、sum() over()这些常用函数各练几个例子。SQL是最容易短期提升拿分的点。第三天Spark和Flink核心概念。重点看宽窄依赖、Stage划分、窗口类型、Checkpoint、Watermark。这些概念在选择题里出现频率高背住就有分。第四天Kafka和HBase核心机制。消费组、ISR、消息不丢失RowKey设计、LSM树。记关键词不用读源码。第五天到第六天完整做一套模拟题严格计时。找找在时间压力下做题的感觉然后针对错题回补知识点。第七天翻笔记不学新知识。重点是那些容易记混的概念比如“Spark的transform和action的区别”“Hive内部表和外部表的区别”“Kafka的at-least-once和exactly-once”。7.3 一些实操中的体会写到最后前面讲的都是方法和框架最后说几个自己亲身感受过、也见过别人踩坑的点。模拟笔试真的很重要。在线笔试和本地做题是两个完全不同的场景——倒计时一直跳、长时间盯屏幕眼睛会酸、不会做的题会带来额外焦虑。我见过有同学平时刷题时正确率很高但第一次做模拟卷时直接懵了原因就是没适应这种高压环境。至少完整模拟一次比多做十道题更有用。复盘时不要只记答案要记“错因”。是因为知识点没掌握还是因为时间分配不合理还是因为题目审偏了三类错因对应的改进方向完全不同。如果发现是时间分配的问题下次做题就要强制自己“先做分高的、先做会做的”。最后“大数据开发工程师”这个岗位在笔试阶段考核的深度并不算深更看重的是知识面的宽度和逻辑的完整性。把SQL练到条件反射把Spark、Flink、Kafka、HBase的原理梳理清楚再把数据规模和数据类型这两件事内化成思考习惯笔试通过只是时间问题。希望这篇梳理能帮你少走一些弯路。