🎯 字节跳动大数据开发面经 1️⃣

一、核心面试问题集锦 🎯

1. 项目深挖类 🔍

🔍 考察重点：实习期间在项目中的具体职责与贡献、技术难点的解决思路、数据落地的全流程把控、业务与技术的结合能力

💡 大厂高频细节提问（结合实习项目背景）及详细解答：

1. 你在这个实习项目中具体负责哪个模块？是独立开发还是协同开发？请说明你从需求对接、开发实现到上线落地的完整流程。

【解答】

① 职责与分工：实习期间核心负责 “用户行为偏好标签” 子模块开发，属于项目核心标签体系的一部分；整体以协同开发为主，我独立承担该子模块的全流程落地，导师和数仓同学提供技术指导，同时需对接运营同学确认需求细节。

② 完整流程：

• 需求对接（1 周）：参与运营侧需求研讨会，记录 “音乐风格偏好”“社区互动偏好” 等标签的业务诉求，会后整理成《标签需求清单》，明确每个标签的业务含义、应用场景（如用于个性化内容推送），同步给导师和数据产品经理对齐口径；

• 开发实现（3 周）：基于数仓 DWD 层用户行为日志表（播放、收藏、评论等），用 Hive SQL 编写标签计算脚本，比如 “音乐风格偏好” 标签通过统计用户近 30 天各风格音乐的播放时长占比确定；开发中每日同步进度，遇到数据来源不明确的问题时，主动对接数仓同学确认数据表字段含义；

• 测试验证（1 周）：搭建测试环境，选取 100 个样本用户，对比标签计算结果与人工标注结果，修正 “播放时长统计遗漏后台播放数据” 的问题；

• 上线落地（1 周）：将脚本提交到生产环境，配合数仓同学完成调度任务配置（T+1 更新），给运营同学做标签使用说明培训，收集初期使用反馈。

2. 项目中核心指标的计算口径是如何确定的？有没有遇到业务方对指标理解有分歧的情况？你是如何推动对齐的？

【解答】

① 口径确定方式：核心指标（如 “高活跃社区用户”“音乐风格偏好占比”）的计算口径，是通过 “业务方提诉求→技术侧拆解→多方评审” 确定的。以 “高活跃社区用户” 为例，先由运营同学提出 “需圈选经常发布笔记、参与互动的用户”，再由我和导师拆解为可量化的指标：近 30 天发布笔记≥3 条且评论互动≥50 次，同时明确 “评论互动” 包含点赞、回复、转发等行为，最终形成《标签口径说明书》归档。

② 分歧处理案例：曾遇到运营同学对 “互动次数” 统计范围有分歧 —— 一方认为仅统计主动发起的评论 / 点赞，另一方认为应包含被动收到的回复。

③ 推动对齐的方法：

• 主动组织小型沟通会，邀请双方运营同学、导师参会；

• 提前准备两种口径的统计结果样例（选取 50 个用户，分别按两种口径计算互动次数），直观展示差异；

• 结合业务应用场景（该标签用于优质用户激励，需聚焦用户主动行为），最终达成共识：仅统计用户主动发起的互动行为，并将共识更新到《标签口径说明书》，同步给所有相关方。

3. 数仓分层（ODS/DWD/DWS/ADS）在你的项目中具体是如何设计的？以你负责的模块为例，说明各层数据表的核心字段、数据来源及加工逻辑。

【解答】

① 项目数仓分层设计核心思路：遵循 “数据逐层清洗、聚合，支撑业务应用” 的原则，ODS 层存原始数据，DWD 层做明细清洗，DWS 层做指标聚合，ADS 层存最终标签结果。

② 以 “用户行为偏好标签” 模块为例：

• ODS 层（原始数据层）：核心表为 ods_user_behavior_log，字段包括 user_id（用户 ID）、behavior_type（行为类型：播放 / 评论 / 收藏）、music_style（音乐风格）、behavior_time（行为时间）、device_id（设备 ID）；数据来源为用户行为埋点日志，按天分区存储，未做任何清洗。

• DWD 层（明细数据层）：核心表为 dwd_user_behavior_detail，基于 ODS 层清洗得到，字段新增 is_valid（是否有效行为：过滤爬虫、测试账号数据）、behavior_duration（行为时长：如播放时长）；加工逻辑：剔除 user_id 为空、behavior_time 异常的数据，补充行为类型枚举说明（如 1 = 播放、2 = 评论）。

