聊聊数据仓库中的缓慢变化维度（SCD）

虽然我的主业是实时计算和批量计算，并不是数仓，但是在日常工作中绝对少不了与数仓打交道。并且我也算是参与过离线数仓建设的，维度建模的基础还是不能忘。本文就作为一篇抄书笔记吧。

顾名思义，缓慢变化维度（slowly changing dimension, SCD）就是数据仓库维度表中，那些随时间变化比较不明显，但仍然会发生变化的维度。考虑以下两个情境：

处理缓慢变化维度是Kimball数仓体系中永恒的话题，因为数据仓库的本质，以及维度表在维度建模中的基础作用，我们几乎总是要跟踪维度的变更（change tracking），以保留历史，并提供准确的查询和分析结果。在《The Data Warehouse Toolkit, 3rd Edition》一书的第5章，Kimball提出了多种缓慢变化维度的类型和处理方法，其中前五种是原生的，后面的方法都是混合方法（hybrid techniques），因此下面来看看前五种，即Type 0~Type 4。

一种特殊的SCD类型，即不管维度属性的实际值如何变化，数仓中维度的值都会维持第一次的值。它主要适用于那些本身含义就是“原始值”（original）的维度，比如在用户维度表中，用户注册时使用的原始用户名（original_user_name）。如果它发生变化，那么变化后的值是无效的，会被抛弃。

最简单的SCD类型，即一旦维度属性的实际值发生变化，就会直接覆写到数仓中。数仓中的维度属性总是且仅仅保存着最近一次变更的值（most recent assignment）。书中的例子如下：

在上图中，Department Name维度发生了变化，并且新值直接覆盖了上一次的值。虽然它很容易实现，但是这样做会丢掉所有变更历史，并且在跨时域查询时，有可能会得到错误的结果。在实际 *** 作中，这种方式几乎总是一种不良设计。

最主要、最常用的SCD类型，在我们日常以Hive为基础的数仓建设过程中，体现为拉链表技术。

这种类型在维度表中添加两个辅助列：该行的有效日期（effective date）和过期日期（expiration date），分别指示该行从哪个时间点开始生效，以及在哪个时间点过后会变为无效。每当一个或多个维度发生更改时，就创建一个新的行，新行包含有修改后的维度值，而旧行包含有修改前的维度值，且旧行的过期日期也会同步修改。书中的例子如下：

在上图中，当前有效列（current列）的过期日期会被记录为9999-12-31。当Department Name维度变化时，旧有的Product Key为12345的行的过期日期被更新为修改日期，并且新建了一个Key为25984的行，包含新的数据。

需要注意的是，这里的Product Key是所谓代理键（surrogate key），即不表示具体业务含义，而只是代表表内数据行的唯一ID。在处理SCD时，代理键可以直接用来区分同一自然键（natural key）的数据的新旧版本。上图中的SKU就是自然键。

这种类型的SCD处理方式能够非常有效且精确地保留历史与反映变更，但缺点是会造成数据的膨胀，因为即使只有一个维度变化，也要创建新行。

Type 2虽然非常好，但是当要在同一个时间维度内把新值和旧值关联起来时，就没有那么方便了。比如在上一节的表中，如果查询2013年2月1日以后的记录，就只能查到Department Name为“Strategy”的记录，而“Education”就被屏蔽了。Type 3就是一种与Type 2互补的类型。在Type 3的处理方法中，不会添加新行，而会添加一个新的属性列，该属性列中保存有对应维度的上一次变化的值。书中的例子如下：

在上图中新增了一个名称为“Prior Department Name”的列，保存着上一次变更的值。这样也解决了Type 2的数据膨胀问题，但是就只能保存一次变更历史，称为“变更现实”（alternate realities）。

另外仍然要注意，如果维度表中的许多维度都会发生类似的变更，那么就要新增很多列，这显然不太靠谱。所以这种类型经常用来处理那种变化可预测的（predictable）、“牵一发而动全身”的少数SCD。

