大数据学习（139）-数仓设计

🍋🍋大数据学习🍋🍋

🔥系列专栏： 👑哲学语录: 用力所能及，改变世界。
💖如果觉得博主的文章还不错的话，请点赞👍+收藏⭐️+留言📝支持一下博主哦🤞

---

一、基础概念与架构设计

1. 什么是数据仓库？与数据库的核心区别是什么

   • 核心区别：

     维度	数据库（OLTP）	数据仓库（OLAP）
     用途	处理实时交易（增删改查）	支持历史数据分析与决策
     数据模型	第三范式（避免冗余）	星型 / 雪花模型（允许冗余）
     数据更新	实时更新	批量加载（每日 / 每周）
     查询特点	短事务、高并发	长查询、复杂分析

   • 答题要点：强调数据仓库的主题性、集成性、稳定性、时变性四大特性。

2. 数据仓库分层架构（ODS/DWD/DWS/ADS）的作用是什么

   • ODS（操作数据层）：原始数据镜像，保持数据原貌。
   • DWD（明细数据层）：清洗（去重 / 脱敏）、标准化（统一字段命名）。
   • DWS（汇总数据层）：按主题聚合（如用户日活按地域汇总）。
   • ADS（应用数据层）：直接服务于业务报表或 API。
   • 追问：为何需要分层？（答：解耦业务逻辑、避免重复计算、提升可维护性）。

3. 星型模型与雪花模型的区别，实际场景中如何选择

   • 星型模型：事实表直接关联维度表（冗余高、查询快），适合报表场景。
   • 雪花模型：维度表进一步规范化（冗余低、维护复杂），适合 OLAP 分析。
   • 案例：电商订单分析优先用星型模型，因查询性能更重要；金融风控数据因合规要求高，可用雪花模型。

二、建模与设计实践

1. 如何设计一张事实表

   • 关键步骤：
     1. 确定业务过程（如 “用户下单”）。
     2. 选择粒度（如 “每笔订单” 或 “每日订单汇总”）。
     3. 关联维度（时间、用户、商品、地域等）。
     4. 确定度量（订单金额、数量、折扣等）。
   • 示例：电商订单事实表粒度为 “单笔订单”，维度包括日期、用户 ID、商品 ID，度量为实付金额、优惠金额。

2. 缓慢变化维（SCD）的处理方式有哪些

   • SCD1：覆盖旧值（不保留历史，如用户最新手机号）。
   • SCD2：新增记录（保留历史，如用户地址变更时插入新行）。
   • SCD3：用字段记录新旧值（如 “当前部门” 和 “原部门”）。
   • 场景：用户性别属 SCD1（几乎不变），职位属 SCD2（需追踪变更历史）。

3. 拉链表的设计原理与适用场景

   • 原理：通过start_date和end_date标记数据有效期，每日仅更新变化记录。
   • 场景：客户信息、产品档案等变更频率低但需保留历史的维度表。
   • 示例 SQL：

     -- 插入新记录或更新旧记录状态
     INSERT INTO customer_zip
     SELECT id, name, address, current_date, '9999-12-31',CASE WHEN old.end_date = '9999-12-31' THEN 'N' ELSE 'Y' END
     FROM stage_customer sc
     LEFT JOIN customer_zip old ON sc.id = old.id AND old.end_date = '9999-12-31'
     

三、ETL 与性能优化

1. ETL 过程中如何处理缓慢变化维和拉链表

   • SCD2 处理：通过MERGE语句比较源数据与目标表，新增记录时标记旧记录end_date。
   • 拉链表更新：每日扫描变化数据，关闭旧记录有效期并插入新记录。

2. 数据仓库中如何优化大表 JOIN 性能

   • 分桶 JOIN：在 Hive 中按关联字段分桶（CLUSTER BY id），使相同 ID 的数据分布在同一节点。
   • 小表广播：Spark 中使用broadcast将小表分发到所有节点，避免 Shuffle（join(broadcast(smallTable))）。
   • 分区裁剪：在 WHERE 条件中添加分区过滤（如dt='2025-06-12'），减少扫描数据量。

3. 数据倾斜的常见原因及解决方案

   • 原因：某一 Key 数据量过大（如订单表中 “未分类” 商品 ID 占比 90%）。
   • 方案：
     • 拆分热点 Key：将key=A临时改为key=A_1和key=A_2，分散到多个 Task。
     • 优化 SQL：避免count(distinct)（改用group by + count后聚合）。

四、工具与实战经验

1. Hive 与 Spark SQL 的性能差异及适用场景？

   • Hive：基于 MapReduce，适合离线批处理（T+1 报表），吞吐量高但延迟大。
   • Spark SQL：内存计算，适合实时分析（分钟级响应），支持流处理（Structured Streaming）。
   • 案例：月度财务报表用 Hive，用户行为实时分析用 Spark。

2. 如何监控数据仓库任务的健康状态？

   • 指标：任务耗时波动（如超过历史均值 20%）、失败重试次数、数据产出延迟。
   • 工具：用 Airflow 监控 DAG 状态，结合 Prometheus+Grafana 绘制任务耗时趋势图。

3. 生产环境中数据仓库故障的应急处理流程

   • 根因分析（如 HDFS 磁盘故障导致写入失败）与预防措施（增加磁盘监控告警）。
   • 临时解决方案（如手动重跑任务、使用备份数据）。
   • 查看日志（YARN 任务日志、ETL 脚本输出）定位错误。
   • 确认故障范围（如某张表数据未更新）。

五、高级概念与架构演进

1. 湖仓一体（Lakehouse）与传统数据仓库的区别

   • 传统数仓：数据需提前建模，存储与计算耦合（如 Hive 表）。
   • 湖仓一体：融合数据湖（存储原始数据）与数仓（结构化分析），支持流式写入与 SQL 查询（如 Delta Lake+Spark）。

2. 实时数据仓库的技术架构如何设计

   • 典型架构：
     • 数据源：Kafka（日志）、Canal（数据库变更）。
     • 计算层：Flink（实时 ETL）、Spark Streaming（准实时）。
     • 存储层：HBase（明细数据）、ClickHouse（聚合查询）。
     • 应用层：实时报表（Superset）、实时告警（规则引擎）。

3. 数据治理在数据仓库中的实践方式

   • 元数据管理：用 Atlas 记录表结构、血缘关系（如 A 表数据来自 B 表和 C 表的 JOIN）。
   • 数据质量：设置规则（如订单金额必须 > 0），失败时触发告警。
   • 权限管控：通过 Ranger 控制用户对表的读写权限（如财务部门只能访问财务相关表）。

六、设计思路

1. 如果让你设计一个电商数据仓库，你会如何规划主题域？

   • 主题域划分：用户域（用户画像）、商品域（商品分类）、交易域（订单 / 支付）、营销域（活动 / 优惠券）。

2. 如何优化数据仓库的存储成本？

   • 冷数据分层：将 1 年前的数据归档到 HDFS 冷存储层（-Ddfs.storage.policy=COLD）。
   • 压缩与分桶：用 ORC 格式（比 Parquet 压缩比更高），按日期分桶减少扫描范围。

3. 数据仓库中的一致性哈希如何应用？

   • 场景：分库分表时确保相同用户 ID 路由到同一节点，避免跨节点 JOIN（如用户行为明细表按 user_id 哈希分桶）。