简约大气网站,网站建设捌金手指花总三十,做的网站访问不了,建设银行网站半天进不去文章目录 一、数仓概述1、数据仓库概念1.1 概述1.2 数据仓库与数据库的区别1.3 技术选型和架构 2、数仓常见名词2.1 实体2.2 维度2.3 度量2.4 粒度2.5 口径2.6 指标2.7 标签2.8 自然键/持久键/代理键2.9 退化维度2.10 下钻/上卷2.11 数据集市 3、数仓名词之间关系3.1 实体表事实表维度表之间的关系3.2 指标与标签的区别3.3 维度和指标区别与联系3.4 自然键与代理键在数仓的使用区别3.5 数据集市和数据仓库的关系 二、离线数仓相关核心概念1、数据仓库分层1.1 概述与原则1.2 数据源层ODSOperational Data Store1.3 数据仓库层DWData Warehouse1.4 维表层DIMDimension1.5 数据应用层ADSApplication Data Services 2、数仓建模方法概述2.1 范式建模法Third Normal Form3NF2.2 维度建模法Dimensional Modeling2.3 实体建模法Entity Modeling 3、维度建模详解3.1 概述3.2 事实表详解3.3 维度表3.5 维度建模三种模式3.6 维度建模过程 4、维度建模理论之维度表4.1 维度表设计步骤4.2 维度变化4.3 多值维度4.4 多值属性 5、数据仓库设计5.1 数据仓库构建流程5.2 数据调研5.3 明确数据域5.4 构建业务总线矩阵5.5 明确统计指标5.6 维度模型设计5.7 汇总模型设计 一、数仓概述 1、数据仓库概念 1.1 概述 通常数据仓库的数据来自各个业务应用系统。业务系统中的数据形式多种多样可能是 Oracle、MySQL、SQL Server等关系数据库里的结构化数据可能是文本、CSV等平面文件或Word、Excel文档中的数据还可能是HTML、XML等自描述的半结构化数据。这些业务数据经过一系列的数据抽取、转换、清洗最终以一种统一的格式装载进数据仓库。数据仓库里的数据作为分析用的数据源提供给后面的即席查询、 分析系统、数据集市、报表系统、数据挖掘系统等。 1.2 数据仓库与数据库的区别 数据仓库在设计是有意引入冗余依照分析需求分析维度、分析指标进行设计数据库是为捕获数据而设计数据仓库是为分析数据而设计 数据仓库是在数据库已经大量存在的情况下为了进一步挖掘数据资源、为了决策需要而产生的它决不是所谓的大型数据库 1.3 技术选型和架构 离线和实时数仓一般架构 2、数仓常见名词 2.1 实体 实体是指依附的主体就是我们分析的一个对象比如我们分析商品的销售情况如华为手机近半年的销售量是多少那华为手机就是一个实体我们分析用户的活跃度用户就是一个实体。当然实体也可以现实中不存在的比如虚拟的业务对象活动会员等都可看做一个实体。 实体的存在是为了业务分析作为分析的一个筛选的维度拥有描述自己的属性本身具有可分析的价值 2.2 维度 维度就是看待问题的角度分析业务数据从什么角度分析就建立什么样的维度。所以维度就是要对数据进行分析时所用的一个量比如你要分析产品销售情况你可以选择按商品类别来进行分析这就构成一个维度把所有商品类别集合在一起就构成了维度表 2.3 度量 度量是业务流程节点上的一个数值。比如销量价格成本等等。事实表中的度量可分为三类完全可加半可加不可加。 完全可加的度量是最灵活最有用的比如说销量销售额等可进行任意维度汇总半可加的度量可以对某些维度汇总但不能对所有维度汇总差额是常见的半可加度量它除了时间维度外可以跨所有维度进行加法操作还有一种是完全不可加的例如比率。对于这类非可加度量一种好的方法是尽可能存储非可加度量的完全可加分量并在计算出最终的非可加事实前将这些分量汇总到最终的结果集中。 2.4 粒度 粒度就是业务流程中对度量的单位比如商品是按件记录度量还是按批记录度量。在数仓建设中我们说这是用户粒度的事实表那么表中每行数据都是一个用户无重复用户例如还有销售粒度的表那么表中每行都是一条销售记录。 选择合适的粒度级别是数据仓库建设好坏的重要关键内容在设计数据粒度时通常需重点考虑以下因素 要接受的分析类型、可接受的数据最低粒度和能存储的数据量粒度的层次定义越高就越不能在该仓库中进行更细致的分析如果存储资源有一定的限制就只能采用较高的数据粒度划分数据粒度划分策略一定要保证数据的粒度确实能够满足用户的决策分析需要这是数据粒度划分策略中最重要的一个准则。 2.5 口径 口径就是取数逻辑如何取数的比如要取的数是10岁以下儿童中男孩的平均身高这就是统计的口径。 2.6 指标 指标是口径的衡量值也就是最后的结果。比如最近七天的订单量一个促销活动的购买转化率等。一个指标具体到计算实施主要有以下几部分组成 指标加工逻辑比如count ,sum, avg维度比如按部门、地域进行指标统计对应sql中的group by业务限定/修饰词比如以不同的支付渠道来算对应的指标微信支付的订单退款率支付宝支付的订单退款率 。对应sql中的where。 除此之外指标本身还可以衍生、派生出更多的指标基于这些特点可以将指标进行分类 原子指标基本业务事实没有业务限定、没有维度。比如订单表中的订单量、订单总金额都算原子指标 业务方更关心的指标是有实际业务含义可以直接取数据的指标。比如店铺近1天订单支付金额就是一个派生指标会被直接在产品上展示给商家看。 但是这个指标却不能直接从数仓的统一中间层里取数因为没有现成的事实字段数仓提供的一般都是大宽表。需要有一个桥梁连接数仓中间层和业务方的指标需求于是便有了派生指标 派生指标维度修饰词原子指标。 店铺近1天订单支付金额中店铺是维度近1天是一个时间类型的修饰词支付金额是一个原子指标 维度观察各项指标的角度 修饰词维度的一个或某些值比如维度性别下男和女就是2种修饰词。 衍生指标比如某一个促销活动的转化率就是衍生指标因为需要促销投放人数指标和促销订单数指标进行计算得出 2.7 标签 标签是人为设定的、根据业务场景需求对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果如网红、白富美、萝莉。对于有歧义的标签我们内部可进行标签区分比如苹果我们可以定义苹果指的是水果苹果手机才指的是手机 2.8 自然键/持久键/代理键 自然键由现实中已经存在的属性组成的键它在业务概念中是唯一的并具有一定的业务含义比如商品ID员工ID。以数仓角度看来自于业务系统的标识符就是自然键比如业务库中员工的编号持久键保持永久性不会发生变化。有时也被叫做超自然持久键。比如身份证号属于持久键 自然键和持久键区别比如说公司员工离职之后又重新入职他的自然键也就是员工编号发生了变化但是他的持久键身份证号是不变的。 代理键就是不具有业务含义的键。代理键有许多其他的称呼无意义键、整数键、非自然键、人工键、合成键等。代理键就是简单的以按照顺序序列生产的整数表示。产品行的第1行代理键为1则下一行的代理键为2如此进行。代理键的作用仅仅是连接维度表和事实表。 2.9 退化维度 退化维度就是那些看起来像是事实表的一个维度关键字但实际上并没有对应的维度表就是维度属性存储到事实表中这种存储到事实表中的维度列被称为退化维度。与其他存储在维表中的维度一样退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。 那么究竟怎么定义退化维度呢比如说订单id这种量级很大的维度没必要用一张维度表来进行存储而我们进行数据查询或者数据过滤的时候又非常需要所以这种就冗余在事实表里面这种就叫退化维度citycode这种我们也会冗余在事实表里面但是它有对应的维度表所以它不是退化维度 2.10 下钻/上卷 下钻这是在数据分析中常见的概念下钻可以理解成增加维的层次从而可以由粗粒度到细粒度来观察数据比如对产品销售情况分析时可以沿着时间维从年到月到日更细粒度的观察数据。从年的维度可以下钻到月的维度、日的维度等 知道了下钻上卷就容易理解了它俩是相逆的操作所以上卷可以理解为删掉维的某些层由细粒度到粗粒度观察数据的操作或沿着维的层次向上聚合汇总数据。 2.11 数据集市 数据集市Data Mart也叫数据市场数据集市就是满足特定的部门或者用户的需求按照多维的方式进行存储包括定义维度、需要计算的指标、维度的层次等生成面向决策分析需求的数据立方体。其实就是从数据仓库中抽取出来的一个小合集。 3、数仓名词之间关系 3.1 实体表事实表维度表之间的关系 维度表维度表可以看成是用户用来分析一个事实的窗口它里面的数据应该是对事实的各个方面描述比如时间维度表地域维度表维度表是事实表的一个分析角度事实表事实表其实就是通过各种维度和一些指标值的组合来确定一个事实的比如通过时间维度地域组织维度指标值可以去确定在某时某地的一些指标值怎么样的事实。事实表的每一条数据都是几条维度表的数据和指标值交汇而得到的。实体表实体表就是一个实际对象的表实体表放的数据一定是一条条客观存在的事物数据比如说各种商品它就是客观存在的所以可以将其设计一个实体表。实时表只描述各个事物并不存在具体的事实所以也有人称实体表是无事实的事实表。 举个例子比如说手机商场中有苹果手机华为手机等各品牌各型号的手机这些数据可以组成一个手机实体表但是表中没有可度量的数据。某天苹果手机卖了15台华为手机卖了20台这些手机销售数据属于事实组成一个事实表。这样就可以使用日期维度表和地域维度表对这个事实表进行各种维度分析。 3.2 指标与标签的区别 概念不同 指标是用来定义、评价和描述特定事物的一种标准或方式。比如新增用户数、累计用户数、用户活跃率等是衡量用户发展情况的指标 标签是人为设定的、根据业务场景需求对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果如网红、白富美、萝莉。 构成不同 指标名称是对事物质与量两方面特点的命名指标取值是指标在具体时间、地域、条件下的数量表现如人的体重指标名称是体重指标的取值就是120斤 标签名称通常都是形容词或形容词名词的结构标签一般是不可量化的通常是孤立的除了基础类标签通过一定算法加工出来的标签一般都没有单位和量纲。如将超过200斤的称为大胖子。 分类不同 对指标的分类按照指标计算逻辑可以将指标分为原子指标、派生指标、衍生指标三种类型按照对事件描述内容的不同分为过程性指标和结果性指标 对标签的分类按照标签的变化性分为静态标签和动态标签按照标签的指代和评估指标的不同可分为定性标签和定量标签 指标最擅长的应用是监测、分析、评价和建模。标签最擅长的应用是标注、刻画、分类和特征提取。特别需要指出的是由于对结果的标注也是一种标签所以在自然语言处理和机器学习相关的算法应用场景下标签对于监督式学习有重要价值只是单纯的指标难以做到的。而指标在任务分配、绩效管理等领域的作用也是标签无法做到的。 3.3 维度和指标区别与联系 维度就是数据的观察角度即从哪个角度去分析问题看待问题。指标就是从维度的基础上去衡算这个结果的值。 维度一般是一个离散的值比如时间维度上每一个独立的日期或地域因此统计时可以把维度相同记录的聚合在一起应用聚合函数做累加、均值、最大值、最小值等聚合计算。指标就是被聚合的通计算即聚合运算的结果一般是一个连续的值 3.4 自然键与代理键在数仓的使用区别 数仓工具箱中说维度表的唯一主键应该是代理键而不应该是自然键。有时建模人员不愿意放弃使用自然键因为他们希望与操作型代码查询事实表而不希望与维度表做连接操作。然而应该避免使用包含业务含义的多维键因为不管我们做出任何假设最终都可能变得无效因为我们控制不了业务库的变动。 所以数据仓库中维度表与事实表的每个连接应该基于无实际含义的整数代理键。避免使用自然键作为维度表的主键。 3.5 数据集市和数据仓库的关系 数据集市是企业级数据仓库的一个子集他主要面向部门级业务并且只面向某个特定的主题。为了解决灵活性和性能之间的矛盾数据集市就是数据仓库体系结构中增加的一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据从而满足用户对性能的需求。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。 数据集市和数据仓库的主要区别数据仓库是企业级的能为整个企业各个部门的运行提供决策支持手段而数据集市则是一种微型的数据仓库,它通常有更少的数据,更少的主题区域,以及更少的历史数据,因此是部门级的一般只能为某个局部范围内的管理人员服务因此也称之为部门级数据仓库。 二、离线数仓相关核心概念 1、数据仓库分层 1.1 概述与原则 为便于数据分析要屏蔽底层复杂业务简单、完整、集成的将数据暴露给分析层底层业务变动与上层需求变动对模型冲击最小化业务系统变化影响削弱在基础数据层结合自上而下的建设方法削弱需求变动对模型的影响高内聚松耦合即主题之内或各个完整意义的系统内数据的高内聚主题之间或各个完整意义的系统间数据的松耦合构建仓库基础数据层使底层业务数据整合工作与上层应用开发工作相隔离为仓库大规模开发奠定基础 仓库层次更加清晰对外暴露数据更加统一 1.2 数据源层ODSOperational Data Store ODS 层是最接近数据源中数据的一层为了考虑后续可能需要追溯数据问题因此对于这一层就不建议做过多的数据清洗工作原封不动地接入原始数据即可至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做 1.3 数据仓库层DWData Warehouse 数据仓库层是我们在做数据仓库时要核心设计的一层在这里从 ODS 层中获得的数据按照主题建立各种数据模型。DW 层又细分为 DWDData Warehouse Detail层、DWMData WareHouse Middle层和 DWSData WareHouse Servce 层 数据明细层DWDData Warehouse Detail 该层一般保持和 ODS 层一样的数据粒度并且提供一定的数据质量保证。DWD 层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。同时为了提高数据明细层的易用性该层会采用一些维度退化手法将维度退化至事实表中减少事实表和维表的关联。另外在该层也会做一部分的数据聚合将相同主题的数据汇集到一张表中提高数据的可用性 数据中间层DWMData WareHouse Middle 该层会在 DWD 层的数据基础上数据做轻度的聚合操作生成一系列的中间表提升公共指标的复用性减少重复加工。直观来讲就是对通用的核心维度进行聚合操作算出相应的统计指标。 在实际计算中如果直接从 DWD 或者 ODS 计算出宽表的统计指标会存在计算量太大并且维度太少的问题因此一般的做法是在 DWM 层先计算出多个小的中间表然后再拼接成一张 DWS 的宽表。由于宽和窄的界限不易界定也可以去掉 DWM 这一层只留 DWS 层将所有的数据再放在 DWS 亦可 数据服务层DWSData WareHouse Servce DWS 层为公共汇总层会进行轻度汇总粒度比明细数据稍粗基于 DWD 层上的基础数据整合汇总成分析某一个主题域的服务数据一般是宽表。DWS 层应覆盖 80% 的应用场景。又称数据集市或宽表。按照业务划分如主题域流量、订单、用户等生成字段比较多的宽表用于提供后续的业务查询OLAP 分析数据分发等。 一般来讲该层的数据表会相对比较少一张表会涵盖比较多的业务内容由于其字段较多因此一般也会称该层的表为宽表 1.4 维表层DIMDimension 如果维表过多也可针对维表设计单独一层维表层主要包含两部分数据 高基数维度数据一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。 低基数维度数据一般是配置表比如枚举值对应的中文含义或者日期维表。 数据量可能是个位数或者几千几万 1.5 数据应用层ADSApplication Data Services 主要是提供给数据产品和数据分析使用的数据一般会存放在 ES、 PostgreSql、Redis 等系统中供线上系统使用也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据一般就放在这里。 2、数仓建模方法概述 2.1 范式建模法Third Normal Form3NF 范式建模法其实是我们在构建数据模型常用的一个方法该方法的主要由 Inmon 所提倡主要解决关系型数据库的数据存储利用的一种技术层面上的方法。目前我们在关系型数据库中的建模方法大部分采用的是三范式建模法。 范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则而在关系型数据库中这种规则就是范式这一过程也被称为规范化。目前关系数据库有六种范式第一范式1NF、第二范式2NF、第三范式3NF、Boyce-Codd范式BCNF、第四范式4NF和第五范式5NF。在数据仓库的模型设计中一般采用第三范式。一个符合第三范式的关系必须具有以下三个条件 : 每个属性值唯一不具有多义性 ;每个非主属性必须完全依赖于整个主键而非主键的一部分 ;每个非主属性不能依赖于其他关系中的属性因为这样的话这种属性应该归到其他关系中去。 2.2 维度建模法Dimensional Modeling 维度模型是数据仓库领域另一位大师Ralph Kimall所倡导他的《数据仓库工具箱》是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型构建的数据模型为分析需求服务因此它重点解决用户如何更快速完成分析需求同时还有较好的大规模复杂查询的响应性能。 典型的代表是我们比较熟知的星形模型Star-schema以及在一些特殊场景下适用的雪花模型Snow-schema。维度建模中比较重要的概念就是 事实表Fact table和维度表Dimension table。其最简单的描述就是按照事实表、维度表来构建数据仓库、数据集市。 2.3 实体建模法Entity Modeling 实体建模法并不是数据仓库建模中常见的一个方法它来源于哲学的一个流派。从哲学的意义上说客观世界应该是可以细分的客观世界应该可以分成由一个个实体以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法将整个业务也可以划分成一个个的实体而每个实体之间的关系以及针对这些关系的说明就是我们数据建模需要做的工作。 虽然实体法粗看起来好像有一些抽象其实理解起来很容易。即我们可以将任何一个业务过程划分成 3 个部分实体事件说明 3、维度建模详解 3.1 概述 维度建模分为两种表事实表和维度表 事实表必然存在的一些数据像采集的日志文件订单表都可以作为事实表 。 特征是一堆主键的集合每个主键对应维度表中的一条记录客观存在的根据主题确定出需要使用的数据 维度表维度就是所分析的数据的一个量维度表就是以合适的角度来创建的表分析问题的一个角度时间、地域、终端、用户等角度 3.2 事实表详解 发生在现实世界中的操作型事件其所产生的可度量数值存储在事实表中。从最低的粒度级别来看事实表行对应一个度量事件反之亦然。事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实 图中的订单表就是一个事实表你可以理解他就是在现实中发生的一次操作型事件我们每完成一个订单就会在订单中增加一条记录。 事实表的特征表里没有存放实际的内容他是一堆主键的集合这些ID分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键可与维度表关联。事实表的度量通常是数值类型且记录数会不断增加表数据规模迅速增长 明细表宽表 事实表的数据中有些属性共同组成了一个字段糅合在一起比如年月日时分秒构成了时间,当需要根据某一属性进行分组统计的时候需要截取拼接之类的操作效率极低。为了分析方便可以事实表中的一个字段切割提取多个属性出来构成新的字段因为字段变多了所以称为宽表原来的成为窄表又因为宽表的信息更加清晰明细所以也可以称之为明细表 事实表种类分为六类 事务事实表 表中的一行对应空间或时间上某点的度量事件。就是一行数据中必须有度量字段什么是度量就是指标比如说销售金额销售数量等这些可加的或者半可加就是度量值。另一点就是事务事实表都包含一个与维度表关联的外键。并且度量值必须和事务粒度保持一致 周期快照事实表 顾名思义周期事实表就是每行都带有时间值字段代表周期通常时间值都是标准周期如某一天某周某月等。粒度是周期而不是个体的事务也就是说一个周期快照事实表中数据可以是多个事实但是它们都属于某个周期内 累计快照事实表 周期快照事实表是单个周期内数据而累计快照事实表是由多个周期数据组成每行汇总了过程开始到结束之间的度量。每行数据相当于管道或工作流有事件的起点过程终点并且每个关键步骤都包含日期字段。如订单数据累计快照事实表的一行就是一个订单当订单产生时插入一行当订单发生变化时这行就被修改 无事实的事实表 我们以上讨论的事实表度量都是数字化的当然实际应用中绝大多数都是数字化的度量但是也可能会有少量的没有数字化的值但是还很有价值的字段无事实的事实表就是为这种数据准备的利用这种事实表可以分析发生了什么。 聚集事实表 聚集就是对原子粒度的数据进行简单的聚合操作目的就是为了提高查询性能。如我们需求是查询全国所有门店的总销售额我们原子粒度的事实表中每行是每个分店每个商品的销售额聚集事实表就可以先聚合每个分店的总销售额这样汇总所有门店的销售额时计算的数据量就会小很多。 合并事实表 这种事实表遵循一个原则就是相同粒度数据可以来自多个过程但是只要它们属于相同粒度就可以合并为一个事实表这类事实表特别适合经常需要共同分析的多过程度量 3.3 维度表 每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键当然维度表行的描述环境应与事实表行完全对应。维度表通常比较宽是扁平型非规范表包含大量的低粒度的文本属性。维度表示你要对数据进行分析时所用的一个量比如你要分析产品销售情况 你可以选择按类别来进行分析或按区域来分析。每个类别就构成一个维度。上图中的用户表、商家表、时间表这些都属于维度表这些表都有一个唯一的主键然后在表中存放了详细的数据信息。 总的说来在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析以查询为主不涉及数据更新操作。事实表的设计是以能够正确记录历史信息为准则维度表的设计是以能够以合适的角度来聚合主题内容为准则。 维度表结构 维度表谨记一条原则包含单一主键列但有时因业务复杂也可能出现联合主键请尽量避免如果无法避免也要确保必须是单一的这很重要如果维表主键不是单一和事实表关联时会出现数据发散导致最后结果可能出现错误。维度表通常比较宽包含大量的低粒度的文本属性。 跨表钻取 跨表钻取意思是当每个查询的行头都包含相同的一致性属性时使不同的查询能够针对两个或更多的事实表进行查询钻取可以改变维的层次变换分析的粒度。它包括上钻/下钻 上钻roll-up上卷是沿着维的层次向上聚集汇总数据。例如对产品销售数据沿着时间维上卷可以求出所有产品在所有地区每月或季度或年或全部的销售额。 下钻drill-down下钻是上钻的逆操作它是沿着维的层次向下查看更详细的数据。 退化维度 退化维度就是将维度退回到事实表中。因为有时维度除了主键没有其他内容虽然也是合法维度键但是一般都会退回到事实表中减少关联次数提高查询性能 多层次维度 多数维度包含不止一个自然层次如日期维度可以从天的层次到周到月到年的层次。所以在有些情况下在同一维度中存在不同的层次。 维度表空值属性 当给定维度行没有被全部填充时或者当存在属性没有被应用到所有维度行时将产生空值维度属性。上述两种情况推荐采用描述性字符串代替空值如使用 unknown 或 not applicable 替换空值。 日历日期维度 在日期维度表中主键的设置不要使用顺序生成的id来表示可以使用更有意义的数据表示比如将年月日合并起来表示即YYYYMMDD或者更加详细的精度 3.5 维度建模三种模式 规范化是指使用一系列范式设计数据库的过程其目的是减少数据冗余增强数据的一致性。通常情况下规范化之后一张表的字段会拆分到多张表。 反规范化是指将多张表的数据冗余到一张表其目的是减少join操作提高查询性能。在设计维度表时如果对其进行规范化得到的维度模型称为雪花模型如果对其进行反规范化得到的模型称为星型模型 星型模式 星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心所有的维度表直接连接在事实表上像星星一样。 星形模式的维度建模由一个事实表和一组维表成且具有以下特点 a. 维表只和事实表关联维表之间没有关联 b. 每个维表主键为单列且该主键放置在事实表中作为两边连接的外键 c. 以事实表为核心维表围绕核心呈星形 雪花模式 雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的虽然这种模型相比星型更规范一些但是由于这种模型不太容易理解维护成本比较高而且性能方面需要关联多层维表性能也比星型模型要低。所以一般不是很常用 星座模式 星座模式是星型模式延伸而来星型模式是基于一张事实表的而星座模式是基于多张事实表的而且共享维度信息。 前面介绍的两种维度建模方法都是多维表对应单事实表但在很多时候维度空间内的事实表不止一个而一个维表也可能被多个事实表用到。在_业务发展后期绝大部分维度建模都采用的是星座模式_ 3.6 维度建模过程 1、选择业务过程 维度建模是紧贴业务的所以必须以业务为根基进行建模那么选择业务过程顾名思义就是在整个业务流程中选取我们需要建模的业务根据运营提供的需求及日后的易扩展性等进行选择业务。比如商城整个商城流程分为商家端用户端平台端运营需求是总订单量订单人数及用户的购买情况等我们选择业务过程就选择用户端的数据商家及平台端暂不考虑。业务选择非常重要因为后面所有的步骤都是基于此业务数据展开的。 2、声明粒度 先举个例子对于用户来说一个用户有一个身份证号一个户籍地址多个手机号多张银行卡那么与用户粒度相同的粒度属性有身份证粒度户籍地址粒度比用户粒度更细的粒度有手机号粒度银行卡粒度存在一对一的关系就是相同粒度。为什么要提相同粒度呢因为维度建模中要求我们在同一事实表中必须具有相同的粒度同一事实表中不要混用多种不同的粒度不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时强烈建议从关注原子粒度开始设计也就是从最细粒度开始因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的所以对于有明确需求的数据我们建立针对需求的上卷汇总粒度对需求不明朗的数据我们建立原子粒度。 3、确认维度 维度表是作为业务分析的入口和描述性标识所以也被称为数据仓库的“灵魂”。在一堆的数据中怎么确认哪些是维度属性呢如果该列是对具体值的描述是一个文本或常量某一约束和行标识的参与者此时该属性往往是维度属性数仓工具箱中告诉我们牢牢掌握事实表的粒度就能将所有可能存在的维度区分开并且要确保维度表中不能出现重复数据应使维度主键唯一 4、确认事实 事实表是用来度量的基本上都以数量值表示事实表中的每行对应一个度量每行中的数据是一个特定级别的细节数据称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量这种情况下该列往往是事实。 4、维度建模理论之维度表 4.1 维度表设计步骤 确定维度表 在设计事实表时已经确定了与每个事实表相关的维度理论上每个相关维度均需对应一张维度表。需要注意到可能存在多个事实表与同一个维度都相关的情况这种情况需保证维度的唯一性即只创建一张维度表。另外如果某些维度表的维度属性很少例如只有一个名称则可不创建该维度表而把该表的维度属性直接增加到与之相关的事实表中这个操作称为维度退化 确定主维表和相关维表 此处的主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_infospu_infobase_trademarkbase_category3base_category2base_category1等其中sku_info就称为商品维度的主维表其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。 确定维度属性 确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择也可通过进一步加工得到。确定维度属性时需要遵循以下要求 1尽可能生成丰富的维度属性。维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。 2尽量不使用编码而使用明确的文字说明一般可以编码和文字共存。 **3尽量沉淀出通用的维度属性。**有些维度属性的获取需要进行比较复杂的逻辑处理例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理可将这些维度属性沉淀到维度表中 4.2 维度变化 维度属性通常不是静态的而是会随时间变化的数据仓库的一个重要特点就是反映历史的变化所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态通常有以下两种做法分别是全量快照表和拉链表。 1全量快照表 离线数据仓库的计算周期通常为每天一次所以可以每天保存一份全量的维度数据。这种方式的优点和缺点都很明显。 优点是简单而有效开发和维护成本低且方便理解和使用。 缺点是浪费存储空间尤其是当数据的变化比例比较低时。 2拉链表 拉链表的意义就在于能够更加高效的保存维度信息的历史状态。拉链表记录每条信息的生命周期一旦一条记录的生命周期结束就重新开始一条新的记录并把当前日期放入生效开始日期。如果当前信息至今有效在生效结束日期中填入一个极大值如9999-12-31 )。 4.3 多值维度 如果事实表中一条记录在某个维度表中有多条记录与之对应称为多值维度。例如下单事实表中的一条记录为一个订单一个订单可能包含多个商品所会商品维度表中就可能有多条数据与之对应。针对这种情况通常采用以下两种方案解决。 第一种降低事实表的粒度例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。 第二种在事实表中采用多字段保存多个维度值每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。 建议尽量采用第一种方案解决多值维度问题。 4.4 多值属性 维表中的某个属性同时有多个值称之为“多值属性”例如商品维度的平台属性和销售属性每个商品均有多个属性值。针对这种情况通常有可以采用以下两种方案。 第一种将多值属性放到一个字段该字段内容为key1:value1key2:value2的形式例如一个手机商品的平台属性值为“品牌:华为系统:鸿蒙CPU:麒麟990”。 第二种将多值属性放到多个字段每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况 5、数据仓库设计 5.1 数据仓库构建流程 5.2 数据调研 业务调研的主要目标是熟悉业务流程、熟悉业务数据例如 分析需求时需要明确需求所需的业务过程及维度例如该需求所需的业务过程就是买家下单所需的维度有日期省份商品品类。做完业务分析和需求分析之后要保证每个需求都能找到与之对应的业务过程及维度。若现有数据无法满足需求则需要和业务方进行沟通例如某个页面需要新增某个行为的埋点 5.3 明确数据域 数据仓库模型设计除横向的分层外通常也需要根据业务情况进行纵向划分数据域。划分数据域的意义是便于数据的管理和应用。通常可以根据业务过程或者部门进行划分本项目根据业务过程进行划分需要注意的是一个业务过程只能属于一个数据域。下面是本数仓项目所需的所有业务过程及数据域划分详情 数据域业务过程交易域加购、下单、取消订单、支付成功、退单、退款成功流量域页面浏览、启动应用、动作、曝光、错误用户域注册、登录互动域收藏、评价工具域优惠券领取、优惠券使用下单、优惠券使用支付 5.4 构建业务总线矩阵 业务总线矩阵中包含维度模型所需的所有事实业务过程以及维度以及各业务过程与各维度的关系。矩阵的行是一个个业务过程矩阵的列是一个个的维度行列的交点表示业务过程与维度的关系 一个业务过程对应维度模型中一张事务型事实表一个维度则对应维度模型中的一张维度表。所以构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是总线矩阵中通常只包含事务型事实表另外两种类型的事实表需单独设计。按照事务型事实表的设计流程选择业务过程à声明粒度à确认维度à确认事实 5.5 明确统计指标 原子指标 原子指标基于某一业务过程的度量值是业务定义中不可再拆解的指标原子指标的核心功能就是对指标的聚合逻辑进行了定义。我们可以得出结论原子指标包含三要素分别是业务过程、度量值和聚合逻辑。 例如订单总额就是一个典型的原子指标其中的业务过程为用户下单、度量值为订单金额聚合逻辑为sum()求和。需要注意的是原子指标只是用来辅助定义指标一个概念通常不会对应有实际统计需求与之对应。 派生指标 衍生指标 衍生指标是在一个或多个派生指标的基础上通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求 当统计需求足够多时必然会出现部分统计需求对应的派生指标相同的情况。这种情况下我们就可以考虑将这些公共的派生指标保存下来这样做的主要目的就是减少重复计算提高数据的复用性。这些公共的派生指标统一保存在数据仓库的DWS层。因此DWS层设计就可以参考我们根据现有的统计需求整理出的派生指标 5.6 维度模型设计 维度模型的设计参照上述得到的业务总线矩阵即可。事实表存储在DWD层维度表存储在DIM层 5.7 汇总模型设计 汇总模型的设计参考上述整理出的指标体系主要是派生指标即可。汇总表与派生指标的对应关系是一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标