当然，也可以根据实际需求新增多个列来保存多次变更历史：

当维度的变化没有那么“缓慢”时，前面三种类型的处理就都显得力不从心了（特别是对于规模非常大的维度表，比如有百万甚至千万行）。这种维度一般就不再称为SCD，而称为“快速变化维度”（rapidly changing dimensions, RCD）。当RCD的规模比较小时，还能够采用Type 2或者Type 3来撑着，但规模很大时，就只能采用Type 4了。Type 4的方式是将那些快速变化的维度从原来的大维度表中拆分出来单独处理，是为微维度（mini-dimension）。

以书中的内容为例，如果顾客维度中有一部分人口统计学（demographic）维度是RCD，就将它们拆成单独的维度表：

其中，微维度表的维度最好是少量、分段的（banded）离散值，例如：

下表仍然来自《数据仓库工具箱》的原文。注意其中除了Type 0~4之外，还有三种混合方式，即Type 5~7。

最后善意提醒，《数据仓库工具箱（第三版）》这本书一定要读英文原版，千万不要读中译本。中译本错误百出，很多地方读起来都不通顺，令人窒息。

民那晚安~

数据库慢一般有三种情况

逐渐变慢

突然变慢

不定时变慢

第一种情况 逐渐变慢 要建立一个长期的监控机制 比如 写个shell脚本每天的忙时(通常 ~ etc )定时收集os neork db的信息 每个星期出report对收集到的信息进行分析 这些数据的积累 可以决定后期的优化决策 并且可以是DBA说服manager采用自己决策的重要数据 DBA的价值 就在每个星期的report中体现

第二种情况 突然变慢 也是最容易解决的 先从业务的角度看是DB的使用跟以前有何不同 然后做进一步判断 硬件/网络故障通常也会引起DB性能的突然下降

第一步: 察看DB/OS/NEORK的系统log 排除硬件/网络问题

第二步 察看数据库的等待事件 根据等待事件来判断可能出问题的环节 如果 没有等待事件 可以排除数据库的问题 如果有等待时间 根据不同的等待事件 来找引起这些事件的根源

比如latch free等跟SQL parse有关系的等待事件 OS的表现是CPU 的占用率高

db file scattered read等跟SQL disk read有关系的等待时间 OS的表现是iostat可以看到磁盘读写量增加

第三步: 察看os的信息 CPU/IO/MEMORY等

a Cpu 的占用率

CPU占用率与数据库性能不成反比 CPU占用率高 不能说明数据库性能慢 通常情况 一个优化很好 而且业务量确实很大的数据库 CPU的占用率都会高 而且会平均分布在每个进程上 反过来 CPU的占用率都会高也不代表数据库性能就好 要结合数据库的等待事件来判断CPU占用率高是否合理

如果某个进程的cpu占用高 肯定是这个进程有问题 如果 不是oracle的进程 可以让application察看是否程序有死循环等漏洞 如果 是oracle的进程 可以根据pid查找oracle数据字典看看这个进程的发起程序 正在执行的sql语句 以及等待事件 然后 不同情况使用不同的方法来解决

b IO

排除硬件的IO问题 数据库突然变慢 一般来说 都是一个或几个SQL语句引起的

如果IO很频繁 可以通过优化disk reads高的TOP SQL来解决 当然这也是解决IO问题的最笨也是最有效的办法

OS以及存储的配置也是影响IO的一个重要的原因

比如 最常见的HP unix下异步IO的问题 如果DBA GROUP没有MLOCK的权限 ORACLE是不使用AIO的 偏偏OS与DB的两方的admin如果配合不够好地话 这个配置就很容易给漏掉了

c Memory

第二种情况与memory的关系比较小 只要SGA区配置合理没有变化 一般来说 只要不是Application Memory leak 不会引起突然变慢的现象

第三种情况 不定时变慢 是最难解决的 现场出现的问题原因也是五花八门千奇百怪 最重要的是 出现慢的现象时 以最快的速度抓取到最多的信息以供分析 先写好抓取数据的shell 脚本 并在现象发生时及时按下回车键