• DWS 层（汇总数据层）：核心表为 dws_user_behavior_30d，按 user_id、music_style 分区，字段包括 play_duration（近 30 天播放时长）、interact_count（近 30 天互动次数）；加工逻辑：对 DWD 层数据按用户 + 音乐风格聚合，统计近 30 天的核心行为指标，支撑标签快速计算。

• ADS 层（应用数据层）：核心表为 ads_user_behavior_preference，字段包括 user_id、main_music_style（主导音乐风格）、interact_preference（互动偏好：评论 / 点赞 / 转发）；加工逻辑：基于 DWS 层聚合数据，计算各音乐风格播放时长占比（取占比最高的作为主导风格）、各互动类型次数占比，最终形成用户行为偏好标签。

4. 开发过程中有没有遇到数据质量问题（如数据缺失、重复、不一致）？你是如何发现并解决这些问题的？有没有建立相关的校验规则？

【解答】

① 遇到的核心数据质量问题：在开发 “音乐风格偏好” 标签时，发现 DWD 层日志中约 5% 的记录缺失 music_style 字段，导致部分用户无法计算偏好标签；同时存在少量重复日志（同一用户同一行为被多次记录），影响互动次数统计准确性。

② 发现方式：通过编写数据校验 SQL 脚本，对 DWD 层数据进行抽样检查（统计各字段缺失率、重复率），同时对比小部分用户的标签结果与人工核对结果，发现异常数据。

③ 解决措施：

• 缺失 music_style 字段：与数仓同学沟通，确认是部分老旧埋点未采集该字段，解决方案为：对缺失字段的记录，通过 music_id 关联音乐信息表补充 music_style；无法关联的，标记为 “未知风格”，后续推动埋点优化。

• 重复日志：在 DWD 层清洗阶段增加去重逻辑，按 user_id、behavior_type、behavior_time、device_id 四字段分组去重，保留一条有效记录。

  ④ 校验规则建立：实习期间协助导师搭建了标签数据校验规则，包含 3 类脚本：

• 字段级校验：每日统计各标签涉及字段的缺失率、异常值占比（如 behavior_time 超出合理范围），超过阈值（缺失率＞1%）则触发告警；

• 逻辑级校验：验证标签逻辑一致性（如 “高活跃用户” 标签必须满足 “近 30 天登录≥10 天”，否则视为异常）；

• 结果级校验：抽样对比标签结果与人工标注结果，准确率需≥95%。

5. 项目中使用 SQL 开发时，有没有遇到性能瓶颈？你是如何通过哪些方式优化的？请具体说明优化前后的效果。

【解答】

① 遇到的性能瓶颈：开发 “近 30 天社区互动指标” 聚合脚本时，初期直接对 DWD 层全量日志按 user_id 聚合，单任务执行时间长达 40 分钟，远超预期的 10 分钟，无法满足 T+1 更新需求。

② 优化方式（结合实习生可落地的方法）：

• 分区裁剪：原脚本未指定分区，全量扫描近 30 天数据，优化后通过 WHERE 子句指定 behavior_time 的日期分区，仅扫描目标 30 天的分区数据，减少数据扫描量。

• 预聚合优化：不再直接基于 DWD 层明细数据聚合，而是先基于 DWS 层按天聚合的互动指标表（dws_user_daily_interact），再汇总近 30 天数据，减少重复计算。

• 调整并行度：在 Hive 中设置 set mapred.reduce.tasks=20（原默认 10），增加 reduce 任务数，提升并行处理能力。

  ③ 优化效果：优化后脚本执行时间从 40 分钟缩短至 8 分钟，满足 T+1 更新要求；同时后续同类标签开发复用该优化思路，平均执行效率提升 60%。

6. 你的项目成果是如何落地到业务侧的？有没有配合业务同学进行效果验证？用哪些数据指标证明了项目的业务价值？

【解答】

① 成果落地方式：我开发的 “用户行为偏好标签” 最终同步至网易内部 “猛犸标签画像平台”，按 “音乐偏好”“互动偏好” 二级分组展示；同时编写《标签使用手册》，包含标签含义、查询方式、应用场景，同步给运营同学，并组织 1 场小型培训讲解使用方法。

② 效果验证配合：协助运营同学使用我开发的标签圈选 “国风音乐偏好 + 近 30 天互动频繁” 的用户，开展定向内容推送实验；全程跟进实验数据，统计推送后的点击量、互动率等指标。

