1. 自我介绍
2. 拉链表的制作，数据量有多少，为什么不用快照表呢
3. 项目有哪些表
4. 数仓分层有哪些，具体做了什么，数仓分层作用
5. 怎么设计表，怎么建模，DIM
6. DWD层的主题分了哪些
7. 如何做的可视化
8. 什么是数据倾斜，数据倾斜的解决方案
9. Hadoop和spark的区别
10. Spark的shuffle流程是怎么样的
11. 对哪些数据库了解
12. Shuffle有哪几种类型
13. 在shuffle的过程中会进行排序吗，有哪几种排序
14. 什么是快速排序，时间复杂度是多少，手撕快排代码题
15. Spark是如何划分stage阶段
16. Spark SQL的执行流程，如何将一个SQL语句转换为任务

1. 自我介绍

考察知识点

• 个人经历与岗位的匹配度（数据相关实习/项目经验）；
• 核心技能栈（数仓、Spark、SQL等）的掌握程度；
• 个人优势与职业规划（体现稳定性与成长性）。

参考回答

面试官您好！我叫XX，XX大学XX专业硕士（或本科），主修数据科学与大数据技术相关课程，具备6个月数据开发实习经验，熟悉数仓建设、Spark/Flink离线与实时计算、SQL优化等技能，曾参与企业用户行为分析数仓项目，负责DWD层建模与数据倾斜优化，将核心任务执行时间从2小时缩短至15分钟。技能上，我熟练使用Hive/Spark SQL进行数据处理，能独立完成数仓分层设计（ODS→DWD→DWS→ADS），掌握维度建模方法（星型模型），熟悉Spark Shuffle优化、数据倾斜解决方案，同时会使用Superset/Tableau制作业务看板。实习中，我主导了“用户拉链表”开发，处理日均500万条用户行为数据，通过拉链表替代快照表，将存储成本降低60%；还参与了实时销量看板优化，通过Flink状态管理与Checkpoint调优，将数据延迟从10分钟降至1分钟内。我对数据开发岗位的兴趣源于对“数据驱动业务决策”的认可，希望能在贵公司深入参与数仓建设与实时计算项目，同时持续提升分布式计算框架的底层原理认知，谢谢！

补充回答注意要点

• 突出“岗位匹配度”：优先提及与数据开发相关的实习/项目，技能栈围绕数仓、Spark、SQL等岗位核心需求；
• 用“数据+成果”量化经历：避免笼统说“做过数仓”，用“处理日均500万条数据”“存储成本降低60%”等量化成果；
• 控制时长：自我介绍建议1-2分钟，重点讲“经历→技能→优势→规划”，避免冗余个人信息（如籍贯、爱好，除非与岗位相关）。

2. 拉链表的制作，数据量有多少，为什么不用快照表呢

考察知识点

• 拉链表的核心原理与制作流程；
• 拉链表与快照表的适用场景与差异（存储成本、历史追溯能力）；
• 实际业务中表结构设计的选型逻辑。

参考回答

在实习的用户行为分析项目中，我负责制作“用户维度拉链表”，处理的数据量为**日均500万条用户行为数据**，全量用户基数约1000万，拉链表最终存储的历史版本数据约3000万条（按3个月历史周期）。

（1）拉链表的制作流程

拉链表用于存储“数据的历史变化轨迹”，核心是通过“生效时间（start_date）”和“失效时间（end_date）”标记每条记录的生命周期，制作步骤如下：

1. 数据源准备：ODS层获取每日用户增量数据（新增/更新用户，如用户等级、手机号变更）和前一天的拉链表全量数据；
2. 数据匹配与更新：
   1. 用增量数据的“用户ID”与历史拉链表关联，标记“历史有效记录”的end_date为“前一天日期”（使其失效）；
   2. 新增/更新的用户数据作为“新有效记录”，start_date设为“当天日期”，end_date设为“9999-12-31”（表示当前有效）；
3. 合并与存储：将“失效的历史记录”与“新有效记录”合并，写入当日拉链表（存储在Hive DWD层，按start_date分区）。

（2）为什么不用快照表

快照表是“每日全量存储当前数据状态”，与拉链表相比，在本项目中存在明显劣势，因此选择拉链表：

