1 介绍自己，讲几个你熟悉的项目
2 数据倾斜怎么处理
3 spark的宽窄依赖
4 数仓模型分层 分层有啥好处
5 有了解过画像吗，自己怎么实现的，有运用算法吗
6 数仓数据质量监控和数据治理怎么实现
7 有做过实时吗，实时怎么实现数据不延迟，如果稳定可靠产出实时指标

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

✅考察知识点

• 角色定位与边界：你在团队中的职责（Owner/Driver/Contributor），与上下游的协作关系。
• 业务价值：指标口径统一、稳定性提升、效率成本优化、收入/转化提升等可量化成果。
• 工程深度：数据建模、数据血缘、质量治理、性能/成本治理、实时链路保障等具体落地。
• 方法论沉淀：可复用的模型分层规范、指标口径体系、监控告警规范、发布变更流程等。

🧩参考回答（模板，可据实改写）

我是 X 年数据平台/数仓工程背景，熟悉 离线（Hive/Spark）+ 实时（Kafka/Flink） 的数仓建设与治理，偏工程与指标体系落地。近两年重点在实时指标平台与画像标签服务。挑 3 个代表项目简述：
项目 A：增长&推荐业务的核心数仓重构（离线+准实时）背景：历史链路多团队并行产出，口径分裂、重复开发和数据倾斜严重，导致同一指标存在多版本、跨报表打不平。我的职责：牵头分层建模（ODS/DWD/DWS/ADS/DIM）、指标口径治理、公共维表与字典统一；建立血缘与质量监控。技术：Hive/Spark 3（AQE）、Iceberg/Hudi 分层存储，Airflow 编排，Data Catalog+血缘，可视化告警。难点与方案：口径统一：抽象业务过程与主事实表，沉淀指标原子口径与复合口径；倾斜治理：盐值（salting）+ 小表广播 + 二次聚合 + AQE Skew Join；稳定性：SLA/SLO 分级，DQC（完整性/唯一性/一致性/及时性）+ 回灌机制。结果：核心报表指标打平率从 85%→99%+，重复开发减少 40%，T+1 核心任务平均耗时下降 35%。

项目 B：营销转化实时指标平台（<5s 延迟）背景：活动强节奏，运营需要次秒级看达标率和 ROI。职责：设计Kafka→Flink→Doris/ClickHouse 实时链路；保证Exactly-once、乱序/迟到处理、维度广播 Join；统一离线/实时口径。技术：Flink SQL/CEP，Watermark，Upsert-Kafka，Two-Phase Commit sink，维表 CDC（Canal/ Debezium），多级缓存。结果：活动峰值期间端到端延迟 P95 < 3s，指标可用性 99.95%，运营决策效率显著提升。

项目 C：用户画像与标签服务（离线+准实时）背景：画像零散、规则归口不清，推荐/投放复用成本高。职责：构建标签体系（主题/类目/原子/衍生）、画像生产链路、标签服务化（在线 KV/向量库）和 AB 评估闭环。技术：Spark 特征加工、Flink 实时增量、规则引擎、LR/XGBoost/Embedding；服务侧 Redis/HBase/向量检索。结果：标签复用率提升 60%+，实验组 CTR/转化率显著提升（以业务口径披露）。

综上，我擅长把分层建模、质量治理与实时工程能力结合业务目标做系统性落地，并沉淀可复用的方法论与模板。

📌补充回答（注意要点/得分点清单）

• 尽量量化：效率、时延、成本、稳定性、营收/转化的具体数字。
• 结构化表达（STAR）：情境-目标-动作-结果；每个项目 60–90 秒。
• 强调口径统一、复用、治理闭环、实时可靠性四大主线。
• 有意识点出协作与影响力：推动跨团队达成一致、沉淀规范。

2）数据倾斜怎么处理

✅考察知识点

• 倾斜识别与定位：如何快速发现“慢 Task/大分区/热点 Key”。
• 治标 vs 治本策略：Join/聚合、分区、算法/业务侧消峰与拆分。
• 工程能力：Spark SQL/核心参数、AQE、广播/盐值、二次聚合、Bloom/Map Join。
• 案例复盘：方案适用边界、收益与副作用、稳定性。

🧩参考回答