一个例子

数据库突然变慢

背景: 一个新应用上线后 数据库突然变慢

第一步 调查新应用

据开发人员讲新应用访问的都是新建立的表 表的数据量很小 没有复杂的SQL查询

查询 v$sqlarea 分别按照disk_reads / buffer_gets / executions 排序 TOP SQL 中没有新应用的SQL 排除新应用数据库访问照成的性能问题

第二步 察看数据库log/ OS log

数据库log中可以看到大量的ORA 错误 以及大量的dump文件 分析dump文件(时间久了 没有dump文件可参考 具体细节没法描述下来 ) 发现是新应用通过dblink访问remote DB时生成的dump文件 应用开发人说没法修改 Oracle也没有相应的patch解决

OS log中没有错误信息

第三步 察看statspack report

从wait events中看到 Top event是 buffer busy waits db file parallel write 等于IO相关的等待事件

从buffer busy waits 的统计信息来看 是等待data block

还有些physical reads等信息与从前比没有太多的异常

Tablespace 的IO reads/writes也没有异常 但是wait明显增加

初步确定是IO问题

第四步 察看OS的信息

top 命令(输出为实验室数据 仅作格式参考)

load averages: : :

processes: sleeping zombie stopped on cpu

CPU states: % idle % user % kernel % iowait % swap

Memory: M real M free M swap in use M swap free

PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU MAND

a K K cpu/ : % top

mpgj M K sleep : % view_server

当时现场数据显示 iowait 值与以前相比大很多 没有异常进程

sar –d (输出为实验室数据 仅作格式参考)

SunOS sc Generic_ sun u / /

: : device %busy avque r+w/s blks/s avwait avserv

sd

sd a

sd b

sd c

sd g

当时现场数据显示 放数据文件的设备 avwait avque blks/s值偏大

第五步 察看数据库的等待事件

一个大业务量的数据库如果性能不好的话 一般来说都会有大量的等待事件 上百个等待事件很常见 我通常会按照EVENT进行group

Select count(*) event from v$session_wait where event not in ( *** on timer pmon timer rdbms ipc message SQL*Net message from client ) group by event order by desc

输出结果显示最多的等待事件是buffer busy waits

进一步分析 找出等待的原因

Select count(*) p p p from v$session_wait where event = buffer busy waits group by p p p

在buffer busy waits等待事件中

P = file#

P = block#

P = id ( 此id对应为等待的原因)

按照p p p group是为了明确buffer busy waits的等待集中在哪些对象上

Metalink对buffer busy waits等待事件的描述有如下一段话

If P shows that the buffer busy wait is waiting for a block read to plete then the blocking session is likely to be waiting on an IO wait (eg: db file sequential read or db file scattered read for the same file# and block#

输出结果显示 等待分布在多个不同的对象上 等待原因为 waiting for a block read to plete 进一步分析为IO的问题

如果 buffer busy waits等待集中在某个对象上 说明有hot block 通过重新rebuild这个对象增加freelist来解决 RAC环境增加freelist group

通过以下SQL可以找到具体的object

Select owner segment_name segment_type from dba_extents where file_id=P and P beeen block_id and block_id+blocks

P P 是上面v$session_wait查出的具体的值

第六步 明确原因 找出解决步骤

分析

磁盘的IO流量增加

磁盘的IO等待增加

DB的IO流量没有增加

DB的IO等待增加

由 可以推出 有数据库以外的IO访问磁盘

察看磁盘配置 该VG只存放了数据库数据文件和数据库系统文件 排除数据文件 产生IO的是数据库系统文件

数据库系统文件一般来说不会产生IO 有IO读写的地方只有log和dump文件

结论 ora 产生的大量core dump文件堵塞IO

解决办法

消除ora (应用不改的情况下 无法解决)

把dump目录指向别的VG

让oracle尽量少的去写core dump文件

background_core_dump = partial

lishixinzhi/Article/program/Oracle/201311/18969

---