• 存储成本过高：若用快照表，每日需存储1000万条全量用户数据，3个月需存储9亿条；而拉链表仅存储“变化的记录”（日均新增/更新用户约50万条），3个月仅3000万条，存储成本降低60%+；
• 无法追溯完整历史：业务需要分析“用户等级变更轨迹”（如某用户从V1→V2→V3的时间节点），快照表仅能获取某一天的用户状态，无法还原历史变化；拉链表通过start_date和end_date，可直接筛选出用户在任意时间段的状态；
• 更新效率低：快照表每日需全量覆盖写入，500万条数据全量写入耗时约1小时；拉链表仅需增量更新变化数据，耗时缩短至10分钟，减轻集群压力。

补充回答注意要点

• 明确拉链表核心字段：强调“start_date+end_date”的作用，体现对表结构设计的理解；
• 对比维度要具体：从“存储成本、历史追溯、更新效率”三个核心维度对比，避免只说“拉链表更好”；
• 结合业务需求：说明选择拉链表是为了满足“历史轨迹分析”的业务需求，体现“技术选型服务于业务”的思维。

3. 项目有哪些表

考察知识点

• 对项目数据链路的整体认知；
• 各表在数仓分层中的定位与作用；
• 表与表之间的关联关系（体现建模能力）。

参考回答

以实习参与的“电商用户行为分析数仓项目”为例，表结构按数仓分层设计，覆盖从原始数据到业务应用的全链路，核心表如下（按分层梳理）：

（1）ODS层（原始数据层）——存储未加工原始数据

• ods_user_log：用户行为日志表，每日增量导入，存储用户点击、浏览、下单等行为数据（字段：user_id、action_type、action_time、page_id、product_id等），数据格式为JSON，按日期（dt）分区，日均数据量500万条；
• ods_order_info：订单原始表，同步业务MySQL的订单表（binlog同步），存储订单基本信息（order_id、user_id、order_amount、pay_time等），按日期分区，日均10万条；
• ods_product_info：商品原始表，同步业务MySQL商品表，存储商品属性（product_id、product_name、category_id、price等），全量同步（每日覆盖）。

（2）DWD层（明细数据层）——清洗、整合为明细宽表

• dwd_user_action_detail：用户行为明细宽表，对ods_user_log清洗（去重、补全缺失值），关联ods_product_info补充商品分类信息，字段新增category_name、product_price，按dt分区，日均480万条（过滤无效数据后）；
• dwd_order_detail：订单明细宽表，对ods_order_info清洗（过滤取消订单），关联用户维度表（dwd_dim_user）补充用户等级、地域信息，字段新增user_level、user_city，按dt分区；
• dwd_dim_user：用户维度拉链表（核心表），存储用户历史状态（user_id、user_name、phone、user_level、start_date、end_date），按start_date分区，支持历史轨迹查询；
• dwd_dim_product：商品维度表，全量更新，存储商品静态属性+动态状态（如上架/下架），按dt分区。

（3）DWS层（汇总数据层）——按业务主题汇总

• dws_user_action_agg：用户行为汇总表，按user_id+dt汇总用户每日行为（点击次数、浏览时长、下单次数等），支持用户活跃度分析；
• dws_product_sales_agg：商品销售汇总表，按product_id+dt汇总销量、销售额、支付转化率，支持商品热销榜分析；
• dws_order_geo_agg：订单地域汇总表，按user_city+dt汇总各城市订单量、客单价，支持地域运营分析。

（4）ADS层（应用数据层）——直接支撑业务应用

• ads_user_active_report：用户活跃报表表，按日/周/月汇总活跃用户数（日活DAU、周活WAU），支撑运营看板；
• ads_product_sales_top：商品销售TOP表，每日计算TOP100热销商品，支撑商品运营决策；
• ads_order_abnormal：订单异常监控表，汇总支付超时、退款率超阈值的订单数据，支撑风控告警。

补充回答注意要点

• 按数仓分层梳理：体现对“分层架构”的认知，让表的定位更清晰；
• 说明表的核心作用：每个表简要说明“存储什么数据、服务什么业务”，避免只罗列表名；
• 提及关联关系：如“dwd_order_detail关联dwd_dim_user”，体现建模时的维度关联思维。