识别：我会先看 Spark UI 的 Stage/Task 分布，若 task 时间/输入大小方差极大、Shuffle Read 某些分区特别大，或热点 Key 单点拉满，则是倾斜。也会抽样统计 TopK Key 占比、Gini 系数衡量不均衡度。
常用治理（按优先级与适用场景）：小表广播（Broadcast Hash Join）：适用：维表≤数百 MB；做法：/*+ BROADCAST(dim) */ 或 DataFrame broadcast(dim)，避免大规模 Shuffle。盐值（Salting）打散热点 Key：适用：单 Key 高基数聚合/Join；做法：在大表对热点 key 增加随机后缀（0..N），维表扩容 N 份或在 Join 后再二次聚合恢复；代价：数据膨胀与二次聚合开销。Map 端预聚合 / ReduceByKey：适用：可交换结合的聚合（sum、count、max/min）；用 reduceByKey/aggregateByKey 替代 groupByKey，显著降低 Shuffle 数据量。自定义分区/增加分区数：合理设置 spark.sql.shuffle.partitions；对倾斜 key 用自定义 Partitioner 让其拆到多个分区。AQE（Adaptive Query Execution）- Skew Join：开启 spark.sql.adaptive.enabled 与 skewJoin，让运行期自动拆分大分区并动态并行度；好处：免手工调参，泛化性强。Bloom Filter / Semi Join 过滤：在大表上先预过滤可能不匹配的数据，再做 Join，减少数据量。业务侧消峰与拆分：如把超大客户/大活动的流量分桶，或拆日账单为多批回填，避免单批极端热点。数据建模层面：维度稀疏/高基数时，考虑维度退化或拆维，减少在事实层的重分布。
小示例（Spark SQL）：

-- 广播小表
SELECT /*+ BROADCAST(dim) */ f.user_id, dim.level, sum(f.amount)
FROM dwd_fact f
JOIN dim_user dim ON f.user_id = dim.user_id
GROUP BY f.user_id, dim.level;

-- 盐值+二次聚合（热点 user_id）
WITH big AS (
  SELECT concat(user_id, '_', cast(rand()*10 as int)) AS uid_salt, amount
  FROM dwd_fact
),
dim_salt AS (
  SELECT concat(user_id, '_', s.salt) AS uid_salt, level
  FROM dim_user
  LATERAL VIEW posexplode(split(space(9),' ')) s AS salt, _
)
SELECT user_id, level, sum(amount) AS amt
FROM (
  SELECT split(uid_salt,'_')[0] AS user_id, level, amount
  FROM big b JOIN dim_salt d USING(uid_salt)
) t
GROUP BY user_id, level;-- 广播小表
SELECT /*+ BROADCAST(dim) */ f.user_id, dim.level, sum(f.amount)
FROM dwd_fact f
JOIN dim_user dim ON f.user_id = dim.user_id
GROUP BY f.user_id, dim.level;

-- 盐值+二次聚合（热点 user_id）
WITH big AS (
  SELECT concat(user_id, '_', cast(rand()*10 as int)) AS uid_salt, amount
  FROM dwd_fact
),
dim_salt AS (
  SELECT concat(user_id, '_', s.salt) AS uid_salt, level
  FROM dim_user
  LATERAL VIEW posexplode(split(space(9),' ')) s AS salt, _
)
SELECT user_id, level, sum(amount) AS amt
FROM (
  SELECT split(uid_salt,'_')[0] AS user_id, level, amount
  FROM big b JOIN dim_salt d USING(uid_salt)
) t
GROUP BY user_id, level;

落地经验：先用广播和预聚合等“不改数据语义”的方式；若仍不够，再用盐值/自定义分区；同时开启 AQE 兜底。最后结合业务做消峰与模型层优化。

📌补充回答（注意要点/得分点清单）

• 说清楚识别—定位—治理—复盘闭环；
• 明确每种方法的适用条件/副作用（如盐值造成数据膨胀、二次聚合成本）；
• 强调优先级：广播/预聚合 > AQE > 盐值/自定义分区 > 业务侧改造；
• 加上一条真实指标：例如“某表倾斜 key 前 1% 占比 40%，治理后 P95 任务时长下降 60%”。

3）Spark 的宽窄依赖

✅考察知识点

• 概念：窄依赖（N→1）、宽依赖（N→N）与 Stage 边界、Shuffle 的关系。
• 算子分类：map/filter/mapPartitions/union（窄）；groupByKey/repartition/sortByKey/join（宽）。
• 性能与容错：血缘恢复、Shuffle 成本、并行度调整、倾斜风险。
• 调优实践：coalesce vs repartition、map 端聚合、缓存与持久化。

🧩参考回答

