一面（8.27）

• 实习内容

还在职吗

实习期间主要干什么

和你对接的同学有哪些

产运和算法同学怎么使用你产出的数据

数据集底层用什么技术栈

你写SQL任务的时候是怎么优化代码的，写代码的时候哪些地方需要注意

有自己搭建过看板吗

知道SLA基线吗，有主动了解过吗

• 大数据技术问题

一个spark任务怎么优化

发现写好的spark任务运行的很慢要怎么办

数据倾斜怎么处理

如果任务在读文件的时候运行很慢怎么办

内存利用率过低怎么办

CPU利用率过低怎么办

你经常用的spark参数还有哪些

• SQL

复制代码

这个SQL写完的结果数据量会变多吗

作者：达不溜季

链接：

https://www.nowcoder.com/discuss/792430168466870272?sourceSSR=search

来源：牛客网

一、基础工作与协作相关问题

1. 还在职吗？

• 考察知识点：求职状态真实性、空窗期价值转化、到岗灵活性（企业关注能否快速衔接工作）。
• 参考回答：目前处于离职状态，上一份数据开发工作结束后，我用1个月时间做了两件事：一是复盘了之前遇到的Spark数据倾斜和Flink CDC同步问题，整理成技术文档；二是学习了ClickHouse的列式存储优化（因为了解到贵公司涉及高频查询场景）。现在时间完全灵活，若拿到offer，可在1周内到岗，且能快速接手核心任务（比如数仓建模或实时同步）。
• 回答注意要点：
  • 要体现“主动成长”（如复盘问题、学习新技能），；
  • 主动关联“岗位需求”（如提到ClickHouse适配高频查询），展示求职针对性；
  • 到岗时间明确，减少企业沟通成本。

2. 实习期间主要干什么？

• 考察知识点：实习工作与岗位的匹配度、技术落地能力（从需求到结果的闭环）、业务价值贡献（数据如何支撑决策）。
• 参考回答：我在某电商公司（主营3C产品，类似京东）数据开发岗实习6个月，归属“618大促数据支撑团队”，核心目标是搭建实时用户行为看板，帮助运营实时调整大促投放策略。具体做了3件核心事，每件都有明确的问题和成果：
  1. 实时数据同步（Flink CDC）：
     • 背景：运营需要“用户点击商品后5分钟内看到实时转化”，但之前MySQL订单表同步到ES要30分钟，延迟太高；
     • 动作：用Flink CDC同步MySQL订单表（每日峰值2000万条），优化两点：① 调整binlog消费位点（从最新位点改为延迟10秒，避免主库压力）；② 增加并行度（从4→8），拆分热点商品ID（如“iPhone 15”单独分2个并行任务）；
     • 成果：同步延迟从30分钟→3秒，大促期间支撑了“实时商品点击-支付漏斗”看板，运营根据数据关停了3个低效广告位，节省成本20万。
  2. 数仓DWD层建模（用户行为表）：
     • 背景：用户行为日志（APP/PC/小程序）分散在3个Topic，运营要分析“跨端用户行为”需手动拼接数据，效率低；
     • 动作：用Spark SQL清洗日志，做3件事：① 去重（过滤1秒内重复点击，占比12%）；② 补全（用设备ID关联用户ID，补全率85%）；③ 统一字段（将3端的“点击时间”统一为“yyyy-MM-dd HH:mm:ss”），产出DWD层dwd_user_behavior_all表；
     • 成果：运营分析跨端行为的时间从2小时→10分钟，基于该表发现“小程序用户加购后，30%会在PC端支付”，针对性做了“小程序加购→PC端优惠券”推送，转化率提升12%。
  3. 数据问题应急处理：
     • 背景：大促前1天，发现用户行为表数据量骤降50%，运营急等数据做最终投放调整；
     • 动作：① 查Flink任务日志，发现是Kafka Topic分区副本同步失败；② 协调运维重启Kafka broker，同时用前1小时的历史数据临时补全；③ 后续加了“数据量监控脚本”（Python写的，每10分钟检查一次，低于阈值发企业微信告警）；
     • 成果：15分钟内恢复数据，没影响大促准备，后续6个月数据任务零事故。
• 回答注意要点：
  • 每个工作都要有“业务背景（为什么要做）→技术动作（具体怎么做，含参数/代码片段）→量化成果（对业务的价值）”，避免“干巴巴列任务”；
  • 补充“应急处理”，体现抗压能力和问题解决思维；
  • 结合行业特性（如电商大促），让经历更真实。

3. 和你对接的同学有哪些？