4. 数仓分层有哪些，具体做了什么，数仓分层作用

考察知识点

• 数仓分层的标准架构（ODS、DWD、DWS、ADS等）；
• 各层的核心职责与实际操作（体现落地能力）；
• 分层架构的设计价值（解耦、复用、效率等）。

参考回答

数仓分层是为了“规范数据处理流程、降低数据耦合度”，行业主流采用“四层架构”（ODS→DWD→DWS→ADS），我在项目中按此架构落地，具体如下：

（1）数仓分层及具体工作

（2）数仓分层的核心作用

4. 解耦业务与数据处理：ODS层保留原始数据，业务系统变更（如MySQL表结构调整）时，仅需修改ODS层同步逻辑，不影响下游DWD/DWS层，降低迭代风险；
5. 提升数据复用性：DWD层的明细宽表可支撑多个DWS主题（如用户行为宽表同时支撑“用户活跃”和“商品点击”两个汇总主题），避免重复清洗数据；
6. 优化查询效率：DWS层提前汇总数据，ADS层直接使用聚合结果，避免业务查询时重复计算（如计算DAU无需扫描千万级明细，直接读取DWS层汇总值）；
7. 便于问题定位：分层后数据问题可快速定位（如ADS层指标异常，先查DWS层汇总数据，再查DWD层明细，最后查ODS层原始数据），排查效率提升50%。

补充回答注意要点

• 分层职责与工作对应：每个分层的“具体工作”要紧扣“核心职责”，体现对分层逻辑的理解；
• 量化分层价值：用“排查效率提升50%”“避免重复计算”等具体效果说明分层作用，避免空泛；
• 结合工具落地：提及Flink CDC、Flume、ClickHouse等工具，体现分层架构的实际落地能力。

5. 怎么设计表，怎么建模，DIM

考察知识点

• 表结构设计的核心原则（规范性、易用性）；
• 数仓建模方法（维度建模为主）；
• 维度表（DIM）的设计要点与作用。

参考回答

在项目中，表设计与建模遵循“**业务驱动、维度建模**”原则，核心目标是“让数据易用、支撑灵活分析”，具体方法如下：

（1）表设计核心原则与步骤

8. 明确业务需求：先与业务方确认分析场景（如用户活跃度、商品销售、地域运营），确定核心指标（DAU、销量、客单价）和维度（时间、用户、商品、地域）；
9. 规范表结构：
   1. 命名规范：按“分层_主题_类型”命名（如dwd_dim_user：DWD层、用户主题、维度表；dws_product_agg：DWS层、商品主题、汇总表）；
   2. 字段规范：统一字段名（如用户ID统一为user_id，避免uid/userid）、类型（如时间字段统一为datetime），添加备注（如“pay_time：订单支付时间，NULL表示未支付”）；
   3. 分区规范：按时间（dt，格式yyyy-MM-dd）分区，支持按时间范围查询；维度表若数据量大，按维度属性分区（如user表按user_city分区）；
10. 选择存储格式：ODS层用JSON（保留原始格式），DWD/DWS/ADS层用Parquet（列式存储，支持谓词下推，查询效率提升30%+），并开启Snappy压缩（减少存储成本）。

（2）数仓建模方法——维度建模（星型模型为主）

数仓建模以“维度建模”为主，聚焦业务分析场景，核心是“事实表+维度表”的关联，项目中采用星型模型（维度表直接关联事实表，避免复杂的雪花模型关联）：

• 事实表：存储业务过程中的度量值（如订单金额、点击次数），分为三类：
  • 事务事实表（如dwd_order_detail）：记录单次业务事件（订单创建、支付），粒度细（一条订单一条记录）；
  • 周期快照事实表（如dws_user_action_agg）：按周期（日/周）汇总业务过程，粒度粗（一个用户一天一条记录）；