窄依赖：每个父 RDD/分区最多被一个子分区使用，如 map、filter、mapPartitions、coalesce（不 shuffle）。窄依赖在失败时可最小代价重算，且无需 Shuffle，性能较好。
宽依赖：子分区依赖多个父分区，需要 Shuffle，如 groupByKey、reduceByKey、repartition、sortByKey、大表 join。宽依赖会产生 Stage 切分，网络与磁盘 I/O 成本高，也是倾斜高发点。
工程要点：优先用 reduceByKey/aggregateByKey 替代 groupByKey；coalesce 在缩小分区时避免 Shuffle，而 repartition 会触发 Shuffle；在宽依赖前尽量过滤与预聚合，减少数据量；尽量广播小表减少 Join Shuffle；Spark 3 开启 AQE，自动优化并行度与 Skew Join。

📌补充回答（注意要点/得分点清单）

• 把“依赖—Stage—Shuffle—性能/容错”串起来说；
• 点名几个典型算子与替代关系（groupByKey → reduceByKey）；
• 提及 AQE 与 coalesce vs repartition 的差异。

4）数仓模型分层，分层有什么好处

✅考察知识点

• 分层体系：ODS → DWD → DWM/DWS → ADS，以及 DIM（维表）。
• 建模方法：事实表（事务/累积/快照）、维度表（SCD1/2/3）、星型/雪花。
• 分层收益：解耦与复用、口径对齐、稳定性、权限与成本治理、可观测性。
• 细节：命名/分区/水位时间/主键、业务时间 vs 处理时间、统一字典与实体主键。

🧩参考回答

常见分层：ODS（数据域/贴源层）：保留原始粒度/字段/轻治理，便于回溯；分区常用 dt/event_time。DWD（明细层）：围绕业务过程建主事实表（如曝光、点击、下单、支付），梳理主键、外键，统一时间/用户/设备口径；引入公共维表 DIM。DWM/DWS（中间/汇总服务层）：在 DWD 基础上做轻度聚合/宽表，沉淀复用指标与宽表服务（如用户日活、渠道周度转化）。ADS（应用层）：面向具体报表/场景输出的终态数据（可轻度反范式化），保证稳定 SLA。DIM：主题维、公共字典（地区、渠道、设备、商品、组织等），注意 SCD 版本管理与主键一致性。
分层好处：复用与解耦：DWD/DWS 承载复用口径，ADS 免重复造轮子；稳定与回溯：ODS 保底回溯，DWD 口径固化，ADS 可随需变更；治理与成本：分层隔离权限、冷热分层、生命周期管理（如 ODS 保留 90 天、DWD 180 天、DWS/ADS 365 天差异化）；可观测与灰度：按层建立 DQC、血缘；ADS 支持灰度发布与对账；实时对齐：离线/实时同一口径在 DWD/DWS 抽象，保证批流一体。

📌补充回答（注意要点/得分点清单）

• 说明事实表类型（事务型/累积型/快照型）与SCD 的取舍（SCD1 覆盖、SCD2 留痕）；
• 强调统一主键与时间（事件时间、业务时间、处理时间）；
• 指出指标口径统一与复用收益（减少重复开发、降低成本）。

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

✅考察知识点

• 标签体系：主题→类目→原子→派生→圈人；离线/实时一体。
• 生产链路：数据源、规则引擎、特征加工、增量更新、服务化。
• 算法与效果评估：LR/XGBoost/GBDT/Embedding、召回+排序、A/B 实验。
• 工程与合规：在线存储/缓存、时效策略、隐私合规（最小必要、脱敏、可追溯）。

🧩参考回答

整体框架：标签体系设计：从“人-货-场”出发，沉淀基础属性（性别、年龄段、地域）、行为偏好（内容/品类偏好、价格敏感度、时段活跃）、价值类（LTV、RFM）、状态类（设备、会员等级）等；层级为主题→类目→原子→衍生，并给出统一命名、口径、字典。生产链路：离线：Spark 以日/小时批加工，原子标签与特征宽表产出至 DWS/ADS；准实时：Flink 从 Kafka 消费事件流，Watermark 处理乱序，使用 Temporal Table Join 关联 CDC 维度，增量更新至 HBase/Redis/向量库；规则引擎：支持 DSL（区间、次数、漏斗、窗口）生成圈人人群包；服务化：标签/特征通过 API 对推荐/投放/BI 提供查询与订阅。算法应用：行为意图/偏好：LR/GBDT/XGBoost 等监督学习做转化/流失预测；相似人群与召回：Embedding（Word2Vec/DeepWalk/双塔）在向量空间做近邻检索；画像校验：标签一致性/稳定性测试，A/B 验证对 CTR/转化的提升。评估与闭环：覆盖率/新鲜度/准确率指标，画像更新延迟（P95/P99）；实验平台对比线上效果，形成淘汰/保留/更新的版本管理与灰度发布。合规：严格遵守最小必要原则，脱敏/匿名化，敏感字段分级管控；建立血缘与审计，记录访问与使用场景。

