摘要：指字段比较多的数据库表。通常是指业务主体相关的指标、维度、属性关联在一起的一张数据库表。宽表由于把不同的内容都放在同一张表，宽表已经不符合三范式的模型设计规范：
1.宽表_dw层
指字段比较多的数据库表。通常是指业务主体相关的指标、维度、属性关联在一起的一张数据库表。宽表由于把不同的内容都放在同一张表，宽表已经不符合三范式的模型设计规范：
坏处：数据有大量冗余好处：查询性能的提高和便捷，可以更好的利用大数据处理框架的处理能力，避免范式操作的过多关联操作，可以实现高度的并行化。宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提供数据挖掘模型训练过程中迭代计算的消息问题。
(1)宽表到底多宽
可以反着思考，宽表不应该包含什么数据。宽表不应该包含不属于它所在域的数据，例如会员域的宽表只应该包含会员相关的信息，同理我们的宽表是针对某一个域而言的，也就是说它是有边界的。只要不跨域，并且方便使用都是合理的。
(2)主次分类
假设我们做的是一个会员域的宽表，但是会员域是还是一个比较大的概念，所以我们还要发掘出我们这个表的主题，例如我们做的是一张会员域下的会员基本信息宽表，那么我们专注的肯定就是基本信息，例如会员信息打通。当让因为事宽表你可能还会冗余的其他信息进来，但是当这样的信息越来越多的时候，我们这张表的主题就越来越弱，所以我们就需要做拆分。
拆分可以让我们更加聚焦表的主题，对于数仓开发人员而言可以更好的维护、对于使用方而言可以更加清楚的理解这张表的主题。
(3)冷热分离
假设有一张宽表，里面有200个字段，有30张报表在使用它，但是我发现前面150个经常字段经常被使用，后面 50个字段只有一两张报表使用到了，那么我们就可以做一个冷热分离，将宽表拆分。
(4)稳定与不稳定分离
经常有这样的宽表，它依赖埋点数据，但是我们的埋点数据的特点就是量大，导致计算经常延迟，那么我们的宽表就会受影响，从而我们的报表就受影响，但是很多时候你发现报表根本没有用过埋点计算出来的指标，或者是只用了一两个。那我们可以将其拆分，如果报表没有使用到那就最好了，如果使用到了，那就后推，在报表层面上做关联，这样我们的埋点数据即使出不来，我们的报表数据还是可以看的。
2.拉链表
(1)什么是拉链表
(2)为什么要做拉链表
(3)如何使用拉链表
(4)拉链表形成过程
(5)制作拉链表
①首日装载
拉链表首日装载，需要进行初始化操作，具体工作为将截止到初始化当日的全部历史用户导入一次性导入到拉链表中。目前的ods_user_info表的第一个分区，即2020-06-14分区中就是全部的历史用户，故将该分区数据进行一定处理后导入拉链表的9999-99-99分区即可。
②每日装载
3.维表和事实表
(1)维表层（Dimension）
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。——一般不分区低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万——一般dt分区维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，地域维度表，维度表是事实表的一个分析角度。维表范围很宽；具有多个属性，列比较多跟事实表相比，行数相对较少；内容相对固定：编码表
DIM_ 主题域 _ 描述 _ 分表规则
其中的pub与具体业务无关，各个业务部都可以共用公共区域维表dim_pub_area
维度表包含了业务过程记录的业务过程度量的上下文和环境。维度表都包含单一的主键列，维度表设计的核心是确定维度字段，维度字段是查询约束条件(where)、分组条件(group)、排序(order)，与报表标签的基本来源。
维度表一般为单一主键，在ER模型中，实体为客观存在的事务，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。维度建模的核心是数据可以抽象为事实和维度，维度即观察事物的角度，事实某一粒度下的度量词，维度一定是针对实体而言的。
维度表通常比较宽，包含多个属性、是扁平的规范表，实际应用中包含几十个或者上百个属性的维度并不少见，所以维度表应该包括一些有意义的描述，方便下游使用。维度表的维度属性，应该尽可能的丰富，所以维度表中，经常出现一些反范式的设计，把其他维度属性并到主维度属性中，达到易用少关联的效果。
维度表的设计包括维度选择，主维表的确定，梳理关联维度，定义维度属性的过程。
(2)事实表——不会作为单独一层(避免过多分区)
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。事实数据表可能包含业务销售数据，事实数据表通常 包含大量的行，事实数据表的主要特点是包含数字数据(事实)，并且这些数字信息可以汇总以提供有关单位作为历史数据，事实表不应该包含描述信息，也不应该包含除数字度量字段及与维度表中对应项相关索引字段意外的任何数据，事实表示的是业务事件的度量值(可统计次数、个数、金额)。
特性
一个事实数据表都要和一个或多个维度表相关联，事实表中的每行数据代表一个业务时间(下单、支付、退款等)。每一个事实表的行包括:具有可加性的数值型度量值、与维表相连接的外键，通常具有两个和两个以上的外键。查询和请求的主要目标是基于事实表开展计算和聚集操作事实表可以存在空值度量外键不可空，这样就引用了不存在的实体非常大；内容相对少，列少；经常变化分类
事务性事实表:以每个事物或事件为单位，一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新周期性快照事实表：不会保留所有数据，只保留固定时间间隔的数据，例如每天或每月的销售额累积性快照事实表:累计快照事实表用于根据业务事实变化。例如数据仓库需要累计或存储订单从下单开始到最后签收的各个业务阶段时间点数据来根据订单的生命周期进展情况，此时记录需要不断被更新(3)临时表TMP
每一层的计算都会有很多临时表，专设一个DWTMP层来存储我们数据仓库的临时表.
(4)退化维度
退化维度，就是那些看起来像是事实表的一个维度关键字，但实际上并没有对应的维度表，就是维度属性存储到事实表中，这种存储到事实表中的维度列被称为退化维度。与其他存储在维表中的维度一样，退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。
那么究竟怎么定义退化维度呢？比如说订单id，这种量级很大的维度，没必要用一张维度表来进行存储，而我们进行数据查询或者数据过滤的时候又非常需要，所以这种就冗余在事实表里面，这种就叫退化维度，citycode这种我们也会冗余在事实表里面，但是它有对应的维度表，所以它不是退化维度。
4.数仓常见术语
(1)主题
在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。例如“销售分析”就是一个分析领域，因此这个数据仓库应用的主题就是“销售分析”。
(2)ETL
ETL ：Extract-Transform-Load，用于描述将数据从来源端经过抽取、转换、加载到目的端的过程。
(3)实体、维度
实体是指依附的主体，就是我们分析的一个对象，比如我们分析商品的销售情况，如华为手机近半年的销售量是多少，那华为手机就是一个实体；我们分析用户的活跃度，用户就是一个实体。当然实体也可以现实中不存在的，比如虚拟的业务对象，活动，会员等都可看做一个实体。
实体的存在是为了业务分析，作为分析的一个筛选的维度，拥有描述自己的属性，本身具有可分析的价值。
维度就是看待问题的角度，分析业务数据，从什么角度分析，就建立什么样的维度。所以维度就是要对数据进行分析时所用的一个量，比如你要分析产品销售情况，你可以选择按商品类别来进行分析，这就构成一个维度，把所有商品类别集合在一起，就构成了维度表。
(4)度量
度量是业务流程节点上的一个数值。比如销量，价格，成本等等。事实表中的度量可分为三类：完全可加，半可加，不可加。
完全可加的度量是最灵活，最有用的，比如说销量，销售额等，可进行任意维度汇总；半可加的度量可以对某些维度汇总，但不能对所有维度汇总，差额是常见的半可加度量，它除了时间维度外，可以跨所有维度进行加法操作；还有一种是完全不可加的，例如：比率。对于这类非可加度量，一种好的方法是，尽可能存储非可加度量的完全可加分量，并在计算出最终的非可加事实前，将这些分量汇总到最终的结果集中。(5)粒度
粒度就是业务流程中对度量的单位，比如商品是按件记录度量，还是按批记录度量。在数仓建设中，我们说这是用户粒度的事实表，那么表中每行数据都是一个用户，无重复用户；例如还有销售粒度的表，那么表中每行都是一条销售记录。
选择合适的粒度级别是数据仓库建设好坏的重要关键内容，在设计数据粒度时，通常需重点考虑以下因素：
要接受的分析类型、可接受的数据最低粒度和能存储的数据量；粒度的层次定义越高，就越不能在该仓库中进行更细致的分析；如果存储资源有一定的限制，就只能采用较高的数据粒度划分；数据粒度划分策略一定要保证：数据的粒度确实能够满足用户的决策分析需要，这是数据粒度划分策略中最重要的一个准则。(6)指标
口径就是取数逻辑（如何取数的），比如要取的数是10岁以下儿童中男孩的平均身高，这就是统计的口径。指标是口径的衡量值，也就是最后的结果。比如最近七天的订单量，一个促销活动的购买转化率等。
一个指标具体到计算实施，主要有以下几部分组成：
指标加工逻辑，比如count ,sum, avg维度，比如按部门、地域进行指标统计，对应sql中的group by业务限定/修饰词，比如以不同的支付渠道来算对应的指标，微信支付的订单退款率，支付宝支付的订单退款率 。对应sql中的where。除此之外，指标本身还可以衍生、派生出更多的指标，基于这些特点，可以将指标进行分类：
原子指标：基本业务事实，没有业务限定、没有维度。比如订单表中的订单量、订单总金额都算原子指标；业务方更关心的指标，是有实际业务含义，可以直接取数据的指标。比如店铺近1天订单支付金额就是一个派生指标，会被直接在产品上展示给商家看。但是这个指标却不能直接从数仓的统一中间层里取数（因为没有现成的事实字段，数仓提供的一般都是大宽表）。需要有一个桥梁连接数仓中间层和业务方的指标需求，于是便有了派生指标派生指标：维度+修饰词+原子指标。店铺近1天订单支付金额中店铺是维度，近1天是一个时间类型的修饰词，支付金额是一个原子指标；维度：观察各项指标的角度；修饰词：维度的一个或某些值，比如维度性别下，男和女就是2种修饰词。衍生指标：比如某一个促销活动的转化率就是衍生指标，因为需要促销投放人数指标和促销订单数指标进行计算得出。标签是人为设定的、根据业务场景需求，对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果，如网红、白富美、萝莉。对于有歧义的标签，我们内部可进行标签区分，比如：苹果，我们可以定义苹果指的是水果，苹果手机才指的是手机。
(7)自然键永久键
由现实中已经存在的属性组成的键，它在业务概念中是唯一的，并具有一定的业务含义，比如商品ID，员工ID。
以数仓角度看，来自于业务系统的标识符就是自然键，比如业务库中员工的编号。保持永久性不会发生变化。有时也被叫做超自然持久键。比如身份证号属于持久键。代理键就是不具有业务含义的键。代理键就是简单的以按照顺序序列生产的整数表示。产品行的第1行代理键为1，则下一行的代理键为2，如此进行。代理键的作用仅仅是连接维度表和事实表。(8)跨表钻取
跨表钻取意思是当每个查询的行头都包含相同的一致性属性时，使不同的查询能够针对两个或更多的事实表进行查询
钻取可以改变维的层次，变换分析的粒度。它包括上钻/下钻：
上钻（roll-up）：上卷是沿着维的层次向上聚集汇总数据。例如，对产品销售数据，沿着时间维上卷，可以求出所有产品在所有地区每月（或季度或年或全部）的销售额。下钻（drill-down）：下钻是上钻的逆操作，它是沿着维的层次向下，查看更详细的数据。5.维度建模
(1)维度建模三种模式
一般采用星型模型，呈现的状态一般为星座模型。选择业务过程→声明粒度→确认维度→确认事实
星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布；
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
(2)维度建模步骤
注意：如果在 DWD 层粒度就是每周或者每月，那么后续就没有办法统计细粒度的指标了。建议采用最小粒度。
确定维度：维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。例如：时间维度、用户维度、地区维度等常见维度。确定事实:此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。在 DWD 层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。根据维度建模中的星型模型思想，将维度进行退化。例如：地区表和省份表退化为地区维度表，商品表、品类表、spu 表、商品三级分类、商品二级分类、商品一级分类表退化为商品维度表，活动信息表和活动规则表退化为活动维度表。
6.Lambda架构
来源：正正杂说