• 考察知识点：跨角色协作的场景化能力、沟通效率（如何对齐需求/解决冲突）、责任边界意识。
• 参考回答：实习期间对接4类角色，每个角色的协作场景和沟通重点都不同，举3个核心例子：
  1. 同组数据开发（李同学）：
     • 协作场景：一起搭建大促数仓DWS层，他负责“商品维度表”，我负责“用户行为表”，需要关联生成“用户-商品偏好表”；
     • 沟通重点：① 每天10点同步表结构（用飞书文档共享，明确字段类型和注释，如“user_level：1-普通，2-会员”）；② 联调时发现“商品ID字段名不一致”（他用goods_id，我用product_id），当天协商统一为goods_id，避免后续关联错误；
     • 结果：2周内完成联调，产出的表支撑了5个大促核心报表。
  2. 运营同学（张同学）：
     • 协作场景：他提“实时商品加购率看板”需求，需要“按品牌+价格段拆分数据”；
     • 沟通重点：① 先确认指标定义（“加购率=加购数/点击数，点击数排除无效点击”）；② 确认更新频率（“每5分钟刷新一次”）；③ 交付后教他“如何看异常数据”（如“某品牌加购率突降，先查是否有库存为0的商品”）；
     • 结果：看板上线后，他每周反馈1次优化建议（如“增加‘地域’维度”），我们迭代了3个版本，成为大促核心监控工具。
  3. 算法同学（王同学）：
     • 协作场景：他需要“用户近7天点击商品序列”做推荐模型训练，要求“Parquet格式，按user_id分桶，每天凌晨5点前输出到HDFS”；
     • 沟通重点：① 确认数据格式细节（“user_id为string，商品序列为array<string>，分100个桶”）；② 同步数据质量标准（“缺失率≤0.1%”）；③ 他发现“部分用户序列为空”，我们一起排查出是日志清洗时过滤了“未登录用户”，后续保留该部分数据并标注“is_login=0”；
     • 结果：数据按时交付率100%，模型上线后商品推荐点击率提升18%。
• 回答注意要点：
  • 每个角色都举“具体协作场景+沟通细节+结果”，体现“不是简单对接，而是解决问题”；
  • 补充“需求对齐”和“问题排查”的沟通细节，展示协作能力；
  • 关联业务目标（如推荐模型、大促报表），说明协作的价值。

4. 产运和算法同学怎么使用你产出的数据？

• 考察知识点：数据的业务落地路径（从数据到决策/模型的闭环）、对下游需求的理解深度、数据价值量化。
• 参考回答：产运和算法同学的使用场景差异很大，核心是“产运靠数据做运营决策，算法靠数据做模型训练”，举具体例子：
  1. 产运同学（以大促运营为例）：
     • 用什么数据：主要用ADS层的“实时看板数据”和“离线报表数据”，比如① 实时看板（我搭建的“商品点击-加购-支付漏斗”，每5分钟刷新）；② 离线报表（每日“各渠道新客转化表”“用户分层表”）；
     • 怎么用：① 实时调策略：大促当天，发现“抖音渠道点击量高但加购率低（仅5%，低于平均12%）”，运营立即调整广告素材（从“价格优惠”改为“现货速发”），1小时后加购率升至10%；② 离线做复盘：大促后，用“用户分层表”（我按RFM模型分的“核心用户/流失预警用户”），对流失预警用户发“专属优惠券”，召回率提升8%；
     • 依赖我的支持：① 看板数据异常时，我帮他们查数据链路（如“支付数突降，查是否是订单表同步延迟”）；② 临时需求（如“查‘学生用户’的消费偏好”），我从DWS层表快速提取数据，1小时内交付。
  2. 算法同学（以推荐算法为例）：
     • 用什么数据：主要用DWS层的“特征数据”和ODS层的“原始日志”，比如① 特征数据（我产出的“user_behavior_features”表，含“近7天点击商品数”“平均点击时长”等12个特征）；② 原始日志（APP点击日志，用于模型冷启动）；
     • 怎么用：① 训练模型：将特征数据输入LR模型，训练“商品推荐评分模型”，我的数据负责“用户兴趣表征”；② 模型评估：他们发现“推荐准确率低”，我们一起排查出“特征中的‘点击时长’有异常值（部分为0）”，我优化了清洗逻辑（过滤时长<1秒的数据），准确率提升15%；③ 模型部署：实时推荐时，他们通过Spark SQL Gateway调用我产出的“实时特征表”（每秒1000+查询），我协助做了表索引优化（按user_id分桶），查询延迟从200ms→50ms；
     • 依赖我的支持：① 保证特征数据的时效性（每天5点前交付，从未延迟）；② 配合他们做数据增强（如增加“用户浏览深度”特征）。
