1 介绍自己，讲几个你熟悉的项目

2 数据倾斜怎么处理

3 spark的宽窄依赖

4 数仓模型分层 分层有啥好处

5 有了解过画像吗，自己怎么实现的，有运用算法吗

6 数仓数据质量监控和数据治理怎么实现

7 有做过实时吗，实时怎么实现数据不延迟，如果稳定可靠产出实时指标

1. 介绍自己，讲几个你熟悉的项目

考察知识点：自我认知、项目经验深度与岗位匹配度（能否体现技术栈与业务结合能力）。

参考回答：我叫 XX，3 年大数据开发经验，主要专注于数据仓库建设和用户增长分析，熟悉 Hadoop、Spark、Flink 等工具，擅长数仓分层设计和 ETL 性能优化。

两个熟悉的项目：

• 电商用户行为数仓项目：负责从 0 到 1 搭建用户行为分析体系，数据源是 APP 日志和业务库数据。用 Flume 采集日志到 HDFS，Hive 做 ODS 层存储，DWD 层清洗（去重、补全设备信息），DWS 层按 “用户 - 商品 - 场景” 主题聚合（如用户日活跃、商品点击转化率）。解决了日志格式混乱和数据倾斜问题（对高频商品 ID 加盐），最终支撑了 3 个运营报表上线，数据延迟从 T+1 降到 4 小时。
• 实时交易监控平台：用 Kafka+Flink 做实时数据处理，监控每秒订单量、支付成功率等指标。我负责 Flink SQL 的业务逻辑开发，比如实时计算 “5 分钟内重复下单用户”，通过 Flink 状态后端优化（改用 RocksDB）和并行度调整（从 10 调至 20），将延迟从 2 秒压到 500ms，保障了大促期间的实时监控稳定。

这些项目让我对离线和实时数据处理都有了实践经验，希望能应用到贵公司的业务中。

2. 数据倾斜怎么处理

考察知识点：数据倾斜的成因分析、具体解决策略及实际应用能力。

参考回答：数据倾斜本质是数据分布不均，导致个别 Task 负载过高。处理分三步走：先定位倾斜（看 Spark UI 的 Task 数据量），再分析原因，最后针对性解决。

常见方法：

• 热点 key 拆分：如果是个别 key 数据量大（比如某活动 ID 占 60%），给 key 加随机前缀（如 “act_1” 拆成 “act_1_0” 到 “act_1_9”），分散到多个 Task，聚合时再去掉前缀合并。之前处理过一个订单表，用这招把单个 Task 的 10GB 数据分到 10 个 Task，计算时间从 2 小时降到 20 分钟。
• 小表广播：join 时若小表 < 100MB，用 MapJoin（Hive）或 broadcast（Spark）把小表广播到每个节点，避免 shuffle。比如用户表（50 万条）和订单表（1 亿条）join，广播后省了 80% 的 shuffle 时间。
• 过滤 / 替换无效值：如果 null 值或空字符串导致倾斜，直接过滤（若业务允许）或替换成随机值（如 “null_1”“null_2”）。
• 调整并行度：加大 shuffle 分区数（Spark 的 spark.sql.shuffle.partitions 调大到 1000+），让数据分布更均匀。

核心原则是 “分散倾斜数据，减少 shuffle 传输”。

3. Spark 的宽窄依赖

考察知识点：Spark 中依赖的概念、区别及对执行计划的影响。

参考回答：宽窄依赖是 Spark 中划分 Stage 的依据，核心区别在是否有 shuffle：

• 窄依赖：一个父 RDD 的分区只被一个子 RDD 的分区依赖（比如 map、filter、union），没有数据 shuffle，可以流水线执行（父分区计算完直接传给子分区，不用写磁盘）。比如 rdd.map (x => x*2)，每个父分区的数据只给一个子分区，效率高。
• 宽依赖：一个父 RDD 的分区被多个子 RDD 的分区依赖（比如 groupByKey、join），必须经过 shuffle（数据按 key 重新分配）。比如 rdd.groupByKey ()，父分区的数据会被分到多个子分区，需要写磁盘再传输，是性能瓶颈。