③ 业务价值证明（基于实习期间可接触到的数据）：

• 精准推送效果：使用标签定向推送的国风音乐内容，点击量较随机推送提升 35%，互动率（评论 + 点赞）提升 28%；

• 标签复用价值：该标签被 2 个运营组复用，用于 2 场精准运营活动，覆盖用户 10 万 +；

• 效率提升：运营同学圈选目标用户的时间从原来的 1 天缩短至 10 分钟（通过标签平台直接组合筛选）。

7. 实习期间在项目中遇到的最大挑战是什么？你是如何分析并解决的？从这个过程中收获了什么？

【解答】

① 最大挑战：推动 “标签口径对齐”—— 初期运营侧不同小组对 “高活跃社区用户” 的口径有分歧（A 组认为需包含歌单分享行为，B 组认为仅需笔记发布 + 评论），且双方都坚持自己的诉求，导致标签开发停滞。

② 分析与解决过程：

• 第一步：主动梳理双方分歧点，明确核心差异是 “歌单分享是否纳入活跃指标”，同时收集双方的应用场景（A 组用于创作激励，B 组用于内容推送）；

• 第二步：提出折中方案 —— 保留两个版本的标签：“高活跃社区用户（基础版：笔记 + 评论）”“高活跃社区用户（扩展版：笔记 + 评论 + 歌单分享）”，同时补充两个版本的指标定义和适用场景；

• 第三步：组织小范围评审会，邀请导师、数据产品经理参会，从业务价值、开发成本（两个版本开发量仅增加 20%）角度说服双方接受方案；最终达成共识，标签开发顺利推进。

  ③ 收获：

• 沟通能力：学会从 “业务场景” 出发拆解分歧，而非单纯争论对错，用数据和方案推动共识；

• 问题解决思维：遇到矛盾时，优先考虑 “兼容需求” 而非 “二选一”，平衡业务诉求与开发成本；

• 业务认知：理解到不同运营场景对标签口径的需求差异，标签开发需贴合具体业务目标。

8. 如果你重新优化这个项目，你会从哪些方面入手？

【解答】

结合实习期间的观察，从 3 个实习生可落地的角度优化：

① 标签开发效率优化：目前标签开发需逐一生成 SQL 脚本，重复工作量大，可搭建简单的标签模板库（如枚举类标签、聚合类标签模板），后续同类标签可直接复用模板，仅修改参数（如统计周期、阈值），减少重复开发时间。

② 数据质量预警优化：现有校验规则仅触发告警，未形成闭环，优化方向为：增加自动修复逻辑（如少量缺失字段自动补充默认值），同时生成每日数据质量报告，同步给业务方和开发方，明确问题责任人和整改时限。

③ 标签价值评估优化：目前仅通过业务活动效果间接验证标签价值，可增加标签使用率、复用率统计，定期（每月）筛选低使用率标签（使用率＜5%），联合业务方评估是否需要优化或下线，避免标签冗余。

2. 函数与开窗函数专题 📊

Q：用过什么函数？SUM 函数可以开窗吗？

A：常用函数包括聚合函数（SUM/COUNT/AVG）、字符串函数（CONCAT/SUBSTR）、日期函数（DATE_FORMAT/DATEDIFF）、条件函数（CASE WHEN/IF）等；SUM 函数可以开窗，开窗后可实现基于特定窗口的累计求和、分组求和等需求，而非全局聚合。

Q：row_number、rank、dense_rank 的区别？

A：三者均用于排序，核心差异在重复值处理和排序序号连续性：

✅ row_number：不考虑重复值，始终生成唯一连续序号（如 1,2,3,4）；

✅ rank：重复值会占用后续序号，序号不连续（如 1,1,3,4）；

✅ dense_rank：重复值共享同一序号，但后续序号连续（如 1,1,2,3）。

Q：若有三行数据 [100, 200, 300]，sum 开窗默认条件下窗口是多大？会得到什么结果？怎么指定 SQL 开窗函数的窗口大小？

A：① 默认窗口：未指定 PARTITION BY 和 ORDER BY 时，窗口为整个结果集；

② 默认结果：三行数据的 sum 开窗结果均为 600（100+200+300）；

③ 窗口大小指定方式：通过 PARTITION BY（按字段分组划分窗口）、ORDER BY（按字段排序定义窗口内顺序）、窗口框架子句（ROWS/RANGE）精准控制，例如：