📌补充回答（注意要点/得分点清单）

• 把标签体系—生产链路—服务化—评估四步讲清；
• 算法不要只报名词，要点出问题定义与目标函数（如转化概率、相似度召回）；
• 强调实时增量与维表 CDC/Temporal Join能力；
• 必提合规与审计。

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

✅考察知识点

• 质量维度：完整性、准确性、一致性、唯一性、及时性、可用性。
• 监控实现：规则类型、采样与阈值、任务编排与告警、血缘与回溯。
• 治理体系：口径与元数据、血缘可视化、权限与分级、成本生命周期、变更管理。
• 平台化与闭环：发现—定位—处置（回滚/回灌/兜底）—复盘—防再发。

🧩参考回答

一套可落地的方法论：质量规则（DQC）：完整性：分区行数/字段非空率/必填覆盖；一致性：主外键一致、口径对账（离线 vs 实时、上游 vs 下游）；唯一性：主键去重率、重复行检测；准确性：值域/字典校验、异常点检测（3σ/IQR）；及时性：分区延迟、端到端时延、指标出数 SLA；可用性：任务成功率、资源饱和度、查询 QPS/失败率。规则表达：SQL/DSL/Great Expectations 等，支持模板化+继承。编排与告警：Airflow/Azkaban 编排，质量任务先于下游发布；告警：分级（P0/P1/P2），多通道（IM/短信/电话），依赖静默抑制/抖动抑制。血缘与元数据：数据目录（表/字段/口径说明）、血缘图（上游—下游影响面）、变更评估与灰度；统一指标口径中心（原子指标/衍生指标/复合指标）与实体主键字典。处置与回溯：回滚/回灌：ODS 留痕+版本化表（Iceberg/Hudi），可按分区/快照回放；兜底：指标读写双写对比、按阈值自动切换备表；复盘：根因分类（数据/任务/口径/资源/权限），记录并固化防再发清单。成本与生命周期治理：分层分级存储（冷热分层），分区裁剪/压缩/索引；表达式复用、跨表 Join 下推；定期 OPTIMIZE/COMPACT。
落地示例（质量规则 SQL）：

-- 非空率
SELECT 1 - (sum(CASE WHEN col IS NULL THEN 1 ELSE 0 END)/count(*)) AS not_null_ratio FROM dwd_x;

-- 主键唯一
SELECT count(*) AS total, count(DISTINCT pk) AS distinct_pk FROM dwd_x;

-- 延迟（分区是否按时到达）
SELECT max(dt) AS latest_dt FROM dwd_x; – 与期望 dt 比较

关键思想：把质量当作产品能力来建设：标准—工具—流程—度量统一，能持续迭代与复用。

📌补充回答（注意要点/得分点清单）

• 把质量规则类型说全并给示例；
• 强调血缘与指标口径中心的治理价值；
• 必提回滚/回灌与灰度发布；
• 质量问题分级与 SLA/SLO。

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

✅考察知识点

• 端到端架构：采集（SDK/埋点/CDC）→ Kafka → Flink → OLAP/在线存储 → 服务/看板。
• 低延迟关键：Watermark/窗口与触发器、乱序/迟到处理、维表 Join、反压治理。
• 一致性与可靠性：Exactly-once、两阶段提交、幂等/去重、补偿回放、监控告警。
• 批流一体与口径统一：离线/实时共用口径与维度。

🧩参考回答

