数仓之缓慢变化维(拉链表)

文章介绍了缓慢变化维(SCD)的概念,特别是在数据仓库中的应用。拉链表作为一种解决方案,用于处理维度表中数据的历史变化,适用于存储空间大且有字段更新的场景,如用户地址或产品描述等。然而,拉链表也存在查询性能低和维护困难的缺点。为优化查询,文章提出了对start_date和end_date建立索引以及提供近期数据子集等策略。此外,文章还提到了流水表、全量表和增量表的区别和应用场景。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

缓慢变化维

  1. 什么是缓慢变化维?
    缓慢变化维,简称SCD(Slowly Changing Dimensions)
    一些维度表的数据不是静态的,而是会随着时间而缓慢地变化(这里的缓慢是相对事实表而言,事实表数据变化的速度比维度表快)这种随着时间发生变化的维度称之为缓慢变化维,把处理维度表数据历史变化的问题为缓慢变化维问题,简称SCD问题。
    具体可参考:https://cloud.tencent.com/developer/article/1780529

拉链表 – 理论

缓慢变化维解决方案:
  • SCD解决方案 - 保留原始值
    某一个属性值绝不会变化。事实表始终按照该原始值进行分组。例如:
    出生日期的数据,始终按照用户第一次填写的数据为准。

  • SCD解决方案 - 改写属性值
    对其相应需要重写维度行中的旧值,以当前值替换。因此其始终反映最近的情况。
    当一个维度值的数据源发生变化,并且不需要在维度表中保留变化历史时,通常用新数据来覆盖旧数据。这样的处理使属性所反映的中是最新的赋值。

  • SCD解决方案 - 增加维度新行
    数据仓库系统的目标之一是正确地表示历史。典型代表就是拉链表。
    保留历史的数据,并插入新的数据。例如: 用户维度表

拉链表场景:

储存空间大
字段变更:上亿数据量,部分字段更新 (用户的地址,产品的描述信息,品牌信息等等;)
查询历史状态(病毒第一次出现日期,最后一次出现日期)
统计历史行为次数

拉链表缺点:

join消耗资源
不容易维护,如果有一天数据错误从这天到现在的数据都要重新跑
查询性能低,存放N年数据,表数据量很大影响性能

拉链表查询优化:

拉链表当然也会遇到查询性能的问题,比如说我们存放了5年的拉链数据,那么这张表势必会比较大,
当查询的时候性能就比较低了,个人认为两个思路来解决:

1.在一些查询引擎中,我们对start_date和end_date做索引,这样能提高不少性能。
2.保留部分历史数据,比如说我们一张表里面存放全量的拉链表数据,然后再对外暴露一张只提供近3个月数据的拉链表。
3. 查询检索性能没有明显提高,但可以将start_dt和end_dt当成分区字段,已提高检索性能;

拉链表 – 示例

sql

测试数据:

ods
('001', '待审核', '2019-12-18', '2019-12-20'),
('002', '待售', '2019-12-19', '2019-12-20'),
('003', '在售', '2019-12-20', '2019-12-20'),
('004', '已删除', '2019-12-15', '2019-12-20'),
('001', '待售', '2019-12-18', '2019-12-21'),
('005', '待审核', '2019-12-21', '2019-12-21'),
('006', '待审核', '2019-12-21', '2019-12-21');

dwd
('001', '待审核', '2019-12-18', '2019-12-20'),
('002', '待售', '2019-12-19', '2019-12-20'),
('003', '在售', '2019-12-20', '2019-12-20'),
('004', '已删除', '2019-12-15', '2019-12-20')

ods表:

-- 创建ods层表
create table if not exists ods_product_2(
  goods_id string,        -- 商品编号
  goods_status string,    -- 商品状态
  createtime string,      -- 商品创建时间
  modifytime string       -- 商品修改时间
)
partitioned by (dt string)
row format delimited fields terminated by ',' stored as TEXTFILE;

dw表:

-- dw层 创建拉链表
create table if not exists dw_product_2(
  goods_id string,        -- 商品编号
  goods_status string,    -- 商品状态
  createtime string,      -- 商品创建时间
  modifytime string,       -- 商品修改时间
  dw_start_date string,   -- 生效日期
  dw_end_date string      -- 失效日期
)
row format delimited fields terminated by ',' stored as TEXTFILE;

拉链逻辑:

在原有dw层表上,添加额外的两列
生效日期(dw_start_date)
失效日期(dw_end_date)
只同步当天修改的数据到ods层

拉链表算法实现
编写SQL处理当天最新的数据(新添加的数据和修改过的数据)
编写SQL处理dw层历史数据,重新计算之前的dw_end_date
拉链表的数据为:当天最新的数据 UNION ALL 历史数据

-- ods 21日新增数据 拉链 dwd 20日数据
SELECT
    t1.goods_id,t1.goods_status,t1.createtime,t1.modifytime,t1.dw_start_date,
    CASE WHEN (t2.goods_id IS NOT NULL AND t1.dw_end_date > '2019-12-21') THEN '2019-12-21' --这里保证只修改最新的那条数据
        ELSE t1.dw_end_date
        END AS dw_end_date