• 回答注意要点：
  • 分角色说“用什么数据+具体使用场景（含决策/模型细节）+你的支持动作”，体现数据的“端到端价值”；
  • 补充“数据问题协同排查”，展示跨团队协作能力；
  • 量化效果（如“召回率提升8%”“准确率提升15%”），避免泛泛而谈。

5. 数据集底层用什么技术栈？

• 考察知识点：大数据技术栈的系统性认知（各组件的分工与协同）、技术选型逻辑（为什么用A不用B）、实际部署细节。
• 参考回答：我们数据集底层用的是“Apache Hadoop生态+部分云原生组件”，按“数据流转链路”分工，每个组件都有明确的用途和选型原因：
  1. 数据采集层：
     • 组件：Flume（采集APP/PC日志）、Flink CDC（同步MySQL业务库）、Kafka（日志/CDC数据的临时存储）；
     • 选型原因：① Flume支持多源采集（APP日志从TCP端口，PC日志从文件），且能做简单清洗（如过滤空行）；② Flink CDC比Canal好的地方是“支持Exactly-Once语义”，避免数据重复（大促期间订单数据不能重复统计）；③ Kafka用3节点集群，每个Topic分10个分区（按“业务线”分，如“order_topic”“user_topic”），副本数2（保证高可用）；
     • 部署细节：Flume Agent部署在每台APP服务器上，Kafka集群用SSD磁盘（提升写入速度，峰值每秒2万条）。
  2. 数据存储层：
     • 组件：HDFS（存原始数据和数仓表）、Hive（管理数仓分层，ODS/DWD/DWS/ADS）、ClickHouse（存高频查询的实时看板数据）；
     • 选型原因：① HDFS适合存大文件（我们单表最大1TB，HDFS的块大小设为256MB，提升读取效率）；② Hive支持SQL，方便数仓建模（我们用Hive 3.x，开启了ACID特性，支持数据更新）；③ ClickHouse比Hive快的地方是“列式存储+主键索引”，实时看板查询（如“查某品牌近1小时的加购数”）能从5秒→100ms；
     • 部署细节：HDFS用5节点集群（1个NameNode，4个DataNode），ClickHouse用3节点集群（分片+副本，每个分片对应1个HDFS目录）。
  3. 数据计算层：
     • 组件：Spark（离线计算，如数仓建模）、Flink（实时计算，如CDC同步、实时特征）；
     • 选型原因：① Spark适合批量处理（我们每天凌晨跑的离线任务，数据量100TB+，Spark的动态资源分配能节省30%内存）；② Flink适合流处理（支持事件时间窗口，能处理延迟数据，大促期间用户行为数据延迟最高5分钟，Flink的水印机制能准确统计）；
     • 部署细节：Spark用YARN集群模式，每个任务的Executor内存设为8G（根据单任务数据量估算），Flink用K8s部署（方便扩缩容，大促时从10个TaskManager→50个）。
  4. 调度与管理层：
     • 组件：Airflow（离线任务调度）、Prometheus+Grafana（监控）、Atlas（元数据管理）；
     • 选型原因：① Airflow支持复杂的任务依赖（如“DWD层任务跑完→DWS层任务才能跑”），且能可视化任务流；② Prometheus监控Spark/Flink的CPU/内存利用率，Grafana做告警面板（如“CPU利用率>80%告警”）；③ Atlas记录数据血缘（如“ADS层报表表→DWS层聚合表→DWD层明细表”），方便排查数据问题（如报表错了，能快速定位到哪个环节出问题）；
     • 部署细节：Airflow用Docker部署，每天调度200+任务，Atlas与Hive元数据同步（每小时同步一次）。
• 回答注意要点：
  • 按“数据流转链路”分类，每个组件说明“用途+选型原因（对比其他组件）+部署细节（参数/节点数）”，体现技术栈的“合理性”；
  • 结合业务场景（如大促、实时看板）说明选型的必要性；
  • 避免只列组件名称，要讲“为什么用”和“怎么用”。

6. 写SQL任务的时候是怎么优化代码的？写代码的时候哪些地方需要注意？

• 考察知识点：SQL优化的系统性思路（从执行计划到语法细节）、代码规范（可维护性）、数据准确性保障（避免业务错误）。
• 参考回答：我优化SQL的核心思路是“减少数据扫描量→优化执行计划→避免资源浪费”，结合实际案例说明；写代码时会重点关注“准确性、可维护性、性能风险”：一、SQL优化方法（以Hive SQL为例，优化“大促用户消费金额统计”任务）二、写SQL时的注意事项（3个核心点）