• 维度表（DIM表）：存储业务分析的维度属性（如用户、商品、时间），是建模的核心，设计要点：
  • 高内聚：一个维度表对应一个业务维度（如user维度表只存用户相关属性，不混入商品信息）；
  • 历史可追溯：静态维度（如商品分类）用全量表（每日覆盖），动态维度（如用户等级、手机号）用拉链表（记录历史变化）；
  • 退化维度：将高频使用的小维度字段（如订单表的order_status）直接写入事实表，避免频繁关联维度表（减少Join开销）；
• 星型模型示例：以“商品销售分析”为例，事实表dws_product_sales_agg（存储product_id、dt、sales_num、sales_amount）直接关联4个维度表：dim_user（用户地域）、dim_product（商品分类）、dim_time（时间维度，如周/月）、dim_channel（销售渠道），支撑多维度下钻分析（如“北京地区、手机分类、本周”的销量）。

（3）DIM表（维度表）的核心作用

11. 支撑多维度分析：业务方通过维度表的属性（如user_city、product_category）对事实表指标进行切片、下钻（如“按城市拆分DAU”“按商品分类拆分销量”）；
12. 降低事实表复杂度：将冗余的维度属性（如用户姓名、商品名称）抽离到维度表，事实表仅保留维度ID（如user_id、product_id），减少事实表字段数量（从50+字段降至20+）；
13. 保证数据一致性：维度表统一维护维度属性（如商品分类名称在dim_product中统一为“手机”“电脑”），避免事实表中出现“手机”“移动电话”等不一致表述。

补充回答注意要点

• 建模方法紧扣业务：说明维度建模是为了“支撑灵活分析”，星型模型是为了“简化关联、提升查询效率”，体现“技术服务业务”；
• DIM表设计讲细节：突出“拉链表存储动态维度”“退化维度减少Join”等实操要点，避免只说“维度表存属性”；
• 结合示例：用“商品销售分析”的星型模型示例，让建模逻辑更直观。

6. DWD层的主题分了哪些

考察知识点

• 对DWD层“明细+主题”核心定位的理解；
• 主题划分与业务场景的匹配度；
• 各主题下明细数据的整合逻辑。

参考回答

DWD层的核心是“按业务主题整合明细数据”，主题划分需覆盖业务核心链路，同时保证“一个主题对应一类业务场景，明细数据一站式可用”。在电商数仓项目中，DWD层按“用户、订单、商品、营销”四大核心业务链路划分主题，具体如下：

（1）用户主题

• 核心目标：整合用户全链路数据，支撑用户画像、活跃度分析；
• 包含表：
  • dwd_dim_user：用户维度表（拉链表），存储用户静态属性（user_id、user_name、注册时间）和动态属性（user_level、phone、user_city），记录历史变化；
  • dwd_user_action_detail：用户行为明细宽表，整合用户点击、浏览、收藏、下单等行为数据，关联商品维度表补充商品分类、价格，关联时间维度表补充时段（如“早高峰9:00-11:00”）；
• 数据来源：ODS层用户日志表（ods_user_log）、业务MySQL用户表（ods_user_info）。

（2）订单主题

• 核心目标：整合订单从创建到支付、履约的全流程数据，支撑订单分析、支付转化率分析；
• 包含表：
  • dwd_order_detail：订单明细宽表，存储订单基本信息（order_id、user_id、order_amount）、支付信息（pay_time、pay_method）、履约信息（ship_time、receive_time），关联用户维度表补充用户地域、等级，关联商品维度表补充订单商品明细；
  • dwd_order_refund_detail：订单退款明细宽表，整合退款申请、审核、到账数据，关联订单表补充原订单信息；
• 数据来源：ODS层订单表（ods_order_info）、支付表（ods_pay_info）、退款表（ods_refund_info）。

（3）商品主题

• 核心目标：整合商品基础信息、库存、销售行为数据，支撑商品生命周期、热销榜分析；
• 包含表：
  • dwd_dim_product：商品维度表，存储商品静态属性（product_id、product_name、category_id、brand）、动态属性（status：上架/下架、price：实时价格）；
  • dwd_product_stock_detail：商品库存明细宽表，整合库存变动记录（入库、出库、调拨），关联商品维度表补充商品分类，按仓库（warehouse_id）分区；
  • dwd_product_click_detail：商品点击明细宽表，整合用户对商品的点击、浏览数据，关联用户维度表补充用户画像标签（如“高消费用户”）；
