一、初级岗（0-2 年）：基础实操类

真题 1：Hive 中如何解决数据倾斜问题？请写出具体优化代码并说明原理。

解析 + 答题模板：数据倾斜是 Hive 中最常见的性能问题，核心原因是数据分布不均，导致某一个或几个 Reduce 任务执行时间过长。完整解决方案分 5 步：

1. 源头优化：数据预处理，避免大表与小表 join 时的倾斜
2. 参数调优：开启 MapJoin、调整 Reduce 任务数
3. SQL 优化：大表加盐、小表广播、分区裁剪
4. 数据模型优化：分桶、分区设计
5. 监控预警：实时监控任务执行状态，提前发现倾斜

代码块示例（必背实操）

sql

-- Hive数据倾斜优化：大表加盐+小表广播
-- 场景：用户表（大表）与订单表（小表）join时，用户表数据倾斜
SET hive.auto.convert.join=true; -- 开启自动MapJoin
SET hive.optimize.skewjoin=true; -- 开启倾斜join优化
SET hive.skewjoin.key=100000; -- 超过10万条记录视为倾斜

-- 大表加盐
WITH user_salt AS (
SELECT
        user_id,
        user_name,
FLOOR(RAND()*5) ASsalt-- 加盐0-4，分散数据
FROM ods.user_info
),
-- 小表扩容（与大表盐值对应）
order_expand AS (
SELECT
        order_id,
        user_id,
        order_amount,
salt
FROM ods.order_detail
LATERALVIEWexplode(array(0,1,2,3,4)) tmp ASsalt
)
-- 加盐后join，解决倾斜
SELECT
    u.user_id,
    u.user_name,
    o.order_id,
    o.order_amount
FROM user_salt u
JOIN order_expand o ON u.user_id = o.user_id AND u.salt = o.salt;

真题 2：用 Spark 写出 WordCount 的三种实现方式，说明各自优缺点及适用场景

python

运行

# Spark WordCount三种实现方式
from pyspark import SparkContext

sc = SparkContext("local", "WordCountExample")
text_rdd = sc.textFile("hdfs:///user/input/text.txt")

# 方式1：基础版（简单直观，适合入门）
word_count1 = text_rdd.flatMap(lambda line: line.split(" ")) \
                     .map(lambda word: (word, 1)) \
                     .reduceByKey(lambda a, b: a + b)
print("基础版结果：", word_count1.collect())

# 方式2：优化版（使用combiner，减少shuffle数据量）
word_count2 = text_rdd.flatMap(lambda line: line.split(" ")) \
                     .map(lambda word: (word, 1)) \
                     .combineByKey(
lambda x: x,  # 初始化值
lambda a, b: a + b,  # 分区内聚合
lambda a, b: a + b   # 分区间聚合
                     )
print("优化版结果：", word_count2.collect())

# 方式3：高级版（使用countByValue，适合小数据量快速统计）
word_count3 = text_rdd.flatMap(lambda line: line.split(" ")) \
                     .countByValue()
print("高级版结果：", dict(word_count3))

# 优缺点对比
# 方式1：优点-简单易写；缺点-shuffle数据量大，适合小数据量
# 方式2：优点-减少shuffle数据量，性能更优；缺点-代码稍复杂，适合大数据量
# 方式3：优点-一行代码完成，速度快；缺点-结果在Driver端，不适合超大数据量

二、中级岗（3-5 年）：性能调优类

真题：公司实时计算任务（Flink）延迟从 5 秒飙升至 30 秒，影响业务实时决策，你的完整处理流程是什么？

解析 + 答题模板（STAR 法则）：

S（情境）：公司电商实时销量统计任务（基于 Flink 1.14）突发延迟，从 5 秒飙升至 30 秒，大促期间影响运营实时调整营销策略，排查发现 Kafka 消息积压严重，Flink TaskManager 堆内存使用率达 90%。

T（任务）：我作为实时计算负责人，需在最短时间内定位延迟原因、恢复任务性能，同时制定长效优化方案，避免大促期间再次出现问题。

A（行动）：

1. 紧急排查：通过 Flink UI 查看 TaskManager 状态，发现窗口函数（10 分钟滚动窗口）存在数据倾斜，某热点商品的销量数据占比达 70%；查看 Kafka 消费者 offset，发现消费速度低于生产速度。
2. 临时修复：调整 Flink 并行度（从 8 提升至 16），对热点商品数据单独分流处理（加盐打散）；增加 TaskManager 堆内存（从 4G 提升至 8G），开启增量 checkpoint。
3. 根本优化：重构窗口计算逻辑，将滚动窗口改为滑动窗口（步长 1 分钟）；使用 Flink SQL 的 TOP N 函数替代全量聚合，减少计算压力；优化 Kafka 消费者参数（增加 fetch.max.bytes），提升消费速度。
4. R（结果）：20 分钟内完成延迟修复，任务延迟恢复至 3 秒内；大促期间稳定运行，支撑实时销量统计准确率 100%；后续通过全链路压测，将任务最大承载能力提升 3 倍。

三、高级岗（5 年 +）：架构设计类

真题：请为金融风控平台设计一套高可用、高可靠的大数据架构，说明设计原则及核心组件选型。

解析 + 答题模板：设计核心原则：遵循 “数据安全优先、实时性保障、可扩展性、成本可控”，覆盖数据采集、存储、计算、服务全链路。

整体架构分五层设计：

1. 数据采集层：采用 Kafka+Flume 组合，Kafka 负责实时数据（交易日志、用户行为）采集，Flume 负责离线数据（历史交易、用户画像）采集，确保数据不丢失。
2. 数据存储层：实时数据用 HBase 存储（低延迟查询），离线数据用 HDFS+Parquet 存储（高压缩比、低成本），核心风控数据用 TiDB 存储（事务支持、高可用）。
3. 计算层：实时计算用 Flink（低延迟、状态管理），离线计算用 Spark（批处理高效），机器学习用 TensorFlow（模型训练），实现流批一体 + AI 融合。
4. 数据服务层：用 Spring Boot 封装 REST API，提供风控指标查询、实时预警服务，同时接入 Redis 缓存热点数据，提升查询效率。
5. 监控运维层：搭建 Prometheus+Grafana 监控平台，覆盖数据延迟、计算资源、任务状态全维度；使用 ELK 栈进行日志分析，快速定位问题。
6. 核心组件选型：Kafka 2.8、Flume 1.11、HBase 2.4、Spark 3.2、Flink 1.15、TiDB 6.1，平衡性能与成本。

是不是总觉得，职场路上总差那么一步？

✅ 想晋升，却被 “学历门槛” 卡住；

✅ 想跳槽，技能储备不够没底气；

✅ 站在职业十字路口，不知道往哪走；

✅ 投出 100 份简历，面试邀约寥寥无几……

别慌！我懂每一个职场人的挣扎与渴望，

关注我，后续持续分享「职场干货」「面试技巧」，陪你一起成长～

祝大家都能顺利通关，斩获心仪的大厂 Offer，在技术道路上越走越远！🚀