• ROWS BETWEEN 1 PRECEDING AND CURRENT ROW（当前行及前 1 行）；

• RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（当前行及之前所有行，默认排序后窗口）。

3. 复杂 SQL 场景题 💻

Q：有 ABC 三列数据，想同时输出 Group by AC、Group by BC 的结果，有什么办法？

A：核心思路是分别计算两个分组结果后合并，常用 3 种方案：

① UNION ALL 拼接：分别写两个 GROUP BY 查询，用 UNION ALL（无去重，效率高）或 UNION（去重，效率低）合并结果；

② 多维度聚合（GROUPING SETS）：使用 GROUP BY GROUPING SETS ((A,C), (B,C))，直接一次性输出两个分组的聚合结果，语法更简洁，效率优于 UNION；

③ CUBE/ROLLUP 扩展：若需更多维度组合，可使用 CUBE (A,B,C)（所有维度组合），但需过滤出目标分组，适用于多维度分析场景。

Q：SQL 实操题（递进式需求）：

① 基础需求：用开窗 count 统计每个用户的行为次数排名；

② 进阶需求：增加子查询打标（如标记行为次数≥10 的用户为 “高频用户”）；

③ 高阶需求：基于打标结果，用 dense_rank 对用户按行为频次等级排序。

💡 应答建议：分步拆解需求，先完成基础开窗统计，再通过子查询 / CTE 添加标签，最后嵌套 dense_rank 排序，注意窗口分区和排序字段的合理性，避免数据冗余。

4. 数据质量与性能优化 🛡️

Q：若某个字段 99% 都是 null，按这个字段分区会发生什么问题？如何解决？

A：① 核心问题：

• 数据倾斜：大量 null 值会集中到一个分区（如 Hive 中 null 会被分配到同一个 reduce 任务），导致该任务执行缓慢，甚至超时；

• 分区无效：分区字段区分度极低，无法实现按分区快速过滤数据，失去分区意义，查询效率低下；

  ② 解决方案：

• 过滤 null 值：若业务无需 null 值数据，查询时直接过滤（WHERE 字段 IS NOT NULL）；

• null 值替换：将 null 值替换为特定默认值（如 “UNKNOWN”），分散到不同分区；

• 调整分区策略：更换区分度高的字段作为分区键（如日期、用户维度）；

• 数据倾斜优化：若必须按该字段分区，可在 Hive 中设置 set hive.optimize.skewjoin=true，或采用随机数打散 null 值后再聚合。

5. 工具与语言基础（Python/Java） 🖥️

Q：写过 UDF 吗？只能用 Java 写吗？

A：写过 UDF（用户自定义函数），用于处理内置函数无法满足的业务需求（如复杂字符串解析、自定义编码转换）；

并非只能用 Java，Python 也可以编写 UDF（如 Hive 的 Python UDF、Spark 的 PySpark UDF），Java 编写的 UDF 性能更优，适用于大数据量场景，Python UDF 开发效率高，适用于快速迭代场景。

Q：在 Python 里如何创建字典对象？

A：常用 3 种方式：

① 直接赋值：dict1 = {"name": "zhangsan", "age": 25}；

② 字典构造函数：dict1 = dict (name="zhangsan", age=25) 或 dict1 = dict ([("name", "zhangsan"), ("age", 25)])；

③ collections 模块：使用 defaultdict（带默认值的字典），如 from collections import defaultdict，dict1 = defaultdict (int)（默认值为 0）。

Q：defaultdict (int) 和 defaultdict (list) 有什么区别？

A：核心区别在于默认值类型不同，适配不同场景：

• defaultdict (int)：默认值为 int 类型的 0，适用于计数统计（如统计单词出现次数）；

• defaultdict (list)：默认值为空列表 []，适用于分组聚合（如将相同 key 的 value 收集到列表中）。

Q：如何取出字典中的 value 值？有哪几种方法？

A：常用 4 种方法：

① dict.values ()：返回所有 value 的视图对象（可迭代，不占用额外内存），需转成列表用 list (dict.values ())；

② 遍历 key 取 value：for key in dict: print (dict [key])（若 key 不存在会报错）；

③ dict.get (key)：安全取 value，key 不存在返回 None，可指定默认值（如 dict.get (key, 0)）；

④ 遍历 items ()：for key, value in dict.items (): print (value)（同时获取 key 和 value，灵活度高）。