• 数据来源：ODS层商品表（ods_product_info）、库存表（ods_stock_info）、用户行为日志表（ods_user_log）。

（4）营销主题

• 核心目标：整合优惠券、促销活动数据，支撑营销效果（核销率、ROI）分析；
• 包含表：
  • dwd_dim_coupon：优惠券维度表，存储优惠券属性（coupon_id、discount、valid_start_time、valid_end_time）；
  • dwd_coupon_usage_detail：优惠券使用明细宽表，整合优惠券领取、核销、失效数据，关联用户维度表补充用户信息，关联订单表补充核销订单金额；
  • dwd_promotion_detail：促销活动明细宽表，整合活动参与（用户报名）、转化（活动订单）数据，关联商品维度表补充活动商品信息；
• 数据来源：ODS层优惠券表（ods_coupon_info）、促销活动表（ods_promotion_info）、订单表（ods_order_info）。

补充回答注意要点

• 主题与业务链路对应：每个主题明确“服务什么业务场景”，体现“主题划分源于业务”；
• 表与主题的关联性：说明每个主题下的表如何“整合明细数据”，如“用户行为明细宽表关联商品维度”，体现DWD层“一站式明细”的定位；
• 突出“宽表”特性：强调DWD层表是“整合多源数据的宽表”，避免只说“存储明细数据”，体现数据整合能力。

7. 如何做的可视化

考察知识点

• 可视化工具的选型与使用能力；
• 从“数据”到“可视化”的全流程（数据准备→图表设计→看板落地）；
• 可视化的核心原则（业务导向、简洁易懂）。

参考回答

在项目中，可视化的核心目标是“让业务方快速获取数据洞察”，流程分为“数据准备→工具选型→图表设计→看板落地→迭代优化”五步，具体如下：

（1）数据准备：确保数据“可用、准确”

• 数据源选择：优先使用ADS层报表数据（如ads_user_active_report、ads_product_sales_top），因ADS层数据已按业务需求加工（包含环比、同比等指标），无需业务方二次计算；
• 数据校验：可视化前通过SQL校验数据准确性（如“日活用户数=各渠道日活之和”“销量=订单表中已支付订单的商品数量之和”），避免图表展示错误数据；
• 数据同步：将ADS层数据（存储在Hive/ClickHouse）同步至可视化工具支持的存储：
  • 实时看板（如销量监控）：直接连接ClickHouse（支持毫秒级查询）；
  • 离线报表（如月度运营报告）：将Hive数据导出至MySQL（可视化工具对MySQL兼容性更好）。

（2）工具选型：按场景选择合适工具

项目中使用两款核心工具，覆盖不同可视化场景：

• Superset：用于实时监控看板（如“实时销量监控”“用户行为漏斗”），优势是支持连接ClickHouse、Hive等大数据存储，支持自定义SQL查询，可配置自动刷新（如5分钟刷新一次）；
• Tableau：用于离线分析报表（如“月度运营分析”“商品生命周期报告”），优势是图表交互性强（支持下钻、筛选），可视化效果更美观，适合生成PPT级别的报表。

（3）图表设计：遵循“业务导向、简洁易懂”原则

• 图表选型：根据指标类型选择合适图表，避免为了“美观”选择复杂图表：
  • 趋势类指标（日活、销量变化）：用折线图（展示变化趋势）；
  • 对比类指标（各渠道日活占比）：用饼图/环形图（展示占比）；
  • 排名类指标（商品销量TOP10）：用柱状图（直观对比）；
  • 转化类指标（用户从点击到下单的转化）：用漏斗图（展示各环节转化损耗）；
• 设计规范：
  • 配色：统一配色方案（如成功用绿色、异常用红色、中性用蓝色），避免超过3种主色；
  • 标签：指标名称简洁（如“DAU”标注全称“日活跃用户数”），单位明确（如“销量（件）”“金额（万元）”）；
  • 筛选器：添加核心维度筛选（如时间范围、地域、商品分类），支持业务方自主分析。

（4）看板落地：按“用户角色”划分看板

