每年三月份开始各大厂的实习生招聘陆续开放网易云音乐的大数据开发实习生岗位一直是很多同学盯着的目标。作为过来人我当年也认真准备过这类笔试前两天还有学弟问我“大数据开发实习生笔试到底考什么该怎么准备”我就借着“网易2018实习生招聘笔试题-大数据开发实习生-云音乐”这个话题完整梳理一下大数据开发实习岗笔试背后的考察逻辑、核心技能点以及围绕网易云音乐这个业务场景可能出现的题目方向和应对思路。这篇文章不聊具体某道题的答案而是帮你把整个备考思路打通让你知道该往哪个方向使劲。1. 先搞明白大数据开发实习生笔试到底在筛什么人很多同学拿到笔试题第一反应是“这题怎么这么杂”又是编程题又是SQL又是Linux命令还有一堆理论选择题。其实这恰恰说明了大数据开发岗位的特点它是一个典型的复合型岗位既要有扎实的工程基础又要有分布式系统的理论修养还得能搞定具体业务场景下的数据处理需求。1.1 大数据开发岗位的核心职责拆解先看网易云音乐的大数据开发工程师日常在做什么。云音乐这个产品有数亿用户每天产生海量的用户行为日志——听歌、切歌、收藏、评论、搜索、创建歌单、分享歌曲……这些行为数据会不断汇入数据平台。大数据开发工程师的核心工作就是把这堆原始数据变成可用的、有价值的资产搭建和维护数据管道把业务日志从各种数据源采集进来做数据清洗、转换、加工形成标准化的数据仓库计算各类核心指标比如日活、留存、播放时长、歌曲热度支撑推荐系统、运营活动、产品决策的数据需求保证数据质量、数据时效性和任务稳定性所以笔试考察的维度基本上就是围绕这些工作中需要用到的能力展开的。单靠临时刷几道题就想过笔试基本不现实关键是看你在学校或者项目里有没有真正动手处理过类似的问题。1.2 笔试考察的能力模型具体来说大数据开发实习笔试一般覆盖下面几块能力可以对照自检能力维度考察内容对应工作场景编程基础数据结构、算法、代码实现能力写UDF、写数据处理脚本、性能优化SQL能力复杂查询、窗口函数、聚合分析日常取数、报表计算、数仓开发大数据组件Hadoop/Spark/Hive/Flink原理与使用数据加工、任务开发、集群问题排查计算机基础操作系统、网络、Linux常用命令部署任务、排查线上故障业务理解指标口径、业务场景设计数据需求对接、分析思路说实话大部分同学在“编程基础”和“SQL”上都能顶一顶真正拉开差距的往往是“大数据组件”和“业务理解”这两块。尤其是业务题题目本身不难但如果你不熟悉流式数据的处理逻辑不熟悉常见的用户行为分析模型很容易答不到点上。2. 大数据笔试核心技能栈逐一破解网上搜“大数据开发”相关热词很多人关心的是Hadoop、Spark、Hive、Flink这些框架到底要不要深入源码级别。作为实习生笔试我个人觉得不用慌到啃源码但核心原理必须能讲清楚而且要会用、能写。2.1 HDFS和MapReduce基础中的基础HDFS的架构要能画出来NameNode管元数据、DataNode存数据块、SecondaryNameNode辅助合并元数据这个必须张口就来。笔试选择题特别喜欢考“一个文件默认块大小是多少副本数默认是多少副本放置策略是怎样的”这类问题。块大小128MB、副本数3、副本策略是“同机架放两个、跨机架放一个”这些是死知识一定要记牢。MapReduce则更偏重理解“分而治之”的思想。比如WordCount是怎么从“hello world”统计出词频的map阶段做了什么、shuffle阶段做了什么、reduce阶段做了什么。面试笔试中经常让你分析某个计算任务在map阶段和reduce阶段各自承担什么逻辑。还有一个高频考点是“数据倾斜”让你说说map端倾斜和reduce端倾斜的原因和解决办法。这类问题没有标准答案考察的是你有没有真正跑过任务、踩过坑。2.2 Spark和Flink流批一体的时代现在的数据开发纯MapReduce的岗位已经很少见了Spark和Flink基本是标配。Spark要理解的核心是RDD的依赖关系和Spark任务提交流程。笔试偶尔会给你一个算子的输出问是什么比如map、flatMap、reduceByKey的区别考察你是否真的上手写过。Flink相比之下更偏实时计算。云音乐这种产品实时场景非常多实时大屏、实时告警、实时榜单、实时个性化推荐。所以Flink的“窗口计算”和“状态管理”就特别重要。笔试如果出“怎么统计过去5分钟内播放量最高的歌曲”这其实就是一个典型的滑动窗口计算题你在Flink里可以怎么做选择哪种窗口类型事件时间还是处理时间水印怎么设置这些都是考官的关注点。2.3 Hive数仓SQL能力的分水岭Hive几乎是所有大数据开发笔试的必考项因为它把SQL和数据仓库绑定在了一起。Hive的考察重点有两层第一层是纯SQL能力第二层是Hive特有的优化。纯SQL层面一定要熟练使用窗口函数。什么叫窗口函数就是既能有聚合函数的能力又能在每一行上保留上下文信息。比如“求出每个歌单下播放量前三的歌曲”用row_number() over(partition by 歌单ID order by 播放量 desc)几下就写出来了。如果不熟悉窗口函数用普通group by实现这类需求会非常痛苦。Hive优化层面常见的优化点包括小文件合并海量小文件会导致NameNode压力大、任务启动慢数据倾斜处理常见做法是加随机前缀打散key、两阶段聚合分区裁剪和列裁剪只读取需要的分区和列减少IO合理设置reduce数量reduce数不是越多越好每个reduce处理的数据量在合理区间才高效选择适当的文件格式ORC、Parquet这类列式存储压缩比高、查询快2.4 Kafka数据管道的大动脉在网易云音乐这种规模的产品里用户行为日志基本都会先进Kafka再由下游消费者比如Flink、Spark Streaming拉取处理。笔试中Kafka的高频考点包括Kafka的架构组成Producer、Consumer、Broker、Topic、Partition、Consumer GroupProducer消息发送的三种模式发后即忘、同步发送、异步发送以及各自的使用场景Consumer的两种提交offset方式自动提交和手动提交手动提交的时机怎么把握Kafka怎么保证消息不丢不重ack机制、Producer重试、Consumer手动提交消息顺序性如何保证单个分区内有序全局有序很难做到对了很多同学看Kafka只看概念忽略了一个关键点一个partition的消费并发度上限是多少答案是“一个partition同一时刻只能被同一个消费组内的一个消费者消费”这决定了你消费者实例的并发上限也是实际开发中经常遇到的问题。3. 围绕网易云音乐场景的技术准备方向网易云音乐和一般产品有点不一样它的核心资产就是“歌单”、“评论”和“个性化推荐”。围绕这些业务模块数据开发要支撑的需求非常多笔试中也特别喜欢结合这些场景出题。3.1 用户行为日志采集与分析云音乐的前端PC端、移动端会不断上报用户行为事件比如“启动App”“点击歌曲”“播放完成”“收藏歌单”“分享歌曲”“发表评论”每个事件会携带一堆属性比如歌曲ID、来源页面、设备信息、用户ID。笔试可能会给你一个简化的日志表结构让你统计“每日活跃用户数”“每日播放歌曲总次数”“每日人均播放时长”。这些问题看似简单但你不光要会写SQL还要知道指标口径怎么定义。比如“活跃用户”是启动就算活跃还是播放歌曲才算“播放时长”是按日志上报的结束时间和开始时间之差算还是客户端统计后上报实际开发中最麻烦的往往不是SQL本身而是数据质量。日志上报的字段可能缺失客户端可能断网导致延迟上报这些都需要在数据清洗时处理。笔试中遇到类似场景最好能主动提一下“需要考虑数据去重、脏数据清洗、时间字段校验”这些点会让面试官觉得你有实战经验。3.2 云音乐推荐系统中的数据支撑网易云音乐的个性化推荐非常出名推荐系统背后离不开特征数据和样本数据的支撑。数据开发要做的事情包括生成训练样本把用户的历史行为和歌曲特征拼成模型训练需要的格式计算实时特征比如用户最近1小时听了哪些歌、最近3天收藏了多少歌单这些特征往往是实时计算出来的离线统计歌曲标签比如每首歌的热度、完播率、收藏转化率处理反馈回流把用户对推荐结果的点击、播放、收藏行为计入下一轮推荐有一类典型的笔试题是“如何判断两个用户是相似用户并给用户推荐歌曲”。这里考察的其实是相似度计算的思路。你可以说用协同过滤也可以说用基于歌曲embedding的计算重点是讲清楚数据加工的过程——用户向量怎么来相似度用什么公式算TopN怎么筛选。3.3 数据仓库的分层设计数据开发工作中绕不开数仓分层。云音乐的数仓大概也是经典的四层架构ODS层原始数据层存放从业务库和日志采集来的原始数据尽量保持原样DWD层明细数据层清洗加工后的明细数据以业务过程为单位组织DWS层汇总数据层按主题汇总比如“日播放主题”“日活跃主题”“歌曲维度汇总”ADS层应用数据层面向具体业务应用的数据比如推荐系统特征表、运营报表笔试或面试中如果问“订单数据怎么分层的”“某张报表的指标怎么追溯上游”本质上就是在考察你对数仓分层的理解。分层的好处是职责清晰、便于追踪、减少重复计算。但坏处是层级太多可能导致数据延迟变长所以调度链路的依赖关系要设计好。4. 笔试中“高性价比”的答题策略与实操演练这里聊聊具体的笔试题型和答题节奏。大数据开发实习笔试一般分选择题、编程题、SQL题和主观设计题四个部分。不同题型的准备策略和临场策略都不一样。4.1 选择题核心是广度选择题覆盖面很广从Java基础、JVM、Linux命令到Hadoop组件原理、网络协议、数据库索引都有可能出现。有些同学看到这种选择题直接崩溃觉得怎么什么冷门知识都考。其实这类题的关键是“广而不深”你不需要知道每个细节但常见概念必须都见过。准备建议把大数据生态里每个组件的核心原理过一遍不求源码但求“这个组件解决什么问题、有什么优缺点”Linux高频命令要会top查看负载、df查看磁盘、grep/awk/sed处理文本、crontab配置定时任务基础算法题的选择版本要熟练时间复杂度的计算、常用排序算法的稳定性比较、哈希表和二叉树的特性4.2 编程题刷题不在多经典题型要熟编程题通常1到3道难度一般介于LeetCode中等和简单之间。云音乐这类业务型公司编程题有时候会结合具体场景。比如可能会出“写一个函数找到播放次数最多的K首歌”这就是经典的TopK问题解决方案有堆排序和快速选择算法时间复杂度都是O(nlogK)。另一个常见题型是“统计一篇文章中出现次数最多的单词”这类题除了要你写对逻辑还要注意代码风格和边界条件比如输入为空怎么处理、大小写是否忽略、标点符号怎么过滤。建议平时写代码就把输入判空、异常处理都写好这在笔试中是很加分的。编程题准备阶段我建议按这五类题型去刷数组和字符串双指针、滑动窗口、哈希表链表反转、合并、找环入口二叉树前中后序遍历、层序遍历、最近公共祖先动态规划背包问题、最长公共子序列、编辑距离TopK类型堆、快排思想、计数排序4.3 SQL题窗口函数是拿分利器SQL题几乎每套笔试题都有而且比重越来越大。有时候直接给你一张用户行为表、一张歌曲信息表让你写SQL。这里有一个经验写完基本逻辑后要再想一步“如果数据有重复我的SQL结果准吗如果某个用户当天没有任何播放记录会被统计进来吗”窗口函数必须玩得转常用场景包括分组TopNrow_number()、rank()、dense_rank()的区别累计求和sum() over(order by 日期)同比环比lag()、lead()取前后行分组内去重计数count(distinct ...) over(...)下面我以一个模拟题目为例子演示一下完整思路。题目背景云音乐有一个“歌曲播放日志表”play_log字段为user_id、song_id、play_time(日期)、duration(播放时长秒)。另有一个“歌曲信息表”song_info字段为song_id、song_name、singer。请统计2024年1月1日当天播放量最高的10首歌及其播放用户数。思路拆解第一步先过滤出1月1日的数据避免全表扫描。如果有分区表SQL里直接写分区条件。第二步在逻辑上区分两个指标“播放次数”指的是日志行数一个人反复播同一首歌会算多次“播放用户数”需要去重是count(distinct user_id)。第三步按播放次数排序取Top10同时输出播放用户数。select info.song_name, info.singer, count(*) as play_cnt, count(distinct log.user_id) as user_cnt from play_log log left join song_info info on log.song_id info.song_id where log.play_time 2024-01-01 group by info.song_name, info.singer order by play_cnt desc limit 10这个SQL看起来简单但有几个点要注意如果一首歌在song_info表里没有对应记录left join后song_name会是NULL要不要保留count(*)会把连接后没有歌曲信息的记录也算进去但有NULL歌曲名会出现在结果里。更严谨的写法是把连接条件内关联或者加一个song_name is not null的过滤条件。另外如果日志量非常大group by之前尽量先过滤掉无效数据避免shuffle的数据量过大。4.4 主观设计题拼的是结构化思维主观设计题是最能拉开分数的因为这类题没有标准答案但非常能体现一个候选人的工程思维。常见的出题方式有两种一种是给你一个数据需求让你设计实现方案另一种是给你一个线上问题让你排查解决。先看第一种典型的问法是“云音乐想统计每天新增用户次日留存率请问你会怎么设计这个数据任务”这个问题看似简单背后涉及好几个关键点“新增用户”的标准是什么以设备号去重还是以账号去重次日留存的时间窗口怎么算自然日还是相对时间24小时如果用户当天注册当天卸载第二天又安装回来还算新增吗增量计算还是全量计算新增用户表是全量最新状态还是每日分区追加这些细节都是答主观题时的加分项。建议答题时不要一上来写代码先用几条文字描述清楚你的思路再给出核心逻辑。再看第二种问题排查题“某天Hive任务跑得特别慢你怎么排查”这种题的答题框架可以是先看任务是否发生数据倾斜某个reduce长时间运行其他reduce很快结束再看是否有大量小文件问题小文件太多导致task数量爆炸调度开销大检查是否资源不足队列资源不够任务在等待再看数据本身是否有问题空值过多、重复key过多可以按“从现象到原因、从环境到数据、从粗粒度到细粒度”的原则回答问题分条列出排查步骤和对应解决方案。5. 常见问题与避坑经验实录写到这里分享几个我在准备笔试和实际面试过程中遇到的问题以及后来总结的经验。这些细节不一定写在书里但真的很重要。5.1 实习项目经验不够怎么弥补这是很多同学最大的痛点简历上没有大数据项目经验。我的建议是不要等自己造轮子。网上有很多公开数据集可以自己搭一套单机版的大数据环境跑通一个完整的离线处理流程用Flume或Kafka模拟采集数据、用Hive做清洗和统计、用Sqoop把结果导出到MySQL最后用可视化工具展示。哪怕数据集很小这个“全链路走通”的过程比背十遍原理都有用面试聊起来也能讲出真实的细节。5.2 笔试前一定要做的三件事第一把SQL窗口函数练熟。找几道经典的排行类、同比环比类题目反复写直到不用翻文档就能写出来。第二把大数据组件的原理过一遍不要求死记硬背但要做到“看到问题能回忆起对应组件”。第三把简历里写过的所有项目重新复盘一遍。重点想清楚项目背景、数据量、技术选型、遇到的难点和解决方式。面试官经常顺着你简历上的项目深挖如果简历写得高大上一问细节就卡壳会留下很不好的印象。5.3 笔试途中的常见失误避坑审题不仔细SQL题要求“按播放次数从高到低排序”结果按“播放用户数”排序了边界条件处理不到位数组为空、除数为0、日期格式不合法时间分配失衡在一道编程题上死磕导致后面的SQL题没时间写Java和Python语法混用笔试用在线编辑器没有自动补全语法写错很浪费时间坦白讲大数据开发实习生笔试不是要考倒你而是想看到一个“将来能一起干活的人”应该具备的底子。所以你在答题时多用“实际工作中会怎么做”的视角来思考会比死记硬背拿到的分数高很多。5.4 从笔试到面试的衔接建议笔试过了不代表万事大吉面试环节一定会追问笔试中的题目。我当年就是笔试SQL题里用了一个窗口函数面试官当场让我现场说说窗口函数的执行原理我当时只能答出语法层面执行原理完全说不清楚场面一度非常尴尬。后来我把窗口函数的执行流程研究深了才知道窗口函数是在map端排序、reduce端计算整个过程会经历collect、spill、merge多个阶段。这些细节虽然笔试很少考但面试问起来是大杀器。建议你笔试结束后把每一道题都重新做一遍尤其是写错或者不会的题彻底搞懂原理。面试官大概率会从这些题目出发考察你的真实水平。6. 云音乐场景下的两个高频业务题深度解析围绕网易云音乐这个业务场景有两类题在笔试和面试中反复出现我单独拎出来拆一下思路方便你举一反三。6.1 如何统计热门歌曲和热门歌单这题表面是“统计播放量Top10歌曲”实际上是在考察你对业务热度的理解。只有播放次数不够准确比如一首歌被用户循环播放了一百次和一百个用户各播一次意义是不一样的。更合理的“热度”可以综合考虑播放次数、播放用户数、收藏次数、分享次数加权得到一个热度分。简单方案是给每个指标设置权重用下面的公式热度分 播放次数 * 0.4 收藏次数 * 0.3 分享次数 * 0.2 评论数 * 0.1这个权重可以按业务效果调整。答题时能讲出“播放次数要先去重”“防止刷量可以考虑过滤异常设备”“小时级更新和天级更新的计算口径不同”这些点就比直接写group by排序高出一个段位。6.2 如何给用户做每日听歌报告每年年底网易云音乐的个人年度听歌报告都会刷屏。这个功能背后就有一堆数据计算任务在支撑。给你一个简化版问题“如何给用户生成每日听歌报告内容包括当天听的歌曲数、时长、最喜欢的歌曲、听歌时段分布。”这个问题要拆成几层离线批量计算每天凌晨跑定时任务把前一天的用户行为日志聚合成报告需要的数据明细数据存储用户当天听过的每一首歌的明细用于生成歌曲列表指标计算总时长、歌曲数、歌手分布、时段分布个性化挖掘当天单曲循环最多的歌、深夜听的歌回答这类题的时候可以主动对比“纯离线计算”和“离线实时结合”的优劣。每日报告这种低频场景用离线计算就够了如果是“实时听歌报告”那就需要实时计算框架在用户听完一首歌后实时更新数据。7. 给正在准备大数据开发实习的同学一些大实话说了这么多最后讲点掏心窝的话。大数据开发这个方向表面上是“考组件原理、考SQL、考算法”实际上考的是你有没有解决实际问题的能力。笔试题目千变万化但底层逻辑始终是给你一堆数据你能不能把数据变成有价值的信息所以我的建议是准备阶段不要把大量时间花在“背面试题”上多动手写SQL、多在本地模拟数据场景、多去看一些大数据平台的真实技术博客。你写过的每一行SQL、跑过的每一个Spark任务、排查过的每一个数据问题最后都会在笔试中体现出来。另外一个很实际的经验是网易云音乐的数据开发岗位对“业务理解”的要求比较高你在准备时多去体验一下产品想想“每日推荐”“私人FM”“歌单广场”这些功能背后分别需要哪些数据支持写题的时候就有了场景感很多问题就能答到点子上。我记得当年在笔试环节有一道SQL题需要求“某首歌在每日推荐位上的点击率”当时我还在纠结“点击率”是按点击次数除以曝光次数算还是按点击用户数除以曝光用户数算。后来我才意识到这种业务指标的定义本身就是和产品、数据团队约定好的不同口径对结果影响巨大提前想清楚比埋头写SQL更重要。这个思考过程其实也是数据开发工程师和纯后端开发工程师最大的区别——我们不只是写代码我们还要理解业务逻辑然后把它翻译成数据逻辑。希望这篇经验贴能帮到正在犹豫、正在准备的同学。大数据开发这条路入门不难但每一步都需要踏踏实实走下去。如果你还在迷茫该从哪里开始那就先从把SQL练熟、把Hadoop生态的组件原理过一遍开始迈出第一步后面就好走了。 大数据开发实习笔试核心考点解析——网易云音乐篇
每年三月份开始各大厂的实习生招聘陆续开放网易云音乐的大数据开发实习生岗位一直是很多同学盯着的目标。作为过来人我当年也认真准备过这类笔试前两天还有学弟问我“大数据开发实习生笔试到底考什么该怎么准备”我就借着“网易2018实习生招聘笔试题-大数据开发实习生-云音乐”这个话题完整梳理一下大数据开发实习岗笔试背后的考察逻辑、核心技能点以及围绕网易云音乐这个业务场景可能出现的题目方向和应对思路。这篇文章不聊具体某道题的答案而是帮你把整个备考思路打通让你知道该往哪个方向使劲。1. 先搞明白大数据开发实习生笔试到底在筛什么人很多同学拿到笔试题第一反应是“这题怎么这么杂”又是编程题又是SQL又是Linux命令还有一堆理论选择题。其实这恰恰说明了大数据开发岗位的特点它是一个典型的复合型岗位既要有扎实的工程基础又要有分布式系统的理论修养还得能搞定具体业务场景下的数据处理需求。1.1 大数据开发岗位的核心职责拆解先看网易云音乐的大数据开发工程师日常在做什么。云音乐这个产品有数亿用户每天产生海量的用户行为日志——听歌、切歌、收藏、评论、搜索、创建歌单、分享歌曲……这些行为数据会不断汇入数据平台。大数据开发工程师的核心工作就是把这堆原始数据变成可用的、有价值的资产搭建和维护数据管道把业务日志从各种数据源采集进来做数据清洗、转换、加工形成标准化的数据仓库计算各类核心指标比如日活、留存、播放时长、歌曲热度支撑推荐系统、运营活动、产品决策的数据需求保证数据质量、数据时效性和任务稳定性所以笔试考察的维度基本上就是围绕这些工作中需要用到的能力展开的。单靠临时刷几道题就想过笔试基本不现实关键是看你在学校或者项目里有没有真正动手处理过类似的问题。1.2 笔试考察的能力模型具体来说大数据开发实习笔试一般覆盖下面几块能力可以对照自检能力维度考察内容对应工作场景编程基础数据结构、算法、代码实现能力写UDF、写数据处理脚本、性能优化SQL能力复杂查询、窗口函数、聚合分析日常取数、报表计算、数仓开发大数据组件Hadoop/Spark/Hive/Flink原理与使用数据加工、任务开发、集群问题排查计算机基础操作系统、网络、Linux常用命令部署任务、排查线上故障业务理解指标口径、业务场景设计数据需求对接、分析思路说实话大部分同学在“编程基础”和“SQL”上都能顶一顶真正拉开差距的往往是“大数据组件”和“业务理解”这两块。尤其是业务题题目本身不难但如果你不熟悉流式数据的处理逻辑不熟悉常见的用户行为分析模型很容易答不到点上。2. 大数据笔试核心技能栈逐一破解网上搜“大数据开发”相关热词很多人关心的是Hadoop、Spark、Hive、Flink这些框架到底要不要深入源码级别。作为实习生笔试我个人觉得不用慌到啃源码但核心原理必须能讲清楚而且要会用、能写。2.1 HDFS和MapReduce基础中的基础HDFS的架构要能画出来NameNode管元数据、DataNode存数据块、SecondaryNameNode辅助合并元数据这个必须张口就来。笔试选择题特别喜欢考“一个文件默认块大小是多少副本数默认是多少副本放置策略是怎样的”这类问题。块大小128MB、副本数3、副本策略是“同机架放两个、跨机架放一个”这些是死知识一定要记牢。MapReduce则更偏重理解“分而治之”的思想。比如WordCount是怎么从“hello world”统计出词频的map阶段做了什么、shuffle阶段做了什么、reduce阶段做了什么。面试笔试中经常让你分析某个计算任务在map阶段和reduce阶段各自承担什么逻辑。还有一个高频考点是“数据倾斜”让你说说map端倾斜和reduce端倾斜的原因和解决办法。这类问题没有标准答案考察的是你有没有真正跑过任务、踩过坑。2.2 Spark和Flink流批一体的时代现在的数据开发纯MapReduce的岗位已经很少见了Spark和Flink基本是标配。Spark要理解的核心是RDD的依赖关系和Spark任务提交流程。笔试偶尔会给你一个算子的输出问是什么比如map、flatMap、reduceByKey的区别考察你是否真的上手写过。Flink相比之下更偏实时计算。云音乐这种产品实时场景非常多实时大屏、实时告警、实时榜单、实时个性化推荐。所以Flink的“窗口计算”和“状态管理”就特别重要。笔试如果出“怎么统计过去5分钟内播放量最高的歌曲”这其实就是一个典型的滑动窗口计算题你在Flink里可以怎么做选择哪种窗口类型事件时间还是处理时间水印怎么设置这些都是考官的关注点。2.3 Hive数仓SQL能力的分水岭Hive几乎是所有大数据开发笔试的必考项因为它把SQL和数据仓库绑定在了一起。Hive的考察重点有两层第一层是纯SQL能力第二层是Hive特有的优化。纯SQL层面一定要熟练使用窗口函数。什么叫窗口函数就是既能有聚合函数的能力又能在每一行上保留上下文信息。比如“求出每个歌单下播放量前三的歌曲”用row_number() over(partition by 歌单ID order by 播放量 desc)几下就写出来了。如果不熟悉窗口函数用普通group by实现这类需求会非常痛苦。Hive优化层面常见的优化点包括小文件合并海量小文件会导致NameNode压力大、任务启动慢数据倾斜处理常见做法是加随机前缀打散key、两阶段聚合分区裁剪和列裁剪只读取需要的分区和列减少IO合理设置reduce数量reduce数不是越多越好每个reduce处理的数据量在合理区间才高效选择适当的文件格式ORC、Parquet这类列式存储压缩比高、查询快2.4 Kafka数据管道的大动脉在网易云音乐这种规模的产品里用户行为日志基本都会先进Kafka再由下游消费者比如Flink、Spark Streaming拉取处理。笔试中Kafka的高频考点包括Kafka的架构组成Producer、Consumer、Broker、Topic、Partition、Consumer GroupProducer消息发送的三种模式发后即忘、同步发送、异步发送以及各自的使用场景Consumer的两种提交offset方式自动提交和手动提交手动提交的时机怎么把握Kafka怎么保证消息不丢不重ack机制、Producer重试、Consumer手动提交消息顺序性如何保证单个分区内有序全局有序很难做到对了很多同学看Kafka只看概念忽略了一个关键点一个partition的消费并发度上限是多少答案是“一个partition同一时刻只能被同一个消费组内的一个消费者消费”这决定了你消费者实例的并发上限也是实际开发中经常遇到的问题。3. 围绕网易云音乐场景的技术准备方向网易云音乐和一般产品有点不一样它的核心资产就是“歌单”、“评论”和“个性化推荐”。围绕这些业务模块数据开发要支撑的需求非常多笔试中也特别喜欢结合这些场景出题。3.1 用户行为日志采集与分析云音乐的前端PC端、移动端会不断上报用户行为事件比如“启动App”“点击歌曲”“播放完成”“收藏歌单”“分享歌曲”“发表评论”每个事件会携带一堆属性比如歌曲ID、来源页面、设备信息、用户ID。笔试可能会给你一个简化的日志表结构让你统计“每日活跃用户数”“每日播放歌曲总次数”“每日人均播放时长”。这些问题看似简单但你不光要会写SQL还要知道指标口径怎么定义。比如“活跃用户”是启动就算活跃还是播放歌曲才算“播放时长”是按日志上报的结束时间和开始时间之差算还是客户端统计后上报实际开发中最麻烦的往往不是SQL本身而是数据质量。日志上报的字段可能缺失客户端可能断网导致延迟上报这些都需要在数据清洗时处理。笔试中遇到类似场景最好能主动提一下“需要考虑数据去重、脏数据清洗、时间字段校验”这些点会让面试官觉得你有实战经验。3.2 云音乐推荐系统中的数据支撑网易云音乐的个性化推荐非常出名推荐系统背后离不开特征数据和样本数据的支撑。数据开发要做的事情包括生成训练样本把用户的历史行为和歌曲特征拼成模型训练需要的格式计算实时特征比如用户最近1小时听了哪些歌、最近3天收藏了多少歌单这些特征往往是实时计算出来的离线统计歌曲标签比如每首歌的热度、完播率、收藏转化率处理反馈回流把用户对推荐结果的点击、播放、收藏行为计入下一轮推荐有一类典型的笔试题是“如何判断两个用户是相似用户并给用户推荐歌曲”。这里考察的其实是相似度计算的思路。你可以说用协同过滤也可以说用基于歌曲embedding的计算重点是讲清楚数据加工的过程——用户向量怎么来相似度用什么公式算TopN怎么筛选。3.3 数据仓库的分层设计数据开发工作中绕不开数仓分层。云音乐的数仓大概也是经典的四层架构ODS层原始数据层存放从业务库和日志采集来的原始数据尽量保持原样DWD层明细数据层清洗加工后的明细数据以业务过程为单位组织DWS层汇总数据层按主题汇总比如“日播放主题”“日活跃主题”“歌曲维度汇总”ADS层应用数据层面向具体业务应用的数据比如推荐系统特征表、运营报表笔试或面试中如果问“订单数据怎么分层的”“某张报表的指标怎么追溯上游”本质上就是在考察你对数仓分层的理解。分层的好处是职责清晰、便于追踪、减少重复计算。但坏处是层级太多可能导致数据延迟变长所以调度链路的依赖关系要设计好。4. 笔试中“高性价比”的答题策略与实操演练这里聊聊具体的笔试题型和答题节奏。大数据开发实习笔试一般分选择题、编程题、SQL题和主观设计题四个部分。不同题型的准备策略和临场策略都不一样。4.1 选择题核心是广度选择题覆盖面很广从Java基础、JVM、Linux命令到Hadoop组件原理、网络协议、数据库索引都有可能出现。有些同学看到这种选择题直接崩溃觉得怎么什么冷门知识都考。其实这类题的关键是“广而不深”你不需要知道每个细节但常见概念必须都见过。准备建议把大数据生态里每个组件的核心原理过一遍不求源码但求“这个组件解决什么问题、有什么优缺点”Linux高频命令要会top查看负载、df查看磁盘、grep/awk/sed处理文本、crontab配置定时任务基础算法题的选择版本要熟练时间复杂度的计算、常用排序算法的稳定性比较、哈希表和二叉树的特性4.2 编程题刷题不在多经典题型要熟编程题通常1到3道难度一般介于LeetCode中等和简单之间。云音乐这类业务型公司编程题有时候会结合具体场景。比如可能会出“写一个函数找到播放次数最多的K首歌”这就是经典的TopK问题解决方案有堆排序和快速选择算法时间复杂度都是O(nlogK)。另一个常见题型是“统计一篇文章中出现次数最多的单词”这类题除了要你写对逻辑还要注意代码风格和边界条件比如输入为空怎么处理、大小写是否忽略、标点符号怎么过滤。建议平时写代码就把输入判空、异常处理都写好这在笔试中是很加分的。编程题准备阶段我建议按这五类题型去刷数组和字符串双指针、滑动窗口、哈希表链表反转、合并、找环入口二叉树前中后序遍历、层序遍历、最近公共祖先动态规划背包问题、最长公共子序列、编辑距离TopK类型堆、快排思想、计数排序4.3 SQL题窗口函数是拿分利器SQL题几乎每套笔试题都有而且比重越来越大。有时候直接给你一张用户行为表、一张歌曲信息表让你写SQL。这里有一个经验写完基本逻辑后要再想一步“如果数据有重复我的SQL结果准吗如果某个用户当天没有任何播放记录会被统计进来吗”窗口函数必须玩得转常用场景包括分组TopNrow_number()、rank()、dense_rank()的区别累计求和sum() over(order by 日期)同比环比lag()、lead()取前后行分组内去重计数count(distinct ...) over(...)下面我以一个模拟题目为例子演示一下完整思路。题目背景云音乐有一个“歌曲播放日志表”play_log字段为user_id、song_id、play_time(日期)、duration(播放时长秒)。另有一个“歌曲信息表”song_info字段为song_id、song_name、singer。请统计2024年1月1日当天播放量最高的10首歌及其播放用户数。思路拆解第一步先过滤出1月1日的数据避免全表扫描。如果有分区表SQL里直接写分区条件。第二步在逻辑上区分两个指标“播放次数”指的是日志行数一个人反复播同一首歌会算多次“播放用户数”需要去重是count(distinct user_id)。第三步按播放次数排序取Top10同时输出播放用户数。select info.song_name, info.singer, count(*) as play_cnt, count(distinct log.user_id) as user_cnt from play_log log left join song_info info on log.song_id info.song_id where log.play_time 2024-01-01 group by info.song_name, info.singer order by play_cnt desc limit 10这个SQL看起来简单但有几个点要注意如果一首歌在song_info表里没有对应记录left join后song_name会是NULL要不要保留count(*)会把连接后没有歌曲信息的记录也算进去但有NULL歌曲名会出现在结果里。更严谨的写法是把连接条件内关联或者加一个song_name is not null的过滤条件。另外如果日志量非常大group by之前尽量先过滤掉无效数据避免shuffle的数据量过大。4.4 主观设计题拼的是结构化思维主观设计题是最能拉开分数的因为这类题没有标准答案但非常能体现一个候选人的工程思维。常见的出题方式有两种一种是给你一个数据需求让你设计实现方案另一种是给你一个线上问题让你排查解决。先看第一种典型的问法是“云音乐想统计每天新增用户次日留存率请问你会怎么设计这个数据任务”这个问题看似简单背后涉及好几个关键点“新增用户”的标准是什么以设备号去重还是以账号去重次日留存的时间窗口怎么算自然日还是相对时间24小时如果用户当天注册当天卸载第二天又安装回来还算新增吗增量计算还是全量计算新增用户表是全量最新状态还是每日分区追加这些细节都是答主观题时的加分项。建议答题时不要一上来写代码先用几条文字描述清楚你的思路再给出核心逻辑。再看第二种问题排查题“某天Hive任务跑得特别慢你怎么排查”这种题的答题框架可以是先看任务是否发生数据倾斜某个reduce长时间运行其他reduce很快结束再看是否有大量小文件问题小文件太多导致task数量爆炸调度开销大检查是否资源不足队列资源不够任务在等待再看数据本身是否有问题空值过多、重复key过多可以按“从现象到原因、从环境到数据、从粗粒度到细粒度”的原则回答问题分条列出排查步骤和对应解决方案。5. 常见问题与避坑经验实录写到这里分享几个我在准备笔试和实际面试过程中遇到的问题以及后来总结的经验。这些细节不一定写在书里但真的很重要。5.1 实习项目经验不够怎么弥补这是很多同学最大的痛点简历上没有大数据项目经验。我的建议是不要等自己造轮子。网上有很多公开数据集可以自己搭一套单机版的大数据环境跑通一个完整的离线处理流程用Flume或Kafka模拟采集数据、用Hive做清洗和统计、用Sqoop把结果导出到MySQL最后用可视化工具展示。哪怕数据集很小这个“全链路走通”的过程比背十遍原理都有用面试聊起来也能讲出真实的细节。5.2 笔试前一定要做的三件事第一把SQL窗口函数练熟。找几道经典的排行类、同比环比类题目反复写直到不用翻文档就能写出来。第二把大数据组件的原理过一遍不要求死记硬背但要做到“看到问题能回忆起对应组件”。第三把简历里写过的所有项目重新复盘一遍。重点想清楚项目背景、数据量、技术选型、遇到的难点和解决方式。面试官经常顺着你简历上的项目深挖如果简历写得高大上一问细节就卡壳会留下很不好的印象。5.3 笔试途中的常见失误避坑审题不仔细SQL题要求“按播放次数从高到低排序”结果按“播放用户数”排序了边界条件处理不到位数组为空、除数为0、日期格式不合法时间分配失衡在一道编程题上死磕导致后面的SQL题没时间写Java和Python语法混用笔试用在线编辑器没有自动补全语法写错很浪费时间坦白讲大数据开发实习生笔试不是要考倒你而是想看到一个“将来能一起干活的人”应该具备的底子。所以你在答题时多用“实际工作中会怎么做”的视角来思考会比死记硬背拿到的分数高很多。5.4 从笔试到面试的衔接建议笔试过了不代表万事大吉面试环节一定会追问笔试中的题目。我当年就是笔试SQL题里用了一个窗口函数面试官当场让我现场说说窗口函数的执行原理我当时只能答出语法层面执行原理完全说不清楚场面一度非常尴尬。后来我把窗口函数的执行流程研究深了才知道窗口函数是在map端排序、reduce端计算整个过程会经历collect、spill、merge多个阶段。这些细节虽然笔试很少考但面试问起来是大杀器。建议你笔试结束后把每一道题都重新做一遍尤其是写错或者不会的题彻底搞懂原理。面试官大概率会从这些题目出发考察你的真实水平。6. 云音乐场景下的两个高频业务题深度解析围绕网易云音乐这个业务场景有两类题在笔试和面试中反复出现我单独拎出来拆一下思路方便你举一反三。6.1 如何统计热门歌曲和热门歌单这题表面是“统计播放量Top10歌曲”实际上是在考察你对业务热度的理解。只有播放次数不够准确比如一首歌被用户循环播放了一百次和一百个用户各播一次意义是不一样的。更合理的“热度”可以综合考虑播放次数、播放用户数、收藏次数、分享次数加权得到一个热度分。简单方案是给每个指标设置权重用下面的公式热度分 播放次数 * 0.4 收藏次数 * 0.3 分享次数 * 0.2 评论数 * 0.1这个权重可以按业务效果调整。答题时能讲出“播放次数要先去重”“防止刷量可以考虑过滤异常设备”“小时级更新和天级更新的计算口径不同”这些点就比直接写group by排序高出一个段位。6.2 如何给用户做每日听歌报告每年年底网易云音乐的个人年度听歌报告都会刷屏。这个功能背后就有一堆数据计算任务在支撑。给你一个简化版问题“如何给用户生成每日听歌报告内容包括当天听的歌曲数、时长、最喜欢的歌曲、听歌时段分布。”这个问题要拆成几层离线批量计算每天凌晨跑定时任务把前一天的用户行为日志聚合成报告需要的数据明细数据存储用户当天听过的每一首歌的明细用于生成歌曲列表指标计算总时长、歌曲数、歌手分布、时段分布个性化挖掘当天单曲循环最多的歌、深夜听的歌回答这类题的时候可以主动对比“纯离线计算”和“离线实时结合”的优劣。每日报告这种低频场景用离线计算就够了如果是“实时听歌报告”那就需要实时计算框架在用户听完一首歌后实时更新数据。7. 给正在准备大数据开发实习的同学一些大实话说了这么多最后讲点掏心窝的话。大数据开发这个方向表面上是“考组件原理、考SQL、考算法”实际上考的是你有没有解决实际问题的能力。笔试题目千变万化但底层逻辑始终是给你一堆数据你能不能把数据变成有价值的信息所以我的建议是准备阶段不要把大量时间花在“背面试题”上多动手写SQL、多在本地模拟数据场景、多去看一些大数据平台的真实技术博客。你写过的每一行SQL、跑过的每一个Spark任务、排查过的每一个数据问题最后都会在笔试中体现出来。另外一个很实际的经验是网易云音乐的数据开发岗位对“业务理解”的要求比较高你在准备时多去体验一下产品想想“每日推荐”“私人FM”“歌单广场”这些功能背后分别需要哪些数据支持写题的时候就有了场景感很多问题就能答到点子上。我记得当年在笔试环节有一道SQL题需要求“某首歌在每日推荐位上的点击率”当时我还在纠结“点击率”是按点击次数除以曝光次数算还是按点击用户数除以曝光用户数算。后来我才意识到这种业务指标的定义本身就是和产品、数据团队约定好的不同口径对结果影响巨大提前想清楚比埋头写SQL更重要。这个思考过程其实也是数据开发工程师和纯后端开发工程师最大的区别——我们不只是写代码我们还要理解业务逻辑然后把它翻译成数据逻辑。希望这篇经验贴能帮到正在犹豫、正在准备的同学。大数据开发这条路入门不难但每一步都需要踏踏实实走下去。如果你还在迷茫该从哪里开始那就先从把SQL练熟、把Hadoop生态的组件原理过一遍开始迈出第一步后面就好走了。