作为快手数据研发工程师，你需要为快手短视频业务设计一个数据仓库模型，以支持用户增长和内容推荐的分析需求。请详细描述你的数据仓库分层结构（ODS、DWD、DWS、ADS）及其设计原则，并针对“用户观看行为”设计一个DWD层的核心事实表。
快手数据研发工程师难度：中等
答案
快手数据研发工程师面试辅导：数据仓库模型设计
1) 【一句话结论】
针对快手短视频业务，数据仓库应采用标准的四层分层结构（ODS、DWD、DWS、ADS），以Kimball维度建模为核心，确保数据的高效、一致性与可追溯性，其中DWD层是支撑用户增长和内容推荐分析的原子级事实数据源。
2) 【原理/概念讲解】
数据仓库分层结构的设计，是为了解决数据冗余、计算逻辑混乱、查询性能低下等问题，确保数据资产的健康和高效利用。
四层结构详解：
| 层级 | 名称 | 核心功能 | 设计原则/类比 |
|---|---|---|---|
| ODS | Operational Data Store (操作数据层) | 原始数据接入、存储。 | 保持原貌：数据不做任何清洗、转换或聚合，仅进行压缩和分区。就像是原始的监控录像。 |
| DWD | Data Warehouse Detail (数据明细层) | 数据清洗、标准化、维度建模。 | 原子性与一致性：基于业务过程（如观看、点赞、评论）构建事实表，并关联一致性维度。这是数据仓库的基石，必须是“单源真相”。 |
| DWS | Data Warehouse Service (数据服务层) | 基于主题域的轻度聚合。 | 主题化与高性能：将DWD的原子数据按主题（如用户、内容、作者）进行预聚合，生成宽表或指标快照，用于加速查询。 |
| ADS | Application Data Service (应用数据层) | 面向具体应用场景的数据集市。 | 定制化与易用性：为BI报表、推荐系统特征工程、A/B测试结果展示等直接提供数据，通常是高度定制化的结果集。 |
设计原则：
- 高内聚低耦合： 确保每层职责单一，层与层之间依赖清晰。
- 数据可回溯性： 任何ADS层的指标都必须能够追溯到DWD层的原子数据，最终追溯到ODS层的原始记录。
- 一致性（Conformed Dimensions）： 在DWD层定义统一的维度（如用户维度、时间维度），确保在DWS层进行跨主题分析时，指标口径一致。
- 性能与成本平衡： ODS和DWD追求完整性，DWS和ADS追求查询性能，通过合理的存储格式（如Parquet/ORC）和分区策略实现平衡。
3) 【对比与适用场景】
| 特性 | DWD (明细层) | DWS (服务层) | ADS (应用层) |
|---|---|---|---|
| 定义 | 业务过程的原子级记录 | 主题域的指标快照/宽表 | 最终应用所需的结果集 |
| 粒度 | 最细（行级别事件） | 中等（日/小时级别聚合） | 粗（报表所需指标） |
| 数据量 | 最大 | 较大 | 最小 |
| 主要功能 | 事实与维度关联、数据清洗 | 预计算、指标沉淀、加速查询 | 支撑业务决策、特征工程 |
| 适用场景 | 临时查询、数据挖掘、模型训练 | 业务监控、趋势分析、指标校验 | BI报表、推荐系统特征输入 |
| 注意点 | 必须保证数据质量和一致性 | 避免过度聚合，保持一定灵活性 | 避免重复计算，逻辑应尽量简单 |
4) 【示例】
针对快手“用户观看行为”设计一个DWD层的核心事实表，以支持用户增长（留存、漏斗）和内容推荐（CTR、完播率）分析。
我们采用事务型事实表设计，粒度为“一次视频曝光到结束（或中断）的完整会话”。
DWD核心事实表设计：DWD_Video_Watch_Fact
| 字段名 | 字段类型 | 描述 | 作用/关联 |
|---|---|---|---|
watch_sk | BIGINT | 观看会话主键（唯一标识） | 唯一性标识 |
user_id | BIGINT | 用户ID | 维度外键：关联用户维度表 |
video_id | BIGINT | 视频内容ID | 维度外键：关联内容维度表 |
author_id | BIGINT | 视频作者ID | 维度外键：关联作者维度表 |
time_id | INT | 观看日期ID | 维度外键：关联时间维度表 |
device_id | INT | 设备信息ID | 维度外键：关联设备维度表 |
reco_strategy_id | INT | 推荐策略ID | 维度外键：支持A/B测试分析 |
start_ts | TIMESTAMP | 观看开始时间戳 | 分区键（通常按天或小时） |
watch_duration_sec | INT | 实际观看时长（秒） | 事实指标：核心指标 |
video_total_duration_sec | INT | 视频总时长（秒） | 事实指标：用于计算完播率 |
is_completed | BOOLEAN | 是否观看完成（>95%） | 事实指标：完播率计算 |
is_like | BOOLEAN | 是否点赞 | 事实指标：互动行为 |
is_share | BOOLEAN | 是否分享 | 事实指标：互动行为 |
exit_reason | STRING | 退出原因（如：滑走、退出App） | 事实指标：漏斗分析 |
伪代码（Hive/Spark SQL）：
CREATE TABLE DWD_Video_Watch_Fact (
-- Keys and Dimensions
user_id BIGINT,
video_id BIGINT,
reco_strategy_id INT,
-- Facts/Metrics
watch_duration_sec INT,
video_total_duration_sec INT,
is_completed BOOLEAN,
is_like BOOLEAN,
...
)
PARTITIONED BY (dt STRING COMMENT '分区日期', hour STRING COMMENT '分区小时')
STORED AS ORC;
5) 【面试口播版答案】
“面试官您好，针对快手短视频业务，我设计的数仓模型将采用标准的四层架构，即ODS、DWD、DWS和ADS，核心目标是确保数据资产的一致性、高性能和可追溯性。
首先，ODS层负责原始日志的接入和存储。
关键在于DWD明细层。这是我们进行维度建模的核心，我将基于业务过程构建事实表。针对用户增长和推荐分析，最核心的是用户观看行为事实表。这张表以‘单次观看会话’为粒度，包含用户ID、视频ID、推荐策略ID等维度外键，以及观看时长、是否点赞、退出原因等原子事实。通过关联统一的维度表，它成为计算所有核心指标的单一数据源。
接着，DWS服务层会基于DWD进行主题域聚合，例如生成‘用户日行为快照’或‘内容日表现宽表’，用于加速DAU、留存率、内容CTR等指标的查询。
最后，ADS应用层则面向具体应用，比如为BI看板提供最终的留存漏斗数据，或为推荐系统的离线特征工程提供高维度的聚合特征。
这种分层结构确保了底层数据质量，中层逻辑清晰，上层应用高效，能够有力支撑快手高并发下的用户增长和推荐迭代分析。”
6) 【追问清单】
| 追问问题 | 回答要点 |
|---|---|
| Q1： 如何处理维度变化，例如用户标签（年龄段）发生变化？ | 采用**慢变维度（SCD）**策略。对于历史分析影响不大的属性（如昵称），使用SCD Type 1覆盖；对于需要保留历史快照的属性（如用户首次注册渠道），使用SCD Type 2，通过增加起始/结束日期和版本号来追踪变化。 |
| Q2： 快手对实时性要求高，如何将实时数据融入这个离线数仓体系？ | 引入Lambda或Kappa架构。实时侧通过Flink/Kafka处理，将实时计算结果直接写入实时数仓（如ClickHouse），并与离线DWS/ADS层进行指标对齐，实现T+0和T+1数据的统一查询。 |
| Q3： 如何确保DWD层数据质量和一致性？ | 建立数据质量监控体系。在ETL过程中，对关键字段（如user_id）进行非空校验、范围校验和唯一性校验。同时，通过一致性维度设计，确保所有事实表引用的维度口径统一。 |
| Q4： 为什么不直接在DWD层做宽表，而是要拆分出DWS层？ | DWD追求原子性和灵活性，如果直接做宽表会导致数据冗余和计算资源浪费。DWS是为了主题化和性能优化，它牺牲了部分灵活性，换取了高频查询的效率，避免了每次查询都扫描巨大的DWD事实表。 |
7) 【常见坑/雷区】
- 混淆分层职责： 在DWD层进行复杂的业务聚合或在DWS层存储原子数据。
- 后果： 导致数据逻辑混乱，难以维护，且重复计算严重。
- 缺乏一致性维度： 不同的事实表引用了不同口径的维度表（例如，用户维度在不同主题下字段定义不一致）。
- 后果： 跨主题分析（如分析不同推荐策略下的用户留存）时，指标无法对齐，分析结果错误。
- DWD粒度设计过粗或过细： 例如，将“用户日汇总”作为DWD事实表，或将“每毫秒的播放心跳”作为DWD事实表。
- 后果： 粒度过粗无法支持细致的漏斗分析；粒度过细则导致数据量爆炸，查询性能极差。
- 过度设计ADS层： 为每一个报表都定制一张ADS表，导致ADS层表数量失控，维护成本极高。
- 后果： 资源浪费，且一旦底层逻辑变化，需要修改大量ADS表。
- 忽略数据血缘和元数据管理： 无法追踪指标的计算路径和数据来源。
- 后果： 无法快速定位数据错误，无法评估数据变更的影响范围。