FROM dw_product_2 t1
LEFT JOIN (SELECT * FROM ods_product_2 WHERE dt='2019-12-21') t2 -- ods昨天数据和今天的dw数据关联,只有修改的
ON t1.goods_id = t2.goods_id
union ALL
select
  goods_id,                -- 商品编号
  goods_status,            -- 商品状态
  createtime,              -- 商品创建时间
  modifytime,              -- 商品修改时间
  modifytime as dw_start_date,  -- 生效日期
   '9999-12-31' as dw_end_date   -- 失效日期
from
  ods_product_2 where dt='2019-12-21'    -- 只有新增和修改的数据
order by dw_start_date, goods_id;

在这里插入图片描述

查询方式
-- 获取2019-12-20日的历史快照数据
SELECT * FROM dw_product_2 WHERE dw_start_date<='2019-12-20' AND dw_end_date>'2019-12-20';
-- 获取最新的商品快照数据
SELECT * FROM dw_product_2 WHERE dw_end_date = '9999-12-31';

在这里插入图片描述

补充

流水表

流水表存放的是一个用户的变更记录,比如在一张流水表中,一天的数据中,会存放一个用户的每条修改记录,但是在拉链表中只有一条记录。
这是拉链表设计时需要注意的一个粒度问题。我们当然也可以设置的粒度更小一些,一般按天就足够。

全量表

每天的所有的最新状态的数据。
(1)全量表,有无变化,都要报
(2)每次上报的数据都是所有的数据(变化的 + 没有变化的)

增量表

新增数据,增量数据是上次导出之后的新数据。
(1)记录每次增加的量,而不是总量;
(2)流量是指在一定时间内的增量;
(3)流量一般设计成增量表(日报-常用、月报);
(4)流量和存量的区别:流量是增量;存量是总量;
(5)增量表,只报变化量,无变化不用报

在这里插入图片描述