架构：事件：客户端/服务端埋点 → Kafka（多分区、冗余副本）处理：Flink（SQL/CEP），Watermark FOR event_time AS event_time - INTERVAL '30' SECOND，支持乱序/迟到；维度：CDC（Canal/Debezium）→ Kafka → Flink Temporal Table/Broadcast State 维表 Join；存储：Doris/ClickHouse（明细+汇总）、HBase/Redis（在线标签/指标）、对象存储（冷备）；出数：API/可视化看板/订阅，离线对齐校验。
不延迟（低延时）关键点：合理的 Watermark 与窗口：乱序容忍 30–60s，滚动/滑动窗口 + 提前触发（Processing-Time 触发器）产出准实时，迟到数据用 Update/回补；维表 Join：小维度走 Broadcast；大维度用 Temporal Join（FOR SYSTEM_TIME AS OF），并设置 State TTL；反压与扩缩容：监控 backpressure、记录堆积；热点 Key 采用 KeyBy+盐值 打散；任务支持 弹性并行度。落库：Upsert-Kafka→Doris/ClickHouse，或 Two-Phase Commit sink 保证 Exactly-once；幂等键（如 (biz_id, window_end)）避免重复。
稳定可靠：Exactly-once：Source 支持读已提交、Checkpoints/Savepoints、2PC Sink；去重：基于唯一业务键 + ROW_NUMBER()（窗口内）过滤；回溯/补偿：保留 Kafka 保留期，按 Offset 回放；多层监控：端到端延迟、吞吐、反压、Checkpoint 时间；指标自监控（产出条数/窗口完整性）。
Flink SQL 示例（窗口聚合与去重）：

CREATE TABLE fact_stream (..., event_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL '30' SECOND) WITH (...);

-- 窗口聚合 + 幂等键（biz_id, window_end）
INSERT INTO rt_metrics
SELECT biz_id,
       WINDOW_END AS window_end,
       COUNT(*) AS cnt
FROM TABLE(TUMBLE(TABLE fact_stream, DESCRIPTOR(event_time), INTERVAL '1' MINUTE))
GROUP BY biz_id, WINDOW_END;

-- 乱序去重（取最新）
INSERT INTO rt_dedup
SELECT *
FROM (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY event_time DESC) AS rn
  FROM fact_stream
) WHERE rn = 1;

口径统一：把原子指标与公共维度沉淀在 DWD/DWS（批/流同一口径），实时仅做增量与窗口化；定期离线对账，保障一致性。

📌补充回答（注意要点/得分点清单）

• 明确端到端链路与每一层的职责；
• “不延迟”的真实含义：低延迟 + 可补偿，不要承诺绝对 0 延迟；
• 强调 Exactly-once/幂等/回放 与 Watermark/迟到处理；
• 指标口径批流一致、离线对账。

结尾：高频追问与标准答法速记

（A）如何确保指标口径一致？

• 建立指标中心（原子/派生/复合），并将口径固化在 DWD/DWS；
• 统一实体主键与时间语义；
• 实时链路复用同一口径定义（代码或函数库复用），并做 离线对账与灰度发布。

（B）SCD Type 1/2 的选择？

• Type 1：覆盖最新值，读快、存储省，适合报表快照较弱的场景；
• Type 2：保留历史，查询需按时间版本过滤，适合回溯/趋势分析；
• 也可混合（关键字段走 SCD2，非关键走 SCD1）。

（C）Join 倾斜与大宽表的取舍？

• 明细层尽量保持范式化 + 公共维表，服务层可适度反范式化；
• 大宽表适合高频查询与固定宽度指标，但要控制列膨胀与更新成本。

（D）如何做成本治理？

• 冷热分层、分区裁剪、列裁剪、压缩编码；
• 定期小文件合并（Iceberg/Hudi/Parquet Compact/Optimize）；
• 指标复用、去重开发，淘汰低价值表。

（E）如何落地质量与发布流程？

• 变更前评审/血缘影响分析 → 预发布灰度 → 在线对账 → 回滚预案；
• DQC 规则先跑后发，严重异常自动阻断发布。

通用答题模板（便于现场发挥）

开头自我定位

我主要负责数仓建模与实时指标\画像平台建设，擅长将分层建模 + 质量治理 + 实时可靠性与业务目标结合，沉淀规范与方法论。

项目表达（STAR）

• S/T：业务痛点与目标（口径不一致、时延高、成本高）；
• A：你的主导动作（建模/治理/实时/算法），给出技术与流程细节；
• R：量化结果（打平率/延迟/可用性/成本/转化）。

技术题关键句式

• 倾斜：先识别（Spark UI/TopK），再广播/预聚合/AQE，必要时盐值/自定义分区和业务消峰；
• 宽窄依赖：窄依赖无 Shuffle、宽依赖触发 Stage；在宽依赖前过滤+预聚合；
• 分层：ODS/DWD/DWS/ADS + DIM，收益在于复用、稳定、治理、成本；
• 画像：标签体系—生产链路—服务化—评估闭环，必要时上LR/XGBoost/Embedding；
• 质量治理：规则体系 + 编排告警 + 血缘 + 回溯 + 复盘；
• 实时：Watermark/迟到/Exactly-once/回放/维表 CDC，批流同口径对账。