尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

积累111

积累111 星型模型、雪花模型这两种模型其实描述的是事实表和维度表之间的拆分关系这两种模型从形状上来看都是从中心点往四周辐射中心点就代表事实表向四周辐射的点就代表维度表星型模型只辐射一次雪花模型在辐射完一次后会再向外辐射也就是在维度表中再次拆分出新的维度数仓建模说到根上就是对事实表和维度表的设计而事实表和维度表从数据根源上来看呢其实只有一种数据就是事实数据。而这个事实数据在进入数据仓库后为了满足后续数据在存储效率表设计规范满足数据库范式原则等情况下就需要对表进行各种拆分在拆分过程中有一个核心原则就是对数据中有着共性信息的提取而这个对共性信息提取的过程也叫维度拆分过程在拆分过程中会涉及到拆分粒度的思考如果你将其中的共性信息提取出来后不再有更进一步的拆分行为此时的建模模型就是星型模型如果将提取出来的共性信息再次拆分就形成了雪花模型例子雪花模型更符合数据库的范式要求但由于数据的拆分粒度更细在现实的使用过程中的多表关联从而导致数据的分析效率变低星型模型虽然维度表可能存在一定的数据冗余但数据分析的效率会更高所以一般推荐使用星型模型维度建模与三范式建模的区别数仓是维度建模三范式建模更适合mysql如何理解拉链表什么场景下需要用拉链表举例对于一个网站的注册用户来说有一张专门用来记录用户注册信息的表当其中某一行的某一列发生的改变的时候一般是有两种数据同步方案第一种是全量同步将修改后的表的最新全量数据同步给数据仓库这样数仓就可以一直保留最新的用户注册信息第二种是增量同步就是业务系统只同步新增和变化的数据到数据仓库然后数据仓库统一用append的方式来记录新增和修改的数据但如果我们想知道用户对信息的整个修改历史记录首先第一种全量同步是做不到的因为它没有保留任何历史数据的痕迹第二种用append的方式虽然是记录了修改的行为但是没有办法直接用条件过滤将这部分有过修改历史的用户筛选出来只能用全表扫描的数据分析方式分析代价比较高。综上就想到使用拉链表开链、闭链开链:就是一条数据生成的时候还没有对其update所呈现的最初的样子代表起数据是有效的闭链就是对一条数据进行状态修改之后所呈现的样子代表数据已经失效为了表示数据是开链还是闭链我们在拉链表中引入两个出业务字段之外的特殊字段Start_time , end_time开链end_time时间为无穷大闭链end_time时间为小于无穷大拉链表中可以用下语句查出所有的有效记录以及用下面这个语句来查询出一个月前今天的历史快照记录对于拉链表来说比较适合这种数据规模较大且存在少量数据更新同时业务又需要保留更新记录以及查看某个历史时间快照信息的场景主要解决状态变更记录总线矩阵指以一致性维度为列以业务过程为行构建业务的数据矩阵通过标记表示该维度与业务过程的相关性为什么说宽表是一把双刃剑优点宽表的字段要比普通的表有更多字段这就意味着包含着更多的数据信息而更多的数据信息就意味着能够提供更完整的业务价值同时宽表的实现比普通表更快因为普通表在数仓建设时需要考虑到维度拆分、满足数据库范式原则等。对于同一个业务需求来说宽表直接就可以提供满足需求的所有维度而普通表需要join操作join又涉及到shuffle操作shuffle会使得整个数据分析变得缓慢缺点因为宽表将所有的维度都揉在了一起这样就会导致其中一些变化缓慢的维度信息出现大量数据重复从而占据过多的存储空间(每个历史分区里面的数据大部分都是一样的)。而且宽表很多时候只是面向某一个业务需要如果业务需要稍微一变化可能就得重新涉及一张新的宽表这就导致单张表的灵活性很低使用场景很窄实际生产中的缺点因为宽表柔和的比较多有些不重要的字段可能产出时间较晚会影响宽表产出宽表上游表较多其中一个出错或产出数据有问题宽表就不能正常产出什么样的表算宽表什么场景下更适合用宽表所谓的宽还是不宽它应该是有一个相对的概念如果在业务过程中这张表还可以进一步进行维度拆分的话那就可以认为是宽表对于数仓建模来说为了让整个建模过程更加的规范表之间能够最大程度的得到复用在后续应对各自不同的业务需求时让开发的效率能够更高那么在数据仓库的中间层设计中我们就要尽可能让表的设计去贴近范式要求让表与表之间达到解耦。但对ads层来说为了尽可能的满足某一个主题域的更多需要可以考虑把这一层的表尽可能的设计为宽表因为这样以来对于同一个主题域相关所有的分析和查询要用到的字段都可以包含在这个宽表中对于前端的业务查询分析来说可以不用跨表就能够实现对该主题域的所有的数据提取颗粒度:在数仓中表的粒度表示表中数据的详细程度。表的粒度越细表中的数据就越详细表的粒度越粗表中的数据就越汇总。例如有一个销售订单表其中包含每个订单的详细信息如订单号、客户ID、商品ID、订单日期、订单数量和订单金额等。这个表的粒度就比较细。如果我们将销售订单表按照客户ID进行汇总统计每个客户的总订单数量和总订单金额那么这个汇总表的粒度就比较粗。在数仓设计中我们需要根据业务需求和分析场景来选择合适的表粒度。通常情况下我们会构建多个不同粒度的表以满足不同层次的业务需求和分析需求。我的理解是一张表的颗粒度有点像主键的感觉其他字段都是围绕这个粒度字段的
返回列表