<think>好的,我现在需要帮用户整理一份工程师面试中常见的SQL考题及答案。首先,我得回忆一下工程师面试通常考察哪些SQL知识点。工程师可能更关注复杂查询、性能优化、据建模、窗口函据清洗等方面的问题。 首先,用户需要的是常见的考题,所以应该覆盖基础到中高级的内容。比如,连接操作、聚合函、子查询、窗口函据去重、分页查询、日期处理、行列转换等。这些都是工作中常见的任务。 接下来,我需要考虑每个知识点对应的典型题目。比如,连接操作可能会涉及到内连接、左连接等;窗口函可能包括排名、分组聚合等。此外,中的优化问题,比如索引使用、查询性能优化,也是常见的面试题。 然后,每个题目需要附带答案,答案要准确且符合SQL标准。需要注意的是,不同的数据库系统可能有不同的语法,比如Hive SQL和传统的关系型数据库(如MySQL、PostgreSQL)在部分函上存在差异。用户提到的是工程师,可能更多涉及Hive或者Spark SQL,所以需要适当考虑这些方言,但通用SQL可能更稳妥。 此外,题目需要由浅入深,结构清晰。可能需要分为基础篇、进阶篇和应用篇,覆盖不同的难度层次,这样用户看起来更有条理。 现在,开始列举具体的问题: 基础部分: 1. 多连接:比如,查询每个部门的员工量,需要连接部门和员工。 2. 聚合函:计算每个部门的平均工资。 3. 去重:找出有销售记录的客户。 4. 条件过滤:查找工资高于平均工资的员工。 5. 分组过滤:找出销售额超过10000的部门。 进阶部分: 1. 窗口函:计算每个部门工资排名前三的员工。 2. 日期函:查询近30天的订单。 3. 行转列:将月份作为列显示销售额。 4. 递归查询:处理层级据,如员工上下级关系。 5. 性能优化:分析查询慢的原因,如何优化。 应用场景: 1. 据清洗:处理重复据。 2. 留存率计算:次日、7日留存。 3. 连续登录用户:连续3天登录的用户。 4. 拉链应用:如何查询某历史时间点的状态。 5. 缓慢变化维处理:Type II的处理方法。 接下来,每个题目需要写出具体的SQL示例,并确保语法正确。比如,窗口函中使用ROW_NUMBER(),日期函中使用CURRENT_DATE进行日期计算,行转列可能需要使用CASE WHEN或者PIVOT(但不同数据库支持不同,这里可能需要用标准方法)。 同时,答案要解释关键点,比如在性能优化中,提到索引、避免全扫描等。 需要注意的潜在问题:用户可能需要答案简洁明了,直接给出SQL语句和解释。但有些问题可能有多种解法,需要选择最常见或最优的方式。比如,去重可以使用DISTINCT或GROUP BY,但这里可能需要说明两者的区别。 另外,中常用的比如Hive的分区、分桶,或者使用EXPLAIN查看执行计划,也可能被提到,但可能属于更高级的问题。在整理时,可能需要适当涵盖这些点。 最后,检查每个SQL的语法是否正确,特别是关于别名、子查询的引用、窗口函的正确使用。例如,在窗口函中,PARTITION BY和ORDER BY是否正确,别名是否正确引用。 总结下来,需要整理大约15-20个问题,覆盖基础、进阶和应用场景,确保每个问题有答案和解析,帮助用户准备面试。</think>以下为数据仓库工程师面试常见的SQL考题及参考答案,按难度和场景分类整理: --- ### **一、基础篇** #### 1. 多关联查询 **题目**:查询每个部门的员工量(`department`有字段`dept_id, dept_name`,`employee`有字段`emp_id, emp_name, dept_id`)。 ```sql SELECT d.dept_name, COUNT(e.emp_id) AS emp_count FROM department d LEFT JOIN employee e ON d.dept_id = e.dept_id GROUP BY d.dept_name; ``` **关键点**:使用`LEFT JOIN`保证部门无员工时显示0。 --- #### 2. 聚合函与筛选 **题目**:统计每个部门的平均工资(`salary`含`emp_id, salary, month`),且仅显示平均工资>5000的部门。 ```sql SELECT dept_id, AVG(salary) AS avg_salary FROM employee e JOIN salary s ON e.emp_id = s.emp_id GROUP BY dept_id HAVING AVG(salary) > 5000; ``` **关键点**:`HAVING`用于分组后筛选,不可用`WHERE`替代。 --- #### 3. 去重与子查询 **题目**:查询有销售记录的客户ID(`sales`含重复的`customer_id`)。 ```sql SELECT DISTINCT customer_id FROM sales; -- 或 SELECT customer_id FROM sales GROUP BY customer_id; ``` **区别**:`DISTINCT`去重,`GROUP BY`可结合聚合函扩展。 --- ### **二、进阶篇** #### 4. 窗口函(排名场景) **题目**:查询每个部门工资排名前三的员工。 ```sql SELECT * FROM ( SELECT emp_name, dept_id, salary, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn FROM employee ) t WHERE rn <= 3; ``` **关键点**:`ROW_NUMBER()`生成唯一排名,`RANK()`允许并列。 --- #### 5. 日期处理 **题目**:查询最近30天内的订单(`orders`含`order_id, order_date`)。 ```sql SELECT order_id FROM orders WHERE order_date >= CURRENT_DATE - INTERVAL '30 days'; ``` **注意**:Hive中需用`date_sub(CURRENT_DATE(), 30)`。 --- #### 6. 行列转换(行转列) **题目**:将月度销售额从行格式转为列格式(原始`sales`含`year, month, amount`)。 ```sql SELECT year, MAX(CASE WHEN month=1 THEN amount END) AS Jan, MAX(CASE WHEN month=2 THEN amount END) AS Feb FROM sales GROUP BY year; ``` **扩展**:列转行可用`UNION ALL`或`LATERAL VIEW`(Hive)。 --- ### **三、应用场景篇** #### 7. 据清洗(去重保留最新记录) **题目**:`user_log`有重复的`user_id`,需保留`log_time`最新的一条。 ```sql DELETE FROM user_log WHERE (user_id, log_time) NOT IN ( SELECT user_id, MAX(log_time) FROM user_log GROUP BY user_id ); ``` **替代方案**:使用窗口函`ROW_NUMBER()`标记后删除。 --- #### 8. 留存率计算 **题目**:计算次日留存率(`login`含`user_id, login_date`)。 ```sql SELECT COUNT(DISTINCT d1.user_id) AS total_users, COUNT(DISTINCT d2.user_id) AS retained_users, retained_users / total_users AS retention_rate FROM login d1 LEFT JOIN login d2 ON d1.user_id = d2.user_id AND d2.login_date = DATE_ADD(d1.login_date, 1); ``` --- #### 9. 拉链查询历史状态 **题目**:查询用户2023-01-01的等级状态(`user_level`含`user_id, level, start_date, end_date`)。 ```sql SELECT user_id, level FROM user_level WHERE start_date <= '2023-01-01' AND end_date > '2023-01-01'; ``` **核心逻辑**:时间区间覆盖查询日期。 --- ### **四、性能优化篇** #### 10. 慢查询分析 **题目**:某查询`SELECT * FROM logs WHERE create_time > '2023-01-01'`执行慢,如何优化? **答案**: - 对`create_time`建索引。 - 避免`SELECT *`,改为指定字段。 - 若为Hive分区,按`create_time`分区。 --- ### **附:高频考点总结** | **类型** | **考点** | |----------------|--------------------------| | 基础语法 | JOIN、GROUP BY、HAVING | | 高级函 | 窗口函、日期函、CASE WHEN | | 场景设计 | 留存率、TopN、去重逻辑 | | 特性 | 拉链缓慢变化维、分区 | 建议结合具体业务场景练习,并理解执行计划(`EXPLAIN`命令)的使用。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值