1. 自我介绍
2. 挑一段你觉得收获最大的实习经历聊聊吧。比如当时做的业务是什么，技术用在了什么场景，最后有没有一些具体的指标来衡量效果？
3. 我们来聊聊数仓吧，为什么要对数据仓库进行分层设计？
4. Hive里的视图（View）用过吗？它主要是解决什么问题的？
5. Hive的分区和分桶，能讲讲它俩的区别和各自的应用场景吗？
6. 能详细说说Spark的shuffle过程吗？
7. 在之前的工作中，有没有碰到过什么让你印象深刻的性能优化案例？
8. 大数据处理中常说的数据倾斜，一般是什么原因造成的？你都知道有哪些解决方法？
9. 编程语言这块，你比较熟悉哪些？
10. MySQL索引的底层原理是什么？能展开讲讲吗？
11. 数据库和数据仓库，它俩的核心区别是什么？分别适合用在什么样的业务场景里？
12. 算法题：写一个二分查找。
13. SQL题：写一条SQL，用窗口函数找出连续登录N天的用户。

来源：牛客网

1. 自我介绍

考察知识点

• 自我认知与岗位匹配度（技能、经历、目标与岗位的契合性）
• 表达逻辑性（能否简洁突出核心信息，避免流水账）

参考回答

我是XX大学数据科学专业毕业生，有6个月电商数据开发实习经验，核心聚焦数据仓库搭建与实时数据链路优化，熟练掌握Hadoop生态（Hive/Spark/Flink/Kafka）、SQL优化及维度建模。

实习期间主导过两个核心项目：一是「用户行为数仓DWS层重构」，针对原宽表冗余字段多、查询效率低的问题，按“用户-商品-渠道”主题拆分宽表，通过分桶（user_id分100桶）+分区（按dt分天）优化，将运营报表查询时间从2小时压缩至15分钟；二是「实时GMV监控系统」，用Flink CDC同步订单数据，通过“热点key加盐”解决数据倾斜，延迟从5分钟降至100ms，支撑618大促实时决策。

职业规划上，希望深耕零售行业大数据开发，贵司在实时数仓与数据治理的布局和我的技术方向高度契合，期待能为团队落地高效数据解决方案。

补充注意要点

• 控制在1-2分钟，按“教育→核心技能→代表性项目（问题+动作+结果）→职业目标”结构；
• 用数据量化成果（如“2小时→15分钟”），避免空泛描述；
• 结尾关联公司业务，体现求职针对性。

2. 挑一段你觉得收获最大的实习经历聊聊（业务、技术场景、效果指标）

考察知识点

• 项目全流程参与度（需求拆解→开发→上线→复盘）
• 技术与业务的结合能力
• 结果导向思维（量化成果）

参考回答

收获最大的是「财务报表自动化」项目，彻底解决了财务团队“手工制表效率低、数据易出错”的痛点：

• 业务背景：原财务月度利润表、部门费用表需人工从SAP系统导出数据，用Excel合并计算，耗时3天，且因公式错误导致数据差异率达5%，影响成本管控决策。业务目标：实现报表自动生成，差异率<0.1%，耗时<1小时。
• 技术应用场景：
  1. 数据同步层：用Sqoop批量同步SAP的科目表、凭证表至Hive ODS层（按dt分区，保留原始字段）；用Debezium捕获实时支付数据（Kafka传输），确保数据完整性。
  2. 清洗建模层：在Hive DWD层做标准化处理——① 过滤无效数据（金额<0、凭证号为空）；② 关联科目字典表（补充“编码→名称”映射，如“1001→库存现金”）；③ 脱敏敏感字段（供应商银行账户AES加密）。
  3. 汇总输出层：用Spark SQL构建DWS汇总表（按“部门+月份+科目”聚合收入/成本/费用），通过Superset配置可视化报表，设置自动刷新（每日凌晨生成数据，每月5号出月度报表）。
• 效果指标：
  • 效率：报表生成时间从3天→40分钟，财务人力成本降低60%；
  • 准确性：数据差异率从5%→0.08%，连续6个月零错误；
  • 业务价值：帮助快速定位超预算部门（如市场部Q3广告超支20%），及时调整策略，节省成本150万。

这次经历让我明白“数据开发需紧贴业务”，也提升了跨团队协作能力（频繁与财务、IT对齐口径）。

补充注意要点

• 按“业务痛点→技术方案（分阶段）→量化效果”逻辑，突出自己的核心动作；
• 关联业务价值（如“节省成本”），而非仅谈技术实现；
• 提及个人成长（如协作能力），体现复盘意识。

3. 为什么要对数据仓库进行分层设计？

考察知识点