• 运营看板（面向运营人员）：包含核心指标（DAU、订单量、支付转化率）、分维度拆解（按渠道、地域、用户等级）、实时告警（如转化率低于阈值标红）；
• 商品看板（面向商品运营）：包含商品销量TOP10、新品上架转化率、库存预警（库存低于安全值标黄）；
• 高管看板（面向管理层）：聚焦核心结果指标（月度GMV、同比增长率、ROI），图表简洁，避免细节数据，支持钻取（如点击“GMV”可下钻至各渠道明细）。

（5）迭代优化：根据业务反馈调整

• 收集反馈：定期与业务方沟通（如每周运营例会），了解看板使用痛点（如“缺少‘新老用户’筛选器”“折线图趋势不明显”）；
• 优化调整：如运营反馈“实时销量波动看不清”，将折线图改为“折线图+柱状图”（折线展示趋势，柱状展示单日销量）；针对“筛选复杂”，添加“常用筛选模板”（如“近7天、一线城市”模板）。

补充回答注意要点

• 流程化讲解：按“准备→选型→设计→落地→优化”分步说明，体现系统化思维；
• 工具选型讲原因：说明“为什么用Superset做实时看板、Tableau做离线报表”，体现工具选型的合理性；
• 结合业务角色：按“运营、商品、高管”划分看板，体现“可视化服务于不同用户需求”，避免千篇一律。

8. 什么是数据倾斜，数据倾斜的解决方案

考察知识点

• 数据倾斜的本质与识别方法；
• 不同场景（GroupBy、Join）下的解决方案；
• 实际项目中的优化经验（体现实操能力）。

参考回答

（1）什么是数据倾斜

数据倾斜是分布式计算（如Spark、Flink）中“数据按Key分区后，部分分区数据量远超其他分区”的现象，核心表现为：

• 任务执行时间差异大：多数Task几分钟完成，少数Task耗时几小时（甚至OOM）；
• 资源占用失衡：部分Executor CPU/内存使用率100%，其他Executor空闲；
• 根源：Key分布不均（如某Key对应数据占比60%），导致该Key所在分区的Task处理数据量过大。

（2）数据倾斜的解决方案（按场景分类）

针对项目中遇到的“GroupBy倾斜”和“Join倾斜”，分别采用以下方案：

场景1：GroupBy倾斜（如用户订单量统计，头部用户订单占比30%）

• 方案1：Key加盐+二次聚合（适用于倾斜Key数据量极大）
  • 第一次聚合：对倾斜Key添加随机后缀（如“user123”→“user123_0”“user123_1”…“user123_9”），使其分散到10个Task，每个Task处理1/10数据；
  • 第二次聚合：去掉后缀，合并相同Key的聚合结果（如“user123_0”和“user123_1”的订单量相加）；
  • 效果：Task执行时间从2小时降至15分钟，避免OOM。
• 方案2：预聚合（Map端聚合）（适用于普通GroupBy倾斜）
  • 用Spark的reduceByKey替代groupByKey：reduceByKey会先在Map端做局部聚合（如每个Map Task先统计本地“user123”的订单量），再将局部结果Shuffle到Reduce端做全局聚合，减少Shuffle数据量（约50%）。

场景2：Join倾斜（如订单表与用户表Join，“null值Key”匹配5000万条数据）

• 方案1：广播小表（Broadcast Join）（适用于一张表是小表，数据量<1GB）
  • 将小表（如用户表，100万条）广播到所有Executor内存，Join时直接在Map端完成（无需Shuffle），避免Reduce端倾斜；
  • 实现：Spark中用broadcast()函数（orders.join(broadcast(users), "user_id")），Flink中用/*+ BROADCAST(users) */ hint。
• 方案2：拆分倾斜Key+单独处理（适用于两张表均为大表）
  • 拆分数据：将订单表拆分为“倾斜Key数据”（如null值、头部用户）和“正常Key数据”；
  • 单独处理倾斜数据：对倾斜Key添加随机后缀，同时将用户表中对应Key的数据也拆分为相同数量的副本（如添加0-9后缀），两者Join后去掉后缀；
  • 合并结果：将“正常Key Join结果”与“倾斜Key处理结果”合并；
  • 效果：Join任务耗时从1.5小时降至20分钟。