1. 虾皮数开面试核心考察方向解析
虾皮(Shopee)作为东南亚领先的电商平台,其数据开发岗位的面试题往往聚焦于实际业务场景中的数据处理能力。根据近期参与面试的候选人反馈,技术考察主要分为三个维度:SQL编写优化(占比约40%)、大数据组件原理(占比35%)、业务场景设计(占比25%)。这种权重分配反映出企业对候选人"既懂工具原理,又能解决实际问题"的复合型要求。
我接触过的多位面试官透露,他们特别注重候选人对Hive执行计划的理解深度。一个典型的考核方式是给出一个包含5张表的复杂关联查询,要求先手写SQL实现,再解释如何通过查看执行计划来优化查询性能。这需要候选人掌握
EXPLAIN EXTENDED
命令的使用,并能准确识别出执行计划中的
Map Join
是否生效、
Reduce
阶段是否存在数据倾斜等关键问题。
重要提示:虾皮面试中约70%的SQL题会涉及窗口函数的高级应用,如
ROW_NUMBER()去重、LAG/LEAD计算环比等,建议重点准备Tumbling Window和Sliding Window的场景实现。
2. 高频SQL题型与破解技巧
2.1 多维度聚合查询实战
去年春招中出现频率最高的是一道订单分析题:给定orders(订单表)、users(用户表)、products(商品表)三张表,要求计算每个用户购买金额的前三名商品类目。标准解法如下:
WITH user_category_spend AS (
SELECT
u.user_id,
p.category,
SUM(o.amount) AS total_spend,
ROW_NUMBER() OVER(PARTITION BY u.user_id ORDER BY SUM(o.amount) DESC) AS rank
FROM orders o
JOIN users u ON o.user_id = u.user_id
JOIN products p ON o.product_id = p.product_id
GROUP BY u.user_id, p.category
)
SELECT
user_id,
category,
total_spend
FROM user_category_spend
WHERE rank <= 3;
这个查询有三个优化关键点:
- 使用CTE提高可读性,避免嵌套子查询
- 在JOIN前先对orders表按user_id做过滤(如有条件)
-
确保
products.category字段有索引
2.2 数据倾斜处理方案
在笔试题中常遇到需要处理
skew join
的情况。例如统计不同价格区间的商品销量时,低价商品往往占据绝大多数。此时应该:
-- 原始写法(存在倾斜)
SELECT
CASE
WHEN price < 10 THEN '0-10'
WHEN price < 50 THEN '10-50'
ELSE '50+'
END AS price_range,
COUNT(*) AS sales
FROM products
GROUP BY 1;
-- 优化方案
SET hive.groupby.skewindata=true; -- 启用倾斜优化
SELECT /*+ MAPJOIN(small_table) */ ... -- 对小表使用mapjoin
实际面试中,可能会要求手写UDF解决特殊倾斜场景。我曾遇到一个案例:需要统计用户最长连续登录天数,其中包含大量非活跃用户。解决方案是先用
distribute by
将数据打散,再在reduce端用
java.util.Stack
实现连续天数计算。
3. 大数据组件原理深度问诊
3.1 HDFS读写流程的陷阱问题
面试官常以"请描述HDFS写文件流程"作为开场问题,但会针对以下细节进行追问:
- 当DataNode在pipeline传输过程中宕机时,客户端如何恢复?
- 为什么HDFS不适合存储大量小文件?(要从NameNode内存模型和MapTask生成量两个角度回答)
-
如果设置
dfs.replication=3但集群只有2个节点,实际副本数是多少?
一个让面试官眼前一亮的回答模板:
"在写入流程中,客户端通过
DistributedFileSystem.create()
获取
FSDataOutputStream
时,会经历三个关键阶段:1)NN检查元数据并分配block;2)DN建立pipeline;3)数据以chunk为单位传输。特别需要注意的是,当pipeline中断时,客户端会根据
dfs.client.block.write.replace-datanode-on-failure.policy
策略选择新的DN,这个参数默认是DEFAULT,意味着..."
3.2 Spark内存管理实战
虾皮的大数据栈重度依赖Spark,内存相关问题出现概率极高。需要准备以下知识点:
-
spark.memory.fraction(默认0.6)中storage和execution内存的动态划分机制 -
当出现
Container killed by YARN for exceeding memory limits时的排查路径 - Tungsten引擎如何优化内存访问(包括堆外内存和二进制格式)
我曾被问到一个经典问题:"假设一个Spark应用配置了
--executor-memory 10G
,但实际使用中频繁发生OOM,应该如何调整参数?" 标准回答应包含:
-
确认
spark.memory.fraction是否合理 -
检查
spark.memory.offHeap.enabled是否开启 - 分析GC日志判断是否内存泄漏
-
考虑增加
spark.executor.memoryOverhead
4. 业务场景设计方法论
4.1 实时数仓设计题
最近一次春招中出现的设计题是:"如何构建虾皮直播间的实时人气值计算系统?" 需要分层次回答:
- 数据采集层 :用Flume收集客户端埋点数据,通过Kafka分区保证同一直播间消息有序
-
实时处理层
:
-
使用Flink的
KeyedProcessFunction维护每个直播间的观看人数状态 -
通过
WindowOperator实现滑动窗口(如5分钟)的点赞数统计
-
使用Flink的
-
数据服务层
:
- 将计算结果写入Redis的SortedSet(按人气值排序)
- 用HBase存储详细指标供后续分析
关键点在于说明如何解决热点直播间问题(如明星带货时)。我的方案是采用
localKeyBy
预处理+两级聚合:
dataStream
.map(record -> (record.roomId % 1000, record)) // 第一层打散
.keyBy(_._1)
.process(new LocalAggregator()) // 本地聚合
.keyBy(record -> record.roomId)
.window(TumblingEventTimeWindows.of(Time.seconds(5)))
.aggregate(new GlobalAggregator()); // 全局聚合
4.2 数据治理案例分析
另一个高频场景是数据质量监控。当被问到"如何发现订单表的数据异常"时,应该建立完整的监控体系:
- 波动检测 :基于时间序列预测(如Prophet算法)建立销售额的置信区间
-
规则引擎
:
# 使用Great Expectations库定义校验规则 validator.expect_column_values_to_be_between( "order_amount", min_value=0, max_value=1000000 # 防羊毛党设置上限 ) - 血缘追踪 :当核心指标异常时,沿血缘关系逐层下钻分析
5. 面试中的隐藏考察点
5.1 代码风格与异常处理
在笔试环节,90%的候选人能写出正确的SQL逻辑,但只有不到30%会注意以下细节:
-
为表别名设置合理的命名(如
ord代替o) - 显式指定JOIN类型(避免隐式内连接)
-
添加必要的
COMMENT说明复杂逻辑 -
包含
TRY_CATCH处理除零错误等异常
一个真实的扣分案例:在计算转化率时直接写
click_count / order_count
而没有处理
order_count=0
的情况,这种疏忽可能导致整个作业失败。
5.2 资源估算能力
面试官曾给出这样的问题:"假设虾皮印尼站每日订单量1亿,每条订单记录约2KB,请设计Hive表分区方案并估算存储需求。" 标准回答应包含:
-
按日期双分区:
dt=yyyy-mm-dd/hour=HH - 采用ORC格式+SNAPPY压缩(压缩比约4:1)
-
存储量计算:
1e8 records/day * 2KB / 4 = 50GB/day 保留90天需:50 * 90 = 4.5TB -
考虑增加
order_status作为静态分区过滤条件
6. 备战建议与学习路线
根据通过面试的候选人经验,建议按以下优先级准备:
-
SQL强化 (2周):
- 精通《Hive编程指南》中的窗口函数章节
- 在LeetCode上刷"困难"级别的数据库题目
-
练习解析
EXPLAIN输出结果
-
Spark调优 (1周):
- 掌握Spark UI各项指标含义
-
复现并解决
Data skew、Small file problem等经典问题 - 阅读Tuning Guide官方文档
-
业务思维 (持续):
- 研究电商行业指标体系(GMV、转化率、复购率等)
- 思考如何用数据解决实际问题(如:如何降低购物车放弃率)
一个有效的训练方法是:在本地搭建伪分布式集群,用TPC-DS数据集模拟真实场景。例如尝试在8GB内存限制下完成10亿级数据的JOIN操作,这种实战经验能让面试官眼前一亮。

365

被折叠的 条评论
为什么被折叠?