• 数仓分层的核心价值（解耦、复用、性能等）
• 分层与业务迭代的关系

参考回答

数仓分层（ODS→DWD→DWS→ADS）的核心是**“解耦数据链路、提升复用性、优化性能、降低维护成本”**，具体原因如下：

1. 解耦数据生产与消费，适配业务快速迭代业务需求常变（如新增“渠道转化分析”），若不分层，每次需重复编写清洗、关联逻辑；分层后，DWD层提供“干净的明细数据”，DWS层提供“主题化汇总数据”，新增需求可直接基于上层开发（如渠道分析只需在DWS按渠道聚合），无需修改底层，迭代效率提升50%。
2. 提升数据复用性，减少重复计算例如，用户行为日志在DWD层清洗后，可同时支撑“用户日活”“商品点击TOP10”“渠道转化”等多个DWS指标，避免每个指标单独清洗原始数据，计算资源节省40%以上。
3. 优化查询性能，降低IO开销上层应用（如ADS报表）无需扫描全量原始数据：DWS层已聚合（数据量比ODS减少80%），且支持分区（按dt分天）、分桶（按user_id分桶），复杂报表查询从小时级→分钟级。
4. 便于问题定位与数据追溯若ADS报表GMV异常，可按“ADS→DWS→DWD→ODS”逐层排查：先查DWS汇总数据，再查DWD明细清洗是否有误，最后查ODS原始数据是否同步异常，避免全链路盲查。
5. 保障数据质量与合规性在DWD层集中做清洗（过滤异常值）、脱敏（隐藏手机号），确保下游所有应用使用“干净、合规的数据”，避免敏感信息泄露。

补充注意要点

• 结合实际案例（如“新增需求迭代效率”），避免纯理论；
• 突出分层的“业务价值”（如合规、迭代快），而非仅谈技术优势；
• 强调“分层是为了让数据链路更可控”，体现系统性思维。

4. Hive里的视图（View）用过吗？它主要是解决什么问题的？

考察知识点

• Hive视图的核心特性（虚拟表、无存储）
• 视图的实际应用场景（简化查询、权限控制等）

参考回答

用过，Hive视图是基于SQL查询结果创建的虚拟表，仅存储查询逻辑，不实际存储数据（查询时动态执行逻辑），主要解决以下问题：

1. 适配业务逻辑变更，减少修改成本若底层表结构变更（如order_dwd新增“支付方式”字段），只需修改视图的查询逻辑，上层应用（如报表）无需调整，实现“一处修改，多处复用”。

控制数据访问权限，保障数据安全若需向第三方提供部分数据（如仅展示用户消费金额，隐藏手机号），可通过视图过滤敏感字段，避免直接暴露基础表：

-- 视图仅包含非敏感字段
CREATE VIEW user_consume_public AS
SELECT user_id, total_consume FROM user_consume_30d;

第三方仅能访问视图，无法查看基础表的敏感信息。

简化复杂查询，降低使用门槛复杂业务场景（如多表关联+聚合）的SQL往往长达数百行（如“用户近30天消费+会员等级+商品分类分析”），普通用户（如运营）难以直接编写。通过视图封装逻辑：

-- 创建视图，封装多表关联逻辑
CREATE VIEW user_consume_30d AS
SELECT u.user_id, u.member_level, g.category, SUM(o.amount) AS total_consume
FROM order_dwd o
JOIN user_dim u ON o.user_id = u.user_id
JOIN goods_dim g ON o.goods_id = g.goods_id
WHERE o.dt BETWEEN DATE_SUB(CURRENT_DATE(), 30) AND CURRENT_DATE()
GROUP BY u.user_id, u.member_level, g.category;

运营只需执行SELECT * FROM user_consume_30d WHERE member_level='VIP'即可，无需关注底层关联逻辑。

补充注意要点

• 强调视图“无实际存储”的特性，区别于表；
• 结合具体SQL示例，体现实操性；
• 说明视图的局限性（如无法创建索引、复杂视图查询效率低），体现全面认知。

5. Hive的分区和分桶，能讲讲它俩的区别和各自的应用场景吗？

考察知识点

• 分区与分桶的核心原理（数据划分逻辑）
• 适用场景的差异（基于业务维度vs数据分布）

参考回答

Hive的分区和分桶均用于“优化查询效率，减少扫描数据量”，但核心逻辑和应用场景差异显著：

应用场景

1. 分区的典型场景：
   • 按时间分区：日志表（dt=20240901）、订单表（month=202409），查询“2024年9月订单”时，仅扫描month=202409的分区，避免扫描全年数据；
   • 按地区分区：用户表（region=华北），查询“华北地区用户”时，仅扫描对应分区。